Introduction

The BMEP58•040S standalone safety CPUs support CIP Safety (IEC 61784-3) communication, and can use this protocol to establish a connection with a CIP Safety device over EtherNet/IP.

CIP Safety uses the consumer-producer mechanism for the exchange of data between safe nodes over EtherNet/IP. (DeviceNet or Sercos III communication is not supported.) The CPU acts in the role of originator that establishes a Unicast (one-to-one) EtherNet/IP connection with each target safety device. The CPU can establish a CIP Safety connection with target devices that support the CIP Safety protocol, and a CIP (non-safety) connection with target devices that support the CIP protocol.

As is the case with all safety PACs, the CIP safety CPU and Copro double execute the CIP safety stack in parallel and compare processing results.

Supported Architectures

Standalone M580 safety CPUs support CIP Safety devices located in DIO clouds.

NOTE: At present, no CIP Safety devices exist that support RSTP and can be installed in an eX80 rack. Thus, CIP Safety devices cannot presently be connected to the dual Device Network ports of the CPU, but can be connected to the CPU Service port.

DIO clouds require only a single (non-ring) copper connection, and can be connected to:

  • a BMENOS0300 network option switch module.

  • the service port of the CPU.

  • the service port of a BM•CRA312•0 eX80 Ethernet I/O adapter module on an RIO drop.

  • a copper port of an Ethernet dual ring switch.

NOTE: When a CIP Safety device is connected to the service port of a BM•CRA312•0 eX80 Ethernet I/O adapter module on an RIO drop, the target CIP safety device may not start automatically while the CRA is loading its configuration. To cause the CIP Safety connections to open as intended, you may need to manage the control bit of the CIP Safety connection in the target DDDT (CTRL_IN or CTRL _OUT) by toggling it from False to True after the BM•CRA312•0 finishes loading its configuration.

As with all equipment located in DIO clouds, CIP Safety devices are not scanned as part of the main RIO ring, and their connection status is not reflected in the CPU LEDs.

For additional information on DIO clouds, refer to the Modicon M580 Standalone System Planning Guide for Frequently Used Architectures and the Modicon M580 System Planning Guide for Complex Topologies.

Configuration Overview

Configuring CIP Safety communications involves three separate configuration tasks:

  • Configure the M580 Safety Standalone CPU with CIP Safety settings in Control Expert. This includes the creation of an Originator Unique Network Identifier (OUNID) that uniquely identifies the CPU. The OUNID is created in Control Expert as a concatenation of two components:

    • Safety Network Number (SNN): An identifier for the CPU created in Control Expert.

    • Main IP address of the CPU, entered in Control Expert as part of the CPU IP address settings.

    Schneider Electric recommends configuring the CPU OUNID setting one time only, in the initial configuration. If you subsequently change the OUNID setting, you would also need to reconfigure all CIP Safety devices that are connected to the CPU.

  • Configure the CIP Safety device, using a safety network configuration tool (SNCT) provided by the device vendor. This includes two tasks:

    • Creation of a Safety Configuration Identifier (SCID): Also known as the configuration signature, the SCID is created in the SNCT and used by Control Expert when configuring the CIP Safety connection between the originator (CPU) and target (CIP Safety device).

    • Assignment of a Safety Network Number (SNN): The SNN is typically created for the CIP Safety device by Control Expert and is assigned to the device by the SNCT.

  • Configure the CIP Safety connection between the CPU and the CIP Safety device. The connection is identified by a TUNID that is created using the device connection DTM in Control Expert using a CIP Safety DTM, which can be based on a manufacturer provided EDS file or used alone if no EDS file is available.

Managing CIP Safety Device Connections

The CIP Safety CPU establishes a connection to a configured CIP device, and then manages the connected device. Because Control Expert supports both the CIP protocol and the CIP Safety protocol, it can manage CIP connections to:

  • CIP devices, which implement CIP over EtherNet/IP, but not CIP Safety.

  • CIP safety devices, which implement CIP Safety over EtherNet/IP, but not CIP.

  • CIP hybrid devices, which implement both CIP and CIP Safety over EtherNet/IP.

NOTE: A CIP device and a CIP Safety device each requires a single DTM for configuration. A CIP hybrid device–which incorporates both the CIP and CIP Safety protocols–requires two DTMs: one configured as a CIP device; one configured as a CIP Safety device.

Establishing an Originator -> Target Connection

The M580 standalone CPU uses only the Type 2 Safety Open request to establish a connection with a CIP Safety device. A Type 2 Safety Open connection can be made to a safety device only after the device has been configured by an SNCT. In cases where the CIP Safety device is a third-party product, Control Expert does not possess and cannot download a configuration file to a CIP Safety device and cannot be used as an SNCT.

NOTE: By contrast, a Type 1 Safety Open connection both provides the safety device its configuration settings and also establishes the connection. M580 CIP Safety CPUs do not support the Type 1 Safety Open connection request.

The following diagram presents an overview of the how a CIP Safety connection is created between the CPU as connection originator and the CIP Safety device as connection target:

In this diagram, the following events occur:

  1. Control Expert uses a vendor provided EDS file as a basis for creating a DTM for the connection between the CPU and CIP Safety device.

  2. The device SNN is created in Control Expert, then entered into the SNCT.

  3. The SNCT creates the SCID for the device, which is entered into Control Expert as part of the connection configuration.

  4. The SNCT downloads to the device its configuration settings, the SCID created by the SNCT, and the SNN created by Control Expert for the connection.

  5. The CPU as originator sends the device a Type 2 Safety Open Request.

  6. The CIP Safety device sends a Safety Open Response to the CPU.

  7. If the checksums in both the request and response match, the connection is established.