10-21-2013 10:58 AM
10-22-2013 10:46 PM
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?
10-23-2013 12:33 AM
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.
10-23-2013 08:45 AM - edited 10-23-2013 08:46 AM
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.
10-29-2013 09:38 AM
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