We added additional parameters to your sample code for embedded commands into the data capture. Its almost like the subprocess method no longer works properly. What’s even more strange, rolling back to an earlier library versions of pyjoulescope_driver and joulescope do no fix the issue. Are we missing a library we need to roll back?
Hi @Nate - Sorry to hear that you are having issues with the script no longer working. You should be able to use C:\Python\python.exe -m pip freeze to display versions. What version of joulescope and pyjoulescope_driver are you seeing the failure with?
If you roll all the way back to joulescope version 0.9.11, do you see this issue?
Thanks for the detail! I am at my contract manufacturer today, and I might not be able to investigate this until tomorrow.
I did notice that the python version is 3.10.0, which is rather old. The 3.10.x branch has had a bunch of bug fixes changelog. Not sure if they affect this, but that could be one thing to try. If you are going to upgrade, I recommend staying on 3.10.8 rather than going to 3.11.0, which is still very new.
I think that this is your test command. The message order is a little confusing. I see done capturing data: quit from stop duration before device.start, so I am not sure what is happening. I am not sure exactly what to make of the log file output.
For the command, you should ensure that you use the same python:
At 08:09:19, it reaches the data collection while not quit_: spin loop. If the command launched at 08:09:11, I have no idea why it took until 08:09:19 to get here. I do not know why it would exit correctly from the command line, but not from your CI environment.
Maybe more print statements can help isolate the problem?
I also noticed that the script you sent earlier has inconsistent use of sys.exit. You probably want to have run return an integer, 0=success, any other value on failure, and then:
These are the two lines of interest from the sequence file. The first is stripped down to just showing the python version. This line executes perfectly.
|[08:09:19]|[Step 5/8] Before device.start|
|[08:09:19]|[Step 5/8] Before time.sleep|
|[08:09:19]|[Step 5/8] Before subprocess.run|
|[08:09:19]|[Step 5/8] After subprocess.run|
|[08:09:19]|[Step 5/8] Capturing data: type CTRL-C to stop|
Its when the next line is executed (the line with the embedded command “C:\CBAT_Test\Labview_7.5_PUMA\Executable\Labview_Main_PUMA.exe - RunConnectivityTest COM10 PUMA 200 spare spare”) that the CI hangs.
One thing I could help explore is “what is it exactly in the call to the Labview_Main_PUMA.exe” that the new Joulescope library doesn’t like. We can strip it down to just pass out a print statement and work up towards the COM port its acquiring to the calls its making under the hood.
Watching it, the Read loops for bootup stuff incremented to 499, but the read loops for command replys never increments and the dialog box doesn’t fill up. The 200 second timeout for the LabVIEW doesn’t seem to work.