io.getportstatus returns 53?



  • 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?


  • administrators

    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



  • 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.



  • 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.



  • 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?


  • administrators

    What device is it?



  • 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
    

  • administrators

    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.


  • administrators

    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.



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

    Yes, many thanks, now it works!



  • 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.



  • 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.


  • administrators

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

    Best regards,
    Martin



  • 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



  • 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


  • administrators

    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



  • 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


Log in to reply