We are seeing new failures in our build environment ever since we have upgraded to the latest version of Joulescope. Are builds are hanging in the step that executes this command:
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?
If you run the pip freeze command, you should see:
joulescope==1.0.12
pyjoulescope_driver==1.1.0
Does this still freeze in your CI run?
Also, double-check that the python version you are using from the command line is the same as the one used by the CI test. Even better, log the result of python3 -VV and pip freeze in your CI run.
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.
Does the same command work from the command line but fail from CI?
It looks like you have access to stdout. Can you try to isolate what is hanging? For example, add a print before device.start, before time.sleep, before subprocess.run, and after subprocess.run.
What does Task Manager show when this hang occurs? I see this:
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?
Inside on_stop
before finally
before device.stop
before recorder.close
before device.close
after device.close
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:
I figured out quit from stop duration. It comes from the joulescope capture command. Is it possible to also show the commands in the CI log? It’s difficult to know what output comes from what command.
I think that this simplified sequence of commands does what you want:
joulescope parameter_set --config auto i_range=on
C:\CBAT_Test\Labview_7.2_Relay_Control\Executable\CMD_Relay_Control.exe - RELAY_CONTROL Relay_Serial_Number Off On On Off True
wait 3
C:\Python\python.exe -VV
wait 3
C:\Python\python.exe C:\CBAT_Test\Python_Datalogger\python_datalogger.py --duration 70 --frequency 50000 --product_tag CMIUV2_LTE_COM_AVG --command “C:\CBAT_Test\Labview_7.5_PUMA\Executable\Labview_Main_PUMA.exe - RunConnectivityTest COM10 PUMA 200 spare spare” --timedelay 15
wait 3
C:\CBAT_Test\Labview_7.2_Relay_Control\Executable\CMD_Relay_Control.exe - RELAY_CONTROL Relay_Serial_Number Off Off Off Off True
wait 3
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.
