Mouse movement speeds up graph plotting activities!

[mowgli]

Hi NI,

I have tried to run a rs-232 data collection project (incoming data at 10msec periodicity...20 bytes every 10msec). The LabWindows environment seems to work more efficiently (faster) if i move my mouse over the plots(without even clicking it!) as opposed to normal plotting in the tabbed pane. I have used a TSQ + thread pool concept to run my data gathering and plot update. Can someone please assist me on the fastest way to plot data. I was earlier advised not to use a GUI timer for plotting purposes with high data rate acquisition and plotting! I cannot seem to understand why the plot is faster when i move my mouse over the graph as opposed to just letting it plot normally! I am using a WinXP machine.

Regards,

-Ashish

[mowgli]

e have tried to study the timing on our TSQ write and read...we are not losing any data due to our huge queue size...however it is taking us approximately 40 msec to write 166 bytes to the queue when the mouse is still and approximately 9 msec when we move the mouse over the GUI form...!!!

The basic outline of our program is based on the BuffNoDataLoss.cws example program...we are requesting NI support on this since our situation in understanding this anomaly is hopeless.

We have tried this example on a Win 7 machine now and CVI 2009 and we are still lost in our understanding. Please help!

[Kanchan]

Hi,

This does seem very peculiar. Can you please tell me your system configuration including that of the Graphics Card.

[RobertoBozzolo]

Hi mowgli, it seems to me that this post from menchar can explain what you are seeing.

Based on this post, you could try setting you application sleeping mode to VAL_SLEEP_NONE when you need fast graph update, coming then back to VAL_SLEEP_SOME when your acquisition activity has finished.

[mowgli · Accepted solution]

Combining Roberto and Kanchan,

1. The machine configuration is: Pentuim CPU 2.8Ghz, 1 GB Ram, Windows XP, Labwindows CVI 2009.

2. The SetSleepPolicy concept seems to have solved part of our problem with the refresh rate for the application...we are very grateful for this input.

3. For all other users of LabWindows CVI, the TSQ concept takes a finite amount of time to place data in the queue...so if you are running at 10msec periodicity to process packets and say the queue write itself takes 50msec...a good idea would be to combine 5 packets and then write to the TSQ... earlier our packets were outstanding in the RS-232 COM port queue by many thousands for a one minute run...we have taken NI inputs to reduce it to less than five packets outstanding for the same amount of run time...also timing analysis of the code functions helped us rework our code by removing function calls that sometimes take a lot of time for processing system events, sync waits etc.

Thanks a ton Roberto...i might just meet my project deadline now 🙂

-Ashish