From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to prevent cDAQ digital output from resetting after communication interruption

I have a NI-9188 8-slot ethernet cDAQ chassis with a NI-9375 Industrial Digital IO module driving a set of valves. I've observed that if the network communication is interrupted (such as unplugging the cable), the cDAQ will maintain the last state that was commanded. This is exactly what I want it to do. However, when network communication is restored the module resets, thus going through its power-up state of all outputs off and closing all of the valves momentarily until the software sends the desired state again. This is an undesirable and potentially hazardous behavior for this system. Is there any way to prevent this re-connect reset behavior?

0 Kudos
Message 1 of 4
(2,822 Views)

JamesLM,

 

It is possible to configure programmable power up states for a lot of our devices.  For the case of the cDAQ the power-up state is dependent on the modules and not the chassis.  Unfortunately, for the NI 9375 the Digital Output power-on state is defaulted to all channels off.  This can be found within it's operation and specification manual (pg.20). The link to the operation manual can be found here: http://www.ni.com/pdf/manuals/374644b.pdf

Aaron L.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 4
(2,770 Views)
Yes, I am aware of this and the power-up state of all-off is what is wanted. What I'm asking is if there is any way to prevent power-up from happening when interrupted communications are restored. An analog I would draw is to a microcontroller like the arduino: those devices will by default restart on each new USB connection, but can be prevented from doing so by connecting a capacitor between the reset and ground pins. Perhaps there is a setting or jumper that would have the same effect on a cDAQ?
0 Kudos
Message 3 of 4
(2,762 Views)

I don't think NI would want you monkeying around inside their hardware anymore than Apple would with their phones.  It can be frustrating working with closed source hardware, and I highly suspect there is not a simple solution like a cap keeping a reset from happening.

 

I doubt this is an option for you, but what if you had a setup where you had an enable digital output, and a state digital output.  So to turn on an output you need to turn on both the enable, and the state.  Then to turn the state off you need to turn on the enable, and set state to false.  This would then prevent an output from turning off, if both the enable, and state went false from a reset.  This would need some extra hardware in the form of multiple relays, or comparitors but honestly I can't think of any good option to work around this.

 

Another solution that would work, but cost a crap ton is to move to the cRIO platform where it can run headless.  Here the cRIO is considered smart where the cDAQ would be dumb.  You can then write the code you want the cRIO to perform when a connection is lost or found.

 

I hate these options, but if you are running some kind of safety critical system a cRIO is probably the best route.

Message 4 of 4
(2,747 Views)