The Industrial Raspberry Pi Forum

Hi,
I have a MODBUS RTU Master in my RevPi connect, with only 5 actions defined. There is 3 slaves attached, the wiring is all twisted Pair CAT5 via a distribution PCB and short stubs of like 20cm to each device. Total cable length is around 1m estimated. The bus is terminated at the RevPi and on the distribution PCB on the far end. Baudrate is 19200.

So these should be at least for my understanding absolutely best case conditions for signal integrity on the RS485. I get random timeouts from the devices, which my software auto-recovers, but it's not nice anyhow.
In the deamon.log I see something like this:

which correlates with what my software does:


Is there any way to increase the timeouts slightly to see if it's a corner case, or to see even the RAW traffic on the bus and log it somehow? I want to get an understanding whats happening before I blame

a) me
b) KUNBUS
or
c) the manufacturer of the MODBUS slaves (which we use a lot of but in a Profibus version, and never had any issues, and the Profibus timing is one of the strictest I am aware of)

Markus

RR4711 wrote: ↑18 Aug 2020, 12:40 I have a MODBUS RTU Master in my RevPi connect, with only 5 actions defined. There is 3 slaves attached, the wiring is all twisted Pair CAT5 via a distribution PCB and short stubs of like 20cm to each device. Total cable length is around 1m estimated. The bus is terminated at the RevPi and on the distribution PCB on the far end. Baudrate is 19200.

Just to double-check, do you have an external resistor between RS485 P and N on the RevPi side? Because AFAICS the RS485 port on the RevPi Connect front plate is *not* terminated internally. The TI SN65HVD75 transceiver doesn't have a pin to enable termination, unlike the Maxim transceivers used on the RevPi Compact and RevPi Flat, which do allow toggling termination using an ioctl().

lukas wrote: ↑18 Aug 2020, 20:04 Just to double-check, do you have an external resistor between RS485 P and N on the RevPi side? Because AFAICS the RS485 port on the RevPi Connect front plate is *not* terminated internally. The TI SN65HVD75 transceiver doesn't have a pin to enable termination, unlike the Maxim transceivers used on the RevPi Compact and RevPi Flat, which do allow toggling termination using an ioctl().

Yes I do. Also biasing resistors for a defined IDLE state (on the distribution board) fed from an galvanic isolated 5V DCDC Converter (since neither the slaves or the RevPi Connect have 5V available for TERMPOWER). Signal GND of the RS485 is connected to the GND of this DCDC and to the signal GND of the devices.

Let alone the whole confusion about RS485 A/B +/- MARK/SPACE P/N D0/D1 etc.
It took me a while to figure the whole wiring it out and as it works most of the time I think I am not too far off from "right"



It doesn't show the 120R Termination resistor which I crimped into the A/B pins of the RevPi RS485 Connector using ferrules,together with the wire.

The board also takes care of the the supply and the fusing for each slave as they are powered also via the CAT5 cable, and this is AWG28 or less and we need to prove for the aircraft certification that there is adequate fusing for each of the devices. (even if it's just 15cm of cable).
Markus

@Amar: any ideas on that? Some secret debug switches or parameters for the modbus master I could use?

You can increase the default action interval (ms) timeout in pictory for all actions which will automatically increase the modbus response timeout.Please refer this post for further explanation.

https://revolution.kunbus.com/forum/viewtopic.php?t=943

Regards,
Amar

Amar wrote: ↑20 Aug 2020, 16:01 You can increase the default action interval (ms) timeout in pictory for all actions which will automatically increase the modbus response timeout.Please refer this post for further explanation.

https://revolution.kunbus.com/forum/viewtopic.php?t=943

Regards,
Amar

But doesn't that also slow down the update rate of the readings in the process image? That is not an option then.

Hi Markus,
Sure.You are right! But the question flipped other way around is when slave response has a considerable lag then master has to alter its update rate.

When you keep 1000ms as action interval in pictory for all the actions you will notice following in /var/log/daemon.log after reset driver/starting modbus master service again
modbus rtu action timeout: 0 s 500000 us
modbus rtu minimal time between telegrams: 0 s 62500 us

for all action interval of 2000ms
modbus rtu action timeout: 1 s 0 us
modbus rtu minimal time between telegrams: 0 s 125000 us

Once random timeout error does not occur, you can make a tweak for Minimal time between telegrams.
For that you make one of the modbus action interval as say 1000ms and all others as 2000ms.
In that case the minimum action interval is 1000ms which will determine the modbus rtu minimal time between telegrams: 0 s 62500 us (i.e the default one)

Regards,
Amar

We want an update rate close to 5 Hz here. Which I think should be feasible. It works 99.9999% of the time. I try play around with it anyhow. I'm just busy debugging the AOUT glitches we still see together with C. Baumann, but I keep you posted.

Markus