For a couple of years I have been using an Arduino to control a rolloff roof. The Arduino runs
24x7. Recently it has been causing problems. The problem is when Ekos is first used things work as
expected.  If Ekos is stopped and restarted it can not connect to the Arduino and produces the
error message about making sure the device is connected to that port. The only way I found to get
it to reconnect is to reboot the system and start again.

On that second attempted start of Ekos the roof driver and the port /dev/ttyACM1 appears normal and
the Arduino is listening for a connection. The appearance of the INDI USB connection in Ekos
has changed from what was previously /dev/ttyACM1 to Arduino_LLC_Arduino_Due-iF00 as show in the
attached screen shot.   

Unlike most Arduino models the Due has 2 USB connections so normally I would see /dev/ttyACM0 and
/dev/ttyACM1 connections.  ttyACM0 is the programming port and is not involved with Ekos
funcionality. The ACM0 Arduino port can use the Arduino console for diagnostic purposes while
the ACM1 port is in use for INDI communications. Today I found that unplugging the programming port
USB cable which Ekos should be unaware of changes the situation. What was /dev/ttyACM1 now becomes
/dev/ttyACM0 of course, the unusual naming in the INDI panel remains as it was with the
LLC-Arduino style identifier.  Without the second port Ekos can now be restarted without requiring
a reboot.

Does anyone know if the diiferent USB identifiers in the INDI panel is due to a Linux or INDI
modification? It is not a naming convention I am familiar with and what if any impact it will have
when returning to using the logical name of /dev/roofCtrl in the udev rules file.

Any suggestions for linux USB related commands that might expose differences from when it does and
does not work?

I have not explored whether adding an second Arduino of the same model will introduce a similar
issue.

 

You can use whatever device created under /dev, the new naming convention is created by INDI from /dev/serial/by-id symbolic links created by the Linux kernel. If there are no identical devices, then it would display them as such. If there are identical devices, it would fall back to the /dev/ttyUSBX and /dev/ttyACMX method.

Thanks that helps to clarify things. I went to look closer intending to use serial/by-id but after reconnecting the programming port could not reproduce the problem.