Page 1 of 1
MODBUS RTU Master stops working with external FTDI Devices
Posted: 12 Mar 2020, 18:41
by RR4711
Hi,
I noticed my Modbus Communication stopped working since I installed a 4 Port USB Hub that has 3 Peltier Controller Boards attached to it with embedded FTDI 232 Chips for communication. I guess the kunbus udev rules assigning the tty device to the RevPi internal FTDI Chip used for the 485 communication do not consider the serial number of the chips onboard properly (which should be known to kunbus and checked for) and the modbus master now tries to communicate with one of my 3 external FTDI chips instead, which obviously failes
Is there a fix planned? I would pin down the udev rules to the serial number of the chip onboard (I'm aware this is extra work in the production line but the MAC adresses are also programmed there and written to a config file, so why not the same for the MODBUS chip? Or at least an option to update the udev rules when someone activates the MODBUS master via Pictory (like a popup "please remove all external HW for now", and then just scan the remaining FTDI chips (which must be the onboard ones then) serial number and create a rule accordingly)
Markus
Re: MODBUS RTU Master stops working with external FTDI Devices
Posted: 16 Mar 2020, 15:32
by Amar
You can first investigate the listed USB devices
lsusb –v and ls /dev/ttyU*
Change Modbus Master default devicepath in pictory:
/dev/ttyUSB0
Re: MODBUS RTU Master stops working with external FTDI Devices
Posted: 16 Mar 2020, 15:35
by RR4711
Yeah well that would be a hack but why not make the UDEV scripts bulletproof so that the onboard RS485 is always /dev/ttyUSB0?
I expect a system that works perfectly beforehand to not stop working suddenly just because I plug additional USB devices....
Re: MODBUS RTU Master stops working with external FTDI Devices
Posted: 17 Mar 2020, 11:33
by lukas
That's not possible. The /dev/ttyUSB* devices are assigned dynamically and it is not guaranteed that ttyUSB0 is assigned to the RS485 port on the front of the RevPi Connect. E.g., if you unbind the driver from the internal RS485 port, then plug in an RS485 adapter in one of the USB ports and finally rebind the driver to the internal RS485 port, then ttyUSB0 will be assigned to the RS485 USB adapter and ttyUSB1 will be assigned to the internal RS485 port.
udev only allows creating symlinks for devices, not assigning ttyUSB0 to a specific port. We've put the following rules in /lib/udev/rules.d/50-revpi.rules to assign symlinks to the internal RS485 ports of the RevPi Connect:
Code: Select all
ACTION=="add", DEVPATH=="*/usb1/1-1/1-1.5/1-1.5.2/*", SYMLINK+="ttyRS485"
ACTION=="add", DEVPATH=="*/usb1/1-1/1-1.5/1-1.5.3/*", SYMLINK+="ttyConBridge"
As you can see, /dev/ttyRS485 will always point to the internal USB port and the port is identified by the physical USB topology (which is soldered down and therefore cannot change). This is simpler and more robust than identifying the port by the FTDI serial number.
To summarize, if you want to run a piModbusMaster on the internal RS485 port, configure it to use /dev/ttyRS485. That path is guaranteed to point to the internal RS485 port.
We will amend PiCtory to use /dev/ttyRS485 as the default if there's a RevPi Connect on the canvas and there's not yet another piModbusMaster on the canvas which uses /dev/ttyRS485.
Re: MODBUS RTU Master stops working with external FTDI Devices
Posted: 17 Mar 2020, 12:23
by RR4711
it IS possible because the FTDI chips have a unique serial number which is known to kunbus (can be readout during production). It could be handled during production as it is done with the MAC adresses that are written to the config file.
I did it myself for a differnt project.
See here: (in German)
https://wiki.siduction.de/index.php?tit ... udev-Regel
Re: MODBUS RTU Master stops working with external FTDI Devices
Posted: 17 Mar 2020, 13:57
by RR4711
lukas wrote: ↑17 Mar 2020, 11:33
This is simpler and more robust than identifying the port by the FTDI serial number.
Obviously not,otherwise I wouldn't have issues here
Re: MODBUS RTU Master stops working with external FTDI Devices
Posted: 20 Mar 2020, 08:32
by lukas
RR4711 wrote: ↑17 Mar 2020, 12:23
it IS possible because the FTDI chips have a unique serial number which is known to kunbus (can be readout during production). It could be handled during production as it is done with the MAC adresses that are written to the config file.
By "that's not possible" I was referring to your request to always assign /dev/ttyUSB0 to the internal RS485 socket of the RevPi Connect. The /dev/ttyUSB* numbers are dynamically assigned by the kernel.
Yes, of course it's possible to differentiate the internal RS485 socket from an FTDI chip attached to one of the USB ports via the serial number. But if the internal RS485 socket is instead identified by the USB topology, we can use the same udev rule on every Connect, instead of having a per-device rule. So users can flash the same image on every Connect and it "just works". If we would instead use the FTDI serial number, users would have to provide it to revpi-factory-reset or an ever-growing list of FTDI serial numbers would have to be shipped on the image. That approach wouldn't scale.
Re: MODBUS RTU Master stops working with external FTDI Devices
Posted: 07 Apr 2020, 22:40
by RR4711
lukas wrote: ↑17 Mar 2020, 11:33
To summarize, if you want to run a piModbusMaster on the internal RS485 port, configure it to use /dev/ttyRS485. That path is guaranteed to point to the internal RS485 port.
Somehow this doesn't work for me. I noticed the symlinks have a different permission than the /dev/ttyUSBx files.
My log gets flooded with:
Code: Select all
Apr 7 20:22:47 sopdetpump piModbusMaster[1522]: modbus rtu action device: /dev/ttyRS485, slave address: 1 function: 0x03, address: 33 failed -1/110/-112345568
Apr 7 20:22:47 sopdetpump piModbusMaster[1522]: modbus rtu action device: /dev/ttyRS485, slave address: 2 function: 0x06, address: 34 failed -1/110/-112345568
Apr 7 20:22:47 sopdetpump piModbusMaster[1522]: modbus rtu action device: /dev/ttyRS485, slave address: 1 function: 0x06, address: 34 failed -1/110/-112345568
Apr 7 20:22:47 sopdetpump piModbusMaster[1522]: modbus rtu action device: /dev/ttyRS485, slave address: 3 function: 0x03, address: 33 failed -1/110/-112345568
I added a custom udev rule to assign my 3 FTDI based devices a unique name (based on the serial number)
The /dev looks like this:
Code: Select all
crw--w---- 1 root tty 4, 9 Apr 7 20:14 tty9
crw-rw---- 1 root dialout 204, 64 Apr 7 20:32 ttyAMA0
lrwxrwxrwx 1 root root 7 Apr 7 20:15 ttyConBridge -> ttyUSB4
crw------- 1 root root 5, 3 Apr 7 20:14 ttyprintk
lrwxrwxrwx 1 root root 7 Apr 7 20:15 ttyRS485 -> ttyUSB2
lrwxrwxrwx 1 root root 7 Apr 7 20:15 ttyTEC1 -> ttyUSB3
lrwxrwxrwx 1 root root 7 Apr 7 20:15 ttyTEC2 -> ttyUSB1
lrwxrwxrwx 1 root root 7 Apr 7 20:15 ttyTEC3 -> ttyUSB0
crw-rw---- 1 root dialout 188, 0 Apr 7 20:15 ttyUSB0
crw-rw---- 1 root dialout 188, 1 Apr 7 20:15 ttyUSB1
crw-rw---- 1 root dialout 188, 2 Apr 7 20:32 ttyUSB2
crw-rw---- 1 root dialout 188, 3 Apr 7 20:15 ttyUSB3
crw-rw---- 1 root dialout 188, 4 Apr 7 20:15 ttyUSB4
I have no idea what going on and limited access to the device especially the inside as it is certified for operation in an aircraft and I'm not allowed to take it apart and see what happens if I unplug the Hub with the additional 3 FTDI devices. I just remember the communication to the MODBUS devices stopped when the HUB with the FTDIs was introduced (I can see the traffic by LEDs flashing on my MODBUS devices for each request, it stopped).
When the HUB was not in, the RS485 was on /dev/ttyUSB0 which was configured in the pictory and it worked. Can that be a permission thing with the symlink? Any hints on how to debug (preferrably via SSH and non-physical access...)
We will amend PiCtory to use /dev/ttyRS485 as the default if there's a RevPi Connect on the canvas and there's not yet another piModbusMaster on the canvas which uses /dev/ttyRS485.
So you think it *should* work this way?
Re: MODBUS RTU Master stops working with external FTDI Devices
Posted: 09 Apr 2020, 15:50
by RR4711
It turned out to be one of the modbus connectors of my distribution board came lose. I still don't know how this could ruin the communication to the other 2 slaves but well. Instrument undergoes recheck then with certfying agency.
Sorry for the noise
Markus