Unreliable timing in consumer/producer VI

[dhlee47]

Hello forums.ni gurus,

I'm a neuroscientist who is using labview to acquire data during a behavioral experiment. Thanks to this forum, I learned about the producer/consumer architecture and have implemented it for my project (this made it run a lot faster!). But I have some issues with the acquisition timing. Namely, it runs mostly at 250hz but sometimes it takes up to 400ms in between two iterations of the producer loop. How can I make sure I acquire data more consistently?

I've attached some pictures of the consumer and producer loops as well as the vi.

Thanks,

-KDan

 

 

[Gregory]

Hi dhlee,
Instead of acquiring 1 sample per loop, you can acquire many samples, so the hardware will take care of the time between samples, and it will be much more uniformly spaced.
If you need to change outputs based on calculations of the collected data at a 250 Hz rate, then you will probably want a real-time system.

[Kevin_Price]

Although the general clutter is mildly terrifying, none of the DAQmx stuff I saw in the producer loop looked responsible for any egregious timing issues (such as the jump from 4 to 400 msec iteration time).  A very few additional remarks:

1. You've asked the Timed Loop to iterate every 2 msec but usually observe 4 msec. I also note that you have multiple software-timed on-demand tasks.  I'm guessing your NI devices are USB-based and experience some combo of USB-induced latency and bus contention.

2. The encoder measurement is a complete black box to me.  Since I don't see any obvious cause of 100's of msec delay elsewhere in the loop, that's gonna be high on my list of suspects.

3. Software timing under Windows will *always* have some uncertainty and variation.  400 msec isn't out of the question, but I would normally expect 100's of msec delay to be rather rare.

4. Learn to use subvi's.  Avoid unnecessary wire bends, wires passing behind structures, wires that don't visibly connect to the structure tunnels, etc.  Don't do it for me, do it for you.   (Note: this isn't going to affect speed or timing, it's just general good practice tips.)

5. You're growing arrays in your consumer loop and repeatedly writing them to a graph, nominally every 2-4 msec.  But you're also clearing out the arrays every 1000 iterations to start over again.   This ain't helping any.

    You should probably get rid of the growing arrays and simply send the individual samples to a chart with a 1000 sample history length to accomplish something mostly similar in a much more efficient way.

6. That leads to the only other candidate I spotted for slowing down your producer loop.  The Enqueue function itself.  If your consumer loop is getting really bogged down with its attempts to update a graph at 250-500 Hz, it's possible you start growing a big backlog in the Queue.   As it grows, you'll eventually fill the available space and the next attempt to Enqueue makes the internal queue code allocate a new bigger memory space and copy everything over before the new Enqueue can happen.  Memory allocation *can* be slow at times.

-Kevin P

[cy...]

perhaps separating the controls (output tasks) from the timed-loop can help, if you do not need them to be as up to date as the measurement processes (2ms response on FP?)

additional improvement can include removing redundant functions (array & timing) & variables, uninitialized shift registers (next run will inherit past data), coercions

is that the only timed loop? or are there others, if there are, loop priority can probably help also