Interesting Modbus Library Behavior with RS-485 RTU Serial

[rhenderson]

Hey, All.

Have a sort of interesting issue with Modbus RTU over RS485 2-Wire Serial (at least that's where we see it).

Issue appears that with two IDs (slaves 1 and 5 on the desk) addressed via LV, there seem to be intermittent timeout errors that occur on reads more so than writes. We did reverse our handling to writes and then reads, but we then saw more again more errors on the reads than writes. There appears to maybe be some report of this happening at https://github.com/NISystemsEngineering/LabVIEW-Modbus-API/issues/7. We did go back to the library before it was OOP and still found this error to be present which is why posting here. If we address the same ID twice serially rather than one and then the other, very little to no errors on reads or writes with either ID being doubly handled. If we address 1 and then 5 or 5 and then 1, lots of read errors and some write errors. Looks almost like the serial buffer is dumped at an in-opportune time with RTU messages being clipped or extended causing the target ID to not understand it and then not replying back causing a timeout.

Something deep in the driver or something we are doing really wrong? Happy to try some things if people have ideas.

Physical setup is two real RS485 2-Wire RTU Serial Slaves with 38400 baud, 8 databits, even parity, 1 stop bit, and no flow control connected either to a cRio (RS-485 RJ-50 to breakout bridged 2-6 and 3-7) or a usb>RS485 converter on the development machine. Have a software serial spy on the development machine, but the behavior and qty of errors appears to be consistent between targets.

Have screenshots, vi, and serial capture of errors to help the conversation. Program was built for fast testing so not fully in love with how it ended up - Lots of obvious areas for better practices.

Key for Error Count Array

ID 1 Addressed Twice per Loop. 1 Error in 1000 loops.

ID 5 Addressed Twice per Loop. 0 Error in 1000 loops.

ID 1 and then ID 5 Addressed Once per Loop. 10 Error in 1000 loops.

ID 5 and then ID 1 Addressed Once per Loop. 22 Error in 1000 loops.

UI Block Diagram

Error Array ++ Block Diagram

Serial Monitor with Messages Hilighted. Shows multiple modbus messages being sent together. Might not be a good tool for this?

ModbusPoll Results. Roughly 100ms/equivalent action. 100 reads each in 10 seconds using the same physical connections and devices and the same registers as LV. I can force timeout errors if I drop the Delay Between Polls much lower than 20ms though (second picture).

Thanks so much for looking and offering thoughts.

[K C]

Hi,

As I understand it both slaves are connected to the same RS-485 interface.

Could it be that the slave devices do not disable the transmitter fast enough. 

Can you look at the interface signal with a scope ?

If not, can you add a time delay between the access to the two devices.

How long is the RS-485 line ? Did you use terminators ? Is the 0V connected ?

Kees

[RTSLVU]

I have a test system that has 12 Modbus slave devices on the same bus and never ran into this behavior. I am addressing them sequentially (1-12) and pulling lots of data from them as fast as I can. 

I think K C is right, this sounds like an issues with your devices.

But you might want to crosspost this to the LabVIEW Modbus API discussion 

[rhenderson]

Appreciate the replies, all.

I will rewire and make sure things are terminated appropriately to at least test the concept. I cannot rule it out outright so I can do that leg work.

Glad to hear someone has tried it without issue on some large scale setups before. @RTSLVU, is your bus RS485 Half-Duplex?

Thank you again.

[RTSLVU]

---

@rhenderson wrote:

Glad to hear someone has tried it without issue on some large scale setups before. @RTSLVU, is your bus RS485 Half-Duplex?

Thank you again.

---

Half-Duplex, it only uses one twisted pair.

[JÞB]

My magic 8-Ball started rattling all by itself when I read through this topic.

Please check your bus configuration.  I am thinking that you may have; double terminated the bus, Star configured it to both slaves or terminated at the near slave only.

It needs to be wired Master to Slave0 to Slave1 to...to SlaveN and terminated with 285 ohms only at SlaveN.  Anything else will cause real trouble if you look at it as an Eye Diagram.

[rhenderson]

Originally I was in a bit of a Y pattern I would say. Yesterday flattened to a straight path with a 120 ohm termination on each end with similar results. Need to verify that the RS485 on the cRio doesn't have an inbuilt termination as a last step there.

I can try terminating past the last device with 285, but I have never seen that before on an RS485 network before. Attached is from a TI document regarding an rs485 network. Will report back results.

[K C]

Hi,

Like I asked before, did you connect the 0V.

If all devices share the same power supply it is not necessary. But if not the interface line could reach a value outside the common mode range of the RS-485 transceivers.

You can also measure the resistance of the line when the power if off.

Why 285 Ohm ??  A typical value would be 120 Ohm which results in a DC resistance of 60 Ohm.

Kees

[rolfk]

If you use failsafe termination mode the recommended values are 549 Ohm for the two bias resistors and 133 Ohm for the termination resistor.

[rhenderson]

So the modbus commons were and all tied together, but there is maybe 0.01 volt difference in potential between cRio power supply common and the modbus commons. I am looking into the RJ50 breakout to ensure I connected to the right terminal and that the RJ50 exposes the RS485 common since this is a hardware port on the cRio. The 285 ohm was based on another commentor's suggestion. To be clear, you are recommending 120 at both ends of the RS485 line with the modbus commons tied together?

Much appreciated.