Modbus RTU and ASCII on the same RS485 cable

Question

I have to read datas from some devices connected through a RS485-USB serial communication cable. The devices use modbus RTU except for one that uses modbus ASCII.
Can I speak two protocols on the same cable? I think RTU units do not reply to ASCII requests and vice-versa, but may this lead to problems? Does anyone tried this or had any experience?

I don't have any device here to try and I have to setup everything directly at client's place.

This would be my ideal configuration

PC_USB----------RS485+RTU------RS485+RTU------RS485+RTU------RS485+ASCII

If this doesn't work I'll have to switch to a solution like the following

PC_USB----------RS485+RTU------RS485+RTU------RS485+RTU
PC_USB----------RS485+ASCII

that would be very problematic due to some constraints on hardware, cables and location.

Answer 1

the short answer is yes. You can speak as many protocols as you want on RS485 as long the messages doesn't get ambiguous.

I have many PV inverters on a shared RS485 line and many other sensors which speak a complete different protocol. The two class of devices share the same line with no problem.

Answer 2

This may be a challenge... Get a copy of the spec here

• according to the spec, Modbus ASCII commonly uses a 7 databits character format whereas Modbus RTU absolutely needs 8 databits. So, unless you can configure the Modbus ASCII devices to switch to an RTU-compatible character format 8 databits you'll need to continuously switch the PC's serial port between the two modes.
• in Modbus ASCII each payload byte is encoded as two ASCII codes, in RTU each byte is send as a byte. This can lead to slaves being triggered by a byte transmitted in the other protocol they mistakenly interpret as their slave address. This can trigger them to reply with an error message, which can effectively knock out your communication. How bad this will be depends on the robustness of the modbus slave implementations and alternating between 7 bits and 8 bits character formats may help mitigating this problem.

I think you'll have to try it and perform a realistic test that's long enough to see whether it works well enough for your purposes.

Answer 3

YES, this can be done, but it helps if you have the exact equipment to Verify the operation as you are developing the code.

I've come up with an "RS_232-485 Slave Simulator" in LabVIEW that will just listen on a Serial Port and capture the Requests, Parse them, and, if desired, provide a Hard-Coded response.

The KEY is that the Serial Parameters must all be the SAME: Baud, Parity, Bits, Stop-bits, etc. My default is 9600, None, 8, 1

This ALSO works for the 'special' RS-232 devices that use an '=' and '#' as the first character of the message.

This is very handy when setting up new equipment or software, writing Software Drivers for legacy equipment, and as a troubleshooting tool for existing systems.

= A few issues that can trip you up:

1. Some RS-485 devices have the + and - identification of the communication lines WRONG,
2. Not ALL devices need or will use the 'extra stop bit' when using No-Parity,
3. Be aware when some DATA is using HEX codes versus ASCII codes - looks the same at first!