Porovnávané verzie

Kľúč

  • Tento riadok sa pridal
  • Riadok je odstránený.
  • Formátovanie sa zmenilo.

Mitsubishi MELSEC protocol (MELSEC Communication Protocol)

Protocol descriptionSupported device types and versions
Communication line configuration
Station configuration
I/O tag configuration
Literature
Changes and modifications
Document revisions

Kotva

...

popis
popis
Protocol description

...

The Mitsubishi MELSEC protocol is used for communication with Mitsubishi PLCs (MELSEC L-series, MELSEC Q-series series, and MELSEC iFX-series) equipped with Ethernet communication modules. The UDP variant using The FINS protocol (Factory Interface Network Service) implements client (master) communication with Omron PLCs. The FINS/UDP protocol variant based on the UDP protocol (on the the TCP/IP-UDP line line) as well as and the FINS/ TCP protocol variant using the TCP protocol (on the the TCP/IP-TCP line) are implemented. Read (MEMORY AREA READ) and write (MEMORY AREA WRITE) commands are supportedand write commands are supported.

The following rame formats are supported (see Frame type protocol parameter): 1E, 3E, 4E. Both binary and ASCII message encoding are supported (see the Code type protocol parameter). ASCII-encoded messages are approximately 2 times longer than binary-encoded messages.

Reading and writing various types of objects (device codes) is supported. These objects are bit-oriented or word-oriented, and the interpretation of several (16 or 32) consecutive bit objects as a signed/unsigned number or two consecutive word objects as a number (unsigned, signed, a real 32-bit number) is supported. Access to a specific bit of a word object is also supported.

Communication was tested against the Mitsubishi FX5UC-32MT/DSS-T model (frame 3E, binary encoding, TCP communication.
Note: it is recommended to use the FINS/UDP protocol variant; FINS/TCP protocol has a higher overhead (16 bytes for each request and response) and is suitable for demanding network environments (firewalls, the need for address translation - NAT, etc.). Not every Omron PLC supports the FINS/TCP protocol variant.
Communication was tested against a CJ-series CJ2M CPU (both FINS/UDP and FINS/TCP protocol variant).

Kotva
komunikacna_linka
komunikacna_linka
Communication line configuration

...

  • Communication line category: TCP/IP-UDP (FINS/UDP protocol variant) or  TCP/IP-TCP (FINS/TCP protocolvariant).
  • TCP/IP-UDP parameters:
    • Host: IP address or of the network interface that is used for communication by the KOM process. A symbolic name that can be translated to an IP address can be entered too.
      Note: a symbolic name ALL or can be entered - in which case all available interfaces are used.
    • Port: UDP port number that is used for communication by the KOM process (according to standard 9600).
    • Note: The parameters of the backup server (Host and Port) are not used in this protocol.
  • TCP/IP-TCP parameters:
    • As the Host, Port, and Line Number parameters are not used (the PLC address is configured on the station), arbitrary values can be specified.


Kotva
komunikacna_stanica
komunikacna_stanica
Station configuration

...


Station protocol parameters

Configuration dialog box - tab Parameter.
They influence some optional parameters of the protocol. The following station protocol parameters can be set:

...

Source Source Node (SA1)Source Unit (SA2)Destination Network Address (DNA)Destination Node (DA1)Destination Unit (DA2)Other communication parameters
4-byte Endian Mode

The parameter affects the work with 4-byte values ​​(DWORD, LONG, FLOAT), which are read in two consecutive registers. E.g. I/O tag with address DM28,FLOAT will read registers 28 and 29 from DM memory and interpret them as a 4-byte real number. The "4-byte Endian Mode" parameter specifies the order of the registers and bytes in the resulting number.
Meaning of letters and numbers in the parameter value name:

  • The numbers 1, 2, 3, and 4 indicate the byte order in the TCP/UDP packet in the communication (bytes are always received in the order 1,2,3,4, i.e. bytes 1 and 2 form a lower register, bytes 3 and 4 form a higher register).
  • b - register with lower address interpreted as big-endian (i.e. bytes 1,2 where 1st byte is more significant, 2nd byte is less significant)
  • B - register with higher address interpreted as big-endian (i.e. bytes 3,4 with 3rd byte is more significant, 4th byte is less significant)
  • l - register with lower address interpreted as little-endian (i.e. bytes 1,2 where 2nd byte is more significant, 1st byte is less significant)
  • L - register with higher address interpreted as little-endian (i.e. bytes 3.4 with 4th byte is more significant, 3rd byte is less significant)

The order of letters and numbers indicates the order of registers and bytes in the interpretation of the resulting 32-bit number, on the left is the most significant byte/register, on the right the least significant.

  • Bb (3412) - big-endian, 2nd register significant - byte order within the register is big-endian, 2nd register is more significant
  • bB (1234) - classic big-endian - byte order within the register is big-endian, 1. register is more significant
  • Ll (4321) - classic little-endian - byte order within the register is little-endian, 2. register is more significant
  • lL (2143) - little-endian, 1st register significant - byte order within the register is little-endian, 1st register is more significant
For example, if bytes <AA><BB><CC><DD> are received, the Bb (3412) order means that the hexadecimal value CCDDAABB will be interpreted, which in the case of DWORD type is a number 3 437 079 227. The IL (2143) order would mean interpretation as a hexadecimal value of BBAADDCC, which in the case of a DWORD type is a number 3 148 537 292.
Note: 2-Byte values are currently interpreted as big-endian. Data Size512
ParameterMeaningUnitDefault value
General Parameters

Section of parameters describing the source address (D2000 KOM process)

Kotva
snactsna
Source Network Address (SNA)

This parameter specifies the network address number of the source device (D2000 KOM process). The Source Network Address is sometimes referred to as SNA in Omron FINS documentation.
The valid range is 0 to 127. Actual network numbers can range from 1 to 127. FINS interprets 0 as 'use the local network'; as such, 0 must not be used when data will be routed through gateway PLCs. The default value for network addresses is zero. This is interpreted by FINS as an instruction to use the local network. Actual network numbers can range from 1 to 127. Using zero is convenient if there is only one network level. When using gateway devices, however, specify the actual network number (1–127) to avoid routing ambiguities.
-0
Kotva
sa1sa1This parameter specifies the node number of the source device (D2000 KOM process). The Source Node is sometimes referred to as SA1 in Omron FINS documentation. The valid range is 0 to 254. If the destination PLC is configured to use automatic address generation, then this number must be the host number portion of the host computer's IP address.
For example, if the host computer has an IP of 111.222.333.123 and the subnet mask is 255.255.255.000, the source node number should be 123. If the target PLC is configured to use an address table, then the table must have an entry for the host computer's IP. The node number in this table entry must agree with the source node number entered for the driver.
Note: if the line is configured as TCP/IP-TCP (FINS/TCP protocol), it is recommended to use a value of 0, which means that the node number of the source device will be assigned by the PLC during connection establishment.
-254
Kotva
sa2sa2This parameter specifies the number of the Unit at the source device (D2000 KOM process). The Source Unit is sometimes referred to as SA2 in Omron FINS documentation. It is an arbitrary number in the range 0-255.-0
Destination ParametersSection of parameters describing the destination address (Omron PLC)

ct
Code type

Type of message encoding:

  • Binary code - messages are binary encoded, they are smaller and more compact
  • ASCII code - messages are text-encoded, they are larger but more visually readable
-Binary code

Kotva
ft
ft
Frame type

The type of frame (header) used. This type must be the same as the type configured on the Mitsubishi PLC side

  • 1E - the simplest header, without a data length specification
  • 3E - header with a data length specification
  • 4E - header with a specification of data length and a serial identifier of individual messages
-3E
1E/3E/4E Frames Common Parameters

Kotva
sn
sn
Station No. (PC No.)

Hexadecimal number (00-FF) specifying the station network module number (for remote stations). Keep the default value FF for directly connected PLCs.

-FF

Kotva
mt
mt
Monitoring Timer

Specification of the time to wait for a response in 250 ms units, which is sent in the message header (a value of 0 means waiting without restriction). The default value of 16 means waiting for 4 seconds.

250 ms16

Kotva
mp
mp
Max Points

The maximum number of objects read in one message. The range is 1-960. Objects can be of bit or word type. A bit object is transmitted as 1 bit (2 bits in ASCII encoding), a word object is transmitted as 2 bytes (4 bytes in ASCII encoding).
When reading objects periodically, read requests are split into multiple if the number of objects in one request is greater than the specified maximum.

-480

Kotva
md
md
Max Data Bytes

Maximum response size - the size of the pure data. The range is 2-8192 bytes.
When reading objects periodically, the read requests are split into several if the response size is larger than the specified maximum.

byte512
3E/4E Access Route Parameters

Kotva
nn
nn
Network No.

Destination network number (for multidrop systems/stations on remote networks). The value is entered in decimal and is in the range 0-255. When communicating with a directly connected station, the value 0 is entered. Other values (see documentation) are entered when communicating with stations located on other network segments (it can also be serial lines) located behind the directly connected station. See Literature for more information.

-0

Kotva
dm
dm
Request destination module I/O No.

Target I / O module number (for multidrop/multiCPU/redundant systems). The value is entered in hexadecimal and is in the range 0000-FFFF. When communicating with a directly connected station, the value 03FF is entered. Other values (see documentation) are entered when communicating with stations located on other network segments (it can also be serial lines) located behind a directly connected station, in the case of multidrop connections, and in the case of working with redundant PLCs and PLCs with multiple CPUs. See Literature for more information.

-03FF

Kotva
ds
ds
Request destination module station No.

Destination station number (for multidrop/multiCPU/redundant systems). The value is entered in hexadecimal and is in the range 00-FF. When communicating with a directly connected station, the value 00 is entered. Other values (see documentation) are entered in the case of a multidrop connection. See Literature for more information.

-00
Kotva
dnadnaThis parameter specifies the network address number of the destination device. The Destination Network Address is sometimes referred to as DNA in Omron FINS documentation. The valid range is 0 to 127.
Actual network numbers can range from 1 to 127. FINS interprets 0 as use the local network; as such, 0 must not be used when data will be routed through gateway PLCs.
-0
Kotva
da1da1This parameter specifies the node number of the destination device. The Destination Node is sometimes referred to as DA1 in Omron FINS documentation. The valid range is 0 to 254.
Note: if the line is configured as TCP/IP-TCP (FINS/TCP protocol), this parameter is not used, as the node number of the destination device will be announced by the PLC during the connection establishment.
-0
Kotva
da2da2This parameter specifies the destination device unit number, which is sometimes referred to as DA2. The valid range is 0 to 255. The default number for DA2 is 0.-0Other Parameters
Kotva
emem-Bb (3412) - big-endian, 2nd register significant
Kotva
dsdsMaximum count of data bytes that are requested in one request. The total size of a response is 14 bytes + Data Size.ByteOther Parameters


Kotva
rc
rc
Retry Count

Maximum count of request retries. If no reply response returns after a request had has been sent, the station will be in the status of 's status will change to a communication error.s-2

Kotva
rt
rt
Retry Timeout

Timeout before resending a request if no reply had not no response has been received.s0.1

Kotva
wt
wt
Wait Timeout

Maximum wait time to receive a response

Timeout for receiving a response. The value of the parameter should be greater than the time corresponding to the value of the Monitoring Timer parameter.

s1.0.1

Kotva
fd
fd
Full

debug

Debug

Logging of additional detailed debug information about communication in the line log.YES/NONO

Note: the configuration of the network parameters for directly connected PLCs was as follows:

...

Kotva
td
td
Text Debug

Text reports of messages. If Code type=ASCII code, message listings will be in text form.

YES/NONO

...


Kotva
merany_bod
merany_bod
I/O tag configuration

...

Possible types of I/O tag values: Ai, Ao, Di, Do Do, Ci, CoTiRToR.

I/O tag address:

...

  • AR - Auxiliary Area
  • DM - DM Area
  • CIO - CIO Area (external inputs/outputs)
  • HR - Holding Area (persistent values, which are kept when power is turned OFF or operation stops in the PLC )
  • TC - Timer/Counter Area
  • WR - Work Area (memory used for programming)

In each area, there is independent addressing with an address size of 2 bytes, i.e. addresses from 0 to 65535. The actual size of the address space depends on the particular PLC model.
The size of the register in the AR, DM, CIO, HR, WR areas is 2 bytes.

The address of the I/O tag format is <area><offset> [.<bit>] [,<type>] where:

...

<type> is an optional part of the address that specifies how the data is interpreted:

The address of the I/O tag is in the form <device code><device number>{ .bit} { ,<value type>} {, items}
Note: the I/O tag is ignored if its address starts with %IGNORE

Kotva
device_code
device_code
Device code

In Mitsubishi protocol terminology, individual objects whose values are read and written are called devices. The protocol allows access to multiple types of devices. Working with the following types of devices is supported:

Device typeDevice codeData type
Special relaySMbit
Special registerSDword
InputXbit
OutputYbit
Internal relayMbit
Latch relayLbit
AnnunciatorFbit
Edge relayVbit
Link relayBbit
Data registerDword
Link registerWword
Timer ContactTSbit
Timer CoilTCbit
Timer Current valueTNword
Retentive Timer ContactSTSbit
Retentive Timer CoilSTCbit
Retentive Timer Current valueSTNword
Counter ContactCSbit
Counter CoilCCbit
Counter Current valueCNword
Link special relaySBbit
Link special registerSWword
Direct access inputDXbit
Direct access outputDYbit
Index register

Z

word
File register

R

word


Kotva
device_number
device_number
Device number

For a specific type of device (device code), individual objects are identified by a number (device number). When using 3E and 4E frames, a 3-byte number is specified, when using a 1E frame, a 4-byte number is specified. Numbering starts from 0, the maximum number for a specific device type depends on the specific PLC.
Note 1: if the number starts with a hash sign (#), it is understood as hexadecimal, e.g. #A3 is 163 in decimal.
Note 2: if the number starts with "o", it is understood as octal, e.g. o17 is 15 in decimal. For several types of Mitsubishi PLCs, the octal system is used to number Inputs (X) and Outputs (Y).


Kotva
bit
bit
 Bit

Optional parameter - access to a specific bit. For device types (device code) that have word data, a specific bit (0-15) can be specified.
Note: writing is not yet implemented for the  I/O tag with a specified bit, only reading.


Kotva
value_type
value_type
 Value type

Optional parameter - data interpretation.
For device types (device code) that have word data, the default interpretation is WORD (e.g. SD5 address).
For device types (device code) that have bit data, the BIT interpretation is preset (e.g. X5 address)

Value typeInterpretation
BITInterpretation of a bit-type device as a bit (e.g. X3, BIT)
Interpretation of one bit of word-type device as a bit (e.g. D5.0)
WORDInterpretation of 16 consecutive bit-type devices as a 16-bit unsigned number (e.g. X10, WORD).
Interpretation of one word-type device as an unsigned 16-bit number (e.g. SD10, WORD).
INTInterpretation of 16 consecutive bit-type devices as a 16-bit signed number  (e.g. X10, INT).
Interpretation of one word-type device as a signed 16-bit number (e.g. SD10, INT).
DWORDInterpretation of 32 consecutive bit-type devices as a 32-bit unsigned number (e.g. X10, DWORD).
Interpretation of 2 consecutive word-type devices as a 32-bit unsigned number (e.g. SD10, DWORD).
DINTInterpretation of consecutive 32 bit-type devices as a 32-bit signed number (e.g. X10, DINT).
Interpretation of 2 consecutive word-type devices as a 32-bit signed number (e.g. SD10, DINT).
REALInterpretation of consecutive 32 bit-type devices as a 32-bit floating-point number (e.g. Y10, REAL).
Interpretation of 2 consecutive word-type devices as a 32-bit floating-point number (e.g. SD10, REAL).

Note: when interpreting 32-bit numbers, the data is interpreted as little-endian (a lower word at a lower address, higher at a higher address).


Kotva
items
items
 Items

The number of elements for structured I/O tags with configured Destination column. Every read element (1,2,3 .. items) will be written to one item of the destination column.
Note: All "items" elements are read at once. If e.g. 100 elements of device type (device code) which has data of word type (e.g. address D10, WORD, 100), are configured, it means reading of a block of 200 bytes.  If the number of objects is greater than the value of the Max Points, parameter, or the data size is greater than the Max Data Bytes, the reading will not be performed and an error message Too many elements in point < I/O tag name> will be added to the line log.

Configuration examples:

  • X10 - Input 10, interpreted as a BIT (default)
  • D0 - Data register 0, interpreted as a WORD (default)
  • M12, WORD - Internal relays 12-27, interpreted as a WORD
  • M#12, WORD - Internal relays 18-33 (0x12=18), interpreted as a WORD
  • D4, REAL - Data registers 4 and 5, interpreted as REAL
  • Y10, BIT, 20 - Inputs 10-29, interpreted as BIT (default), assigned to 20 items of the Destination column
  • D4, REAL, 10 - Data registers 4-23, each couple interpreted as REAL, assigned to 10 items of the Destination column
  • D4, WORD, 10 - Data register 4-13, interpreted as WORD, assigned to 10 items of the Destination column
  • R1000, , 3 - File registers 1000-1003, interpreted as WORD (default), assigned to 3 items of the Destination column

Kotva
literatura
literatura
Literature

...

...

Two 16-bit registers interpreted as a 32-bit unsigned number (byte order depends on the  4-byte Endian Mode parameter)

...

Examples of configuration::

  • DM10 - DM area, register 10, interpreted as a 16-bit unsigned number
  • HR0200.0 - HR area, register 200, the lowest bit
  • DM#020, FLOAT - DM area, registers 32 and 33 interpreted as a 32-bit float number 

...


Kotva
zmeny_upravy
zmeny_upravy
Changes and modifications

...

-

Kotva
revizie
revizie
Document revisions

...

  • Ver. 1.0 - August 28th, 2020 – March 10, 2021 - a document created.
  • Ver. 1.1 - September 3rd, 2020 - support for FINS/TCP variant.Ver. 1.2 - October 5th, 2020 - support for BCD numbers.– October 24, 2023 - support for file registers
Info
titleRelated pages:

Communication protocols

...