Hi @Martin-Kudláček,

b86_filter is effectively the best fit for my case, many thanks!

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

Hi @Martin-Kudláček,

Many thanks for you advise: it could be helpfull or maybe also b84 or b85...
I will check whitch FB match best my needs.

Kind regards, Pascal

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

Dear Support team,

I need a function block to get the average of a numeric variable over time:

in1: numeric value
in2: time period
=> (out): average of all different values received on the input during specified time time period

Is there any pre-defined function block in Mervis for this? (did not found...!)

Many thanks in advance for your help

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

Dear Unipi support team,

Is there a way to make the SSCP to SQL Bridge more robust, for example, so that it is not necessary to restart it manually after every solution deployment or PLC restart?

Many thanks in advance and kind regards.

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.

Hi @Martin-Kudláček,

Sorry, I maintain that with Mervis IDE 2.1.3 (80903) it was possible to have multiple tasks running on an Axon M505.

The problem with a single task running multiple programs is that the quickest program will not re-execute as long as the slowest program has not finished...

The other advantage to have multiples tasks is the ability to set different priorities, execution type and sleep ratio.

Please check if this is not a bug with IDE 2.2.0 (91474) !?

Many thanks in advance