Triggered Stream ALL_OR_NOTHING infrequent error | LabJack
 

Triggered Stream ALL_OR_NOTHING infrequent error

2 posts / 0 new
Last post
christianreece
christianreece's picture
Triggered Stream ALL_OR_NOTHING infrequent error

Hello

I am performing a triggered stream of AIO0 sampling 1000 times at 500 Hz (2s of stream time) using a triggering TTL signal into DIO_EF0 using LabVIEW. I have my labview code setup in the following format:

Initiate stream --> Send triggering signal --> wait sampling time + 0.1s --> read stream.

I iniate the stream using the settings you reccomend (https://labjack.com/support/datasheets/t-series/communication/stream-mode). However, what I find is that >99% of the time there is no problem in reading the stream that way, but infrequently when I get to eStreamRead2D.vi I get the no scans returned error, which causes a missing read in my experiments. As far as I can tell this isn't a hardware issue with the pulse driver, so what I think is happening is that the stream is somehow not saving or reading the streamed data correctly.

My thinking is that it seems to be from the LJM_STREAM_SCANS_RETURN_ALL_OR_NONE setting that is required for the stream, and that perhaps using a burst stream would fix some of the issues. Is it possible to set a triggered burst stream in LabVIEW?

LabJack Support
labjack support's picture
Stream burst is basically

Stream burst is basically just an eStreamStart call, maybe a few eStreamRead calls, and eStreamStop call wrapped up in one function. Note that stream burst would block the same way eStreamRead does by default, except it will block for a whole numScans/scanRate seconds.

I would suggest setting LJM_STREAM_SCANS_RETURN_ALL_OR_NONE back to the default value of 1; this will make it so that eStreamRead will block until it gets scansPerRead samples. You could set scansPerRead to 250 (half the scanRate), start stream, then just call eStreamRead in a loop 8 times to get a total of 2 seconds worth of data. Call eStreamStop then the next time you start stream any residual samples you did not read from the buffer (which would be samples acquired after the 2s sample range of interest) will be deleted, and so the entire functional flow above will be similar to the behavior of doing a stream burst.