1794-ADN Devicenet Flex I/0 PWR Loss

terlija

Member
Join Date
May 2017
Location
Massachusetts
Posts
9
Here is the scenario that I am sorting through.
Outputs in a flex I/O rack are commanded on off by a Foxboro DCS system logic via Devicenet to a Flex I/O 1794-ADN Devicenenet module .So with all outputs in a normal running state, power bump or loss occurs. DCS system is backed by UPS so output commands remain 'on' for typical 'enable' signals to VFD's, valves etc.. Power is returned to the Devicenet rack, but the outputs on the Devicenet reack remain off. We tried the HLS [ hold last state ] feature on the Devicenet Flex I/O communication module , but it did not set the outputs on after power up and comms reestablished.
Is there a reason for this that anyone is aware? It actually seems inconsistent as well. Like once, it actually recovered as expected, next power off simulation, the outputs stayed off aven though DSC is commanding off.

Thanks- Raylan
 
Is the UPS only holding power on Processor and not rack (if I read correct)
What type of output module are you referring to 1794-xxxx
 
If the adapter is not locked out by the PRL switch, it
will be automatically reset via special commands sent over the
communication link.
Do not cycle power to the adapter to clear a fault. All
queued block transfer instructions will be lost.

Not sure what special commands are needed to be sent to reset
 
Only cycling power to simulate a quick outage or power bump. It's an agitator motor in a bioreactor that need to restart when power is cycled. The enable / run signal from the DSC controller remains 'on'. I'm not sure about PRL switch setting, but the rack powers up normally when power is restored and devicenet comms re-establish on thier own. Outputs do not return to thier previous commanded state even though the controller is telling them to be on though, thats the issue.
 
Does the ADN get set up with a first pass bit on Processor. If so maybe your loosing the module configuration and since Processor stays on it never re sends configuration.
 
I think the OE4 Gets set up with a Block transfer usually with a first pass bit to a BTW
 
Processor Reset Lockout and Block Transfers are features that are specific to the 1794-ASB, the classic Remote I/O Adapter for 1794 FLEX I/O.

They are not relevant to the 1794-ADN DeviceNet Adapter. The DeviceNet node number is the only physical setting on the adapter; everything else is in its configuration held in nonvolatile memory.

And remember that this is Foxboro DCS, not an A-B controller that's acting as the network master. How it handles slave device connection failure is up to that firmware.

If the 1794-ADN is powering down during the power loss, then the Foxboro DCS should be sending it an all-new connection request and Polled I/O connection. When the Adapter comes back online, it should set the outputs to whatever state the data in that connection commands them to.

I'm interested in whether the I/O connection is actually being re-established correctly. What are the status of the LEDs on the 1794-ADN ? Do the analog outputs on the 1794-OE4 module operate correctly after the power cycle ?

My speculation points to two things: that the Foxboro isn't resetting the I/O connection properly, or that the 1794-ADN is not applying the new Output data correctly. Those adapters are very mature and stable, but I can't completely rule out a firmware bug.

The Analog module connection and reconfiguration might require a separate thread of explanation, as it can be saved in the 1794-ADN adapter or sent at every re-connection as part of the Output data connection.
 
'If the 1794-ADN is powering down during the power loss, then the Foxboro DCS should be sending it an all-new connection request and Polled I/O connection. When the Adapter comes back online, it should set the outputs to whatever state the data in that connection commands them to.'

My question is, if 1794-ADN powers down and Foxboro DCS remains up by UPS, is it possible that Foxboro needs to re-connect or re-initialize to the adapter? If we turn the agitator enable off and then on again for example, it restarts and everything else comes back on that should've been on.
Thanks for your input Ken.
 
Any time a networked slave device connection fails, the master device has to re-establish the connection. That applies whether the slave device is physically unplugged, or is powered down, or is reset is some other way. That is a totally normal function.

My first diagnostic step would be to power down the 1794-ADN and then watch the LEDs to see if the connection re-establishes.

If the "MOD/NET" LED stays blinking green, then that's evidence that the Foxboro DCS is not establishing a new logical connection to the adapter.

If the MOD/NET LED goes solid green then the I/O Status LED can tell you if the connection is still in Idle mode (like if a PLC is put into PROG mode) or if it's running properly (solid green) and commanding the outputs to be OFF.

This sort of multi-vendor compatibility and functionality testing used to be my job at Rockwell, and I used protocol analyzers and to capture and analyze the traffic and functions.
 
Yeah this is what I was trying to do before lunch. Monitor the traffic on the devices. However, as noted, my analyzer wouldn’t even see the devices because it shows that the bus termination resistors are ‘missing’. I only saw one resistor in the main panel. I’ll go back up later or tomorrow to try and locate the second one and see why I can’t see the devices.
Thanks again Ken, I appreciate your feedback.
 
termination resistors

Because of the voltages put on the lines by the CAN transceivers during operation, I always check for termination with the 24V DC DeviceNet power off, and use an ordinary DMM between the blue and white signal wires and measure for resistance.

You should see about 60 ohms when both termination resistors are in place. The more nodes connected to the segment the lower the parallel resistance is, so in practice I measure between 55 and 60 ohms.

Resistance in the 120 ohm range suggests strongly that only one terminating resistor is installed.

What type of analyzer do you have ? I used to use an internal Rockwell tool as well as the Frontline Test Equipment network analysis suite.
 
GridConnect Devicenet Detective.
As mentioned, right now the detective won’t even see the devices because it sees a bus termination issue.
I can power down and check with a meter but the detective worked fine when checking on other segments that were powered up.

I’ll check on these things and get back asap Ken.
 

Similar Topics

This is killing me. I've only got one facility with DeviceNet and don't really know much about it. We're expanding that facility, and I need to...
Replies
7
Views
2,523
Hi all, We got hot backup redundant application with Compactlogix and DeviceNet network. Flex IO module connect to controller bus via...
Replies
2
Views
4,372
I have to configure new 1794-ADN Series C in my devicenet network. I have downloaded the EDS File and registered it. But while configuration in...
Replies
3
Views
1,010
I have 1794-ADN Flex I/O Adapter connected over device-net network with scanner . The I/O and network status led are blinking RED . I have...
Replies
0
Views
2,303
First of all im using a softlogix 5860 processor connected via 1784 PCIDS card to the 1794 devicenet adapter. my first module is a 16 bit DC...
Replies
3
Views
2,307
Back
Top Bottom