Modbus CRC errors, rs485 extensions on Neuron
After upgrading to the latest kernel modules and modbus tools, there seems to be an issue with rs485 communication with serial devices.
Sending a "turn on coil" command through rs485 produces the following communication output on /dev/ttyNS0
< 0x01 ([SOH]) < 0x05 ([ENQ]) < 0x00 ([NUL]) < 0x00 ([NUL]) < 0xff (�) < 0x00 ([NUL]) < 0x8c (�) < 0x3a (:) > 0x01 ([SOH]) > 0x05 ([ENQ]) > 0x00 ([NUL]) > 0x00 ([NUL]) > 0xff (�) > 0xff (�) > 0x00 ([NUL]) > 0x8c (�) > 0x3a (:)
In the reply from the serial extension, the byte "0xff" seems to be duplicated. This doesn't happen on the physical layer, attached decoded communication using an oscilloscope. Also, other types of communications don't seem to be affected (turn off coils, read inputs etc).
root@basementplc:~# dpkg -l | grep unipi hi unipi-common 1.2.30 armhf Common utilities for Unipi/Neuron/Axon hi unipi-firmware 5.52 all Firmware files for UniPi Neuron/Axon boards hi unipi-firmware-tools 1.2.30 armhf Firmware utilities for UniPi Neuron/Axon controllers. hi unipi-kernel-modules-dkms 1.62 all UniPi Neuron/Axon kernel modules - DKMS source hi unipi-modbus-tools 1.2.30 armhf Modbus server for UniPi Neuron/Axon controllers. root@basementplc:~# uname -a Linux basementplc 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l GNU/Linux
Seems like 0xff gets duplicated in the response even if it is part of the CRC
< 0x01 ([SOH]) < 0x01 ([SOH]) < 0x00 ([NUL]) < 0x00 ([NUL]) < 0x00 ([NUL]) < 0x0e ([SO]) < 0xbd (�) < 0xce (�) > 0x01 ([SOH]) > 0x01 ([SOH]) > 0x02 ([STX]) > 0xf4 (�) > 0x00 ([NUL]) > 0xff (�) > 0xff (�) > 0x3c (<)
Hello @Achilleas-Kotsis ,
thank you for your detail report!
We check this and will get back. With the previous version of unipi-kernel-modules package, the issue never appears?
How did you simulate the issue in the listing above? By a loopback using the other serial?
I used interceptty to create a pty that logs and passes through to the serial port. I don't know the exact version number where it broke, but definitely happened after I last upgraded, previously it was working OK. Currently using a usb->rs485 adaptor and everything works as expected.
the issue is not with the unipi-kernel-module, but with the unipi-firmware 5.52. We have removed it from our repository and advise to downgrade to 5.50 (and flash it to the HW via /opt/unipi/tools/fwspi). We are working on the fix.
Thank you again for reporting this issue and have a nice day,