USB port changes

Basic Information:

Printer Model: Home-built Rostock type Delta
MCU / Printerboard: Arduino MEGA2560, Raspberry Pi 2
klippy.log
klippy.zip (1.5 MB)

Fill out above information and in all cases attach your klippy.log file. Pasting your printer.cfg is not needed
Be sure to check our Knowledge Base and in particular this and this post

Describe your issue: I have been finding problems flashing an ATMEGA2650 and communicating with it from a Pi 2B. Although I have come up with an answer, it is not completely satisfactory. Has anybody a better answer?

DETAILS: Using the method in most documents and videos, vis: use ls /dev/serial/by-id/* to get the I.D. of the port, which in my case was: /dev/serial/by-id/usb-Arduino__www.arduino.cc__0042_856323331363517080D0-if00
and using this both as a flash address and in the printer.cfg file
The above method repeatedly failed, even with different Arduino boards and Raspberry Pis. But using dmesg | tail gave me /dev/ttyACM0 which, used in both flash and printer.cfg did work satisfactorily.
The problem arises if there is a temporary stutter in the connection between the Pi and the Arduino which results in /dev/ttyACM0 being disconnected and a new connection, /dev/ttyACM1 being created so Klipper is now not communicating.

Any solution is gratefully received.

From Linux OS view and also Klipper’s view both
/dev/serial/by-id/usb-Arduino__www.arduino.cc__0042_856323331363517080D0-if00
and
/dev/ttyACM0
are equivalent. In fact they are the same just in a different representation.
I cannot really think about a reason why there should be a difference, except some Linux permission issues.

In any case you could probably use UDEV rules to avoid the described scenario between ACM0 and ACM1. See [How To] Force a specific USB device to a certain TTY · GitHub for an example

I had noticed the symlink pi@miranda:~/printer_data/logs $ ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 Feb 17 11:23 usb-Arduino__www.arduino.cc__0042_856323331363517080D0-if00 → …/…/ttyACM0
but it does not work even now after I have had success with /dev/ttyACM0. I think that it flashed O.K., but perhaps the string was too long for Klipper??
I will lokk at how to force the USB to a TTY
Thanks,
Mike

Thank you Sineos, I set up a new rule and it seems to work.
KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0042", SYMLINK="ttyP3D"

Mike

1 Like