Today is...
Tuesday, October 23, 2018
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
A tutorial introduction to programming using the QuickBuilder Programming Environment.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
FX5 PLC Modbus RTU Slave Timeout Error
Keep getting slave timeout error on PLC. TX light on PLC flashes and RX light on slave flashes.

Keep getting slave timeout error on PLC. TX light on PLC flashes and RX light on slave flashes, but still get time out error and no error response from slave.

- Have re-wired to test setup using a 1m cable.

- Have checked communications of PLC and slave match: RTU/9600/8 bits/no parity/1 stop bit.

- Have tried with and without terminating resistor.

- Have tried with and without connecting the signal ground to a clean earth.

- Have followed programming example in FX5U manual.

If anyone's interested, I can email screenshots of everything and a photo of the wiring. Please email me at
a.thompson(at)chelmerheating.co.uk.

Many thanks!

If the PLC master is addressing slave #3 and the slave's node ID address is #1, then the slave's Rx LED will likely flash because the slave 'sees' the incoming message. But the slave will not respond because it is slave #3 and the message is addressed to slave #1.

Thanks, David,

I'm pretty sure I'm addressing slave 1, but I'm not certain the command itself isn't the issue, which could result in the same.

FYI the command is currently:
ADPRW H1 H3 H0CA K1 D204 M321
Where:
ADPRW (Slave ID) (Read command) (Start register) (No. registers) (Store add) (Status out)

Thanks again.

Hi,

Your command format does not exactly look like Modbus RTU Read command format which should be:
Slave ID hxx, Function Code h03, Start Register Hi Byte hxx, Lo Byte hxx, No of Registers Hi Byte hxx, Lo Byte hxx, CRC-16 verification Hi Byte xx, Lo Byte xx.

Response from the Slave should be:
Slave ID hxx, Function Code h03, Byte Qty hxx, Data (1) Hi Byte hxx, Lo Byte hxx, Data (2) Hi Byte hxx, Lo Byte hxx,.... Data (n) Hi Byte hxx, Lo Byte hxx, CRC-16 verification Hi Byte xx, Lo Byte xx.

I don't see the CRC-16 check in your format. If the CRC-16 check is not valid the PLC may not respond or should respond with an error message:
Slave ID hxx, Function Code h03+80, Error Code hxx, CRC-16 verification Hi Byte xx, Lo Byte xx.

For error codes and more details check:
http://modbus.org/docs/PI_MBUS_300.pdf

Omer Gokcen
ASD Automation

By W.L. Mostia on 4 May, 2018 - 11:27 am

One suggestion is to swap your signal lines. I find it very useful when I've had problems with Modbus to look at what the master and slave are actually sending by using communication monitoring software. You might also try some of the readily available Modbus simulators to talk to your slave, and some of the software can simulate a slave to talk to a master to see if you can spot the problem (most have a demo mode or a free trial).. See below links (Caveat emptor):

www.simplymodbus.ca/RTUmaster.htm

http://www.iccdesigns.com/software/43-icc-modbus-master-tool.html

https://automationforum.in/t/modbus-test-utility-free-alternative-to-modscan-modbus-poll-simply-modbus/2828

https://www.win-tech.com/html/modbus1.htm

There are plenty of other Modbus simulators available on the web and a search will find them if the above is not to your liking.

I also noted in your post that you had for Modbus RTU no parity/1 stop bit. I believe with no parity for RTU, you need two stop bits. (See PI-MBUS-300 Rev. J page 7)

William (Bill) L. Mostia, Jr. PE
ISA Fellow, FS Eng. (TUV Rheinland)
WLM Engineering Co.

Thanks for your reply, Bill.

Must admit I though the default setting of the slave having no parity and only one stop bit was odd too. Only ever seen it even to pad the bits on other devices. Will query with the manufacturers.

Also, thanks for the suggestion on the monitoring software, have ordered a usb to RS485 interface and will give it a go.

By Bob Peterson on 8 May, 2018 - 1:15 pm

The light on the slave may just mean a valid message was received. Could be the message did not ask the slave to send anything back. Are you sure you are addressing the correct slave? If the slave address is 2 and you are sending to slave 1 the message is still valid but slave 1 just ignores it.

--
Bob
http://ilbob.blogspot.com/