Understanding CIP addressing

Messages can be transmitted through a CIP system in either of the two ways: connected or unconnected.

To use connected messaging, you must first establish a connection to the CIP Message Router in the target CIP node (using a DTL_CIP_CONNECTION_OPEN call or DTL_CIP_LARGE_CONNECTION_OPEN). This provides you with an application connection ID. You can then send a message on the connection by making a DTL_CIP_MESSAGE_SEND call, specifying the application connection ID (in a DTSA_AB_CIP_CONN structure) along with the Internal Object Identifier for the desired object in the target CIP node. In order to establish a connection, unconnected messaging must be used.

To use unconnected messaging, you must explicitly identify each CIP node in the communication path to the target CIP node, in the form of a path segment. Each path segment contains both a

CIP port

which identifies the network interface through which the message is to be sent and an

CIP link address

which identifies the destination CIP node on that network. This path is built into a DTSA_AB_CIP_PATH structure, after which it can be used in either a DTL_CIP_MESSAGE_SEND or a DTL_CIP_CONNECTION_OPEN (or DTL_CIP_LARGE_CONNECTION_OPEN) call.

In order to understand how paths are constructed, you need to know which devices in a CIP system are actual CIP nodes, and which are merely communication interfaces. This is not necessarily obvious.

Send unconnected CIP messages externally

When an application wants to send an unconnected message via RSLinx Classic, the first path segment in the communication path must identify the

hop

from RSLinx Classic to the next CIP node. The CIP port in this case corresponds to the desired RSLinx Classic driver, and the meaning of the CIP link address will vary according to the driver. For example:

When using the RSLinx Classic SDK's DTSA_AB_CIP_PATH or DTSA_AB_DH_CIP_PATH structure, the driver_id field of the structure already identifies the CIP port. When filling in the

baPath

field, the CIP reserved port 0 is used in the first path segment to indicate that the actual CIP port is determined by the driver ID. If the specified driver requires a link address, this initial path segment specifying CIP port 0 must be included in the baPath field. Otherwise, an application may omit this initial path segment. (The RSLinx Classic SDK will pre-pend this segment internally when it sees that a driver was specified.) If the application does include this path segment for a driver that needs no link address, the full form of the path segment should be the following two hex bytes: 10 00. (This is interpreted as port 0, with a zero-length link address.)

Send unconnected CIP messages internally

It is also possible for an application to send a CIP message to RSLinx Classic itself or to another application running in the same host computer. When constructing a DTSA_AB_CIP_PATH using the RSLinx Classic SDK, this is accomplished by setting the driver_id field to the return value of DTL_GetRSLinxDriverID. In the absence of any path segments, RSLinx Classic itself will process the message. If an initial path segment with CIP port 1 is specified, however, the message will be serviced by an application on RSLinx Classic's internal virtual CIP network. See DTL_CIP_APPLICATION_REGISTER for information on how an application using the RSLinx Classic SDK can register a CIP link address with RSLinx Classic to receive messages on this internal virtual network.

Send PCCC messages through a DHRIO DH+ channel

For RSLinx Classic to send a PCCC message over a CIP network (for example, ControlNet or Ethernet) to a ControlLogix Gateway to be bridged out a DH+ Channel of a 1756-DHRIO module, a CIP path to the DHRIO module must be constructed. This path must be built into a DTSA_AB_DH_CIP_PATH structure (with an extra DH+ Channel Identifier byte added). This DTSA structure can then be used with any SDK function that sends PCCC messages. RSLinx Classic will use the specified path to open a CIP connection to the DHRIO module and forward the PCCC message over that connection.

Receive CIP messages

An application using the RSLinx Classic SDK can receive CIP messages sent over ControlNet and through a KTC card. The application must register a link address with RSLinx Classic. (See DTL_CIP_APPLICATION_REGISTER.) The path from a device on ControlNet will then consist of three path segments. The first path segment will specify the device's ControlNet port and the KTC card's configured MAC ID. The second path segment will specify port 1 and link address 0. (This gets you from the KTC card into RSLinx Classic.) The third path segment will specify port 1 and the application link address you registered. Port 1 here represents an internal virtual CIP network managed by RSLinx Classic in much the same manner as the DH+ Virtual Link.

For more information on how an application can receive CIP messages and accept CIP connections over this path, see DTL_CIP_APPLICATION_REGISTER and Understanding CIP Communications.