15-20 latency seeing changes in Analog Inputs

[wildcatherder]

I have inherited an enormously complex program.  I find that I am seeing 15-20 second latency on changes to the analog inputs.  I cannot post the code - (it has over 200 sub VIs) but I have captured the pertinent section in Long latency analog input changes.jpg attached.

I have tried changing the sampling rate and see the same problem from 1Hz to 25Hz (limit of reliable sampling with this PC).  I am looking at indicators that are directly connected to the DAQ Read.vi as shown by the big red arrow.

I have modeled the nested structure in the attached Model without latency problems.jpg.  There is no perceptible latency although it duplicates the nested structures.  

The only thing not shown is that there are several instances of DAQ Read.vi using the same physical changes but not of them are in loops that should be running at the same time.

The data is consistent with inputs, just delayed.

The Signal Processing device is a USB-6343.  I am running these VIs on LabVIEW 2011 Development System.

Any ideas?

[JÞB]

Sequenceitis!

or why we prefer state machines to sequences.  I know I have only hit the broad strokes but I trust my fellows to help you dig into a queued state machine.

[Freelance_LV]

Hello

I had recently done something very very similar. Just that I did not have 200, but about half that number. However, the challenge was still the same and I reduced some part of the delay. Now, it is about 1 to 2 second delay, which is fine for now.

As pointed out already, state machine helps! I had removed most of the sequences and replaced them with a state machine, init stage, event stage and shutdown stage. Event stage fired events to a parallel running consumer loop through Queues. The consumer loop was another state machine with states correspondign to each event. Each state has code inside respective sub modules.

I had removed ALL Local and Global variables in the inherited code, replaced with property nodes where required, or bundled into clusters and passed the data through the state machine. Create a cluster that contains all the required data, from the GUI and from the block diagram. Pass it through the consumer state machine using shift registers. Put most of the stuff inside sub modules and clean the Block diagram

Ensure that the while loops run with comparable time delays, if not very different.

I took two and half months for this renovation project. Of course I had to add new features too.

Good luck

[wildcatherder]

I appreciate your mention of the local variables as a source of problems rather than suggesting I simply re-write five years of someone else's code.  Previous versions of this program did work properly.  

I was hoping to get an answer from someone who had inadvertently introduced this problem into their own code and managed to "back out".

Even better would be an explanation of how the direct output from the read function can somehow "buffer" that much data.

I will file a technical support request on this problem while I eliminate local variables and reverse through my various back-ups.

[dkfire]

I can see one issue with your code.

How fast do you think your loop is running ?

As it is now you are reading one sample per itteration. 

If you are sampling with

• 1000hz the loop has to run faster than 1ms, I dout that is possible.
• 25hz, the loop has to run faster than 40 ms. 

So if your loop is slower than 40 ms then the DAQ buffer will start to fill up. At one point your samples in the buffer will be overwriten, resulting in an error, but you will always be behind.

If that gives you a latency of 20 sec, I don't know. But it will give you some trouble.

You need to read more samples at a time to be able to keep up with the DAQ.

Try to test how fast your loop is, and let us know the answer.

How does the rest of the loop look like ?

[dkfire]

And one more thing, why all those type cast ?

[wildcatherder]

The type casts are a way to give unique names to probes and serve no other purpose.

I tested the sampling at between 1Hz and 25Hz, which is near the upper limit that my PC will process the data.

I have opened a tech support case with National Instruments and sent them 230 MB of code so that they can duplicate my results.

When I hear anything definitive I will post it here.

[Kevin_Price]

Even better would be an explanation of how the direct output from the read function can somehow "buffer" that much data.

Ok, here goes:

You have a buffered task and your call to DAQmx Read.vi only asks for 1 sample at a time.  The normal behavior will be to return to

you the *OLDEST* data that you hadn't previously retrieved from the buffer.  The reason is that DAQmx will try to deliver to you *all*

the data from your buffered task, losslessly and in order.

If you aren't reading data out of the buffer as fast as the task is putting it in, you will see a latency that keeps increasing until your

buffer is completely full of unread data.  After that, the task will normally produce an error.  Seeing the deeply nested program structure

you're dealing with, the existence of latency issues is not particularly surprising. 

There are a variety of ways to deal with the issue, the best choice depends on your overall app.   Do you need all data collected

without loss?  Do you need to make decisions on low-latency data?  Do you ever need to read multiple samples at once?  Various

inputs to the DAQmx functions and propery nodes allow for very flexible management of tasks and data buffers, it's all a matter

of what you need.

-Kevin P

Edit: Due to a big latency between starting this reply and ending it , I see that the 1-sample-at-a-time issue was

already addressed...

[wildcatherder]

I would prefer to get the most recent sample at the start of each loop iteration.  The rest of the data is strictly "don't care".  I am measuring physical process which do not change significantly over a tenth of a second. I have occasionally seen buffer overrun errors with advice to change buffer size.  Nowhere have I found a method of how to do this.  

Your explanation is the first I have seen that makes any kind of sense.  

I thought I was sampling a real-time data stream at 25Hz.  Instead, I seem to be sampling a buffered data stream with long latency.  Is there a way to do this unbuffered?

[dkfire · Accepted solution]

Yes, instead of just getting 1 sample from the buffer, try to get all samples.

Then you can extract the newest sample from all the samples you get, and discard the rest of them. 

Or you can change the taks setup to only sample one time whenever you call the read function.