First of all, highlight mode messes all timings esp. in parallel loops.
That being said, your screenshot in the first post tells us nothing, turbot. We don't know how many elements are in the queue and how many iterations each loop has already run through at the moment you made the screenshot.
But there is one thing we can tell for sure: Most propably, the package you "just received" from the dequeue element is not the the same as the one which is "just recently sent" by enqueue.
I never saw a queue loosing data except:
- Limited queue which is full
- Instead of dequeueing a single element all elements where read and all except of one was discarded
- System ran out of memory (2GB per application for 32-bit OS regardless of RAM size [special settings allow up to 3GB])
The first two reasons are custom made, the last one is a limitation of the addressspace and therefore there is nothing LV can do about.
I asume the following:
Your producer is an untimed loop containing some logic and a DAQmx read. The DAQmx read has a -1 connected for samples to read. So if no samples are in the PC buffer, the read returns.... tada... an empty array.
The logic could take even less than 1ms, so statistically spoken, you should retrieve arrays of size of 4x50 (jittering a lot because the producer is running different times for the algorithm and windows interactions). The large amount we are seeing in your screenshot is created due to highlight mode!
So it could happen, that the DAQmx read fetches an empty array. I have to confess that this is really odd in highlight mode. But if you just entered highlight during execution, this is possible!
hope this helps,
Norbert
Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
