Is there any update to this problem?
I am facing something similar with a cDAQ-9188 configured with a startic IP Address.
Basicaly, I am able to communicate normally with the cDAQ, but after some hours of running, the connection drops and the "Active" LED turns off. The only way to re-start the measurement is to create the task again and run it.
I had a pretty in-depth discussion with one of the NI application engineers. As of yet, they have not gotten back to me. I think it is a fundamental problem with the approach they have to using the cDAQ with the ethernet connection. They anticipated:
b) Continuous acquistion
c) End Acquisition and End Task
The 9219 Module is not intended for that. With it having a minimum acquisition time of 1.95 seconds, that does not make it a likely candidate for continous acquisition over the network. NI did not include tools to be able to query the chassis to ascertain the state of the connection. They really should have documented the "heart-beat" protocol and what happens when the heartbeat is lost.
You can "defensive" code around it, but it is not an elegant solution. Issuing the "Self Test.vi" will get it re-heartbeating again, but you have no way of knowing if your connection is lost or not.
If a DAQmx task is active on a module in the chassis and the heartbeat times out (which means the connection has been lost), you will receive one of these errors:
-201390 Connection to the network device was lost. This can indicate an unplugged network cable, a failing network component, or a network device that is reserved by another host.
-50405 No transfer is in progress because the transfer was aborted by the client. The operation could not be completed as specified.
The first one is preferred and most common, but the second one sometimes occurs because of the asynchronous nature of the way we handle TCP/IP transfers and cancellations at a low-level in NI O/S abstraction layers.
So, if you are actively running a task and one of these errors occurs, that is your signal that the connection is lost and needs to be re-established. If you are not actively running a task, then there is no running mechanism by which to report the occurrence of a connection loss. So, a Self Test will either confirm the connection or re-establish it.
One way to sense that a module is 'not present' (perhaps because the chassis connection is not yet active and will require a Self Test or Device Reset) is to check for this error when attempting to access module I/O:
-88705 The specified device is not present or is not active in the system. The device may not be installed on this system, may have been unplugged, or may not be installed correctly.
Initiaing a "Self Test" does not return an error. What vi or command would/did you use to get that error message?
I really, really wish NI would give us a specific query for heart beat status. Would make it much easier to error handle and make decisions without having to parse out inidividual error numbers specifically for that error.
Attempting to exercise any I/O on a module that was previously present but is in a disconnected chassis would give you -88705 and signal that a Self Test on the chassis is required. If you execute the Self Test (or any other driver call) and it fails because the network is permanently disconnected, you would see this error:
-201401 Retrieving properties from the network device failed. Make sure the device is connected.
If you are currently accessing the I/O module when the connection is lost, a DAQmx Read/Write would return either of the other two errors I mentioned.
So, you can always Self Test before accessing the I/O, and if it succeeds without error you can assume the I/O is there. Or, you can try to access the I/O and get the -88705 error which should then signal you to Self Test. It's a valid suggestion to add a way to query the connection status directly, but I think all cases are covered currently by the program flows I suggested above. If you can think of one that is not, please post and I will try to find another way to address the need with what is already available in DAQmx.
I take it from your reply that NI will not be giving us a query tool to ask the chassis if it has lost heartbeat since the last time it was accessed?
This is a little perturbing. You don't document the heartbeat feature at all. Then, to make sure you get error free responses, we are told to give it a "Self Test" command before each time we try to talk to it. Why not just include the "Self-Test" code in the background of all your access VIs? That way, we'll never see the issue at all.
I'll make the request one more time - PLEASE give us a tool that allows us to query the chassis to know if the heartbeat has been lost since the previous time we accessed the device. Do ya'll not foresee the possibility that a customer may want to know if the Internet connection was lost and for how long?
I will never say never on an API entrypoint, but I still contend that it is superfluous to have that.
The hearbeat mechanism is an internal implementation detail, so it is not something that is intended to be user-visible. It is just the mechanism we use to sense whether regular access to the device has been interrupted.
To answer your question directly, in my opinion, the way the device is handled in software does not make it necessary to know that the connection was lost at any point in time and the duration of that loss of connection if the device was not being accessed at the time of loss.
We consider the ethernet connection to be a "tether" between the Windows PC and the cDAQ chassis, much like a USB cable or PCIe interface on other devices. The cDAQ chassis isn't a device that comes and goes as it is accessed, then. It is there once when you start (or if it isn't, you can't start), and if it goes away while you are accessing it then that is a fatal condition.
So, you can probe the modules by trying to access them to see if the chassis and modules are accessible or not. If it was before (say, when you verified the device in MAX), chances are it still is. If not, you'll get an error that it isn't present. Or you can always just Self Test before your first module access. Either Self Test will succeed (and the tether will be established and verified) or it will fail because there is no network path to the device.
Once you're using the modules, if the connection is lost you'll get an error that indicates that, and you'll have to fix the condition (maybe a cable failed or something) and then re-establish the tether before you can use it again.
Sorry if I sounded a little snarky. Admittedly, I am not terribly familiar in dealing with the ethernet protocols. Just a little mystified that the heartbeat information is not included in the cDAQ Ethernet instructions. I would still like to know how long the interruption has to be, or how many packets are lost or whatever the protocal is, before it loses heartbeat. If I ever have connectivity problems that would be a handy bit of information to have.
Thanks for the feedback. We are investigating some products that may use a similar software architecture as the ethernet cDAQs, and as we add those and change or add features, there might also be an opportunity to update reporting for this sort of thing with cDAQ. I can't make any promises now, but I will definitely bring this up during the planning process. If it looks like we will add this feature (or something like this), I'll post back in this thread. If you need any tips about making your application robust to any transient disconnections, please post here and I will do my best to help.