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

    io.getportstatus returns 53?

    Mervis
    4
    17
    1772
    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.
    • M
      Matt last edited by

      Hi,

      I'm trying to use the serial port /dev/ttyUSB0 on an Axon M505, but I'm getting a port status code of 53 after attempting to open the port. According to the table shown at https://forum.unipi.technology/topic/763/undefined-code-from-io-getportstatus-handle/3 this corresponds to "FileNotFound". I'm supplying the string 'serial:10:115200,8,N,1' to io.openport.

      Any ideas?

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

        Hi @matt,
        can you please verify how your USB device is enumerated in the system? Can you please post the dmesg output issued after connecting the device?

        Thank you in advance and have a nice day,
        Martin

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

          Thanks @martin-kudláček. Here's the dmesg output:

          [237619.915800] usb 2-1: new full-speed USB device number 2 using ohci-platform
[237620.166155] usbcore: registered new interface driver usbserial
[237620.166234] usbcore: registered new interface driver usbserial_generic
[237620.166296] usbserial: USB Serial support registered for generic
[237620.171302] usbcore: registered new interface driver cp210x
[237620.171386] usbserial: USB Serial support registered for cp210x
[237620.181473] cp210x 2-1:1.0: cp210x converter detected
[237620.191236] usb 2-1: cp210x converter now attached to ttyUSB0

          I had to compile the cp210x module to get this device to work, but I can now talk to it Python script so the driver seems to be working fine.

          M 1 Reply Last reply Reply Quote 0
          • M
            Matt @Matt last edited by

            Hi @Martin-Kudláček, any ideas on this? I implemented a workaround with a Raspberry Pi talking to the device and sending the readout to the UniPi over Modbus, but it'd be nice to figure this out.

            P 1 Reply Last reply Reply Quote 0
            • P
              pascal37 @Matt last edited by

              Hi @martin-kudláček, same issue for me.
              Serial device connected on Axon M505 via USB port 1
              (Baud=300, Databits=7, Parity=Even, Stopbits=1)

              def := 'serial:10:300,7,E,1';
handle := io.openport(def);

              I get also status code 53 after opening the port, could you help?

              1 Reply Last reply Reply Quote 0
              • T
                tomas_hora administrators last edited by

                What device is it?

                P 1 Reply Last reply Reply Quote 0
                • P
                  pascal37 @tomas_hora last edited by pascal37

                  Hi @tomas_hora

                  Thanks for your help.

                  It is a optical meter reader:

                  Here are the technical specifications:
                  https://shop.weidmann-elektronik.de/index.php?page=product&info=24

                  Here is also the dmesg output issued after connecting the USB device:

                  [ 3051.254500] usb 2-1: new full-speed USB device number 2 using ohci-platform
[ 3051.541253] usbcore: registered new interface driver usbserial
[ 3051.541302] usbcore: registered new interface driver usbserial_generic
[ 3051.541339] usbserial: USB Serial support registered for generic
[ 3051.551364] usbcore: registered new interface driver ftdi_sio
[ 3051.551419] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 3051.551798] ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
[ 3051.551964] usb 2-1: Detected FT-X
[ 3051.555614] usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB0
                  T Martin Kudláček 2 Replies Last reply Reply Quote 0
                  • T
                    tomas_hora administrators @pascal37 last edited by

                    Hello @pascal37,

                    thanks for pointing this out. We have missed the config file responsible for static mapping of the USB ports. Its now part of the unipi-common package in version 1.2.15.test.20191129155215 so you can install it by "apt update && apt install unipi-common=1.2.15.test.20191129155215" or get a fixed OS image version 2.2.0.20 from our knowledge base.

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

                      Hi @pascal37,
                      just to let you know, that the neccessary changes has been merged into unipi-common v1.2.16 and the MervisOS image 2.2.0.20 is online.

                      1 Reply Last reply Reply Quote 0
                      • P
                        pascal37 last edited by

                        Hi @tomas_hora and @Martin-Kudláček,

                        Yes, many thanks, now it works!

                        1 Reply Last reply Reply Quote 0
                        • P
                          pascal37 last edited by pascal37

                          Dear Unipi support team,

                          Sorry, I have still some issues with USB serial communication on my Axon M505:

                          1. After doing a successfull io.writeport (returns value 1 = data was written) and
                            successfull io.getportstatus (returns value 0 = ok), the PLC task and all programs are "frozen" for about 14 seconds.
                            After that, I start getting the expected answer from my serial device.

                          2. After getting the complete answer, any new io.getportstatus fails (returns value 31 = empty buffer).
                            I have to close and reopen the port to be able to communicate again.

                          Do you know what could cause theses issues?

                          The vendor of the serial device recommends to disable flow control and hardware handshake like this
                          Linux serial port configuration example:

                          stty -F /dev/ttyUSB0 300 -parodd cs7 -cstopb parenb -ixoff -crtscts -hupcl -ixon
-opost -onlcr -isig -icanon -iexten -echo -echoe -echoctl -echoke

                          How can I make sure this is equivalent with a Mervis handle definition:

                          def : string := 'serial:10:300,7,E,1';

                          Many thanks in advance and kind regards.

                          P 1 Reply Last reply Reply Quote 0
                          • P
                            pascal37 @pascal37 last edited by pascal37

                            Dear Unipi support team,

                            Do you have any idea what could cause this USB serial communication freeze in Mervis?

                            As a workaround, I had to develop a python script running directly on the Debian linux OS and transfer data to Mervis via pymodbus client... but it would be a nice to be able to communicate with USB serial interface directly under Mervis.

                            Many thanks in advance for your help.

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

                              Hello @pascal37,
                              please check the dmesg around the time it freezes. It will tell you if the HW is disconnecting.

                              Best regards,
                              Martin

                              1 Reply Last reply Reply Quote 0
                              • P
                                pascal37 last edited by pascal37

                                Hello @Martin-Kudláček

                                I do not have any USB serial related error with dmesg

                                My issue occurs after receiving some data: suddenly io.getportstatus fails (returns value 31 = empty buffer) and the whole Mervis execution task is frozen for about 14 seconds. I have to close and reopen the serial port to be able to communicate again.

                                Since my workaround is working fine (python script running directly on PLC's Debian OS), I suppose the issue is more on the Mervis side or how the serial port is initialized.

                                Here is how I initialize the serial port in my python script:

                                #
# Initialize serial interface
#
ser = serial.Serial(
    port='/dev/ttyUSB0',
    baudrate=300,
    bytesize=serial.SEVENBITS,
    parity=serial.PARITY_EVEN,
    stopbits=serial.STOPBITS_ONE,
    xonxoff=False,
    rtscts=False,
    dsrdtr=False,
)

                                How can I do a strict equivalent definition in Mervis ? (last 3 parameters)

                                Many thanks in advance

                                1 Reply Last reply Reply Quote 0
                                • P
                                  pascal37 last edited by pascal37

                                  Dear support team,

                                  I have a new issue with USB serial port 1 (/dev/ttyUSB0) on my Axon M505:

                                  Communication was quite stable (>2 months) with a Python script running directly on Debian OS.
                                  (I had do this because using the port in Mervis did not work as expected, see above).

                                  But now, since a few days, I get often a serial port failure and following output with dmesg :
                                  Apparently, the USB hub disable the port and linux remaps it automatically to /dev/ttyUSB1 ...
                                  I have to reboot the PLC to be able to use again the USB port 1 with correct mapping to /dev/ttyUSB0 !

                                  [ 1083.551191] hrtimer: interrupt took 542133 ns
[ 7701.614361] usb usb2-port1: disabled by hub (EMI?), re-enabling...
[ 7701.614468] usb 2-1: USB disconnect, device number 2
[ 7701.615927] ftdi_sio ttyUSB0: error from flowcontrol urb
[ 7701.616536] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 7701.616659] ftdi_sio 2-1:1.0: device disconnected
[ 7701.946499] usb 2-1: new full-speed USB device number 3 using ohci-platform
[ 7702.191214] ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
[ 7702.191471] usb 2-1: Detected FT-X
[ 7702.197545] usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB1
[ 7704.706641] i2c i2c-0: mv64xxx_i2c_fsm: Ctlr Error -- state: 0x2, status: 0x0, addr: 0x18, flags: 0x1
[10226.647074] usb usb2-port1: disabled by hub (EMI?), re-enabling...
[10226.647146] usb 2-1: USB disconnect, device number 3
[10226.648321] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[10226.648482] ftdi_sio 2-1:1.0: device disconnected
[10226.980898] usb 2-1: new full-speed USB device number 4 using ohci-platform
[10227.225364] ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
[10227.225650] usb 2-1: Detected FT-X
[10227.229364] usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB1
[10481.675076] usb usb2-port1: disabled by hub (EMI?), re-enabling...
[10481.675148] usb 2-1: USB disconnect, device number 4
[10481.676441] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[10481.676591] ftdi_sio 2-1:1.0: device disconnected
[10482.011841] usb 2-1: new full-speed USB device number 5 using ohci-platform
[10482.254036] ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
[10482.254188] usb 2-1: Detected FT-X
[10482.258873] usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB1
[12105.526945] usb usb2-port1: disabled by hub (EMI?), re-enabling...
[12105.526999] usb 2-1: USB disconnect, device number 5
[12105.527887] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[12105.527992] ftdi_sio 2-1:1.0: device disconnected
[12105.867445] usb 2-1: new full-speed USB device number 6 using ohci-platform
[12106.113305] ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
[12106.113644] usb 2-1: Detected FT-X
[12106.119647] usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB1
[18657.958039] usb usb2-port1: disabled by hub (EMI?), re-enabling...
[18657.958128] usb 2-1: USB disconnect, device number 6
[18657.959412] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[18657.959600] ftdi_sio 2-1:1.0: device disconnected
[18658.292376] usb 2-1: new full-speed USB device number 7 using ohci-platform
[18658.537251] ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
[18658.537612] usb 2-1: Detected FT-X
[18658.541207] usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB1
[19028.489018] usb usb2-port1: disabled by hub (EMI?), re-enabling...
[19028.489106] usb 2-1: USB disconnect, device number 7
[19028.490737] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[19028.490926] ftdi_sio 2-1:1.0: device disconnected
[19028.825400] usb 2-1: new full-speed USB device number 8 using ohci-platform
[19029.075843] ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
[19029.076006] usb 2-1: Detected FT-X
[19029.079076] usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB1
[19686.121969] usb usb2-port1: disabled by hub (EMI?), re-enabling...
[19686.122040] usb 2-1: USB disconnect, device number 8
[19686.123081] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[19686.123228] ftdi_sio 2-1:1.0: device disconnected
[19686.455405] usb 2-1: new full-speed USB device number 9 using ohci-platform
[19686.701190] ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
[19686.701452] usb 2-1: Detected FT-X
[19686.710785] usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB1
[20333.122917] usb usb2-port1: disabled by hub (EMI?), re-enabling...
[20333.122971] usb 2-1: USB disconnect, device number 9
[20333.123729] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[20333.123828] ftdi_sio 2-1:1.0: device disconnected
[20333.454354] usb 2-1: new full-speed USB device number 10 using ohci-platform
[20333.700065] ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
[20333.700248] usb 2-1: Detected FT-X
[20333.706356] usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB1

                                  I dot not have this issue when using USB port 2 !
                                  Could it be a hardware issue with USB port 1 ?

                                  Many thanks in advance for your help

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

                                    Hello @pascal37,
                                    I would blame the serial converter first for the disconnecting issue. You said it started to behave like this after 2 months of operation and I guess you haven't tried it for the same amount of time on the second USB port.

                                    Generally, the enumeration of USB devices is dynamic and if you want the device to be enumerated statically, you need to write an udev rule. Try following this tutorial: https://unix.stackexchange.com/questions/91629/symlinks-on-dev-ttyusb-via-udev

                                    Best regards,
                                    Martin

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

                                      Hi @martin-kudláček,

                                      I am not sure to undersand:

                                      It was stable during > 2 months but now, I can reproduce the issue systematically with USB port 1 (after a few hours of operation), but not when connecting the same hardware to USB port 2.

                                      Kind regards,

                                      Pascal

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