Using the Mitsubishi No Protocol with the RMC SERIAL

Note: This Mitsubishi protocol was added to the RMC SERIAL module in 20010802 firmware. Modules with firmware dating prior to this do not support this protocol.

Introduction

This protocol is for serial communication with Mitsubishi FX controllers. For details on a serial protocol for Q series controllers, see the Using the Mitsubishi Bidirectional Protocol with the RMC SERIAL topic.

The Mitsubishi FX controllers support five types of serial communication. The one that matches the needs of the RMC is called "No Protocol." This name implies that the meaning of the data sent via this protocol is not predefined. The interpretation of this data for communication with an RMC will be called the Mitsubishi-RMC Protocol. Mitsubishi's No Protocol is implemented using the PLC's RS function. The No Protocol and the RS function are described in Mitsubishi’s FX Communication (RS-232C, RS-485) User’s Manual (manual number JY992D69901).

The Mitsubishi-RMC Protocol allows the Mitsubishi PLC to read and write binary data from an RMC over RS-232 or RS-485. Up to 96 registers can be transferred with just one RS function. However, it is recommended that large blocks of data be broken down into smaller packets when the RMC is active, because the RS function only allows one transfer to be in progress at a time, and thus the status information will not be transferred until other transfers are complete.

Configuring

Both the RMC and the Mitsubishi are very flexible and provide many options for configuring the serial ports. All of the settings below must be set as indicated, except the baud rate and parity, which can be changed as long as both the RMC and PLC use the same values. However, the values used give the fastest possible baud rate and highest level of error detection.

RMC SERIAL Settings:

Use the Serial Module Options dialog box as described in Configuring the RMC SERIAL to select the following options for the RMC SERIAL:

Baud Rate: 19,200
Data Bits: 8 bit
Parity: Even

Mitsubishi PLC Settings:

The Mitsubishi PLCs use D8120 to control its communication format. Assuming the maximum baud rate of 19,200 and even parity are used, then the following value must be used to communicate with an RMC:

D8120 = H0097

In addition M8161 should be set as follows to select 16-bit data:

M8161 = OFF

D8120 can be broken down into the following options:

Data Length: 8 bit (b0 = 1)
Parity: Even (b1, b2 = 1, 1)
Stop Bits: 1 (b3 = 0)
Baud Rate (bps): 19,200 (b4-b7 = 1, 0, 0, 1)
Header: None (b8 = 0)
Terminator: None (b9 = 0)
Control Line: None (b10-b12 = 0, 0, 0)
Protocol: No protocol (b14 = 0)
Bits 13 and 15 are reserved for No Protocol, and must be zero (0).

A demo program NOPROTO should be used as a starting point for any Mitsubishi FX program using a RMC. This program is posted on the web at http://www.deltacompsys.com/Files/rmcfx.zip.

Using the Mitsubishi-RMC Protocol

Communicating with the RMC from the Mitsubishi PLC requires two buffers in the PLC: one for sending data and one for receiving data. Each buffer should be 100 words long. This allows for data transfers of up to 96 words of data with a header consisting of a length and RMC address, and a trailing checksum using the CCD instruction that actually generates two words. The parity check result of the CCD function is the second word and is not used.

The RS function should be used to used as set the buffer addresses and the length of each transfer. The buffer address should never change from one transfer to the next but the length will change.

After the out going message is constructed it is sent using a RS function. This is enabled by setting bit M8122. At this point, the RS function will send data and wait to receive the requested number of bytes from the RMC. When both have occurred, bit M8123 will be set. At this time the RMC should have returned its response as shown above. The checksum in the response can then be checked using the CCD function again.

The Mitsubishi-RMC Protocol defines the following three request/response packets. Each is composed of 16-bit fields, with each being sent low-byte first by the Mitsubishi. Send buffer locations will be referred to as Dxx00 to Dxx99, where xx are two digits, and receive buffer locations will be referred to as Dyy00 to Dyy99, where yy are two digits.

Read Data from the RMC

Request (to RMC):

$image\ebx_1561833902.gif$

Dxx00 Length. Gives the number of 16-bit registers to read from the RMC. This number will be positive, as differentiated from the Write Data request, which uses the negative of the length.

Dxx01 Address. Gives the address of the first register to read from the RMC. See RMC Register Map (PROFIBUS-DP) for the addresses of all RMC registers.

Dxx02 Checksum. The checksum is calculated using the PLC's CCD function. The length, address, and any data is included in the checksum. The CCD function calculates both a checksum and a parity check; only the checksum is used. Notice that the CCD function will also modify Dxx03.

Response (from RMC):

$image\ebx_469659592.gif$

Dyy00 Length. Will match the request's length.

Dyy01 Address. Will match the request's address.

Dyy02 Data. First data word read.

Dyy03 Data. Second data word read.

…

Dyy01+N Data. Last data word read.

Dyy02+N Checksum. Validate with the CCD instruction.

Write Data to the RMC

Request (to RMC):

$image\ebx_-2086869858.gif$

Dxx00 Length. Negative of the number of 16-bit registers to write to the RMC. This number is negative to differentiate it from the Read Data request, which uses the positive of the length.

Dxx01 Address. Gives the address of the first register to write in the RMC. See RMC Register Map (PROFIBUS-DP) for the addresses of all RMC registers.

Dxx02 Data. First data word to write.

Dxx03 Data. Second data word to write.

…

Dxx01+N Data. Last data word to write.

Dxx02+N Checksum. Set using the CCD instruction. Notice that Dxx03+N will also be modified by CCD with the parity, but this register should not be sent.

Response (from RMC):

$image\ebx_-1117148130.gif$

Dyy00 Length. Will match the request's length.

Dyy01 Address. Will match the request's address.

Dyy02 Checksum. Validate with the CCD instruction.

Halt RMC

This function will send Disable Drive (K) commands to all axes in the RMC.

Request (to RMC):

$image\ebx_405764183.gif$

Dxx00 Length. A length of zero indicates to the RMC to halt all axes with Disable Drive (K) commands.

Response (from RMC):

$image\ebx_-632843875.gif$

Dyy00 Length. This will be zero to indicate an error response.

Dyy01 Error Number. This indicates that this error response was requested by the user. See Errors at the bottom of this topic for a list of other error responses.

Dyy02 Checksum. Validate with the CCD instruction.

Example RS Instructions:

These examples assume the send buffer is at D100 and the receive buffer is at D200.

To read status for 8 axes or 80 words:

$image\ebx_-2085612562.gif$

The lengths (K6 and K166) are in bytes. Remember to add the length, address and checksum to the length of the data. Therefore the send length of six bytes comes from the length, address, and checksum at two bytes each, and the receive length comes from 80 words (160 bytes) plus six bytes for the length, address, and checksum.

To write commands for 8 axes or 48 words:

$image\ebx_871948215.gif$

To write 12 steps to the step table where each step is 8 words:

$image\ebx_-227578147.gif$

If more than 12 steps need to be transferred then more RS blocks are required to transfer the remaining steps.

Data Consistency

When writing to the RMC it is often important that all the data is written at once so the RMC gets the data in one scan. If the RMC uses partially updated data from the command area or the step table, unintended results may occur. It is also important that the status area be from the same RMC scan so that positions can be compared. The RMC guarantees data consistency over the following areas:

Data from Status reads from RMC's registers D0 to D79 will be from the same scan.
Data written to the RMC's command registers from D80 to D127 will be processed in the same scan.
Data read or written to the parameter area will be consistent if the transfer is 64 words or less. This means that initializing all 8 axes with 128 words of data will take two RMC scans. This should not be noticeable.
Data read or written to the step table is copied from the RMC's serial board to the step table in 100 word blocks. It is important that the RMC not execute a step that is partially updated. Therefore the PLC should either:

Update the step table in blocks smaller than 100 words and in multiples of eight (8). Transfer sizes like 64, 80 or 96 work well.
Stop the RMC from executing steps while downloading the step table.
Use the CommTrig (C) link type so the RMC waits until the last step is updated.

Errors

When the RMC returns a length of zero, the value in the address field is an error number. The Error codes are as follows:

Value	Description
-1	Time Out: More than 100 milliseconds has gone by with out receiving a character.
-2	Overrun Error: The RMC was not able to read the character in the serial port before the next character over wrote it.
-3	Framing Error: The RMC’s serial port received a incorrectly formed character. This is normally due to baud rate mismatch between the RMC and the PLC although it could be due to a corrupted character due to noise.
-4	Parity Error: This is caused by noise causing the RMC's serial port to incorrectly receive the character.
-5	Break: A break signal has been detected by the RMC's serial port. This is caused by the serial line being held low for an extended period of time. This will cause the RMC's state machine to start back at state 0.
-6	Length of Zero: The RMC received a length of zero. This is causes the RMC to stop all axis using a hard stop.
-7	Invalid Checksum: The RMC did not receive the correct check sum.
-8	Invalid Length: The RMC received a length greater than 96 or less than -96.

When the RMC returns only a 0 and error number the communications will stop because the PLC is expecting more characters to be returned. The PLC should have a communications time out timer that will restart the communications. It should also check the length for a return 0 and the error codes above. The error codes are useful for initial debugging because they give some indication as to why the communication is not working.