DAQFactory Slow to Respond (for a little while)

[jackwilson]

Hello,

I am using DAQFactory Base edition v. 5.84 to stream 22 channels from 2 labJacks. I am streaming at 500Hz, an I am using a history length of 36,000, and a persist length of 300,000. I made these values large because I was having problems processing the data as it was acquired, so i am now acquiring data for 3-5 minutes, stopping the stream, and then processing and selectively recording some of it to a file. I am using a Dell Latitude D830 laptop with a dual core 'Centrino Duo' and 4gigs of ram.

The program starts up fine, but as soon as I start the sequences and the streaming, is becomes really slow for the first 10-20 minutes. After a certain amount of time, it will run perfectly. By 'slow', I mean that the main screen flickers and updates slowly, and the data acquisition seems to skip data. The Windows Task Manager indicates that the CPU is not maxed out, only using about 40-60%. I experience the problem regardless of what page I am on, and I have checked my pages for components that access the persist file, but I have not foud any.

This is a pretty big problem for me because the system is designed to be mobile, and it is shut down and started up frequently. Do you have any ideas on why this is happening? I can upload the .ctl file if you need it, but it is pretty messy (lots of commented out, and misplaced code). I hope to clean it up when I get everything working.

Thanks,

Jack Wilson

[AzeoTech]

DAQFactory running slow is almost always caused by one of three things:

1) script in component events / actions that aren't really fast. Same applies to system events, especially onMouseMove. These scripts run in the primary thread of the application, the same one that handles the user interface and all the graphics. If they run slow, then DAQFactory will appear sluggish even if the CPU load is 100% because the UI doesn't get any processor time.

Never put a loop or a delay() or wait() in these scripts

2) loops without delays in script. Unless you are running your sequences at priority 0, and sometimes even then, you should always have some sort of delay inside a loop to ensure that the processor is released to windows to do other things. Usually the delay is created using delay(), but serial/ethernet comms in itself will create a delay, provided its not erroring out. A common mistake is to put a delay() inside a try/catch block rather than outside:

while(1)
   try
	  ....
	  delay(0.1)
   catch()
   endcatch
endwhile

The problem with this is if there is an error, the delay() is skipped and the loop runs at full speed, starving the processor.

3) channel events: these also need to be really fast because they run in the thread the data arrived in and keep the channel list locked up. This means two things: because they run in the thread of data acquisition, a slow channel event script will cause the data acquisition to stop while its running. For streaming data, this runs in an callback thread from the LabJack driver, which means it will keep the driver from processing more streaming data, and if its slow enough, cause a backlog and eventually stop the streaming. Second, the channel list may be blocked while its running, which means no other threads can access the channels, which essentially stops most everything.

As for what to do, I'd start by cleaning up your code. Waiting until you get it working to clean it up doesn't make sense, since the mess is probably hiding the cause of the problem. Save the document under a different name if you want to keep all that code somewhere for future reference.

Note that CPU usage is not always a clear indication of problems. I've seen lots of apps that run at 100% CPU without any issues, while others with 3% that are very sluggish (usually because of the first item above).