I'm running an experiment where we move a motor and then start the stream read in order to measure a signal with 500 Hz carrier frequency. However, we don't want to read while the motor is moving.
The solution we are currently using in Python employs a loop:
- function to move the motor
- start stream: eStreamStart
- read stream: eStreamRead
- stop stream: eStreamStop
The whole process takes a total of (0.8 seconds + the measurement time):
- start, read, stop functions require 0.8 seconds
- measurement time is the # of scans per read / scan rate
We would like to optimize the measurement process and reduce this 0.8 second loop duration for setting up the LabJack stream and taking a scan. Ideally, we'd like to get it down to ~0.3 seconds.
We tried other solutions, including using stream burst mode -- but in that case, the duration was even longer (2 seconds).
We also tried keeping the eStreamRead open without using eStreamStart inside the loop -- however, we got buffer overflow errors because our code did not call the read function fast enough (due to also having to move the motor).
Please advise. Any suggestions would be greatly appreciated.
.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")
Triggered stream with StreamBurst seems like a potential option. You could set up triggered stream at the start of your program, then allocate a thread for stream burst to run in; you want it in its own thread because the call will block any other execution until your trigger. You could use a queue to synchronize the movement of data between the stream burst thread and any thread used for processing the data. Then if you get that sorted, all you should need to do is cause a trigger on the selected line when you want to start streaming. If you do not have an external trigger you could wire an output DIO to the trigger line. It should typically take 2ms or less to set a DIO state:
https://labjack.com/support/datasheets/t-series/communication/stream-mod...
Another potential option is to run stream continuously and create a stream callback to help avoid the buffer overflow issue. You would need to implement some mechanism to toss data you do not want, and getting the timing of when to start saving data might be tricky:
https://labjack.com/support/software/api/ljm/function-reference/ljmsetst...
https://github.com/labjack/labjack-ljm-python/blob/master/Examples/More/...
Thanks for the detailed reply. We tried implementing a stream callback but to no avail. It would be really helpful to have a conceptual overview of the example script -- how the threading works, what exactly the callback function is doing...
Also, could you please elaborate on the triggered stream with stream burst? I think this could be a viable option for us, if we are able to figure out how to implement it. What does it mean to use a queue to synchronize the movement of data?
I think the triggered stream with stream burst is the better solution here, getting timings with the callback seems like it could be difficult.
The LJM callback function is basically just creating a thread internal to LJM to call eStreamRead. The callback function will only be executed once scansPerRead samples are available (and each time scansPerRead samples are available). The example just sets up a callback function, the callback defined near the top of the file, then the program runs until all of the desired data has been captured from doing callbacks:
https://labjack.com/support/software/api/ljm/function-reference/ljmsetst...
We also have a triggered stream example. The setup required to set up the trigger is all above line 127:
https://github.com/labjack/labjack-ljm-python/blob/master/Examples/More/...
When you run multiple threads you need to ensure there cannot be a race condition where you overwrite data in one thread when trying to read data in another. This is not often an issue with the data containers in Python, and my suggestion to use a queue is just one possibility to safely move data between threads:
https://docs.python.org/3/library/queue.html
This makes sense -- I am going to try to implement the DIO trigger with our motor.
I'm trying an alternative method of data collection and disentangling the LabJack data acquisition from our motor experiment altogether. Do you have suggestions on what might be causing this unknown error?
I am not sure what would cause that error. If you are currently using the release installer, please try running our beta installer and test again:
https://labjack.com/support/software/installers/ljm
If that does not resolve the issue, please enable our LJM debug log and send us your log file after the program errors out again:
https://labjack.com/support/software/api/ljm/function-reference/debuggin...
Hello,
We figured out there was a function in our code that had not been indented correctly and this was what was causing it to run slowly. Now that we've fixed this, everything works more smoothly. We also installed the beta installer.
However, our scans still regularly return various errors, most often 1221. Sometimes our program crashes unexpectedly, while it does not crash when we comment out the eStreamRead function.
I have attached our debug log. Could you please take a look?
Here is one more debug log! Since the errors are varying, I'll keep sending them as they arise.
LJM library error code 1231 LJME_CANNOT_CONNECT
After running 5 successful scans in succession, starting a new scan resulted in this error
After 5 scans, we got a buffer overflow error which is new. Please see attached!