• Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search

    Modbus CRC errors, rs485 extensions on Neuron

    Official EVOK API
    3
    5
    67
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      Achilleas Kotsis last edited by Achilleas Kotsis

      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
      
      1 Reply Last reply Reply Quote 0
      • A
        Achilleas Kotsis last edited by

        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 (<)
        
        1 Reply Last reply Reply Quote 0
        • M
          martin_triska administrators last edited by

          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?

          1 Reply Last reply Reply Quote 0
          • A
            Achilleas Kotsis last edited by

            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.

            Martin Kudláček 1 Reply Last reply Reply Quote 0
            • Martin Kudláček
              Martin Kudláček @Achilleas Kotsis last edited by

              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

              1 Reply Last reply Reply Quote 0
              • First post
                Last post