Windows Processes are Hanging

I could find out about the LabVIEW code next week. Could I use jls_v2_writer and the capture_jls_v2 with a JSv1? Not sure which files I would need to replace or which libraries specifically to install. If I have to use the JS220, I’ll have to swap it in to the CI station.

Yes, the JS110 works with JLS v2. The change is pretty easy:

pip3 install -U pyjls

Then at the top of your code, change from joulescope.data_recorder import DataRecorder to from joulescope import JlsWriter. Then down below:

device.open()
recorder = JlsWriter(device, filepath)
recorder.open()
items.append([device, recorder])
device.stream_process_register(recorder)

The Joulescope UI reads and displays JLS v2 already. It just does not record them. JLS v2 is a much better format, but we have not yet implemented recovery for files that are not correctly closed.

See JLS on GitHub for details.

I’ll give this a shot Monday morning. Have a great weekend!

1 Like

Made the changes to my python_datalogger.py file.

Keyword error

Hi @Nate - I just duplicated this issue. It works with the JS220, but not with the JS110’s info structure. I just updated joulescope to 1.0.13 with a fix. You should be able to upgrade and it should work:

pip3 install -U joulescope

Updated to 1.0.13

Embedded command hangs.

But the data does seem to be captured when I force close LabVIEW.

The command to the radio is not going through so while the datalog is captured, its not the expected signal.

So, from my perspective, the Joulescope JS220 seems to be working. What would cause the command to the radio not go through and for the LabVIEW program to not execute as expected? Can you snoop what is happening on this communication link? Does the LabVIEW command work when you are recording to JLS with the latest Joulescope UI (not the custom capture script)?

The LabVIEW command doesn’t work when the Joulescope UI is used. I can ask for some help creating a debug version of the LabVIEW executable to show more debug output.

Do you know of another way we can run the LabVIEW command using something else besides subprocess?

Hi @Nate - Thanks for trying it with the Joulescope UI. The problem is not with subprocess since running the LabVIEW program separate from both the capture script and Joulescope UI both show the same issue.

Here is my brainstorm list of potential problems, mostly related to timing in one way or another:

  1. Timing sensitivity in LabVIEW program - The new Joulescope v1 backend runs at elevated priority on Windows. Also, it sounds like you are using USB to serial adapters, which often add ~2 milliseconds of latency to each direction. If timeouts were already marginal, then the new Joulescope v1 backend could push it over the limit.
  2. Some USB bandwidth sensitivity. Although the new v1 backend receives the same amount of data with the JS110, it does use different underlying transfer sizes, which could affect USB transaction timing.
  3. Out of memory - because HDD/SSD swapping, which then causes timing issues.
  4. USB device scanning - The v1 backend uses the same device_change_notifier, but the SetupDi* functions to scan for changes is somewhat different.
  5. Processing load - v1 is different from v0
  6. VM USB behavior? Are you running these tests natively or in a VM?

Figuring out what is going wrong with LabVIEW would definitely help.

You could also try building a version of the pyjoulescope_driver that runs the backend at normal priority. Here’s how:

  1. clone joulescope_driver
  2. Install Cython dependencies, namely Build Tools for Visual Studio. It looks like you have to select “Desktop Development with C++”, then unselect MSVC v143 and select MSVC v142. Also, select the most recent Windows 10 SDK and unselect Windows 11. See here.
  3. In src/backend/winusb/backend.c, delete SetThreadPriority and error handling on line 1016-1018.

I have no idea if this is exacerbating the problem, but it’s something to try…

I’ve done steps 1-3 using Visual Code, but not sure how to build a version of pyjoulescope_driver. Never built python libraries with c++ code.

Well, you have some choices. Since this is a one-off edit, you can just build & install it.

pip3 uninstall pyjoulescope_driver
cd {path/to/joulescope_driver}
python setup.py install

If you would rather run from the source which can allow a quicker edit cycle:

pip3 uninstall pyjoulescope_driver
set PYTHONPATH={path/to/joulescope_driver}
python setup.py build_ext --inplace

I’ve made the repo on my dev machine (at home). But the machine that has all the test hardware is at work. Whats the process for that?

Could I build the library on my dev machine and copy a folder over?

You can build the wheel:

pip3 install -U wheel
python setup.py bdist_wheel

You should then have a file dist/pyjoulescope_driver*.whl. Copy this file to the other machine and install it:

pip3 install {path/to/pyjoulescope_driver*.whl}

1 Like

Success.

I’m gonna run it a couple more times.

Another good run!

1 Like

Ok, my suspicion is that something in that LabVIEW executable is either time-sensitive or has a very optimistic timeout for running on MS Windows. While I really like having the backend run at higher priority to limit processing starvation, I could add an environment variable that could control the thread priority.