Hi, I have been using T7 to stream in with non-looping stream out. I am using Python function WriteAperiodicStreamOut to load a file with my signal that is next streamed out using FIO. The ultimate purpose is to send pulses to trigger different devices at different times. At the same time, I also stream in a few channels. The stream looks very stable, and the stream speeds are also very fast (5000-10000Sa/sec). However, once in a while I’ve noticed a glitch in the stream out data. It looks like some data that was not in the file, is being added to the stream. After that, stream out resumes reading data from the file from where it stopped (it looks like no data from the file is lost, but something is added). It is only happening on stream out while stream in signal is uninterrupted. It is never a full number of scans per read that is being added. Just a few samples. And it is happening regardless of scan frequency. There doesn’t seem to be a rule when it will happen. And I have two T7 devices, and it occurs on both of them.
Could you help me understand what is happening? I’d be happy to provide you with more information but I don’t know what is important. I attached a screenshot of the signal to illustrate the problem.
.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")
Nothing about your setup immediately jumps out to me as problematic, so I am not sure on this one. I will try to reproduce tomorrow and hopefully have something more useful to reply by then.
Were you able to reproduce my issue?
Sorry for the delayed response.
I have not been able to reproduce your issue. The issue seems to be the opposite of the issue I would expect while using stream out and the aperiodic stream out functions; any delays in stream out should result in the line holding at its last value, which should result in the line staying high or low longer than desired.
How does the glitch high or low time compare to your sampling period? Is it shorter or longer than the sampling period?
Maybe what I thought were additional samples, is in fact some delay that is holding the last signal value. For the signal that changes from low to high every next sample, it looks like it might be the case (attached screenshots)
The glitch is typically a few samples – anything between 5 and 10, so it is typically longer than sampling period and it is a real signal showing at the output.
I’ve tried modifying scans per read between the recommended scan_frequency/2 and scan_frequency/10, but that doesn’t seem to fix anything. The glitch tends to occur more often for lower scan frequencies… Is there something else that I could try to modify in order to minimize the chances of delays in stream out?
Would sending my code be helpful? Although it is quite big application.
First, I want to step back from the stream out considerations and suggest an alternative in case you did not consider it. The T7 supports PWM output features and these could be used while streaming. The biggest limitation of the PWM output feature is that you effectively only have two separate clock sources, so at most you would be able to run two different PWM frequencies at once (with variable duty cycle across all of the PWM channels). The PWM can be reconfigured on the fly to alter the frequency or duty cycle:
https://labjack.com/support/datasheets/t-series/digital-io/extended-feat...
The main suggestions I have for stream out are the same as listed in #4 from this topic:
https://labjack.com/comment/7300#comment-7300
Looking through code doesn't seem optimal to me. Instead, I would recommend probing around your code to better figure out what is causing the issue.
One good test, if possible, would be to replace your file IO / AperiodicStreamOut system with a dummy waveform generated before stream starts in your program. Namely, I would suggest loading a bunch of samples of a simple waveform that toggles the FIO high and low to the LJM stream out buffer before starting stream. If that works correctly try the same thing but feeding out samples using WriteAperiodicStreamOut while streaming and doing eStreamRead calls. Those tests should help tell you if your file IO or the number of samples you write per your main loop are bottlenecks. Keep in mind that if it takes 50ms between WriteAperiodicStreamOut calls then you should be loading at least 50ms of samples each time you call WriteAperiodicStreamOut. You could do similar tests with eStreamRead or time your stream loop to make sure all of your timing is consistent with what you expect and viable for your sample rate.
I am looking for someone to assist with a project I have using T7 streaming several channels of data and generating operator interface to display various operator screens. If interested please contact [email protected]