modbus virtual server USB device path (/dev/ttyACM0) does not support symlinks

mezz · Post by **mezz** » 18 Jan 2018, 00:28

Hello,

when settings up several modbus rtu virtual servers connected via USB the device file path needs specifying as /dev/tty* apparently, so the physical file descriptor of the serial port.
The pi exposes two other ways natively of accessing the same device:
/dev/serial/by-id
/dev/serial/by-path

These are symlinks pointing to /dev/tty*, the advantage is that they possess a meaningful fixed name that does not reshuffled on reboot.

Apparently symlinks are not supported on pictory, which is picky about too long strings too. Even mapping the device files with udev rules did not succeed.

Is there a way of sticking fixed names for USB device files that do not change at reboot?

Thanks

Enrico

volker · Post by **volker** » 18 Jan 2018, 06:55

Hi,
we need to check this, please give us a little time. In all our setups we've had fixed constellations so a reboot never changes the tty x naming. There will be a big change this year when we will update the kernel because the newest one does no longer use ttyx terminology but generic driver names instead. But as far as I'm informed this is not yet part of the new Stretch image which will be released soon.
I'll get back to this thread as soon as we could check the limitations you have commented on...

volker · Post by **volker** » 18 Jan 2018, 09:55

I've checked things together with our experts and we can't find any reason why symlinks should not work with RevPi. You simply need to set up a udev ruel to define your symlink and then use this symlink in PiCtory , e.g. "/dev/mytty".
Please not we did not yet have had time to check this with a test setup hw because right now we are blocked with plenty of high priority work. But if you can't egt this running please tell us exactly what you have done to set up your scenario, what was the result and what you had expected to be the result.

On the other hand I fear that you where expecting any symlinks being part of Debian. This is not the case. To my knowledge there are no such tty-symlinks "natively" on a Raspi. You always have to set up these links yourself. Please follow the explanations in several internet blogs, like:
https://community.openhab.org/t/raspber ... inks/35847
please note that these symlinks only work well if you have any method to distinguish between several USB to serial converters!!! E.g. if you use FTDI chip based converters you get in big trouble: They are all coming without Serial-ID. You just get a Vendor and a Product ID which is the same on all devices. So the only way to distinguish them is to use other attributes like the USB tree and the physical position of your USB device in this tree.
Another method of getting away from this trouble would be to start multiple Modbus devices one for each USB to serial converter. Then use the Modbus information (could be one register) to recognize which Modbus bus you are on and let your application do the dirty work of re-arranging the data according to the correct modbus bus.

mezz · Post by **mezz** » 19 Jan 2018, 00:10

Hi Volker,

in the specific case I am using 2 Arduinos connected to a USB hub connected to a revpi core, I get two device paths that get shuffled on reboot, eg: /dev/ttyACM0, /dev/ttyACM1.
The pi exposes these serial ports as symlinks/aliases in /dev/serial/by-path/* and /dev/serial/by-id/* that can be helpful for identifying particular ports. the by-path and by-id aliases help you find the right physical port.
In my case for instance:

Code: Select all


lrwxrwxrwx 1 root root 13 Jan 16 00:19 usb-Arduino_Srl_Arduino_Mega_75439313737351309111-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 16 00:19 usb-Arduino__www.arduino.cc__0043_85231363136351F012D0-if00 -> ../../ttyACM1

Since these names are two long for PiCtory I have added my own rules to udev as detailed here:
https://unix.stackexchange.com/question ... tatic-name
https://www.domoticz.com/wiki/PersistentUSBDevices
https://g0kao.wordpress.com/2013/08/08/ ... pberry-pi/

In my case I added shorter names in order for PiCtory to be able to save them:

Code: Select all


lrwxrwxrwx 1 root root 7 Jan 16 00:19 /dev/arduino_emon -> ttyACM0
lrwxrwxrwx 1 root root 7 Jan 16 00:19 /dev/arduino_temp -> ttyACM1

Code: Select all


udevadm info --name=/dev/arduino_temp --attribute-walk
udevadm info --name=/dev/ttyACM1 --attribute-walk

gives the same output.

piTest when /dev/ttyACM1 is used returns:

Code: Select all


$ piTest -r temp_1_lo
2 Byte-Value of temp_1_lo: 224 dez (=00e0 hex)

When /dev/arduino_temp is used (save and reset on PiCtory):

Code: Select all


$ piTest -r temp_1_lo
2 Byte-Value of temp_1_lo: 0 dez (=0000 hex)

So apparently the value returned is always 0. I have tried it several times, a reboot as well, anything wrong with what I a doing?
The alias applied to ttyACM0 works, it is the alias on ttyACM1 that does not work.

Cheers

Enrico

volker · Post by **volker** » 19 Jan 2018, 09:10

Hi Enrico,
thanks for clarifying this. I was not aware that the system does establish these symlinks. We always edited a udev file to do the work.
I've just tried to get that name into the PiCtory field and YES you're right and my colleagues who told me there would be no limitations are wrong: The complete path is too long for the field.
okay, this would not be show stopper as you could and have defined your own udev rule.
If your first udev rule works but the second not I would suggest that there might be an error in the rule. could you please post it too? And please also check the error register of the Modbus master (the specific task which fails to give the right value).

mezz · Post by **mezz** » 19 Jan 2018, 10:19

Hi Volker,

I have to correct my statement, I rebooted and after a while even the first rule does not work, so it seems a general issue.
It is as if something was cached after a reset on PiCtory.
I am using udev rules only because the pi native symlinks are too long for PiCtory.
Here are the rules:

file
/etc/udev/rules.d/99-usb-serial.rules

SUBSYSTEM=="tty", ATTRS{idProduct}=="0042", ATTRS{product}=="Arduino Mega ", SYMLINK+="arduino_emon"
SUBSYSTEM=="tty", ATTRS{serial}=="85231363136351F012D0", SYMLINK+="arduino_temp"

As said the symlinks are correctly set up after reboot and the udevadm info --name=/dev/[device id] --attribute-walk gives the correct output.

My suspicion is that symlink is not picked up. The specific task is this:

: revpi_modbusrtu_action.PNG (13.49 KiB) Viewed 14189 times

Thanks for the help, unfortunately without fixed names on each reboot I may need to reset the device path on PiCtory or the like.

volker · Post by **volker** » 22 Jan 2018, 11:52

Hi Enrico,
so finally we could check this and I can say that things are running well on our test system. This is what we have done:

Setting up two virtual modules Modbus RTU on one RevPi3 (up to date sw).
configuring two USB to serial dadapters to be the TTY-port for the Modbus master modules
cyclically writing /reading to two different modbus slaves which are running on a windows PC (PC has two USB to serial adapters for these slaves)
Checking Modbus data traffic with the PC slave software

After resetting the Pi: Insert the USB devices. Configure the correct ports in PiCtory for the 2 masters. Resetting PiControl => correct data traffic on both Modbus RTU connections.

Second set up:
Replacing the direct assignment of serial ports by alias names defined in udev rules:

ACTION=="add", ATTRS{product}=="USB Serial Converter", ATTRS{serial}=="FTG4RZOG", SYMLINK+="ttyUSBSer1"
ACTION=="add", ATTRS{product}=="USB Serial Converter", ATTRS{serial}=="FTAKJ514", SYMLINK+="ttyUSBSer2"

Starting the same way => correct data traffic on both Modbus RTU connections.
Unplugging the USB devices and interchanging the USB ports when plugging in again. Then reset piControl => correct data traffic on both Modbus RTU connections.

we know that the system behavior when hot plugging USB is not the best because of the requirement to reset piControl. But this is a general problem of USB handling. Our Modbus RTU stack is self healing any broken Modbus connection but not the abort of a serial driver under Linux. So you might want to add your own application layer software to self heal this kind of error by either watching USB to fail or Modbus error register in the process image to induce a piTest -x command or the related ioctl call whenever you assume to have a fail and shut down of the USB serial driver.

I do not know what the problem with your setup might be but I assume that your udev rules might not behave well. We've experienced the same (only one USB to serial device was running while the second failed - both vise versa) when the udev rules had been entered wrong. So may be you try and use the syntax I've copied into this posting...
Good luck
Volker

mezz · Post by **mezz** » 22 Jan 2018, 23:35

Hi Volker,

in the end I got it to work: the trick was to use the tty* prefix before the aliases, eg:

SUBSYSTEMS=="usb", ATTRS{serial}=="75439313737351309111", SYMLINK+="ttyemon"
SUBSYSTEMS=="usb", ATTRS{serial}=="85231363136351F012D0", SYMLINK+="tty1wire"

to monitor the /dev/tty* access I used fswatch (https://github.com/emcrisostomo/fswatch):

Code: Select all

fswatch -v /dev/tty1wire

When no actions are set on PiCtory there are no events, when the modbus master is set correctly you can see access logs at the defined intervals.
I noticed that no events are fired if the prefix is other than tty apparently, I don't know if it is required/desired or a regular expression slipped in.

Thank you for your help, your working example helped

Enrico

volker · Post by **volker** » 23 Jan 2018, 00:09

Great! Thanks for the feedback. I'll let this check our Linux Expert... Because it is definitely nothing in the Modbus Stack causing this behavior. The stack uses a string to open the Linux device - so it is fully transparent whatever you have in this string will reach Linux. I wonder where the tty is mandatory to make the Symlink working... I've not yet seen this documented anywhere...