timeout for change detection event

[neptun]

Hi there,

I would like to get some help in understanding the change detection events in LV8.5

I am using NI USB-6221DAQ card and processing rizing edge digital change on Port0.

Inside the loop I am collecting data from other USB-based spectrometer (non-NI)

I would like to know why all the examples on this Forum, which address event change cases, also have a timeout event handler (timeout=5ms)

Is this event required to allow other background processes to run?

The reason why am interested is that my event processing seems to be less reliable without these 5ms event (I am occasionaly loosing some data when actively interacting with Labview front pannel). Adding 5ms timeout seems to make things more robust, but then comes the question: what is the optimal timeout number and how it is related to Widows multitasking with other threads?

Thank you,

Mikhail

[John_P1]

Hi Mikhail,

Since the event structure is a blocking call, it will prevent subsequent loop iterations from occurring.  I'd imagine this is why you are msising data when there is no timeout case--if the change detection event does not occur then you will not be able to sample the next set of data.

The timeout case would allow you to move on to the next loop iteration even if the change detection event does not occur.  To see how to use the timeout case, you can take a look at this community example that I recently posted (although it's not exactly what you're trying to do, it does use DAQmx events with a timeout case):

Reconfigurable Finite Counter Output Using DAQmx on E or M Series

In the example, I am using the DAQmx Counter Output Event to break out of the loop.  To allow the loop to execute continuously, I added a timeout case.  So, the DAQmx Event structure controls the loop rate--every time it times out I move on to the next loop iteration.

If you want more information about optimizing performance in LabVIEW when using Event structures, you might want to try the LabVIEW forums.  I'm not sure what your exact application is or what the change detection event is controlling, but I hope this helpful for you anyways.

-John

[neptun]

Hi JohnP,

I think you clarified this for me. Thank You.

However my problem is that I am getting jittery performance even with Timeout loop of 5ms.

My spectrometer unfortunately does not have as large buffer and NI USB-6221 does. It is only capable of holding two spectra in its FIFO buffer.

Therefore my application perfomance depeneds on being fast enough to read the spectrometer data in on the NI cgange event loop.

So here is my question:

if there is any benefits of Timed Loop structure (processing change detection event ticks) vs. my current Event detection structure (change detection event+Timeout) with respect to optimal performance?

Thank you

Mikhail

[John_P1]

Hi Mikhail,

What OS are you running and how jittery of a performance are you seeing?  One thing to keep in mind is that USB is a non-deterministic protocol, so even on a RT system there could be some jitter there.  How are you communicating with the spectrometer?

If possible, you could try running the spectrometer code in a parallel thread with a faster loop rate to avoid missing samples.  When running the spectrometer code independently of the DAQ code are you able to capture all samples?  How long does the code take to execute inside the loop?

I'm not positive on the benefits of a timed loop vs. event structures, I'd try the LabVIEW forum for an answer to that question.  Out of curiosity, what exactly are you using the change detection event for?  Could you post some code so that we could better understand your application?

-John