VI slows down data collection after 120 seconds

[Nittany]

Jennifer.

Thank you very much.  I think I am understanding it more.  Although I have some last questions.
1. After I wire the data to the Enqueue Element, I would like to display all of the channels with indicators.  Using flush queue does not work and neither does changing dynamic data to an array.  I would like to get the information into an array or cluster so I can unbundle it and use indicators on all 31 channels.  How do I use the queue signal to do this?
2. I wire the data signal from the DAQ inside the producer loop to the write file inside the consumer loop right?
3. I still am unsure about where outside the producer loop the queue is used and how to hook it up to the consumer loop, and if I even need to do that... When does the queue first leave the producer loop? when I am done displaying all of the data?

Sorry for all the questions
thank you for your help
Catherine

[Otis]

Hi Catherine,

I think that we may be pursuing a more difficult arrangement than you are really looking for.

In your first post you said that you have 31 channels and you want to take data once every 0.1 seconds for 120 seconds.

It sounds like you only want one point at a time, so that brings your total to 1200 Samples.  This is definitely not a large amount of data, so I doubt you will need a more complex Consumer/Producer program (it definitely will work, but I'm not sure it's what you need).

Could you maybe post the code you were originally working with so that we can take a look at it and get a better idea of where the extra time is coming from?

Thanks,

[Nittany]

Hi Otis,

I have posted my VI.  I got it to run every 0.1 seconds for long periods of time, but I wanted to know if it was possible to do this for 0.01 seconds and for it to display every 0.01 seconds.  I want to have continuous display and updating on my front panel as well without it slowing down.

also:  I am using a graph indicator and it is not working - any suggestions?

Thank you in advance,
Catherine

[falkpl]

There is probably no sense in updating a display faster than 30 Hz since this is not noticed by human vision system.

[Otis]

Hi Catherine,

Out of curiosity why are you wanting to update your display so quickly?  The typical monitor has a refresh rate of only 60 Hz, and your eyes have a refresh rate of 25-30 Hz, not to mention that you will need to see enough data to actually process it in your head, so rates beyond 10 Hz are really going to be too quick...at least for a display.

While it is possible to get those faster rates, I typically recommend against updating the front panel controls/indicators more than about 10 times per second because it increases the possibility to bogging down your system and increases the jitter in software due to the extra processing time.

Finally, in your application it tries to use a continuous acquisition, but still only read one point at a time.  This should work for lower speeds, but will be difficult to keep working when dealing with higher speeds (>50 Hz) because you are continuously calling a single point across the bus, which is the same situation that you ran into before.  It would probably be best to see if there's some way that you can analyze more than a single point at a time in your application so that you're still sampling at the faster rate in hardware, but only processing the data a few times per second.

Regards,