Decoding RS-485 Modbus RTU - Page 1
Forum section: electronics / projects

author: Mario87
author_rank: Frequent Contributor
timestamp: June 12, 2022, 10:04:52 am
content: Hi all,I have a device here that I was told was tested, but for the life of me cannot get to communicate. Its a custom industrial device that communicates over Modbus RTU. Now when I got it I thought maybe I had incorrect BAUD rates or NodeID's or had A & B the wrong way round, but I have since used CAS Modbus Scanner and found the device at 9600 BAUD on NodeID 1 (essentially, default factory settings).However with CAS Modbus Scanner when it does the discovery it returns error -2 (too short). If I use CAS Modbus Scanner to try and poll data I get the following:Code:=> Poll: 01 03 00 00 00 09 85 CC<= Response: 00 01 83 02 C0 F1 00Error - Modbus message invalid length, shortIf I try to use the proper software for the device and monitor the USB to RS485 using wireshark I see the following, within the software itself it either says timeout or says that the response must be an even length of bytes (the responses I am seeing are 7 bytes long).Code:Poll: 01 03 03 f3 00 02 34 fcResponse: 00 01 83 02 c0 f1 00As you can see, the response for both the CAS tool and the proper software is the same. A bit of googling says this is an "Illegal Data Address" response from the device, which is strange. When tested, they would have used a MOXA Ethernet to D-Sub, so it would be sent from the PC as Modbus TCP, converted to Modbus RTU within the MOXA device and sent over to the unit.I, however, am just using a cheap USB to RS485 device, namely the Waveshare USB To RS232/485/TTL (link below) and I have not used this device before for RS485.https://www.waveshare.com/product/iot-communication/wired-comm-converter/rs232-rs485-can/usb-to-rs232-485-ttl.htmSo I am wondering, is there any way I can monitor and decode the RS485 comms on the lines themselves? I would like to check if the data being sent to / from the unit actually matches what the PC is logging or if this cheap USB to 485 device is introducing errors.I have a Siglent SDS1104X-E (hacked) scope and Digilent Digital Discovery, but neither seem to support RS485 / Modbus decoding. The Digital Discovery can have custom scripts made for it to decode any protocol, but I think that is a bit beyond me.I have checked with the scope and used the math function to do an A-B, but truthfully, I am struggling a bit with the decoding, it SEEMS to me that the data on the scope is not matching what I am seeing on the PC logs, but I am not sure if that's maybe me not decoding it properly?Any idea / suggestions on what to check / what could be wrong could be great, as I have spent essentially the last 2 days on this and not gotten any further.Short of any other options, if I posted the scope signals here from the math function (A-B), would someone on here be willing to try manually decoding the 1st couple of bytes to see if it matches the data being sent?

author: jeremy
author_rank: Super Contributor
timestamp: June 12, 2022, 10:47:57 am
content: I think you should just be able to decode the RS485 on your scope by using the UART serial decoder and the math channel to transform the differential into single ended.Alternatively you can just hook up a second RS485 transceiver in RX mode and just decode the output.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 12, 2022, 11:44:31 am
content: Thanks, I had a fiddle around with the decoder settings on the scope (it cannot decode the math channel) and I noticed that if I probe between A+ & GND, decoder protocol UART, 9600-8-N-1, idle level high and bit order LSB it seems to work fine!I was able to capture 3 packets being polled and the response on the scope at the same time as logging in wireshark, the data is essentially the exact same!The polled data to the device is 100% identical (2 messages were the same as one another and the 3rd was different, but all matched between the scope and wireshark) and the only difference on the received data is that the device is returning just 01 83 02 c0 f1, but wireshark detects it as 00 01 83 02 c0 f1 00 with the extra 00 bytes at the beginning and end.So based on that, it seems the actual USB to RS485 device is working...Not sure where to go from here!

author: jeremy
author_rank: Super Contributor
timestamp: June 12, 2022, 11:54:53 am
content: In your request, have you tried adding a 0 byte before and after your poll? ie00 01 03 00 00 00 09 85 CC 00The device may be expecting the line to be driven low rather than silence on the bus. Technically I think RTU is supposed to have actual silence (ie RS485 bus released) but people do funky thingsEdit: I just looked up Wikipedia, you might need four bytes of zero before and after the poll.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 12, 2022, 12:10:17 pm
content: Thanks, but I don’t think it is that as even the software designed specifically for this product is polling without extra 0’s according to wire shark and I have used this software successfully with this device in the past (not the exact one on my bench obviously, but others).So the issue is certainly not the comms from the PC but looks to be an issue with how that is interpreted.Makes me wonder if the FW has become corrupt or gone funny, but the strange thing is that this is a redundant unit with 2 independent sides and they both behave the same way!Hence I was looking at a common point (the USB to 485 device that has not been used with this before), but now I’ve confirmed it is not that I’m a bit unsure.

author: jeremy
author_rank: Super Contributor
timestamp: June 12, 2022, 12:23:49 pm
content: Right, but the issue could be that your new USB to RS485 converter doesn’t have the same timing with respect to when the bus is being driven; perhaps the master device they tested their software with permanently drives the idle bus low (only one master exists so that is fine) and when the bus is released, the slave device interprets that as a non-idle state - this isn’t covered as part of the modbus spec as far as I know. And RS485 is used for a lot more than just modbus, so I wouldn’t just assume that any USB to RS485 converter would work with any software.The unusual behaviour you see where your response has extra zeros in wireshark could be a clue that there is some mismatch with the timing/idles here. Adding zeros to the request would make the RS485 drive the bus earlier with idle bytes.

author: jeremy
author_rank: Super Contributor
timestamp: June 12, 2022, 12:42:01 pm
content: See more info about this here under “Biasing RS485 connections”:https://blog.opto22.com/optoblog/rs-485-to-terminate-bias-or-bothDriving early zeros is essentially the same thing as biasing your bus with pull-ups.

author: jeremy
author_rank: Super Contributor
timestamp: June 12, 2022, 12:45:59 pm
content: Also I just noticed that your request has 3.5 bytes worth of idle inside the message, can you try reading from holding register 1 instead of 0 to eliminate this?

author: Mario87
author_rank: Frequent Contributor
timestamp: June 12, 2022, 12:57:43 pm
content: Quote from: jeremy on June 12, 2022, 12:42:01 pmI have checked the schematics of the device (luckily have access to them) and there are already 10k biasing resistors in place. If I read scope the A+ line against GND I need to tell the scope that the idle state is high to decode it (pulled up to 5V via resistor) and if I scope the B- line against GND I need to tell the scope the idle state is low (pulled down to 0V ref via resistor) to correctly decode it.To me this looks correct and should negate these potential issues you mention.Quote from: jeremy on June 12, 2022, 12:45:59 pmYou are looking at the data from CAS Modbus Scanner tool, that is just random data, the real data collected by wireshark is in my first post as well, but it is01 03 03 f3 00 02 34 fcThat is data polled directly from the software that is designed for this product, it is captured from WireShark by sniffing the USB port (before it comes into contact with the 485 converter), the data on the lines from the 485 converter matches that perfectly (as long as I set idle high when looking at the A+ line and idle low when looking at the B- line to decode as mentioned above).The only change to data is occurring on the response where the device is sending01 83 02 C0 F1but wireshark is seeing it on the USB port as0001 83 02 C0 F100, so those extra 0's are maybe being added by the USB to 485 device, but from what I have seen 01 is the device ID, 83 means error and 02 is the error code specifically for "illegal data address". The device is reporting it is not happy with the data being sent to it.The data address being polled by the software works on other ones of this same hardware with either a Moxa 3480 or a Brainbox US-324 device without issue, neither of which (from what I can see) offer any special biasing of the 485 lines either, hence biasing is done at the device I am trying to test.

author: jeremy
author_rank: Super Contributor
timestamp: June 12, 2022, 01:02:53 pm
content: Are you able to open the slave device and measure the signal at the TX output of the RS485 transceiver ?

author: Mario87
author_rank: Frequent Contributor
timestamp: June 12, 2022, 01:40:01 pm
content: Not quite, the position of the transceiver means I cannot probe directly onto it when the device is powered, but I can probe on the connector pins of the PCB where the signal is coming into / out of the board incase the issue is signal degredation along the wires and it is exactly the same as when I check at the 485 converter end.The signal matches what I see on wire shark and the response is always the same, except wire shark has the extra 00's at the beginning and end, so the issue is not signal degredation along the wiring either.The transceiver on the slave is close to the connector, but on the other side, sandwiched against another PCB, so can't connect directly to it, but this is very close (within a couple of CM).Also, I noticed you mentioned to prove the Tx, I should mentioned this is half-duplex comms, so there is no separate Rx & Tx, just an A+, B- & GND

author: jeremy
author_rank: Super Contributor
timestamp: June 12, 2022, 01:48:14 pm
content: Hmm, when you say you are probing the wires leaving the board, which pin on the transceiver are you referring to? I think the important one to measure is pin 1 in this diagram (or whichever is equivalent on your transceiver). Sorry, TX out is a bit ambiguous.That way you can see exactly what the MCU will see at the UART input.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 12, 2022, 02:18:13 pm
content: Ah ok, I was probing the connector pins that connect to pins 6 & 7 (A & B lines) with reference to GND (pin 5). I cannot probe the pins on the other end of the transceiver to the MCU as it & the MCU are on the bottom of the board & sandwiched between another board unfortunately.

author: wizard69
author_rank: Super Contributor
timestamp: June 12, 2022, 07:44:29 pm
content: it might pay to step back a minute. For example lets assume that the device is actually getting an invalid address. Are you requesting the right bit of data? Are the additional hardware you are connecting through configured correctly.Another avenue, does the unit support direct connection via RS232 and ASCII protocol. RTU has some interesting requirements that you can ignore via RS232 comms if the device supports such. This might make it easier to understand what is going on. Of course is ASCII isn't supported this will be useless to you.Hopefully you already know about "https://modbus.org/".

author: Mario87
author_rank: Frequent Contributor
timestamp: June 12, 2022, 09:12:16 pm
content: Quote from: wizard69 on June 12, 2022, 07:44:29 pmThanks, but in terms of requesting an invalid address, as I have mentioned above, I the software I am using is designed specifically for this hardware and I have used it with this slave device in the past without issue (not the exact one I am struggling with, but the same hardware / product), so that is not an issue.The only difference is previously I have connected either with a Moxa 3480 or a Brainbox US-324, this time I have a Waveshare USB to RS485 device (link in the original post). There is no configuration on the device other than termination resistance (not required for such low distances, but I have tested it and it didn't help) and within device manager you can adjust latency and such, I have altered these settings as well, again all to no avail, and there is no reason altering those would help anyway, as I have proven that the data on the bus to the devices matches exactly what the PC is sending and vice versa, so there is no setting that is altering the data.The device does not support RS232, but it does have CANBUS support, unfortunately I do not have a CANBUS to USB adapter to test with, however.

author: jeremy
author_rank: Super Contributor
timestamp: June 13, 2022, 07:11:21 am
content: Unfortunately I think probably the only thing you can do then is try to borrow or otherwise find one of the working converters, and compare the signals on the RS485 bus from that converter to the one that you have now.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 20, 2022, 07:56:56 pm
content: Just a small update on this, got sent some other units today and they work flawlessly, exact same item, so definitely nothing to do with my USB to RS485 or the software that was causing issues above.Suspected to be a firmware issue, will no doubt get round to taking a look at some point, but good to know all the supporting equipment is working well!