Mini 2 - a myriad of issues

So, I have a number of problems. All at once.

Cannot connect to printer via USB

This is a new problem, and popped up seemingly out of nowhere yesterday. If I have my printer on and plugged into my Ubuntu/Cura/Nuc setup, it doesn’t connect. If I use the ‘lsusb’ command in terminal it detects that there’s a Rambo board there … but in Cura, when I click ‘connect,’ it says ‘connection closed.’ I have essentially the same issue when I plug the printer into my Windows 10 laptop – Device Manager knows something is there, and Cura recognises something is plugged in, but I can’t actually connect to it. This issue has become my #1 priority, as all other issues hinge on it.

Having done a bit of digging, I have added myself to the dialout/tty groups prior to posting here. It made no difference. I’m a novice Linux user, so it’s completely possible I’ve missed something ‘obvious’ in my approach to getting Cura (on Ubuntu) to talk to my printer.

Incidentally, getting CuraLE to work on a Win10 machine is an unpleasant experience (normally I don’t use the printer with my Win 10 laptop – I only installed Cura on it as I’ve taken the printer home). But I doubt that’s news to anyone.


This one has been an ongoing issue, and didn’t strike me as a problem until I decided (in an effort to solve problem #1) it was probably worth re-flashing the Mini 2’s board. Basically, it’s a school printer, and at school we keep it plugged into a Nuc with Debian/Cura. Cura lets us do everything, so we don’t really mind that the LCD isn’t functional. The LCD backlight is on, but it doesn’t display anything. It’s been that way since we replaced the board a few months back (some chickenhead, who shall remain nameless but whose name may start with ‘c’, managed to nuke a board while doing he something he shouldn’t have). I’ve swapped the ribbon cables around and that proved to be no solution – the LCD gets no power at all if I do that … I wouldn’t really care if a LCD wasn’t helpful in my effort to re-flash the board.


This is the issue that may have led to issue #1 in the first place. Basically, the printer seems to be … unreliable. I run off a handful of jobs and it gets clogged. Sometimes a cold pull does the trick – I pull the filament, trim it, and reinsert it, and I’m good to go again. At other times I end up disassembling the hot end. Sometimes it seems like the hot end itself isn’t so much jammed as … not picking up filament at all (i.e. the cog doesn’t properly feed the filament down into the extruder). We’re using a decent quality PLA at an appropriate temperature (205*C), and I’m aware that over-tightening the idler can cause problems.


As I said, issue #1 – the non-responsiveness via USB – is my biggest concern. Like all classic IT problems, it’s a case of it working fine (albeit with a useless LCD and a case of the jams) until all of a sudden it wasn’t. I didn’t do anything stupid – i.e. I didn’t have the printer switched on and plugged in while futzing about with the hot end. I also checked the fuses on the board this morning, and none of them seem to be damaged. My electronics knowledge is minimal, but a quick inspection of the board (which, as I said, is relatively new) doesn’t reveal any obvious loose connections/etc.

I’ve also tried, yes, two different USB cables just in case Error #1 was simply caused by a dodgy cable …

I’m willing to bed if you have LCD issues they are causing the connection issues.

On my Mini 1 I bought an add on LCD and the ribbon cables plugs were not installed correctly. If the LCD was connected it wouldn’t turn on and I could not get it to connect via USB. It doesn’t seem like the same issue as mine since it worked before, but I would input. The ribbon cables from the back of the LCD and see if you can connect.

With the PLA I would bump up the temp a bit more. Maybe try 210 or 215. The jamming might be that it’s not hot enough.

What do you mean ‘input the ribbon cables’? As in … buy new ones and swap them over?

Sorry, gotta love autocorrect on my phone.

Unplug the ribbon cables from the back of the LCD.

Detaching the ribbon cables made no difference.

The printer’s assembly is fully documented (the printers are “open source hardware” and LulzBot provides documentation which is thorough enough that you could actually build your own clone printer).

The assembly documents for all printers are located at: (OHAI = Open Hardware Assembly Instructions). Developer documentation (where you can find parts lists, etc.) is located at:

Since your LCD isn’t displaying anything, check section 11 on this page:

It’s possible that there’s a loose wire harness somewhere.

3D printers are a combination of a lot of simple circuits … combined to create a complex machine. But each individual component is typically simple to debug. If you have a 3D printer, it’s a very good idea to also have a multi-meter. It need not be an expensive model because mostly you’ll test for simple continuity, resistance (ohms), or DC voltage.

So … this morning I’ve made (what I think is) a kind of progress.

I’d been doing a bit of digging around on this forum (and elsewhere) and found a post from way back forever ago mentioning the possibility of the ‘reset’ button being jammed down. I prodded it a couple of times and it … slightly sprung up. Instantly I could communicate a little more with the printer – i.e. I was able to update the firmware through CuraLE. Now it’s hung up on a DIFFERENT stage when I try to connect via USB. It says ‘connecting’ and then ‘autodetecting baud rate’. Eventually it fails. It says this even when I manually choose a baud rate. I’ve tried a couple of different cables and different bad rates AND a different USB port but it behaves the same way each time.


I installed Pronterface on my Win10 laptop and when I tried to connect to the printer it spat out this message: Connecting…
[ERROR] Could not connect to COM3 at baudrate 250000:
Serial error: could not open port ‘COM3’: WindowsError(2, ‘The system cannot find the file specified.’)
Printer is now online.
echo:Marlin 1.1.9
echo: Last Updated: Nov 2 201814:37:38 | Author: (Aleph Objects Inc., LulzBot Git Repository)
echo:Compiled: Nov 2 2018
echo: Free Memory: 2427 PlannerBufferBytes: 1408
echo:V55 stored settings retrieved (655 bytes; crc 53710)
echo: G21 ; (mm)
echo: M149 C ; Units in Celsius
echo:Filament settings: Disabled
echo: M200 D3.00
echo: M200 D0
echo:Steps per unit:
echo: M92 X100.00 Y100.00 Z200.00 E420.00
echo:Maximum feedrates (units/s):
echo: M203 X300.00 Y300.00 Z300.00 E40.00
echo:Maximum Acceleration (units/s2):
echo: M201 X9000 Y9000 Z200 E1000
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo: M204 P1000.00 R3000.00 T1000.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 S0.00 T0.00 X12.00 Y12.00 Z0.40 E10.00
echo:Home offset:
echo: M206 X0.00 Y0.00 Z0.00
echo:Auto Bed Leveling:
echo: M420 S0
echo:Material heatup parameters:
echo: M145 S0 H200 B70 F0
echo: M145 S1 H240 B110 F0
echo:PID settings:
echo: M301 P21.00 I1.78 D61.93
echo: M304 P384.33 I72.17 D511.64
echo:Z-Probe Offset (mm):
echo: M851 Z-1.10
echo:Stepper driver current:
echo: M906 X920 Y920 Z960
echo:Hybrid Threshold:
echo: M913 X72 Y72 Z3
echo:Sensorless homing threshold:
echo: M914 X4 Y4
echo:Linear Advance:
echo: M900 K0.00
echo:Filament load/unload lengths:
echo: M603 L40.00 U80.00
Error:MINTEMP triggered, system stopped! Heater_ID: 0
[ERROR] Error:MINTEMP triggered, system stopped! Heater_ID: 0

Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!

I Put my 2 Cents here. From another Forum discussion. Baud rate maybe not correct or mobo defect.