I'm using an externally clocked stream on a T7-pro. The program is written in Python. I used this file to install LJM: labjack_ljm_minimal_2020_03_31_armhf_beta.tar.gz
I get a LJME_TRANSACTION_ID_ERR if I stop my program and run it again. This happens every 2nd time:
Run (no error) - Stop - Run (transaction id err) - Stop - Run (no error) - Stop - Run (transaction id err)...
I was using STREAM_RECEIVE_TIMEOUT_MS = 0. If I set this timeout to 1000, the problem disappears.
eStreamStop() and closeAll() are called when stopping the program.
Have I missed something to close everything nicely ? I'd rather avoid having to set a timeout as the clock signal might start a while after the program has started.
.png%3Fitok=PHGBxf6M "EEV Blog Reviews LabJack T7-Pro & Software Tools")
.jpg%3Fitok=B1YcuDFK)
.png%3Fitok=Ybt-OlgU "LabJack + JEDI One Can Create a Powerful Distributed DAQ Ecosystem")
Once the external clock signal starts, what's the slowest frequency it might output? That's what should be used to calculate LJM_STREAM_RECEIVE_TIMEOUT_MS, plus extra for intermittent communication delays.
The LJM C example more/stream/stream_external_clock.c can loop indefinitely until the external stream starts (depending on the NUM_LOOP_ITERATIONS). It sets the following configurations:
Sets LJM_STREAM_SCANS_RETURN to LJM_STREAM_SCANS_RETURN_ALL_OR_NONE
Sets LJM_STREAM_RECEIVE_TIMEOUT_MODE to LJM_STREAM_RECEIVE_TIMEOUT_MODE_MANUAL
Sets LJM_STREAM_RECEIVE_TIMEOUT_MS to 100
Thanks ! I didn't get that it "waits" until the stream starts even if it is longer than timeout. The frequency will be around 70Hz.
I tested starting the clock later and also interrupting it for some time, it works fine. And I'm not worried about having to set a large timeout. :)
What I observed is that if I set a timeout that is too low (but not 0) I also get LJME_TRANSACTION_ID_ERR the next time I launch the program. I'm currently using DAC1_FREQUENCY_OUT_ENABLE for testing (10Hz), a timeout of 150ms works fine but 100 or lower does not.