3D Printer Control Over Linux Serial Port

(Christian Heath) #1

OS: Ubuntu 14.04.6 LTS
Main board: Creality CR-10 mainboard
Printer Firmware: Marlin v1.19
Arduino IDE 1.6.8

My goal is to control the movement of the 3D printer by sending gcode over the serial port to the printer. I am starting with sending the M115 command and I expect the printer to respond back with its firmware information. The printer is on /dev/ttyUSB0.

In one terminal I send the M115 command:
echo -e "M115\n" >> /dev/ttyUSB0

I monitor the reply from the printer in a second terminal with:
tail -f /dev/ttyUSB0

The output I get is garbled characters:

It seems like a baud rate mismatch between my computer and the printer. But i have confirmed that Marlin is using baud 115200. It says this in the configuration.h file.
#define BAUDRATE 115200

Linux is also using baud 115200 for /dev/ttyUSB0. To confirm this I typed:
stty < /dev/ttyUSB0
and got the following output:

speed 115200 baud; line = 0;
min = 0; time = 0;
-brkint -icrnl -imaxbel
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

Next, I used Arduino IDE Serial Montor to send the M115 command. I set the baud in the Monitor to 115200 and the printer replied back to the Monitor with the firmware info. So I was able to communicate over the Arduino Serial Monitor just fine.

Why is the communication through the Linux terminal coming out garbled?

(Michael K Johnson) #2

Does minicom work? If so, while it’s running, is stty output different?

Does ttywatch work? ttywatch --logpath . --name USB0 --port /dev/ttyUSB0

1 Like
(Eric Davies) #3

8bit versus 7bit?

1 Like
(Michael K Johnson) #4

Good point… stty -a would definitely help diagnose this! (Why that is not the default escapes me.) cs7 vs cs8 but also istrip

(Christian Heath) #5

Thank you for the quick reply.

I installed minicom per the instructions here:

I then set the following port settings using minicom, Bps/Par/Bits = 115200 8N1:

And voila! I was able to send Gcode to the printer and receive status messages back.

Its worth noting that I needed to configure the ‘screen and keyboard’ in Minicom to enable line feed, carriage return, and line wrap options, as they were disabled by default. The messages I was receiving back were in a single line and running off the screen until I enabled these options. that stumped me for a while.

Output of stty < /dev/ttyUSB0 -a confirms baud112599 and cs8:
I wanted to post an image of the output but I am currently limited to 1 image per post.

So is it fair to say that the best practice for communication over serial ports is to use a terminal emulator, such as minicom, to configure the settings(Bps/Par/Bits) on the port to ensure predictable behavior?

I didn’t have a chance to test ttywatch yet. I will try it by end of this week and reply back with the result.

(Michael K Johnson) #6

The terminal I/O system is a bit baroque and has its roots in the days of mainframes. I read the then-current kernel source code when I wrote the terminal handling chapter of Linux Application Development in order to document what Linux did at the time. It hasn’t changed a lot.

I wrote ttywatch (18 years ago!) as a much lighter-weight replacement for things like minicom. But it assumes that you use stty to set many of the appropriate terminal settings; it doesn’t have a comprehensive set of terminal handling setting options. So while you are running minicom, you can use stty -a to find all the settings, and then set the ones that matter before using ttywatch. Use it only if you want something that doesn’t interpose VT100 emulation. I wrote ttywatch and I still use minicom plenty, including for talking to embedded devices.

Minicom is going to be generally easier, especially if using stty feels like an unnecessary annoyance. You probably want to configure it not to send a modem initialization string though!