So, my arduino mega clone for RAMPS shows up as /dev/ttyACM0 .

So, my arduino mega clone for RAMPS shows up as /dev/ttyACM0 . On one computer (Linux mint LXDE maybe a year old?) @OctoPrint sees this and is able to connect. On another computer, OctoPrint does not see it. Both computers can flash the board through the arduino IDE on the device mentioned above. Anyone know what I might look for before I jump in? First thing I’ll check is group permissions for my users and the device.

From the terminal: “lsusb” and “dmesg” can be helpful.
I make udev rules for my arduinos and printers.

I’ve a VIA C7 I use with a funduino. Lubuntu pronterface will toggle between ACM0 and ACM1 every time I unplug and plug it in.

Maybe check for 1?

What’s the flavor of the other OS? Arch? If so, in arch you need to be part of the uucp group, or you can create a set of udev rules that enable the port with relaxed restrictions.

On Ubuntu and Debian, you need to add yourself to the dialout group to connect to a RAMPS-equiped RepRap with Pronterface, I wonder if it’s the same for Octoprint?

Other OS is Linux Mint 15. Unfortunately for our knowledge’s sake, a reboot this morning made the other machine see it as well. Permissions were the same in both spots. Maybe the arduino IDE hosed something. Thanks for the tip on udev rules though. Should come in handy.

Arduino IDE seems to probe serial devices when it starts. My printer halts mid-print when I start ArduinoIDE. Of course I learned this 8 hours into a print.

Older linux kernels sometimes registered Arduino boards as /dev/ttyUSBxx which might explain why Octoprint cannot find it.

@Daid_Braam , I’m on Linux 3.14 (for workgroups!) and I get mine registered as ttyUSBxx, Octoprint works fine with it. I’ve found my Sanguinololu (on the same machine) registers as ttyACMxx, so maybe it has to do with the board having an FTDI chip vs a 32u4

My old Gen 6 board (which uses the Sanguinololu arduino addons) registers as /dev/ttyUSB0. When I was having the problem, OctoPrint was only showing USB0, and not ACM0 as the new board appears to register as.