io.getportstatus returns 53?



  • 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