Multilines plotting significantly slows down my data acquisition.

[fdtan]

After I converted my DAQ program from LabWindows 6.0 to version 8.0, the DAQ rate significantly slows down due to multi-lines plotting during the DAQ. Two-line plotting pretty much keeps the original repetition rate, however three or four-line plotting drops the DAQ repetition rate down by almost half. Any suggestions, experiences to solve this problems?

[MJF]

Is the only difference that you built the application in CVI 8.0?

What version of NI-DAQ are you using?

Are you running it on a different PC with maybe a different OS?

Non-NT versions of Windows give direct access to hardware resources, NT versions (NT, 2000, XP) do not, they use an intermediary driver to emulate direct access. If the OS is different, this can change things significantly.

[fdtan]

The OS are also different. The original program was built with LabWindows Version 6 on a Windows 98 OS, and the new one is with LabWindows 8.0 (with latest NI-DAQ) on a Windows XP OS. The performance of DAQ is quite different when I swap two hard drive with two different OS.  It just looks like I have to limit the lines plotted less than 2 in order to keep the repetition rate.

[RobertoBozzolo]

You could also try plotting only an abstract of your acquisition (say 1 point every 200 or 500) and stream the rest to disk / leave in memory: after the acquisition is ended you can redraw the graph with complete set of ponts. This permits the operator to have a raugh idea of what's happening and saves a lot of drawing work.

[MJF]

Well, it's pretty much what I suspected then. I am at a loss to suggest anything that might help short of a major rewrite of your program to put data-acquisition in a separate thread from the user interface management. This is how I would design the program from the outset:

• Main thread deals with UI management and sets up DAQ thread, any necessary semaphores for synchronization and thread-safe queue for pipelining data.
• DAQ thread only deals with acquiring data. All data is placed in the thread-safe queue.
• Main thread sends start and stop signals to DAQ thread and reads the queue to plot the data.

If you are using the old-style "Traditional NI-DAQ" functions, perhaps changing to the new-style functions may help? I am not really sure. I tried doing a search of the knowledge base to see if anything came up that obviously addresses the problem but I didn't see anything in the few minutes I have to look at it. Perhaps some deeper digging may help. It may also be worth posting this question to one of the boards more specifically relating to NI-DAQ.

One further thing I would suggest is to turn off autoscaling on the plots. Set a reasonable starting scale and only re-scale on command.

[Travis_M.]

These suggestions are great.  Also, I think the best start to troubleshooting this would be to determine which exact component is causing the slowdown.  There are a couple possibilities, but I would like to determine if it is the DAQ slowing down as a result of acquiring more channels of data, or whether its the updating the graph with extra data which causes the slowdown.  What happens if you substitute all of your DAQ calls with random number generation?  What happens when you acquire all of your data points, but don't plot any of them to the screen?  Suggestions provided by other users about not updating with all of the points is sound advice -- and wouldn't be extremely difficult to implement.  Multithreading your UI could be done (and in general is a good program design), but it gets slightly more complicated.  Furthermore, multithreading on the older OS might not be as helpful as it is on a modern built-to-multithread processor.  Feel free to attach screenshots of your code too -- someone might be able to offer some additional advice based on that.

hope it helps -- let us know how it goes!

[fdtan]

Thank you all for the suggestions. One thing I'm pretty sure is that it is the plotting of the data points to screen that causes the slowdown. Without drawing anything to the screen, there is almost no slowdown to the data acquisition. And after I plot the data every other data points, the data acqusition is back to normal (THANKS, Roberto). However, I cannot skip too many points, otherwise some main features will be missing during the scanning. Bottomline, although the program is ready for use, I think the problem is still there. It maybe due to the using of traditional DAQ functions, but I am not sure.

[RobertoBozzolo]

Well, as usual is the actual problem that must trace the path to the "right" solution. My suggestion was intended for a scenario with a test running of a relatively short duration with data collected and stored for post processing and with a sample only of data shown to let the operator mantain some surveillance over the process.

In case your test is long lasting, with a huge amunt of data the operator must handle during the process, the multithreading solution seems the most appropriate, in addition you are running with a modern OS and the latest CVI so you should have all the resources needed.

But you told something about swapping the hard disk to test the two scenarios, that means the hardware is the same and you only switch the software environment, so this question comes to my mind: may your XP environment be suffering the contraints of an "old" pc (processor, memory, graphics card...)? This could maybe explain the poor performance you are experimenting.