X homing kills Mini 2

I’ve had a Mini 2 for about 6 weeks now. All has been going well until the last couple days when the X homing process starts grinding and the printer is killed. I can’t seem to find the X limit switch, so I’m not sure how the homing is done on this thing. If the x homing does work, then a lot of times if fails when trying to do the bed leveling. Any knowledge would be appreciated. I’ve emailed support, but I’ve heard that has been an issue since the ownership change.

The Mini 2 uses a smart motor that can “sense” when movement is being resisted (when the motor hits a limit it will draw more amperage and the board can detect this). There is no physical end-stop switch/button.

I don’t own a Mini 2, but I do own a TAZ Pro and it works the same way. On my Pro, under the advanced configuration menu there is a “bump sense” setting.

Adjusting downward toward 0 makes it less sensitive. Adjusting upward makes it more sensitive.

You want to find the lowest value you can get away with that reliable detects the limit. If you adjust it too high then moderate amounts of resistance can trigger the printer thinking it hit an end stop … when it didn’t. This can result in layer-shifts on your part.

The Marlin firmware “M194” g-code can also be used to adjust this (via the Terminal in Cura or whatever slicer software you use). See: https://marlinfw.org/docs/gcode/M914.html

Thank you! That makes sense. I think the grinding is the motor spinning with the belt not moving. It’s there any benefit to tighten the belt?

It sounds like I may need to make the setting more sensitive?

Thanks again.

It sounds like I may need to make the setting more sensitive?

Yes. Your Mini 2 has a “Einsy Retro” control board (one of these: https://www.lulzbot.com/store/parts/einsy-retro-board-v1). I have a TAZ Workhorse (which uses a RAMBo board) and a TAZ Pro (which uses an Archim board). My Workhorse has a mechanical switch on the X-axis stop, but the PRO uses the same “TNC Bump” sensing system. On that printer, there is a menu to access the “Bump Sense” setting and the printer is set to a value of about 6.

I’m not sure how to navigate to this setting on your Mini 2. On my PRO the setting is located under “Menu” -> “Advanced Settings” -> “Bump Sense”. You can check the menu on your Mini 2 to see if you can find a similar setting.

But you can also do it via the “Terminal” window in Cura. In the Cura “Monitor” screen (in Cura LE 3.6.x there’s a “Prepare” and “Monitor” selection along the top of the window) then on the right side you can “Connect” to the printer (assuming it is connected via USB). Once connected, click the “Terminal” button to open a Terminal window. This will let you see the G-codes being processed by the printer but will also let you interact with it (you can manually type in G-code commands).

See: https://marlinfw.org/docs/gcode/M914.html

If you type:


This will return a report with all the current settings.

Look through that list for a line that begins with “M914” and those are your bump sense settings. There should be a value for each axis that uses bump-sense. E.g. if your printer use bump-sense on both X & Y axis but uses a physical switch on the Z axis then you would only see settings for X & Y … not Z.

For example it might say:

M914 X5 Y5

Meaning both X & Y are using a value of ‘5’ (in the range of 0 to 255).

You can use the M914 command to change it. E.g. suppose you wanted to set it to 8, then you would type:

M914 X8

This will change it to 8 … BUT it wont remember the change (the next time you power-cycle the printer it would revert to the old value … e.g. in my example it would revert back to 5 again.)

To save the value, use the M500 command (this is the ‘save settings’ command in Marlin). This commits the setting to non-volatile memory so that it will still be there the next time you power-on the printer.

Your values may be a little different than the values used by my printer.

Again, if values are too large it can false trigger the printer into thinking it hit the travel limit… and this might result in a layer-shift on your prints. If you start to see layer shifts, you might need to dial the value back down a bit. The idea is to find a value just large enough to reliably trigger when it really hits the X-axis limit, but no larger to avoid false-triggers and layer shifts.

For this reason, you try to use the lowest value you can get away with … but high enough to prevent the grinding sound of the printer trying to force the X-axis to move when it hits the travel limit.

I’ve changed it in a script (I use simplify 3D). It’s still not working. I’m wondering if it is hardware and not software at this point. When I get past homing, then it locks up at bed leveling.

I’ve emailed Lulzbot, I’m not sure if they are responding these days. Lots of negative comments on the forum.

I’ll keep working on it. Thanks again.


When I bought my printer they had the reputation for having the best support (by far) of any 3D printer company.

Certainly the lay-off late last fall was a dark period in their history and I feel bad for all the employees who lost their jobs. The good news was they got acquired. The bad news was the acquisition involved a move to a new state. That’s a hard disruption to any business (even if they hadn’t recently laid off most of their workforce) because I think most employees can’t easily pick up and move to a new state. They may family obligation, school, or other reasons why they need to stay behind. Sure… some will move, but most will find it difficult or impossible.

The last business that I watched go through above across the country needed about three months before things started getting back to normal. This is because the move itself takes a while. All production has to stop. Everything has to be dissembled and crated. Parts used to build product all have to be packed. That product would have been on shelving units but those shelving units need to get packed. And nothing can get assembled at the new location without those shelving units (so the last thing they take apart at the old site has to be the first thing they put together at the new site).

And of course… they have to hire and train a lot of new staff.

My personal guess was that I did not expect LulzBot to get back to anything near normal much before March.

You can (and should) follow them on Facebook to see how they are doing (you’ll get more info there than you will here): https://www.facebook.com/LulzBot/

If you go there, you’ll see they finally have production rolling again and lots of new employees (probably still not enough because I think they are still hiring).

So I expect things will get back to normal in the not-too-distant future. I pretty much expected things to be pretty bad for these last couple of months … but that’s because I’ve seen healthy companies get really bad during a move because of how disruptive it is.

There’s another Facebook group you might want to join but this one is not an official “LulzBot” group. It’s just a group run by LulzBot owners. You can find it here: https://www.facebook.com/groups/504350206441596/

But there are LulzBot employees in that un-official group and they’ve been really helpful to people who have questions. It’s certainly easier if it’s an “easy” question (doesn’t require hours of support) so they tend to be really good about those.

I’ve tried to be helpful in how you can self-diagnose the X-axis homing problem because that’s usually an easy-tweak you adjust on your own and doesn’t really require service to the machine (the trick is knowing that you can do it … and how).

Hopefully you are able to get your machine back in operation without too much more fuss.

Best Regards,

I’m rooting for them to succeed, as I think the printer, the build quality and platform are top notch. I live in Kansas, so I was surprised they moved from Colorado to North Dakota. Maybe tax or business environments are better in ND?

I did get an email response asking for more info today, so they are still kicking up there.

Oddly, enough, I have found a temporary solution. I noticed that if I try an auto home with a small, 1mm or less piece of plastic against the left wall, the printhead will happily home and proceed. I’m using the plastic micro SD card comes in and opening it up so half of it drapes against the “bump” wall. So far it’s worked. I tried the M914 command, but I was getting above 10 with no change, so I’m holding on that thought for awhile.

I have a plain old Mini which I purchased very cheaply because the bed would slam to the rear and the motor would keep going. The fix was easy as the red wire coming to the microswitch mounted on the underside of the bed had broken inside of the insulation due to flexing, I believe. I was, prior to retirement , an instrumentation designer so I contacted Lulzbot and asked them why they had mounted the microswitch to a moving part as this was something we would always avoid in the real world. Their quick response was that the wires rarely failed.
It is interesting for me to read that in the Mini 2 they have actually dispensed entirely with the microswitches which do have a definite and predictable lifespan, moving definitely to a more ‘state of the art’ solution.

I ran into the exact same problem, and Tim’s write-up was very helpful in figuring out how to fix the issue. However my solution was lowering the M914 x value, and this resulted in my bump sensor finally working. Anything greater than X2 results in my Mini 2 failing a homing sequence.

With the bump sensitivity, the lower the x value, the more sensitive the printer is to contacting the min and max distances.

So you are correct in that moving the X value to 2 will cause it to work over going to a higher value.