Today is...
Wednesday, September 20, 2017
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
Watch an animation of a conveyor stacking operation demonstrating the use of a move on a gear command.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
MODBUS RTU to RS485 Configuration
I'm trying to set up comms from a PLC to a VFD using MODBUS. PLC has RS232 and VFD has RS485 running through a RS232 to RS485 serial converter.
By Shandene Solomons on 13 September, 2017 - 6:24 am

Hi there.

I'm new to MODBUS communications and would like to enquire something.

I'm trying to set up comms from a PLC to a Variable Frequency Drive using MODBUS protocol. On the PLC I have RS232 and on the VFD I have RS485 which I have running through a RS232 to RS485 serial converter from MOXA.

The PLC is setup using MODBUS RTU protocol and I'm trying to output a word to a parameter on the VFD. The VFD only has RS485 built-in and on the spec sheet the address I'm looking at is 0x0505.

The PLC has a message frame monitor function where I can read the messages transmitted and received to and from the drive. However, only messages from the MODBUS master (which is the PLC) show up with the following message:

SOH EOT NUL FF NUL SOH  
SOH EOT ENQ ENQ NUL SOH ! BEL

The MODBUS parameters are setup the same (Parity, Stop bits, etc) but I am not receiving any comms back from the slave which is the VFD).

Is this setup incorrect or am I not able to communicate this way at all?

I appreciate your assistance.

Shandene

Decoding/decrypting Modbus messages in hexadecimal is awkward enough, but your message is encrypted in ASCII character codes. You might consider investigating whether the message display/interpretation can be displayed as hex, rather than ASCII.

Here's a decoder table:


Chr ASCII Hex
SOH 01 01
EOT 04 04
BEL 07 07
ENQ 05 05
NUL 00 00
! 33 21

The first message

SOH EOT NUL FF NUL SOH
01 04 00 FF 00 01

mixes in an FF character (0xFF = 256 decimal) which is not on an ASCII table, because ASCII is 0-127 decimal, but the message does decode to a complete 6 byte Modbus query (minus the two CRC error check characters):

Master poll/query/request (6 bytes without 2 byte CRC)
01 slave address 01
04 Function Code 04, read input register(s)
00 starting address high 00
FF start address low
00 quantity of registers High
01 quantity of registers Low

which asks for a single register value from address 0x00FF from slave 01 in conventional Modbus RTU format (not Modbus ASCII, ASCII is just the format the PLC displays)

The second message


SOH EOT ENQ ENQ NUL SOH ! BEL
01 04 05 05 00 01 21 07

is a complete Master RTU poll query:

01 slave address
04 Function Code 04, read input register(s)
05 start address High
05 start address Low
00 quantity of registers High
01 quantity of registers Low
21 CRC Low
07 CRC High

0x0721 is the correct CRC value for that Modbus message, so it is a valid Modbus RTU message that asks for a single register at address 0x0505 from slave 01.

Several issues:

1. Assuming you can get the PLC to send only the 2nd message, you should expect a reply from the drive if the drive is slave 01, set up at the same baud rate/parity/8bit and all the serial stuff works.

2. PLC serial ports are not always enabled for Modbus. Are you sure the 232 serial port is getting the Modbus message?

3. >"I'm trying to output a word to a parameter on the VFD"

Function code (FC) 04 is read-only, by definition. Input Registers are always read-only. FC 04 will never write a value to an input register.

Holding registers can be read/write or read-only, depending on what the vendor allows.

Function code 06 writes a single value to a single holding register.
Function Code 16 (decimal, 0x10) writes multiple values to multiple registers.

It's my opinion that it is best to get Modbus functionally working by reading a known value from a known register before attempting to write values, but that's just my opinion.

4. Serial modbus 232/485 can have multiple issues with connections that prevent point-to-point communications.

A. 2 wire RS-485 has no industry wide convention for the (+)/(-) line driver connections.

Although (+) should connect to (+), or A to A, B to B, it is not uncommon that (+) connects to (-) or A connects to B.

Connecting backwards does not damage the drivers, but it won't work. So the rule is to try swapping A/B or (+)/(-) or whatever the labeling is on your 485 lines.

B. On the 232 side, Tx has to connect to Rx on the other end. Wiring a converter can be tricky.

I refuse to use "port powered" 232/485 converters because many of them just do not work with the available port power.

C. VFDs are electrical noise generators and it pays to use twisted pair/shielded cable for the comm line and to not run it in the same conduit/cable tray with the power cables.

D. The higher the baud rate, the more issues you have. Get it running at 9600 baud and then change baud rates once you have it working.

E. RS-485 should have a terminating resistor at each end, but for a short cable run at 9600 baud you can probably get by without termination.