| Customize Help

Industrial communication with EtherNet/IP



MIL supports communication with the EtherNet/IP industrial communication protocol. EtherNet/IP is an industrial communication standard for connecting devices together, and it defines a communication protocol that allows interaction between devices used in industrial automation processes. This information is received or transmitted through the computer's (or smart camera's) 100 Mbit/1 Gbit Ethernet port. When using this protocol with MIL, your local computer is considered to be an adapter (equivalent to slave) in the network, and the EtherNet/IP controller (typically a PLC) is typically considered to be the scanner (equivalent to master).

Setting up the environment

To use the EtherNet/IP industrial communication protocol with your MIL application, you need to set up the environment on the EtherNet/IP controller's side and on the local computer's side.

You must configure the EtherNet/IP controller (using its appropriate software package) to recognize the local computer as a slave device. You must also configure the EtherNet/IP controller with the local computer's IP address; the local computer's IP address should be static. An EDS file is provided and can be found in Matrox Imaging\MIL\Config\EthernetIP of your installation directory.

Once the EtherNet/IP controller has been configured to recognize the local computer as an Matrox EtherNet/IP automation device, you must enable the EtherNet/IP protocol service using the MILConfig utility's Communication item. Then, if the local computer has multiple network adapters, use the Interface item to specify which should be used. The default assembly size on the local computer is 64 bytes, but can be changed in the MILConfig utility.

Receiving and sending data to the controller

To communicate with the EtherNet/IP controller, allocate an Industrial Communication context using McomAlloc() with M_COM_PROTOCOL_ETHERNETIP. To send data to the EtherNet/IP controller, use the McomWrite() function and specify the M_COM_PROTOCOL_ETHERNETIP Industrial Communication context that you have just allocated. The McomWrite() function actually writes to the local computer's assemblies the data to send to the EtherNet/IP controller on its next read cycle. To read data received from the EtherNet/IP controller, use the McomRead() function and specify the M_COM_PROTOCOL_ETHERNETIP Industrial Communication context. The McomRead() function actually reads the local computer's assemblies for data received from the EtherNet/IP controller during its last write cycle. So when you call McomWrite() / McomRead(), you must specify the assembly in which to write, or from which to read.

The EtherNet/IP assemblies are created in local memory when the EtherNet/IP service is enabled and configured using the MILConfig utility. The supported assemblies on the local computer that can be accessed from the MIL application are:

EtherNet/IP is a polling protocol (implicit producer) and as such, it should be noted that whatever is written to a local memory assembly (using McomWrite() with M_COM_ETHERNETIP_PRODUCER) might not be read by the EtherNet/IP controller if another McomWrite() operation occurs before the EtherNet/IP controller's read cycle is completed.

You can, for example, use McomRead() to receive a request from a EtherNet/IP controller to grab and analyze an image, and then return the analysis results, necessary for the automation process, back to the EtherNet/IP controller using McomWrite().

Assemblies and their data fields

The MIL Industrial Communication module is very flexible, knowing that different applications need to send/receive different information to/from the EtherNet/IP controller. As such, it allows you to establish how to divide the assemblies into different data fields (register fields). For example, you could organize data for your consumer and producer assemblies as follows:

  • Consumer assembly:

    • PLC ready bit. The PLC should set this bit when its ready for production.

    • PLC error bit. The PLC should set this bit when it is in an error state.

    • PLC reset bit. The PLC should set this bit when it is about to be reset.

    • Trigger bit. The PLC should set this bit when it wants the MIL application to initiate a grab and process operation.

    • Result acknowledge bit. The PLC should set this bit when it acknowledges that it has received a result from a grab and process operation.

  • Producer assembly:

    • Success bit. The MIL application should set this bit when the grab and processing was successful.

    • Failure bit. The MIL application should set this bit when the grab and processing was not successful.

    • Error bit. The MIL application should set this bit when there was an error in the grab and processing operations.

    • Project running bit. The MIL application should set this bit while a grab and process operation is in progress.

    • Success number bits. The MIL application should set these bits to identify the number of successful operations.

    • Failure number bits. The MIL application should set these bits to identify the number of failed operations.

Note that this is only an example of how you can organize your data in the assemblies. In addition, the software running on the EtherNet/IP controller (for example, a ladder logic software) must be aware of how the data is organized in the assemblies.

Explicit communication with another device on an EtherNet/IP network

The only time when the local computer needs to know the IP address of another device is when connecting as an Unconnected Message Manager (UCMM) to configure a setting of another EtherNet/IP device on the network. While explicit communication using TCP is supported, the EtherNet/IP standard intends for this type of connection to be used to configure other devices, and not as a primary method of consuming data from a producing device.

To configure or read a setting of a device on the network, you must specify the following when calling McomWrite() / McomRead():

In theory, you could explicitly consume data from another device by specifying its IP address and the device's relevant assembly ID, but this method will be slower than using implicit messaging. The EtherNet/IP protocol recommends to produce and consume data in an implicit manner. Implicit connections in EtherNet/IP are performed using the User Datagram Protocol (UDP).