Analog read loses data when dragging window

[Steve_Block]

I'm using DAQmx and have a program that is collecting analog read data from a CDAQ module. There are a few graph controls on the window that data is being displayed to. When I drag the window data collection pauses though until I stop the drag. There is no event structure in the code. Does anyone have thoughts about what the cause can be.

Sorry, I'm not allowed to post the code.

[James.M]

No event structure, huh? Is the acquisition stopping, or just the graphs?

Are you sure there's no event structure? That sounds like something is stopping the code when a drag event occurs.

[Michel_Gauvin]

When dragging the window what it your CPU usage?  Maybe the buffered data gets overwritten before they are read by your application because of the lack of CPU to process them. Just an idea.

[Michael_78]

If the PC has poor graphics performance and the graph terminals are in the same loop as the daq read them this behaviour is likely. Use a producer/consumer architecture and draw the graph in the consumer loop.
Cheers. Michael.

[James.M]

---

@Michel_Gauvin wrote:

When dragging the window what it your CPU usage?  Maybe the buffered data gets overwritten before they are read by your application because of the lack of CPU to process them. Just an idea.

---

I was thinking this, but I think it wouldn't be one gigantic gap of data from drag-start to drag-end that is lost. It would be laggy sections of data during the drag that are lost. But I guess we don't know what OP's code looks like, so it's possible.

[Michael_78]

I had a very similar problem some time ago.  I has an Intel Atom based fanless embedded PC, a very low spec machine.  Whenever I moved the front panel, the CPU hit about 90% and everything else stopped completely.  Charts were the problem.  Please correct me if I am wrong, but I think that because charts must store every value written to them, they block the UI thread while they are being written.  This is not true for other indicators, as LabVIEW has an intermediate buffer and can update the UI at will. To correct the problem, I moved the chart to a 'UI update' loop and queued its data. I hope this is helpful,  Michael.

[James.M]

---

@Michael_78 wrote:

I had a very similar problem some time ago.  I has an Intel Atom based fanless embedded PC, a very low spec machine.  Whenever I moved the front panel, the CPU hit about 90% and everything else stopped completely.  Charts were the problem.  Please correct me if I am wrong, but I think that because charts must store every value written to them, they block the UI thread while they are being written.  This is not true for other indicators, as LabVIEW has an intermediate buffer and can update the UI at will. To correct the problem, I moved the chart to a 'UI update' loop and queued its data. I hope this is helpful,  Michael.

---

So what part of moving to a separate loop fixed the problem? Does the hangup occur at the terminal, so the loop would actually lag at the terminal write node?

Would the interface still lag in this instance, but just not lose the data because of the queue?

I tried to simulate the issue here on my own by writing a ton of data to a chart, but what I get is the window drag itself lags/skips and the data doesn't. I run SolidWorks on this machine, though, so it might just be too fast.

[Steve_Block]

The other thing that does not make sense is the AtoD on the DAQ should be FIFO buffered.

[Michael_78]

OK, I was wrong, it does not block the UI thread as such, or we would have major probelms with most applications!  But it does *seem* to block the loop on a low performance machine.  Onboard graphics pre-intel i series with single core processors will probably suffer worst.  What machine are you running the application on?  As for the buffers, if your delay is in the order of seconds you will have a problem as the FIFO on the DAQ will be comparatively small.  Move the charts out of the DAQ read loop and see what happens.

Michael.

[Michel_Gauvin]

---

@Steve_Block wrote:

The other thing that does not make sense is the AtoD on the DAQ should be FIFO buffered.

---

What's the exact hardware you are using? What is your sample rate? Can you duplicate the behavior with a simple example?