Linux Desktop - RHEL 8.7 - Serial 21.5 - BACKWARDS DISCOVERY - Non-permanent Port Assignments

[RVallieu]

Updated recently to LaBVIEW 2022 with 2022Q3 drivers...  NI continues to have what I consider issues in the serial driver.  At least I can configure 4-wire mode on the RS-485 cards now.

My issue is the non-permanent assignment of ports for the PXI-8433/4 cards in the system AND the fact that they discover in reverse order of the slots in the system which COMPOUNDS the non-permanence of the port assignments.

I have Slot 4, Slot 5, Slot 6, Slot 7 filled with PXI-8433/4

Slot 7 gets ASRL2, 3, 4, 5

Slot 6 gets ASRL6, 7, 8, 9

Slot 5 gets ASRL10, 11, 12, 13

Slot 4 gets ASRL 14, 15, 16, 17

If I pull out a card this all gets jumbled and slot 6 get ASRL2, 3, 4, 5

etc.

Assigning an alias to the ports does not solve the problem.  The Alias just becomes "Unavailable" when the cards are not inserted and stick with the wrong ASRL at that point.

i.e. if I assign COM2 to Slot4-Port1 when it is ASRL14 and then power down and remove the Slot6, 7, 8 cards, COM2 becomes unavailable since it was associated with ASRL14 and now it would be detected as ASRL2.

Why do the cards not discover in rising numerical order?

I will probably have to write detection software with SystemConfig and hope I can assign COM ports on the fly and force my own LUT to Slot/Port - PITA

Anyone have a better way to deal with this in Linux?

[JasonSmith]

This is frustrating. The behavior you are describing is unfortunately the way Linux handles serial port numbering. As ports are enumerated they are assigned a simple index in the driver, and there isn't a mechanism to change the assigned number or to allow gaps in the sequence when hardware is missing on boot.

This is likely a minor inconvenience in a stable system, since as long as hardware is not added or removed you should see the same port numbering across reboots. In a system like yours which is frequently reconfigured I can see how this is much more troublesome.

I think that proceeding System Configuration API makes sense. You could create a utility which reads information about all devices on the system, and uses that to create symbolic links from a name like "PXI1_Slot12_Port1" to the devnode such as "/dev/ttyNI843xPort".

[RVallieu]

Luckily the system will be mostly stable and cards shouldn't be getting removed.  I'm just going to proceed for now assuming the cards will be static and assign aliases to match the expected order from lowest to highest.

[Dhakkan]

Perhaps udev rules could be set up for getting predictable device symlinks (aliases)? This online article captures my intent.

[JasonSmith]

Yes, udev is probably the preferred way to achieve this. I found another example that is more specific to PCI-based hardware. This differs from the USB example in that it calls a helper script to determine the name to use, which allows more flexibility in how that name is determined.

I do not know whether the mechanism they use to achieve the serial number will work with NI hardware. If not, it should be possible to determine the PCI slot number, although this won't intuitively correlate to the actual PXI slot number. System Config can be used to retrieve the PXI chassis/slot number, but I suspect that it might not yet be usable at the time when device enumeration occurs.

StackExchange: How to create serial number based symlinks for PCIe UIO devices? 

[RVallieu]

I had been pointed to udev rules and the USB examples as a possible starting point to a solution.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001E0IeCAK&l=en-US

Unfortunately when I run the udevadm info -a -n /dev/ttyNI843xPort[n]  command and compare the outputs for all of the cards and ports, no unique ATTR presents itself to allow me to create a rule.

There is not a serial number ATTR presented for example.  That must be specific to USB devices.