Controlling the RMC over EtherNet/IP I/O

As described in the Setting Up an EtherNet/IP I/O Connection topic, each RMC can have I/O connections open with up to four EtherNet/IP clients (such as the ControlLogix PLC). Only one of these connections can produce data for the RMC to consume. All of these connections will consume data produced by the RMC.

The following diagram shows three clients accessing a single RMC:

Notice how the RMC produces one data frame that is consumed by all three clients using what is called a multicast. All three clients produce data frames consumed by the RMC, but only one has data for the RMC (CL1 in this example). The other two are heartbeat frames to time out old connections. These heartbeat connections are shown as dotted lines in the above diagram.

Therefore, excluding the heartbeat frames, the RMC only receives one set of data and generates one set of data each RPI, regardless of how many I/O connections it is handling. So, what data is included in these frames?

Output Data (from Client):

Offsets and sizes are in 16-bit words (INT on the ControlLogix).

In addition to the above Output Data, the controlling client also sends a four-byte prefix, which indicates whether the client is in Run or Program mode. This is used as described in Handling Broken I/O Connections.

Input Data (to Client):

Offsets and sizes are in 16-bit words (INT on the ControlLogix).

The Input Data is updated and sent at the RPI by the RMC regardless of the state of the Sync Registers. As described below under Using the Sync Registers, the Sync Registers only apply when issuing commands.

Using the Sync Registers

The RMC ENET does not look at the command registers in the Output Data it receives until the Sync Out Register changes. When this register changes, then all commands for all available axes are processed.

The Sync In Register will change to match the Sync Out Register after the command(s) have been received by the RMC and the status registers in the Input Data have been updated.

Sync Registers are used for the following reasons:

• To avoid splitting up of commands issued to the RMC.

Example:

The ControlLogix does not synchronize its I/O with the PLC scan. Therefore, in the time it takes to place values in the command words for one or more axes, the Output Data could be sent out to RMC, mixing some old and some new data. By having the RMC ignore command changes until the Sync Out Register changes, this problem is avoided.

• To coordinate when the status in the Input Data has been updated to reflect a command that was issued.

Example:

Suppose an axis is in position, and therefore the In Position bit is set in the axis's Status word. The PLC sends a Go (G) command to this axis to move it to another position. As soon as this command is received by the RMC, the In Position bit will be cleared, and it will not be set again until the axis reaches the new position. However, if the In Position bit in the Input Data is checked before the client receives Input Data reflecting the Go command, then the In Position bit will still be set, possibly leading the PLC program to think the axis is in-position prematurely.

Here is the recommended sequence for issuing commands:

1. Wait until the Sync In and Sync Out Registers match.
   If they do not match, then this means that another command or set of commands is in progress.

2. Clear any old commands from the Command registers for each axis.
   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)

Copyright (c) 1997-2015 by Delta Computer Systems, Inc.