Handling broken i/o connections, Handling broken i/o connections -103 – Delta RMC101 User Manual
Page 353
Ethernet 5.2
Communications
5-103
Otherwise, when the Sync Out Register is changed, the commands would be re-issued.
3. Write all required command fields to the Output Data for all commands you want to issue.
You can issue up to one command per axis. Leave the Command field set to 0 for each axis that
you do not want to issue a command to.
4. Change the Sync Out Register.
The easiest way to do this is to add one to it. Some PLCs report an error when a register
overflows (e.g. 32,767 to -32,768), so you will instead want to add one and mask it with a value
such as 16,383. This will make the register count from 0 to 16,383, and then wrap back down to 0
without an error. Take care to ensure that you only update the Sync Out Register once so that the
commands do not get re-issued. Therefore, you may need to do intermediate processing in a
separate local register and copy the result into the Sync Out Register.
5. Wait for the Sync In Register to match the Sync Out Register.
It is important to wait until this occurs before using the status bits in the Input Data. See the
example above for how problems can occur if this step is ignored.
Configuration Data
In addition to the Input and Output data that is sent every RPI, configuration data can be sent
when the connection is established. The RMC defines only the first configuration byte. Any
additional configuration bytes must be zero or the connection attempt will be rejected. This byte is
defined as follows:
Configuration Data:
Offsets and sizes are in 8-bit bytes (SINT on the ControlLogix)
Offset
Size
Description
0
1
Broken Connection Action.
This byte controls the
RMC's handling of a broken controlling I/O connection,
or a transition of the controlling EtherNet/IP client from
Run to Stop/Program. The options for this field are
described in Handling Broken I/O Connections.
If no configuration data is sent when the connection is
established, then this value is assumed to be -1.
5.2.6.3.5 Handling Broken I/O Connections
It is important in many industrial applications to detect faults quickly. One such fault is losing
communication to EtherNet/IP I/O. EtherNet/IP supports a variable timeout value, which is
expressed in terms of Requested Packet Intervals (RPIs). For example, the ControlLogix
establishes its EtherNet/IP I/O connections with a timeout of 32 RPIs. Therefore, an RPI of 5.0
ms will have a timeout of 32 x 5.0 ms or 160 ms.
When either device in an I/O connection does not receive a packet from the other device for the
timeout interval, it closes the connection and typically indicates this condition to the main
program. The method of indicating this condition depends on the actual device. This topic
describes the methods used by the RMC and ControlLogix.
Handling Broken I/O Connections in the RMC
The following conditions are defined as a broken connection in the RMC ENET: