Is the problem unique to the 9184? I see you have been testing with a 9188 only, and your 9184 doen't look like it has any moduels fitted.
i have not a 9184 on my side. In both 9188 was a 9206 to check, if after a restart of my pc the modules directly can be used without reseting the device.
The behavior you are discussing is a known challenge in network connectivity for all ethernet DAQ devices. Tom provides a great explanation here.
Does your chassis stay powered up all the time? It sounds like you are shutting down your host each evening and then booting it again in the morning.
You may be interested to know that both the host (running DAQmx) and the chassis are aware of their connection status and attempt to keep a connection active at all times by corresponding via a 'heartbeat' message. If either side of that communication isn't possible then the entire communication path between host and chassis comes into question.
If either side of the link senses a loss in connection (or if both do), then some action is required to re-establish communication. In the case of the host-side losing its connection to the device (which a reboot would definitely qualify as), any driver operation will cause DAQmx to reinitiate communication.
The challenge, I'm guessing, is that you are trying to perform DAQmx operations on the modules in your chassis. In the case where a chassis is Added but not Reserved, or where the chassis has sensed a connection lapse, the chassis shows up as present in the system but modules do not. So, in order to make your modules re-appear you end up having to Self Test, Device Reset, or otherwise interact with the chassis before you can program the modules again.
There are cases where the driver will attempt to automatically Reserve and make the chassis and modules accessible, but if the chassis remains active while the host connection goes 'down', then there can be this sort of confusion between host driver and chassis. If you could ensure that the chassis was powered down and rebooted around the time that the host machine was it *might* re-establish communication automatically. But, as Chris mentioned, inserting a Self Test or Device Reset at the beginning of your application would be more of a fail-safe.
Hopefully this helps-
Thanks for that explanation. I have a similar problem. I did NOT know that there is a "heartbeat" communicatin between the host and the chassis. Is that documented somewhere? I need to know the timeout of teh heartbeat. Also, is there any way to "inquire" of the chassis to determine what state it is in? I found a LabVIEW utility that I can ""ping" the chassis to see if I physically have a network connection and power. But I can find no tool in the DAQmx tool pallete that allows you to query the chassis for the state that it is in. I alway get an Daq read error after the network goes down.
Unfortunately, no -- the heartbeat is not publicly documented. For most cDAQ users, it's an irrelevant detail, given that we abstract much of the network connectivity effort in order to provide an experience that is as close to plug-n-play as possible. Does your project involve advanced networking? Why do you need to know the timeout? Are you receiving errors that indicate network timeouts?
The System Configuration API can provide information about local and remote systems and devices that your host has configured or detected. I recommend checking out Show All Hardware.vi for an idea of how to use the Hardware Management palette to query device info. You can find it in the Example Finder under Hardware Input and Output»System Configuration. In the System Hardware (or System Filter) property node, look for the property Is Present under Devices & Chassis. You should be able to determine the state of your networked chassis by querying Is Present through the Hardware node, but you may notice that it takes some time to return any info for a device that has dropped off the network. Depending on your application, you might find that simply handling network timeout errors in your code is a better option. There are some tradeoffs to balance.
I am trying to error check my application. I am setting up remote facility sensing chassis. This is a continuously running application logging inforamtion. Occasionally, the network may go down or the power may go off. I am pinging the units before I try to read them. That portion works fine.
The probledm I have is that if the network goes down for 10 seconds (that is the rough heartbeat timeout I have found) or more, but come back up, the ping will work fine, but when I try to do a read on the unit, it is lost in the indertiminate state because of the loss of connectivity. The cDAQ Chassis does NOT return to the state it was programmed to before the loss of connectivity.
I can't fine a tool that lets me query the cDAQ Chassis to see if it is in the indeterminate state.
I'll check the resources you suggested.
At first glance, this seems like a pretty big hole that NI left in the cDAQ operation. If the cDAQ Chassis has lost the heartbeat, I need a tool that I can query the chassis with to know that. Otherwise, I have to start writing lots of "what if" code to handle all the errors generated.
Thanks for explaining. Certainly, check out System Configuration to see if it will be an appropriate solution -- it does exactly what you're asking, but it may not do it in a way you can easily implement in your existing code. *fingers crossed*
Ultimately, our most common recommendation for recovering (or "reaching out to") a chassis that has lost connection with its host is to programmatically call Self-Test. That approach would replace your current method of pinging a device before reading from it, and the advantage would be that Self-Test reaches out to the chassis, where a ping just tells us if it's present on the network. I don't know off the top of my head how much longer (if at all) it will take to execute a Self-Test compared to a ping.
*Calling Is Present from System Configuration also reaches out to the chassis.
Thanks again for the information. Here is my situation.
I am developing a system that will span multiple chassis over a network. Each chassis can be a single module up to an eight module chassis, as needed by the customer. All the modules will be 9219 modules. This is a slow collection speed. I will be monitoring pressures and temperatures around the clock for very long periods of time. The data collection rate will only be once per minute or so.
What I don't want to occur is to have so much setting and resetting of modules that I begin to spend more time configuring modules than I do taking a reading and then waiting until the next read time.
A little clarification, just so I know I am on the right track and we are on the same page.
1. When a 9219 module is configured for a measurement in a 9181, 9184 or 9188 Chassis, does it maintain that configuration even after a power loss to the chassis?
2. When a 9219 module is configured for a measurement in a 9181, 9184 or 9188 Chassis, does it maintain that configuration after a loss of "heartbeat signal" to the chassis?
Per our previous conversation, I looked some more at the available tools in the palletes. There is not a tool I can find that reports the "heartbeat" status. Essentially, the network side of the chassis says everything is OK, but the Module side of the chassis is not communicating.
If the answer to quesion #1 is "No", then I will need to put a timer in a loop using the "Self Test" vi and determine if the chassis did indeed lose heartbeat.
I can use the "Self-Test" vi, and it will force the module to "re-link" if the heartbeat has been lost. But I do not know the length of that delay. and if it consistent.
The unknown I have at this point is does the "Self-Test" completely restore the configuration to the Module, and is it ready to execute a Read, even if the power went out?
Another unknown is the state of the module configuration during loss of heartbeat. Does the 9219 module maintain its operation?
I guess I a a little baffled that there isn't a register setting in the chassis that is set high if it lost heart beat, and then register could be read.
I might have missed this in the discussion, but have you tried to programmatic reserve/unreserve the chassis?
For the very long time between samples you could do something like this:
Force reserve chassis --> start acquisition task --> acquire fixed number of samples --> stop task --> unreserve chassis
and simply repeat this every minute.
That is not a desirable solution. Depending on tthe customer requirements, I could have 10-15 different chassis takinga reading once per minute. IF it takes 10 seconds to reserve a chassis snf I hsvr 10 chassis, I am at 100 seconds. I need to collect the data as close as possible to the interval (60 seconds)
Having to write workaround code for missing, needed hardware functionality is not a good thing.
NI should have a tool that keeps track of the loss of heartbeat and give you the ability to query it.