Modbus RTU with Red Lion DA10D

Hi all,

Got an issue with some equipment I'm trying to get talking over modbus RTU, using a Red Lion DA10D. I have attached a couple of screenshots of the configuration settings.

I have several issues presenting, but the main one is that we appear to be receiving data once, timing out, and then having to re-establish the connection to receive more data.

I’ve created a very simple program which is just trying to read a single Modbus register one slave device into an internal block. The DA10D is set up as a modbus RTU master, slave timeout set to 6000ms, and the "ping holding register" value is set to the same address as the single register being read (I have also tried setting it to zero to disable it).

On the DA10D’s RX/TX indicators you see a repeated sequence: single green flash, one second pause, red flash immediately followed by green flash, 6 second pause, and repeat. Assuming I’m correct in saying that green is RX and red is TX, we’re seeing:

Transmit
(one second pause)
Receive and immediate transmit
(six second pause)

…and repeat. It’s as if the red lion transmits and waits for a response, which takes about a second to come. As soon as it gets a response, the red lion transmits again, but this time the slave doesn’t respond at all. Six seconds later the timeout expires and the red lion tries again, with the same results. When the Rx light flashes I do actually receive data, so I know that all of my wiring/comms settings/etc are working. If I set the timeout delay down low enough, it works enough to be largely functional, as the data will update every few seconds, but it's still not right.

I have adjusted the timeout setting and the behaviour is exactly the same, except that the six second pause obviously changes accordingly.

I have adjusted the minimum polling delay from 100ms to 500ms; the result is an extended delay between the Rx light and the subsequent Tx light, but regardless of this delay, the slave device never responds to the second Tx.

I have tried putting in a communication delay of 1-2 seconds; no change.

I have tried all the different poll modes for the block itself (Automatic, continuous, timed with various time settings from 500ms to 5000ms). No change to the observed behaviour.

I have tried changing baud rates on both devices and both of the RTU framing options; no change to the observed behaviour.

Anyone got any ideas as to what else I could try?

Further diagnostics with Modscan. It briefly reports "received invalid response from modbus query", then changes to "exception response received from modbus device".

Modbus data capture:


XMT: [001][003][000][031][000][001][053][076]
RCV: [001][003][002][064][069]

XMT: [001][003][000][031][000][001][053][076]
RCV: [001][003][002][064][069]

XMT: [001][003][000][031][000][001][053][076]
RCV: [001][032][005][075][010][118]

XMT: [001][003][000][031][000][001][053][076]
RCV: [001][003][002][064][069]

XMT: [001][003][000][031][000][001][053][076]
RCV: [001][003][002][064][069]

XMT: [001][003][000][031][000][001][053][076]
RCV: [001][032][005][075][010][118]

XMT: [001][003][000][031][000][001][053][076]
RCV: [001][003][002][064][069]

XMT: [001][003][000][031][000][001][053][076]
RCV: [001][003][001][000][112][127]

XMT: [001][003][000][031][000][001][053][076]
RCV: [001][003][002][064][069]

XMT: [001][003][000][031][000][001][053][076]
RCV: [001][003][001][000][112][127]

XMT: [001][003][000][031][000][001][053][076]
RCV: [001][003][002][064][069]

XMT: [001][003][000][031][000][001][053][076]
RCV: [001][003][002][064][069]

Your screen shot shows that you have Ignore Read Exceptions enabled and your Modscan screen shot seems to show that is what is happening. The device is returning an exception response.

Is the Red Lion actually getting the correct data if only once? If not, I would look at the possibility that you are reading one word of a two word block, or that there is zero vs. one based addressing issue.

If I have the "ignore read exceptions" box checked, then yes, I do get the correct data. Without that, I get nothing. I had to offset the address by one as you suggest, but it's definitely getting the right data. It's a single status word that I'm trying to read, and in any case I'm actually able to both read and write multiple registers and everything behaves as it should, except that it's taking forever because of the repeated timeouts. If I have the timeout set to 5 seconds, it takes 20-25 seconds for the data to update. So for troubleshooting purposes I've stripped it back to just reading a single word and trying to get it happening normally.

The checksums appear to be wrong on those Modbus polls.

Are those from ModScan, or from the Red Lion ?

The values appear to be in Decimal, since the requested address value is "31".

But when I run them through the never-been-wrong-before Chipkin Modbus Parser, the checksum bytes are incorrect on both the Transmit and Receive frames.

XMT: [001][003][000][031][000][001][053][076]
RCV: [001][003][002][064][069]

Convert to hex

XMT: [01][03][00][1F][00][01] [CRC] should have checksum [B5][CC], not [35][4C]
RCV: [01][03][02] [CRC] should have [A1][31], not [40][45]

I could certainly be wrong (and I'm eager to be), but I've never seen either Chipkin or ModScan give the wrong checksums so I must be reading this incorrectly.

Even the response frame for an error response should have [83] not [03], for Error Response 0x02 = Invalid Address.

Because the response frame matches the command (function 0x03), it should contain a valid response, but there's only one byte and there should be at least two for a Holding Register.

The more I look at that raw serial capture the more it looks wrong.

I used to be able to decode Modbus by eye, but these days I bring up the SimplyModbus website and my Chipkin parser for reference.

The first two bytes of a Modbus RTU Command or Response frame are always the Slave Address and the Function Code.

When there's an exception, the high bit of the Function Code is set =1, which makes the first digit an 8 in hex.

So when you're looking at Modbus traffic in hex, you can just focus on the first bytes and look for errors:

Tx: 01 03 [address, length, CRC]
Rx: 01 03 [length, data, CRC]

Tx: 01 03 [address, length, CRC]
Rx: 01 03 [length, data, CRC]

Tx: 01 03 [address, length, CRC]
Rx: 01 83 [exception code, CRC] (exception code)


I have never seen Red Lion, ModScan, or Chipkin get the error checking calculations wrong, so I don't know how to explain that.

I suspect that the Modbus RTU implementation on that slave device is all fouled up. It's not properly sending exception codes, and it's replying both with exceptions and with valid data to the exact same Modbus poll frame.

Edit: I noticed that you also set "Disable Frame Validation" to YES, along with "Ignore Read Exceptions". Those should not need to be set, for a Red Lion talking to a correctly configured and correctly functioning Modbus RTU device.

It turns out the immediate culprit was indeed an incorrect (and poorly documented) setting in the slave device. Once that was corrected, the device started responding properly to ModScan.

Unfortunately it didn't resolve the overall problem like I'd hoped it would. Basically I was able to communicate with one of these devices at a time, but the poll rate settings etc never really seemed to have any effect. And then as soon as I tried to connect a second device, it would only ever talk to one at a time.

I eventually noticed that every time the master sent a request, the response would come back a whole second later. I thought I was seeing Tx-Rx, then a gap, then Tx-Rx, and so on. Turns out I was seeing Tx, wait a second, Rx and immediate Tx, and so on. Basically, the slave takes a whole second to gather it's one or two registers of data before putting them back on the wire. When I had two devices in the "scan list" this was presumably a problem because the red lion would have to give up and move on to poll the second device, only to have the first device respond after requesting something from the second device. So everything hits the fan and the red lion tries to start again.

So, I set the blocks in the red lion to update on a timed basis, two seconds apart, and now it will successfully talk to both devices (albeit very slowly), as it doesn't have a second device to poll straight away.

So, ultimately, I think that it's simply that these slave devices are utter garbage and there's not much more I can do with them. Previous non-modbus encounters with the devices a few years ago in a far away country have given me the same impression; it seems like nothing has changed.


Thanks for taking a look Ken and Okie, appreciate the information!

I eventually noticed that every time the master sent a request, the response would come back a whole second later.

Click to expand...

Does the device have a configurable timeout value, because it's expecting repeat commands ?

Does it have a configurable "Reply Delay", intended to allow half-duplex communications with modems or automatic RS485 transmit detection ?

A thoroughly wild guess: their firmware developers mistook the timeout for the reply delay.

There aren't any settings like that as far as I can see, and that's even after I enter the OEM-only-not-for-end-users password that I wrangled out of the OEM. Your wild guess falls well within the realm of possibility, given the other, erm, "shortcomings" that are apparent in the device's firmware/software.

Good news! The OEM got back to me and confirmed that the one second delay in response times is "normal" and "no problem" and that if I'm reading 5 registers I should set the timeout to 5 seconds because modbus is "slow".

"normal", eh?

<facepalm>