continuous data acquisition pause

[MorrisSzyslak]

Hello, I use some cDAQ-9181 in Windows XP. I develop in Borland C++ Builder and access the devices via the c-API. Most of the time everything works fine. However, randomly one of the devices or maybe just the driver stops giving data. Then after a couple of seconds I can read the delayed data. I tried different approaches on reading the data: -timer based, each second reading a fixed number of samples waiting for a timeout -timer based, each second reading all available samples from the buffer -triggered via a synchronous callback function, reading all announced samples -triggered via an asynchronous callback function, reading all samples with each approach I get delays. When reading timer based I also get the error code -200279, which requires the restart of the sampling task. Any of the devices is affected. I also tried to increase the process priority of the application and the driver process (nimxs.exe?), without effect. I can deal with a delay of up to two seconds, but I have seen delays of up to ten seconds. Unfortunately I didn't find anything helpful in the FAQ or forums. Can someone point me a direction where to look? Has someone experienced similar problems? Any tips on what to improve? My setup: seven cDAQ-9181 (1-slot-ethernet-chassis) with NI-9215 (4-channel-AI-module) task is continuous sampling of one channel of each device at 1kHz machine: dual core atom; 2GB RAM; CPU-load at ~5%; network load at ~0.3%; no antivirus

[FCTesting]

Hey MorrisSzyslak,

How do you have the 9181 chassis connected (directly, over network)? Have you looked into your network traffic and connection quality? It is possible that the network connection is causing the delay. I would also suggest looking into whether this error will still occur reading only 1 chassis.

Also how often does this occur and do you recieve any other error codes when the delay happens?

[MorrisSzyslak]

Thanks for your reply,

the chassis are connected via some switches to the PC. Cable lengths for the test setup are <5m. Later we'll use ~60m, WLAN and fiber. The chassis and PC all have static IPs. No other devices in the network. Network traffic looks very regular from what I can see in the task manager: nearly constant at about 32K. When I disconnect a chassis then there is a gap in traffic as one would expect. When a pause occures the traffic is still constant. So I think the chassis are sending data continuously, but the driver has some problem to process the data or the read requests.

When I read the data upon the callback trigger, then there are no error messages. Only the callback isn't called for some time and after that pause it's called with a greater nSamples. So I don't "loose" any data, it's just belated. One more thing I noticed recently: the callback thread is halted when a pause occures and resumes after the pause. So probably the pause occurs within the function executing the callback inside the driver?

When I read timer based then sometimes there is the famous error -200279, sometimes not. Seems to depend on the duration of the pause. When I get the error, then I have to restart the task, otherwise the error persists and I can't get any more data. The error message telling me to "read data more frequently" is a bit ironic, since I try to do just that 😉

When I started on the project I had but one device for testing and the problem was the same but to a much smaller extend. Maybe once or twice a day. At that time we decided that it could be ignored. Now with seven devices I can see pauses quite randomly but nearly every five minutes, sometimes every 20 seconds. The interruptions seem to affect a certein device at some time of the day more frequently then wander off to another device. But all of the devices are affected at some time.

Regards, Moe.

[MorrisSzyslak]

Oh my.

A colleague of mine suggested to take the error message literally: "read data more frequently." I do now read the data every 100ms instead of 1 second. I hadn't thought that it would make a difference - I was wrong.

Now it happens once in a while that I don't get data for a read command, just as it was with the 1 second interval. However, the pause that occurs is - until now - always less then a second. So I have at least some samples at the end of each second to work with. The problem as such may be solved...

...I still don't get how this could make a difference. I'd appreciate any comment that sheds some light on this mystery.

[AnMu]

Hi Moe,

if you use the timer based method, when you read all available samples from the buffer and you get a delayed response, then your solution to fix this problem is correct.

In this link, it is explained why you should read the data more frequently.

http://digital.ni.com/public.nsf/allkb/AB7D4CA85967804586257380006F0E62#freq

Regards

Anoj Mubarak

National Instruments