FINS/UDP

The FINS/UDP protocol is an Omron protocol which can be used by a PLC program to transfer data and perform other services with a remote PLC connected on an Ethernet Network. The FINS protocol allows Omron PLCs to communicate with the RMC75E orRMC150E. The RMCs support FINS/UDP.

The FINS/UDP protocol is an open application protocol developed and used by Omron Electronics Inc. This protocol is available over a number of media, including Ethernet and serial. Additional information is available in the CS1 Communications Reference Manual, available on Omron's web site: http://www.omron.com/oei.

The FINS protocol uses a three-stage addressing system: network address, node number, and unit number. These three address elements have the following purposes:

• Network Address
  This value identifies the network on which the target node resides. The PLC looks up this number in its Local and Remote Network Tables to determine which local unit number should be used to send out the request. For Ethernet systems, typically only the Local Network Table is used to map a network address (for example, 1) to the unit number on the ETN01 Ethernet Unit (for example, 0).  See your Omron PLC and/or CX-Programmer documentation for details on setting up the Local and Remote Network Tables.

• Node Number
  This value identifies the node on the network given by the network address. For Ethernet networks, this number must be converted to an IP address. This conversion is done by the ETN01 Ethernet Unit. Three methods are available. In the Automatic Address Generation method, the IP address is derived by combining the ETN01's IP Network Address (e.g. 192.168.0.0) with the Node Number (e.g. 5) to get an IP Address (e.g. 192.168.0.5).  In the IP Address Table method, each Node Number maps to an IP Address via an entry in an IP Address Table. In the Combined method, the IP Address Table is used first, but if the Node Number is not found in the table, then the Automatic Address Generation method is used. See the Omron ETN01 Ethernet Unit manual for details on these methods.

• Unit Number
  This value identifies the unit number on the rack of the remote node identified by the Network Address and Node Number.

 

The RMC does not require manually setting these values in the RMC. Only the IP address needs to be set in the RMC; see theRMC Ethernet Setup topic for details.

Addressing:

See the FINS Addressing topic for information on the FINS address of RMC registers.

Communicating Directly over UDP

For RMC firmware versions prior to 3.31.0, in applications where none of the RMC抯 protocols are supported by the master controller, but direct communication over UDP is allowed, Delta recommended that FINS/UDP is implemented by the user manually. The remainder of this topic describes how to manually implement FINS/UDP to communicate with the RMC75E and RMC150E, ignoring the unused features and fields in the protocol. Firmware versions 3.31.0 and newer support the Delta Motion Control Protocol (DMCP), which is the preferred method of manual direct communication over UDP.

The RMC75E and RMC150E listen for FINS/UDP requests on UDP port 9600. The client port number can be any number. This protocol is a request/response protocol, meaning that for each request packet sent to the RMC, there will be one response packet sent by the RMC. The only FINS/UDP commands used in this topic are CMD_MEM_AREA_READ and CMD_MEM_AREA_WRITE.

Writing Data to the RMC

To send one or more registers to the RMC, send the following packet to the RMC:

Offset	Data (hex)	Description
0-8	80 00 02 00 00 00 00 00 00	Static Values. These 9 bytes should always have these values in a write request.
9	kk	Service ID. This value is simply echoed by the RMC in its response packet. It can be used to match responses with requests, since UDP does not prevent packets from being delivered out-of-order or dropped.
10-11	01 02	FINS Command. These two bytes should be 01 02 to indicate a memory area write.
12-15	xx yy zz 00	FINS Address. This value encodes the register address to write to in the RMC. See the FINS Address section below for details.
16-17	mm nn	Write Length. This values holds the number of 16-bit values to write. Notice that because the RMC uses 32-bit registers, this value should be twice the number of RMC registers being written to. This value is encoded in binary with the most-significant byte first. This value must be less than or equal to 512.
18-...	...	Data. The values of each register to write should follow the above header. Each 32-bit value should be encoded as two 16-bit words, with the least-significant word first, but with each individual 16-bit word encoded with the most-significant byte first. For example, the value 0x11223344 should be encoded as 33 44 11 22.

 

The RMC will respond to this request with the following packet:

Offset	Data (hex)	Description
0-8	C0 00 02 00 00 00 00 00 00	Static Values. These 9 bytes will always have these values in the response.
9	kk	Service ID. This value will echo the Service ID in the request. It should be used to match this response to the corresponding request.
10-11	01 02	FINS Command. These two bytes will match the command from the request.
12-13	rr ss	Response Code. Indicates whether the write was successful or not. See the FINS Response Codessection below.

Reading Data from the RMC:

To read one or more registers from the RMC, send the following request packet to the RMC:

Offset	Data (hex)	Description
0-8	80 00 02 00 00 00 00 00 00	Static Values. These 9 bytes should always have these values in a read request.
9	kk	Service ID. This value is simply echoed by the RMC in its response packet. It can be used to match responses with requests, since UDP does not prevent packets from being delivered out-of-order or dropped.
10-11	01 01	FINS Command. These two bytes should be 01 01 to indicate a memory area read.
12-15	xx yy zz 00	FINS Address. This value encodes the register address to read from the RMC. See the FINS Address section below for details.
16-17	mm nn	Read Length. This values holds the number of 16-bit values to read. Notice that because the RMC uses 32-bit registers, this value should be twice the number of RMC registers to read. This value is encoded in binary with the most-significant byte first. This value must be less than or equal to 512.

 

The RMC will respond to this request with the following packet:

Offset	Data (hex)	Description
0-8	C0 00 02 00 00 00 00 00 00	Static Values. These 9 bytes will always have these values in the response.
9	kk	Service ID. This value will echo the Service ID in the request. It should be used to match this response to the corresponding request.
10-11	01 01	FINS Command. These two bytes will match the command from the request.
12-13	rr ss	Response Code. Indicates whether the read was successful or not. See the FINS Response Codessection below.
14...		Data. The values of each register that was read will follow the above header. Each 32-bit value will be encoded as two 16-bit words, with the least-significant word first, but with each individual 16-bit word encoded with the most-significant byte first. For example, the value 0x11223344 will be encoded as 33 44 11 22. Notice that many registers are in IEEE floating point format, which can generally be cast to C language floatdata values after correcting the byte order to match your platform.

FINS Address

The FINS address field is a 4-byte field that instructs the read or write command as to where in the RMC the data should be read or written. The first byte is called the Area Code and selects which of three memory areas in the RMC to access. The next two bytes are called the Starting Address, and indicates the offset from the start of the selected memory area. Each memory area is limited to 32,768 sixteen-bit words. The fourth byte indicates the bit address, but must be zero in requests with the RMC.

The starting point for determining the FINS Address is to look up the address as shown in the FINS Addressing topic. A convenient tool is provided as well in the topic for converting from an IEC address (e.g. %MD56.0) to a FINS Address. The address given by that topic will be in the form of Dxxxxx or Ey_xxxxx. The prefix (D, E0_, or E1_) indicates the Area Code to select, and the number following the prefix is the Starting Address. Use the following chart to select an area code:

Prefix	Area Code
D	82
E0_	A0
E1_	A1

 

In the FINS/UDP protocol, the Starting Address is encoded as a 16-bit value with the most-significant byte first.

Example

Find the FINS/UDP encoding for the RMC address %MD56.0.

By using the conversion tool in the FINS Addressing topic, we find that %MD56.0 is represented by FINS Address D28672. Notice that the Low Address listed there as well (D01536) can be ignored when using FINS/UDP in this manner. It is necessary only when using PLCs that prevent the user from entering high addresses.

We separate the FINS Address into its prefix (D) and starting address (28672). By using the prefix chart above, converting the starting address to hexadecimal (0x7000) and appending the 00 bit address byte, we get the following FINS/UDP encoding of our address:

82 70 00 00

FINS Response Codes

The response packet holds a two-byte Response Code field, indicating to the client whether the transaction was successful or not. The RMC uses the following response codes:

Response Code	Description
00 00	Success.
04 01	Undefined Command. The 2-byte Command field did not match a command supported by the controller.
10 01	Packet Too Long. There were more bytes in the packet than expected for the command type.
10 02	Packet Too Short. There were fewer bytes in the packet than expected for the command type.
10 03	Bad Data Length. The amount of data in a write request did not match the Write Length field in the packet header.
11 01	Invalid Address Area Code. The Area Code (first byte in the FINS Address field) is not a valid value.
11 02	Size Error. Either the 4th byte in the FINS Address field is non-zero, or the Read Length or Write Length field is greater than 512.
11 03	Bad Starting Address. The 2-byte starting address is greater than 0x7FFF.
11 04	Bad Ending Address. The 2-byte starting address plus the read or write length exceeds 0x8000. A single read or write cannot cross over memory areas.

Example 1: Writing a Single Register

In this example, the client will write the value 0x11223344 to variable 0 (%MD56.0). The FINS Address of the current value of variable 0 (%MD56.0) is 82 70 00 00, as shown in the example in the FINS Address section above. The client chooses a Service ID of 00 for this packet, either because he is not using this field, or because this is the first transaction. Finally, we must re-arrange the byte order on the value we are writing from 0x11223344 to 33 44 11 22.

The Write Length is two (2) because each 32-bit RMC register requires two 16-bit FINS registers.

This gives us the following packet that should be sent to UDP port 9600 on the RMC:

80 00 02 00 00 00 00 00

00 00 01 02 82 70 00 00

00 02 33 44 11 22

After the RMC has successfully received and processed this write request, it will respond with the following packet:

C0 00 02 00 00 00 00 00

00 00 01 02 00 00

Notice that the last two bytes are the response code, with 00 00 meaning success.

Example 2: Reading a Single Register

In this example, the client will read a value from variable 0 (%MD56.0). The FINS Address of the current value of variable 0 (%MD56.0) is 82 70 00 00, as shown in the example in the FINS Address section above. The client chooses a Service ID of 1, perhaps because this is the second transaction.

The Read Length is two (2) because each 32-bit RMC register requires two 16-bit FINS registers.

This gives us the following packet that should be sent to UDP port 9600 on the RMC:

80 00 02 00 00 00 00 00

00 00 01 01 82 70 00 00

00 02

After the RMC has successfully received and processed this write request, it will respond with the following packet if variable 0 held the value 0x11223344:

C0 00 02 00 00 00 00 00

00 00 01 02 00 00 33 44

11 22

Notice that bytes 12-13 hold the response code, and byte 14-17 hold the data that was rea