In our setupt, we're using a T7 Pro to monitor 15 channels connectected to magnetometers and the range is +/-10V with a gain of 1. The resolution index is set to 5. In the future, this system will be used for to correct for variations in the magnetic field in a live setting. Because of this, we need to be able to aquire the data from our Labjack as many times a second as we can in order to react to instant changes. To do so, we'd like to ideally call eStreamRead multiple times per second. However, as we've been looking into this and seeing how the labjack behaves when eStreamRead is called several times a second, we were wondering about exactly what the limitations on the rate are when we call this function multiple times a second. We've put together a document outlining our attempts so far and we've attached the code we've been using. If you could explain exactly why we're seeing the inconsistent timing we are, that would be great.
.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")
It sounds like you're using delays/interval timing in combination with eStreamRead. Instead of doing that, you should call eStreamRead as fast as possible. eStreamRead itself will delay until data is ready. Also, since stream data is collected according to the device's clock (not the host computer's clock), any timing mechanism on the host computer is subject to clock drift from the device's clock.
For information on getting eStreamRead to return data at the highest frequency possible, see the low-latency section of eStreamStart:
https://labjack.com/support/software/api/ljm/function-reference/ljmestre...
That indicates that you could probably get eStreamRead to return one scan at a time at a ~7 kHz ScanRate.
It seems we were misunderstanding how eStreamRead was supposed to be called, and thanks for correcting us on that. However, after taking away the LJM_start_interval code and solely relying on eStreamRead to keep timing on track, we're eperiencing the same problems as before even with much more conservative numbers than were used in the example in the low-latency section (looking back, we don't think LJM_WaitForNextInterval was actually ever doing anything).
Also, we've noticed that every so often, eStreamRead seems to miss a couple readings, have the buffer fill up a bit and return several readings in quick succession to make up for the delay. For example, we've gotten the data below, with the time taken by eStreamRead on the left and the LJM buffer backlog on the right (taken with a scanRate of 300 and scansPerRead of 6 for a frequency of 50 Hz).
Time taken by eStreamRead LJM Buffer Backlog 0.049253 0 0.049353 0 0.049526 0 0.249786 60 0.000451 45 0.000375 30 0.000390 15 0.000462 0 0.049239 0For some reason it waited a full 0.249786s at one point, and then got called extremely fast for the next couple times. If you have any more suggestions or ideas of why any of these results or our other inconsistencies are occuring, your help would be greatly appreciated.
Please upgrade to the beta version of LJM:
https://labjack.com/support/software/installers/ljm
LJM 1.2001 improved CPU usage during stream, which sounds like it could be related.
It's possible the OS scheduler is giving other processes CPU time. Try restarting, disabling unneeded processes (especially ones that use significant CPU), then running your stream program.
Try increasing the priority of your process:
What connection type are you using? USB or direct Ethernet give the most reliable timing, since networks are inherently susceptible to contention.
My question is related in that I am trying to get my T7-Pro to stream very quickly (low latency). Looking at the low-latency link, what tweaks have to be made to the StreamBasic example (MATLAB) to get the metrics referenced on the webpage (7250 Hz,1 scan per read)? If I run the StreamBasic code with most everything in the eStreamRead thread commented out, I still get a timed scan rate of ~64 scans/second as opposed to 7250 scans/second.
Our end goal is to externally trigger the stream-in with a 4kHz pulse, just one scan per read. Is this plausible with the T7-Pro over USB or ethernet? I got the triggering working, but the timed scan rate is always very low compared to the scan rate I set in the code when I have the scan per read set to 1 so it is not actually seeing every trigger pulse. Any suggestions here?
You need to make the following changes:
What's happening to the backlog parameters of the eStreamRead call when it's slower than you expect? Is eStreamRead returning any error?
It sounds like you mean externally clocked stream, as opposed to triggered stream. Those are both described on the T-series stream datasheet page:
https://labjack.com/support/datasheets/t-series/communication/stream-mode#externally-clocked
4kHz with one scan per read with USB or Ethernet is plausible, given that the Low-Latency section describes 7.25kHz with ScansPerRead=1 and a USB connection. Ethernet has better throughput compared to USB, but longer latency (typically not by much) due to network propagation. You can use direct Ethernet if you need minimal latency with Ethernet:
https://labjack.com/support/app-notes/networking/direct-connection-ethernet-app-note
What is your STREAM_EXTERNAL_CLOCK_DIVISOR set to? It should be 1.
What happens if you use more\stream\stream_external_clock.c from the C examples (https://labjack.com/support/software/examples/ljm/c) and connect FIO0 to CIO3? There's a .exe for Windows that makes it simple to try externally clocked stream with a 1000 Hz scan rate via a pulse out on FIO0.
Are you using a CB15 to ensure a solid connection to CIO3?
Edit: typo
Also, how many iterations are you using to calculate the average iteration time? You should use at least a couple seconds worth of iterations.
I have switched over to using my triggers as an external clock instead of a trigger. This is working only partially. I am using a square wave at 4 kHz as my external clock. I have the scan rate set to 6000 and the number of scan per read set to 1500. When I run my code which is essentially just one call of eStreamRead, it is measuring a timed scan rate of 2600. Sometimes at this number of scans per read and at all higher values, it instead calls a STREAM_SCAN_OVERLAP error. If I lower the number of scans per read, the timed scan rate gets even lower.
My problem may be from an unreliable connection in the CIO3 pin, so I will try to work on fixing that. However, is there anything in terms of my code that I may be missing? My STREAM_EXTERNAL_CLOCK_DIVISOR is set to 1. Right now I am only iterating over the eStreamRead function once, but that is because the SCAN_OVERLAP error was coming up so I just wanted to simplify the code a bit. Also, the external clock .exe executes as expected.
Thanks!
When not using external stream, are you able to get 4kHz stream with ScansPerRead=1? Try that first. Make sure you can run that for a couple seconds and get approximately the right scans per second when you measure it. Make sure the backlog parameters of eStreamRead are staying low.
From Stream Timing:
If the external clock .exe works, that means the pulse out on the LabJack is working correctly with CIO3, though you might want to try it with 4kHz pulse out. Altering the external clock example should be pretty easy to do that.
Can you look at the LabJack's pulse out waveform with a scope and compare that to your waveform? Make sure the rising edges look good.
As suggested, I tried using a modified version of the provided stream basic code to do 4kHz stream with ScansPerRead=1. This actually worked as long as I set my maxRequests=4000. If I only requested 2000, for example, the Timed Scan Rate came out around 3500 scans/second. I think this might have to do with matlab's tic/toc functionality because it isn't skipping any scans. However, the LJM backlog is hanging around the 1200 mark (the device backlog=0). I am still getting STREAM_SCAN_OVERLAP when I try an external clock even when I lower it to 1kHz.
I have not yet tried modifying the externalclock.exe. I will work on that today. Thanks for your help so far.