Hello,
I am experiencing randomly long acquisition time when I use getAIN().
Here is my code :
def function():
acq = []
for ain in range(3):
acq.append(labjack.getAIN(ain))
return acq
Most of the time (99%) these three acquisitions take less than 2 milliseconds, which is perfect, but sometimes it takes around 20 milliseconds.
Do you have any ideas on what could cause such delays and how to avoid that?
For information, I have 4 threads in parallel calling periodically function().
Thanks for your help!
.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")
The software library is thread safe, and in the context of our devices that means you are blocking any getAIN calls on other threads when you run getAIN. The device can only process one request at a time. I would recommend doing all of your AIN reads in one thread to reduce the complexity. Also note that you can reduce your communication overhead by using a feedback command rather than doing getAIN in a loop:
https://github.com/labjack/LabJackPython/blob/master/src/ue9.py#L477
https://labjack.com/support/datasheets/ue9/low-level-function-reference/...
Do you see the same timing issue if you only run the acquisition in one thread?
Hello,
Thanks for your reply!
I updated my code as follows, to avoid using getAIN():
acq = labjack.feedback(AINMask=0xFF)
Then, I read values directly from the returned dict acq.
The conclusion is:
I am not considering doing a single thread for my application for now.
One thing I don't understand is why I have to wait for 15 ms sometimes for acquisitions? Most acquisitions (99 %) are made in ~2,3 ms so with four threads and in the worst case I should wait for 3 x 2,3 ms = 9,2 ms. Is there something I don't get?
Cheers.
Seeing occasional transfers that take longer than average is consistent with what we have seen during testing. These occasional high latency transfers can be attributed to the OS scheduler or high processor load. The following page was generated using a T7, but we would expect similar behavior when using a U6:
https://labjack.com/support/app-notes/maximum-command-response
Thanks!
So using a single thread for acquisitions won't help me on this.
Is there a way to avoid these long acquisitions times? Maybe with streams?
I think running acquisition in a single thread could still be useful. By running multiple acquisition threads you are adding more opportunities to put your threads in a blocked state, which the scheduler might preempt. It is hard to say the exact impact of that, especially considering the threading abstractions used in Python, but running large feedback commands in a single thread (and processing the data in other threads) should be more efficient if that is possible.
Stream mode acquisition would not have the same delays as the feedback commands, but you must stream at a rate of 6 samples per second or higher, and you could not initialize multiple streams or in multiple threads.