I am working on a simulator for control systems written in Javascript and Node.js in which a T7 can be used as part of the plant/process. In every step of the simulation we are reading AIN, which value will be send to the next module in the simulation, and writing the value received from the last module into DAC. So I have to use LJM_eNames in every step of the simulation, which are normally repeated every 0.01s. But according to the professor, for who I am programming this simulator, the use of LJM_eNames is too slow. So I tried to use the stream functionality for reading AIN. And now it gets weird. I've connected DAC and AIN with a jumper, so I should always read the same value from AIN I have written into DAC one simulation step earlier (because AIN is red before DAC is written) (see Screenshot 2022-02-24 at 10-54-46 Steuerungs-Regelungs-Simulator.png). Sadly the stream I receive from the T7 returns rubbish, as you can see in the other attached image (Screenshot 2022-03-10 at 09-38-18 Steuerungs-Regelungs-Simulator.png). What am I doing wrong? And is there a faster method for reading and writing?
.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")
Unfortunately, stream mode is not very suitable for feedback applications. Higher sampling rates are achieved by hiding communication overhead incurred through the use of sample buffering, and sending sample data in large chunks. This means that throughput is typically higher with stream mode, but the time to get a single sample of data is longer. Any feedback from the AIN to the DAC is always going to lag the AIN sampling by a notable margin when using stream mode. You may be able to get a better looking DAC waveform by using stream out mode for the DAC and sending AIN samples to the stream out buffer in large chunks.
The best option for feedback operations would typically be to use an embedded lua script, but it sounds like you may not be able to take advantage of an embedded lua script in any meaningful way:
https://labjack.com/support/datasheets/t-series/lua-scripting
Depending on how you have the AIN setup currently, you may be able to achieve faster rates using eNames by setting the AIN resolution index to 1 and AIN range to ±10V:
http://labjack.com/support/datasheets/t-series/ain#resolution
Setting the AIN resolution index to 1 helped. This reduces the average communication time via USB from 1.74ms to 0.77ms and via Ethernet from 2ms to 1ms.
But there is still one major problem. The maximum communication time can be very high from nearly 6ms via USB to more than 20ms via Ethernet. And this is a serious problem if we work with real time and send out and need to receive new data every 10ms.
Unfortunately, command response is inherently somewhat unreliable with sampling time. We expect the time to typically stay around the median communication time, but with occasional jumps to higher delays.
If you can do your feedback independent of your host application, lua runs locally on the device, and would be much more consistent with timing since there is no communication overhead.
Sadly, that's not possible because the T7 receives values from the computer and has to send the result based on these values back.
I thought about using the asynchronous version of LJM_eNames and a promise race that sends the last received value the the next module of the simulation if the result from the T7 does not arrive after a certain time. But my experience with asynchronous programming is limited and the asynchronous LJM commands seem to be different from the standard asynchronous commands.