Today we will say something about communication with PLCs manufactured by Mitsubishi. To be precise, they are manufactured by Mitsubishi Electric. And which PLCs do I specifically mean?
MELSEC product lines
There are several PLC product lines manufactured by Mitsubishi Electric:
- MELSEC-iQ-R
- MELSEC-iQ-F
- MELSEC-Q
- MELSEC-L
- MELSEC-F
- MELSEC-QS/WS
- MELSEC-A – the production of individual models ended in 2006/2008/2014
We focused on the MELSEC-L and MELSEC-Q series. Communication with them is described in the MELSEC Communication Protocol Reference Manual. This document also talks about the MELSEC-iQ-R series, but at the same time, it only talks about serial communication with this series. The implementation of the protocol in the D2000 is primarily focused on Ethernet communication.
From the point of view of classification, this is a standard request - response communication protocol. Communication takes place using TCP or UDP, the message format is the same in both cases.
The station configuration in the D2000, therefore, contains the IP address and port number (for both TCP-IP/TCP and TCP-IP/UDP lines). If a TCP-IP UDP line is used, the IP address and UDP port on which the D2000 KOM process will listen are entered. If the address is entered as ALL or *, the KOM process listens on all available network interfaces. If a TCP-IP/TCP line is used, the IP address and port are unused (the same is true in the Omron FINS protocol, which also supports both TCP and UDP variants).
Formats
In fact, the specification describes not one format for Ethernet communication, but even three! Their names are 1E, 3E, and 4E and they are probably gradually developed variants of the protocol.
The 1E format is the simplest variant. The message contains:
- Specification of operation - Subheader - e.g. batch read in bit or word units, batch write read in bit or word units)
- destination station identification - PC No.
- timer indicating the waiting time to complete reading/writing - ACPU monitoring timer
- section with data (Request/response data – e.g. type and address of data and values being written).
In addition to the header fields, the response contains information about the success (End code), optionally data (e.g. in case of a read request), in case of an error further error details (Error information).
Formats 3E and 4E have a more complicated structure. They differ in the implementation of the Subheader field. The 3E format has it constant, the 4E format also contains a serial number that is the same in the answer as in the request. The Access route field indicates the path to the target PLC, if it is located behind the PLC with which we communicate directly (i.e. it allows something like protocol routing, which is also present in the BACnet protocol – for example, the target PLC can be on a serial bus). Then a field indicating the length of the data follows (Data length), a timer indicating the waiting time to complete read/write – identical to 1E format (ACPU monitoring timer) - and a section with data (e.g. type and address of written data – however, specification is different than in 1E format - and values being written).
In addition to the header fields, the response contains information about the success (End code), optionally data (e.g. if there was a read request), and, in case of an error, further details about the error (Error information).
The data length specification and serial number allow sending multiple read/write requests using the 4E format and then process the responses, pair them, and evaluate them.
Another complication is the existence of two encodings. The binary encoding uses the "little-endian" data format. ASCII encoding sends numbers from the highest digit and its messages are 2 times larger than binary. The specification of read and write data is different for ASCII and binary encoding. The advantage of ASCII encoding is easier human readability when viewing communication logs. To preserve it, the "Text Debug" protocol parameter was created. If set to True and ASCII encoding is used, the communication listing is in ASCII format, otherwise in Hexa format.
Services
The Mitsubishi MELSEC protocol specifies a relatively large set of operations. We have implemented 3 basic ones:
- batch read in word units - reading of multiple values from a contiguous interval of addresses, data are read in words (2-byte units)
- batch write in word units - write of multiple values from a contiguous range of addresses, data are written in words (2-byte units)
- batch write in bit units - write of multiple values from a contiguous interval of addresses, data are written in bits
We have not implemented bit reading - we read bit variables using word units. In the case of discontinuous addresses (e.g. bit variables with addresses 0,1, 5, 20, 25) the entire address range (0-31, i.e. 32 bit variables, i.e. 4 bytes) is read. Two protocol parameters were created to limit the range. "Max Points" defines the maximum number of objects in one request, "Max Data Bytes" limits the size of data in the response. E.g. the read response of 100 word variables has 100 data bytes for binary encoding, 200 for ASCII encoding. The response to reading 100 bit variables has 13 data bytes for binary encoding, 26 for ASCII encoding.
Formats 3E and 4E also allow "random" reading, but we have not yet implemented this optimization.
Objects
Objects (corresponding to I/O tags) are called devices in Mitsubishi MELSEC terminology. There are different types of devices, they can be bit or word (in the case of MELSEC iQ-R also double-word).
The list of supported device types is shown in the following figure. In addition to the name, the device code (specified in the address of the I/O tag) and the data type are also displayed.
Value type
The values of one or more devices can be interpreted in different ways. We implemented support for:
- work with individual bit and word devices
- work with a specific bit of a word device
- interpretation of a word device (or a block of 16-bit devices with contiguous addresses) as an unsigned or signed integer
- interpretation of two word devices (or a block of 32-bit devices with contiguous addresses) as unsigned, signed, or floating-point 32-bit numbers.
Finally, reading values into a structured variable column is also supported. Using one I/O tag, it is thus possible to read several values and store them in the column of the structured variable.
The address of the I/O tag thus consists of the device code, device number, optionally it is possible to enter a specific bit (for devices with word data), value type, and the number of read elements (items). If the address starts with the %IGNORE string, the I/O tag will be ignored.
And in order for the D2000 user to combine all the information given about the addressing of the I/O tag, the documentation of the Mitsubishi MELSEC protocol also contains examples of addressing.
Conclusion
Support for the Mitsubishi MELSEC protocol further expands the communication capabilities of the Ipesoft D2000 real-time application server. I believe that it will please people from practice and attract other customers who work with Mitsubishi PLCs and need to communicate with them from the level of SCADA and MES systems.
Ing. Peter Humaj, www.ipesoft.com
