Please enable JavaScript to view this site.

DAQFactory User's Guide

Navigation: 0 Licensing and Performance

0.2 DAQFactory Performance

Scroll Prev Top Next More

Often DAQFactory users will use the Windows performance monitor to see how much CPU power DAQFactory is using.  The performance monitor is a bit deceiving when using DAQFactory. To truly determine how much processor time is being used, go to the channel list or other configuration view. This will tell you better about how much processor power is being used to perform the acquisition and sequences.

It is also important to remember that as long as the CPU usage isn't hitting 100% you are fine. Even if it touches 100% occasionally, data acquisition and sequences have priority over the user interface and many other things in Windows, and so will run fine.  Also, the CPU will often hit 100% when you are manipulating components, turning a knob say, or when dragging windows around, or other such things. With the exception of the fastest computers, most systems will do this even without DAQFactory. To see this, just open the task manager and start dragging it around the screen.

The bottom line is that unless the user interface is sluggish, or your loops are not running in the times specified, or you are getting Timing Lag errors, you should not worry. But even if one of these things happen, the problem may not be with CPU power. For example Timing Lag errors are most common when you try and overdrive your DAQ hardware. The most common reason for a sluggish user interface is having a looping sequence without a reasonable delay(), or by using wait() improperly.  

If you are really concerned, here are a few other things you can do to help performance of your application:

1) Reduce the refresh rate of the screen (right click on the page name and select Properties...). The default is 2 hz.  There is no reason to have a refresh rate that is faster than your fastest data rate.

2) Keep your history lengths on your channels at smaller values. This is usually only an issue if you have histories above 20,000 or so on slow computers.  On newer computers, history lengths in above 100,000 are easily possible.  If you need larger histories or persistence lengths, make sure and subset all your data before manipulating it.  For example, if you are doing a graph, don't just put the channel name, but rather subset to the x axis scaling.

3) Check your sequences for reasonable loop times, and whenever possible, use events instead of sequences with loops.  For example when monitoring an input for a particular value, you should use that channel's event instead of creating a sequence loop, though you do need to be careful not to do anything slow in the event.