USB serial timeout on Mini 1 under Manjaro

General Software
1

Hi, I am running a Mini 1 (approximately 7 years old, non-LCD) under Manjaro using the Cura LE 4.13.17 appimage (latest). The printer is using firmware 2.0.0.144 (latest).

Over the last few months I have noticed that the printer has often stopped receiving hot end temperature telemetry on temperature change commands in Cura, necessitating a restart of Cura. Once or twice there has been a failure to connect which has necessitated a reboot. As of today the printer has stopped connecting to the host altogether, with the following sequence of events and symptoms:

  • Cura indicates that a USB device is available.
  • I click connect.
  • The RAMBo serial indicator LED flashes twice and I hear a very faint click from the control box. I read somewhere that this is indicative of a reboot of the board?
  • I get an immediate message saying that the connection timed out on all baud rates on the relevant device (typically /dev/ttyACM0).

I have tried auto device detection and auto baud rate detection, as well as manual settings.

I can connect to other serial devices without issue.

I can connect to the serial console of the printer bidirectionally using picocom at 250,000 baud:

Terminal ready
start
echo:Marlin 2.0.0.144

echo: Last Updated:  | Author: (Aleph Objects Inc., LulzBot Git Repository)
echo:Compiled: Jul 12 2019
echo: Free Memory: 4871  PlannerBufferBytes: 1376
echo:V67 stored settings retrieved (606 bytes; crc 911)
echo:  G21    ; Units in mm (mm)

echo:Steps per unit:
echo: M92 X100.50 Y100.50 Z1600.00 E833.00
echo:Maximum feedrates (units/s):
echo:  M203 X300.00 Y300.00 Z8.00 E40.00
echo:Maximum Acceleration (units/s2):
echo:  M201 X9000.00 Y9000.00 Z100.00 E1000.00
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo:  M204 P2000.00 R3000.00 T2000.00
echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
echo:  M205 B20000.00 S0.00 T0.00 X12.00 Y12.00 Z0.40 E10.00
echo:Auto Bed Leveling:
echo:  M420 S0
echo:PID settings:
echo:  M301 P28.79 I1.91 D108.51
echo:  M304 P294.00 I65.00 D382.00
echo:Z-Probe Offset (mm):
echo:  M851 Z-1.15
echo:Linear Advance:
echo:  M900 K0.00
echo:Stepper motor currents:
echo:  M907 X1300 Z1630 E1250
echo:Backlash compensation:
echo:  M425 F0.00 X0.00 Y0.00 Z0.00 S3.00
M115
FIRMWARE_NAME:Marlin  FIRMWARE_VERSION:2.0.0.144 EXTRUDER_TYPE:SingleExtruder SOURCE_CODE_URL:https://code.alephobjects.com/diffusion/MARLIN PROTOCOL_VERSION:1.0 MACHINE_TYPE:LulzBot Mini EXTRUDER_COUNT:1 UUID:[REDACTED]
Cap:SERIAL_XON_XOFF:0
Cap:BINARY_FILE_TRANSFER:0
Cap:EEPROM:1
Cap:VOLUMETRIC:0
Cap:AUTOREPORT_TEMP:1
Cap:PROGRESS:0
Cap:PRINT_JOB:1
Cap:AUTOLEVEL:1
Cap:Z_PROBE:1
Cap:LEVELING_DATA:1
Cap:BUILD_PERCENT:0
Cap:SOFTWARE_POWER:0
Cap:TOGGLE_LIGHTS:0
Cap:CASE_LIGHT_BRIGHTNESS:0
Cap:EMERGENCY_PARSER:1
Cap:PROMPT_SUPPORT:0
Cap:AUTOREPORT_SD_STATUS:0
Cap:THERMAL_PROTECTION:1
Cap:MOTION_MODES:0
Cap:CHAMBER_TEMPERATURE:0
ok P15 B4

Moreover:

  • I have correct dialout/uucp configuration.
  • I have tested different cables and USB ports.
  • I’ve deleted and recreated the printer in Cura.
  • I can connect to the printer on a system running Ubuntu (24.04 I think) and issue commands, start prints.
  • I can connect to the printer using Ultimaker Cura on the Manjaro host and jog the steppers, heat the bed and hotend but I cannot initiate a print successfully for some reason.
  • I cannot connect to the printer using Pronterface on the Manjaro host, but this is due to a Python exception at the selected baud rate, which is in my mind likely a bug in Pronterface.

Hopefully someone who reads this can pick out an obvious issue with my configuration or point me in a diagnostic direction.

Thanks.

2

This much tells me it’s a problem you need to work out with the Linux guys, since it seems to work fine on a different system. Those of us here are more familiar with the printers, not Linux troubleshooting.

3

Hi,

I’d only partially agree with that, given that the printer can talk to Ultimaker Cura on the same host to some extent. Obviously this is an OS/software/firmware interaction, however I’ve posted the symptoms here in a hope that someone will recognise ‘ah that’s caused by [QUIRK X]’, even if the root cause may lie strictly outside of the Lulzbot software/hardware ecosystem.

Thanks for your time.

4

You know the Lulzbot mini 1st edition uses & make sure the computing device does not time out also their now is bGcode so be sure to check also gcodes can use up a lot of space so don’t be afraid to save gcodes on a removable drive or dm yourself

5
  • The Mini 1 uses an ATmega 32u2-based USB-serial bridge. There is no FireWire interface.
  • Barring aftermarket addons, the Mini 1 has no provision for reading data from removable storage.
1 Like
6

I’ve done some further investigation:

  • I incorrectly described the system on which the printer works fine as running Ubuntu, it’s actually also Manjaro (we’ll call this System B).
  • After installing software updates on System B it also fails to connect, with the same error.
  • This designates the problem as arising from a recent Manjaro software update.

Unfortunately USB passthrough to a VBox Ubuntu client is unsuccessful.

Whatever the precise issue is, it is likely to affect anyone running the Cura LE appimage on Manjaro (and perhaps Arch more generally).

7

I believe I have identified the root cause of this issue:

  • The Mini (with recent firmware) operates at a baud rate of 250,000.
  • This is AFAICT a nonstandard baud rate.
  • This causes an exception in serialposix.py (22, ‘Invalid argument’) on a connection attempt, which is reported in the Cura LE logs. The Cura LE appimage appears to be bundling its own Python 3.8.
  • This error also occurs in Pronterface which uses the system Python (presently 3.13 on my system), when attempting to connect at 250,000 baud.
  • This indicates that the system termios API is probably throwing some error. This error then causes an exception in the Python code.
  • The nearest standard baud rate is 230400, however a) this cannot be specified in Cura LE; and b) testing in Pronterface reveals that the printer cannot communicate at that rate. Other baud rates do not raise an exception but fail to connect.
  • To the best of my knowledge, termios.h is provided by glibc, which I see was updated on my system to 2.42 on the day I created this thread.

The relevant Cura LE log lines are:

2025-08-29 14:00:50,665 - DEBUG - [MainThread] USBPrinting.USBPrinterOutputDevice.connect [178]: Pulling active printer Baud Rate setting: AUTO
2025-08-29 14:00:50,665 - DEBUG - [MainThread] USBPrinting.USBPrinterOutputDevice.connect [181]: Baud Rate set to AUTO, auto-detecting baud rate…
2025-08-29 14:00:50,667 - DEBUG - [JobQueueWorker [2]] USBPrinting.AutoDetectBaudJob.run [22]: Auto Detect Baud Connection Job started.
2025-08-29 14:00:50,668 - DEBUG - [JobQueueWorker [2]] USBPrinting.AutoDetectBaudJob.run [34]: Serial creation attempt: 1.
2025-08-29 14:00:50,668 - DEBUG - [JobQueueWorker [2]] USBPrinting.AutoDetectBaudJob.run [44]: Checking baud rate 250000.
2025-08-29 14:00:50,679 - ERROR - [JobQueueWorker [2]] UM.Logger.logException [122]: Exception: Job <USBPrinting.AutoDetectBaudJob.AutoDetectBaudJob object at 0x5648ddde1fb0> caused an exception on worker JobQueueWorker [2]
2025-08-29 14:00:50,680 - ERROR - [JobQueueWorker [2]] UM.Logger.logException [126]: Traceback (most recent call last):
2025-08-29 14:00:50,681 - ERROR - [JobQueueWorker [2]] UM.Logger.logException [126]: File “/home/curadev/CuraDev/curabuild-lulzbot/build/inst/lib/python3/dist-packages/UM/JobQueue.py”, line 133, in run
2025-08-29 14:00:50,683 - ERROR - [JobQueueWorker [2]] UM.Logger.logException [126]: File “/tmp/.mount_Cura_Lt7QmWo/usr/bin/plugins/plugins/USBPrinting/AutoDetectBaudJob.py”, line 48, in run
2025-08-29 14:00:50,684 - ERROR - [JobQueueWorker [2]] UM.Logger.logException [126]: serial = Serial(str(self._serial_port), baud_rate, timeout = read_timeout, writeTimeout = write_timeout)
2025-08-29 14:00:50,685 - ERROR - [JobQueueWorker [2]] UM.Logger.logException [126]: File “/home/curadev/CuraDev/environment/lib/python3.8/site-packages/serial/serialutil.py”, line 244, in init
2025-08-29 14:00:50,686 - ERROR - [JobQueueWorker [2]] UM.Logger.logException [126]: File “/home/curadev/CuraDev/environment/lib/python3.8/site-packages/serial/serialposix.py”, line 332, in open
2025-08-29 14:00:50,687 - ERROR - [JobQueueWorker [2]] UM.Logger.logException [126]: File “/home/curadev/CuraDev/environment/lib/python3.8/site-packages/serial/serialposix.py”, line 517, in _reconfigure_port
2025-08-29 14:00:50,689 - ERROR - [JobQueueWorker [2]] UM.Logger.logException [126]: termios.error: (22, ‘Invalid argument’)
2025-08-29 14:00:50,690 - WARNING - [MainThread] USBPrinting.USBPrinterOutputDevice._autoDetectFinished [138]: Auto Detect Baud failed.

I see in the glibc release notes for 2.42:

* On Linux, the <termios.h> interface now supports arbitrary baud rates;
  speed_t is redefined to simply be the baud rate specified as an
  unsigned int, which matches the kernel interface.

This change in the termios API probably means that the serialposix.py signature for configuring a serial connection has changed subtly in some way and that the 250,000 baud specification is not being sent properly. This is likely to affect other printers on Linux as their glibc installations are updated. Manjaro (being Arch-derived) is ahead of the curve.

Possible mitigations:

  1. If someone could show me how to bust my Mini 1 firmware back to 115200 baud that should/might work.
  2. This error indicates an incompatibility between Cura LE and glibc 2.42 which bears patching.
  3. I was able to get printing to work on Ultimaker Cura, however the lack of Lulzbot presets and other affordances means that the print quality is poor (but not catastrophically so). The start/finish G-code also does not benefit from automatic population of material-specific variables like on Cura LE. So this is a stopgap mitigation but requires some dialling in.

Possible enhancements:

Exceptions like this could stand to be echoed to the terminal. The error pop-up in Cura is also misleading because the error does not appear to be a timeout, at least not directly.

Thanks for your time.

@TimPostma: it’s impolite to silently edit information out of a post after someone has replied to it, because it makes it look like that person is making statements apropos of nothing.

8

Baud rate is set in configuration.h when compiling marlin:

image
image1623×353 36.9 KB

I’m surprised 250000 is causing issues, since that’s what Marlin uses as a default.

9

Hi,

Thanks for your reply. I should perhaps write less authoritatively when I say that 250,000 is a non-standard baud rate. Rather, I have seen others characterise it as ‘non-standard’, and it does not appear to be one of the constants commonly given in baud rate enumerations (e.g. Cannot use non-standard baud rates for uploading on MacOS · Issue #771 · avrdudes/avrdude · GitHub )

The breaking change in glibc is probably related to this: termios: add new baud_t interface, defined to be explicitly numeric · bminor/glibc@5f13851 · GitHub

If Cura LE is trying to specify the baud rate for communication by reference to a non-existent ‘B250000’ constant or similar (after glibc has moved to integer(?) baud rates, potentially supplemented by a collection of constants not including B250000), that might account for the exception, but that’s just a guess. I’d have to decipher the code.

In the meantime I have successfully dialled in Ultimaker Cura and am getting good prints, albeit without some of the useful Cura LE functionality (e.g. extrude/retract macro buttons). I’ll hold off modifying the firmware so as not to risk bricking the printer.

Thanks for your time.

10

It’s tough to brick the printer with a valid Marlin build (maybe impossible?). It does make me wonder why they chose to go with 250000 instead of an actual standard baud rate.