Modbus CRC errors, rs485 extensions on Neuron



  • Hello,
    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).
    dso.png

    Package versions:

    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 (<)
    

  • administrators

    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.


  • administrators

    Hello @Achilleas-Kotsis,
    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,
    Martin


Log in to reply