Firmware flash bricked my Mini?

Hi guys-

Have a Lulzbot mini - don’t remember when exactly I got it, but it had been running Cura 21.02. Wanted to do a print that had varying infill in a model, and based on what I could see from the internet, that was a Cura 3.x feature not something I could do in my older version. Here is what I did today.

  1. Did a test print in 21.02 to make sure that everything worked.
  2. Downloaded 3.2.32 and connected it. Did a test print to make sure that it worked.
  3. During the test print it nagged me about updating the firmware - so I did, storing my e-steps and z-axis offset.
  4. After updating firmware, I ran the M commands to update z-axis. E-steps were same so I did not update that.
  5. Tried to do another test print - this failed miserably. The arm at the top (with the hot end) moves all the way left, but when it hits the edge of the printer it tries to keep going, leading to a really loud annoying knocking sound (likely as gears are trying to force their way). The first couple times I heard this I aborted and turned the printer off, but I did let it go for a little longer once to see if it improved. After the gears grinded for a while, things stopped. I aborted.
  6. Did a quick forum search and read about other problems with 3.x.x, so I installed 21.02 again, verifying that it was connected to a lulzbot mini, and did the firmware upgrade from the menu in that program. I assumed this would downgrade the printer back to where it was before.
  7. Printing in 21.02 now does the same thing. I can turn the printer on, open up the control, and move the X left and right, and also adjust the Y direction, so I still have ability to send commands, just something is broken. Maybe a startup script, I’m not sure.

Any suggestions? Would be nice to upgrade to 3.x.x but if the best I can do is downgrade it back to 21.x then I’m totally cool with that, as this setting was for a single project, not anything I can’t live without :slight_smile:.

You will probably need to reflash the firmware using Cura 21. The firmware is different for “Old” Cura and “New” Cura. They say that the esteps, etc did not need to be reentered for the “new” Cura, but you will need to reenter them after reflashing with the “old” Cura.

Thank you. I did reflash the firmware using Cura 21 in step 6. I just did it now (a third time) to validate.

Got the following when I issued the two M commands;

< echo:V23 stored settings retrieved (396 bytes)
< echo:Steps per unit:
< echo: M92 X100.50 Y100.50 Z1600.00 E833.00

< echo:Z Offset : -1.43

Both the E-stops and Z-Offset match the settings from before I did the first flashing to Cura 3.x.x.

After reflashing from within Cura 21 and getting a success message, I did a test print and got the gear grinding again - same as yesterday.

Is there a M-command that I can issue that can validate the firmware version that is running on my printer? That way I could see if the flashing back to the 21.x version is actually executing, because it is behaving as if it is not.

Try M115

Thank you. I ran that and got the following:

FIRMWARE_NAME:Marlin (Aleph Objects Inc.'s Phabricator) SOURCE_CODE_URL: PROTOCOL_VERSION:1.0 MACHINE_TYPE:LulzBot Mini EXTRUDER_COUNT:1 UUID:351487b6-ca9a-4c1a-8765-d668b1da6585

Did a quick google on firmware revisions for Lulzbot Mini, found this page which, under v21.02 (which I’m now running) says that the firmware revision is So - it looks like my downgrading of the firmware actually worked.

Is there some setting where the system could have lost track of how far left to move the printer head upon print start? The only two settings that the manual says to track before flashing firmware are the e-stops and the z-offset, both of which are correct.

Addendum - another forum post recommended 21.08 for a different problem. I uninstalled 21.02, installed 21.08 and did the firmware flash from there. That firmware appears to be installed:

< FIRMWARE_NAME:Marlin (Aleph Objects Inc.'s Phabricator) SOURCE_CODE_URL: PROTOCOL_VERSION:1.0 MACHINE_TYPE:LulzBot Mini EXTRUDER_COUNT:1 UUID:351487b6-ca9a-4c1a-8765-d668b1da6585
Print started at 08:37:41

So it’s Marlin instead of the that I had with 21.02 which is what I expected. Same problem though upon starting a print. Does not matter what material I have loaded - it’s well before anything starts to heat up, right at the start of the print process. I can issue commands manually to move the arm to the right, and then on start it will go all the way left and try to keep going left past the end of the bar that it’s on.

This is going to indicate an issue with your endstop. First, move your print head to the far right of the X axis. On the far left hand of the machine, there will be a trigger that senses when the tool head makes contact:

Tell your printer to home the X axis, and manually push this button with your finger. If it stops the tool head, it will indicate your printer head is missing that switch and will need re-alignment. If it does not stop your tool head, it will indicate an issue with the Endstop wiring harness, or end stop switch port on your board.

Feel free to reach out to for assistance if you run into any problems or have any questions.

Thank you Brent. Is it better to post here in the forum or email the support@ alias for help?

Here is what I did:

  1. Move the print head to the far right. I found the end stop switch. I pressed home and then pressed the switch and the head stopped (indicating the switch was working). I did this several times.

  2. Move the print head to the far right. Pressed home. Did not intervene manually. The head moved left, and then when it depressed the switch, it “bounced.” Meaning it reversed direction to the right for an instant, then moved left and came to a stop right next to the switch. So this makes me think that the sensor here worked as it should.

  3. Moved the print head to the far right. Started a print. The head moved left, and it did the grind thing where it kept going past it. It is almost as if it is not sensitive to this switch when it is starting a print, but it did work properly when testing via the home button.

Do you have any additional suggestions as to what to try?

Thank you again…

It has been awhile since I was in support, so they might have a trick or two I don’t know of. I’ll take one more shot and if it doesn’t work I would reach out to them.

As the limit switch is triggering by hand, it indicates firmware is not the issue. Instead your tool head is hitting the plastic mount on the lead screw before making contact with the switch. Chances are this has come slightly loose, which would also explain why it is inconsistent.

Try loosening the two screws holding it in place, shifting the switch to the right, and re-tightening. Also inspect where that makes contact with your tool head carriage, and ensure no damage is done there. (Maybe a piece chipped off and allowing more space?)

If this one doesn’t get it sorted, it is time to call in the pros =)

Ok so good news as long as I can be patient.

I think you showed me how to fix it, even though the problem isn’t where I thought it was. The “bad” news is I don’t have a hex key the correct size to do the fix. Looks like I need a 1.27mm (or 0.05in) hex key. None of the stores around here have it in stock so Amazon will have one here on Monday.

More details - the arm that moves the hot end is totally fine. My ears were playing tricks on me. The arm hits the limit switch and everything is good.

What actually is happening - as soon as the Y axis home completes, the X axis home starts. Since the platform was already in the home position it didn’t have to move any, and THAT is the one that is causing problems. The “gear grinding” sound is the sound of the rubber belt around the bottom skipping over the gear on one end when the X axis cannot keep moving. I have done the same test of the limit switch there - moving the platform away from home position, pressing home, then manually triggering the limit switch, and that works fine.

However when trying to home the Y axis - the switch doesn’t trigger. In fact, if I turn motors off and just manually move the platform to the home position, it takes a decent amount of force for me to get the switch to trigger. I have to put my hand on the back of the platform, put my other hand on the front of the case below the platform, and give it a decent pull. So it feels like something is out of adjustment there - it should depress that switch much more easily.

My thinking was to adjust the limit switch so it “sticks out” a little bit more. Clearly it is aligned properly to hit the platform when enough force is applied, so it is correct in the X and Z positions. Sticking it out a bit more in the Y direction would enable it hopefully to hit what it needs to hit more easily. Would you agree with that thinking?

So thank you for all your help - even though it wasn’t the limit switch we first thought it was, you taught me enough about limit switches in concept that I could figure out the real problem. I really appreciate it.

Sounds right to me, but a little digging found this forum post on the Mini Y axis:

If the repositioning doesn’t get you sorted, you may want to reach out to support to see if it might be the same thing.

Not a problem, we are happy to lend a hand! These machines are a lot of fun, and once you get familiar of how they are supposed to operate it makes it much easier to track down what is wrong.