1756 en2t connection managment

[mcgov]

We have a 3rd CIP (ethern/IP) stack communicating to a remote i/o chassis using 1756 en2t bridge module in the remote chassis. We want to failover to a second processor. Does anyone have any experience with the proper sequence to 'close' down all the module connections in the remote rack, or information on how the remote rack will time out if the owner controller stops communicating.
Thanks

 

[Ken Roach]

Do you mean a 3rd Party EtherNet/IP stack with a custom controller ? I have not seen any of those that will connect to 1756 I/O modules, though there's nothing special that says they can't.

I am also concerned because it sounds like you're trying to implement a redundancy system using a network that even A-B doesn't use for I/O redundancy.

Generally a cyclic CIP connection is declared "timed-out" after 4x the API, with a minimum of 100 ms.

When a 1756 I/O module or chassis object connection breaks, the module or chassis object goes to its configured fault mode. Most output modules are configured to simply turn off their discrete outputs and set their analog outputs to zero. Most 1756 series output modules can be configured on a per-channel basis to hold last state or go to a specific output value in the event of a connection failure. This configuration is sent to the output module during the CIP connection establishment process, usually as a Configuration Assembly object.

 

[mcgov]

Ken,

Yes a 3rd party stack with a vme processor. We are connecting and operating fine to multiple chassis.

Yes we are trying to implement a non-standard failover scheme due to some unique requirements.

We are working to establish a consistent method of managing the connections during failover, or consistent time the remote chassis will need go to a known state prior to establishing connection with a secondary processor.

Do you know if your statement below applies the controller side and the module side of the connection: "Generally a cyclic CIP connection is declared "timed-out" after 4x the API, with a minimum of 100 ms."

Thanks,
mcgov

 

[Ken Roach]

My advice is going to be limited, then; I can only tell you how I've observed A-B controllers on the network.

The connection failure time is negotiated at the time of the connection; the timeout multiplier is transmitted along with the other aspects of the connection like the connection ID. In every implementation that I've seen of EtherNet/IP, the connection multiplier was 0, which means "default 4x API".

The controller will consider the I/O module connection timed out after 4xAPI, and likewise the I/O module will consider the connection timed out after 4xAPI.

The connection originator (the controller and its originating network bridge) will send a CIP Connection Close request after the timeout but of course in the case of an actual disconnection there is no reply. If for some reason there is a reply, the connection is placed in a shut-down state by both devices.