Cura LE 2.6.66 firmware flash vs OctoPrint

I’ve been delaying upgrading to Cura 2.6.66 due to the warning about needing to flash the firmware, and that once flashed, STLs sliced under previous versions will not work.

My problem is that I use my printer in a mixed environment: At home, I slice in Cura on my Mac Laptop, and send the gcode to my Lulzbot Mini (either directly, or via OctoPrint).

I also volunteer in an elementary school where we do various projects using my 3D printer. The laptops which the classroom has access to are ancient and won’t run even moderately demanding programs (we do our design work online in TinkerCad). Due to both the limitation of the available equipment and the logistics of managing a classroom full of kids, we’ve been using OctoPrint to control the Mini and do our slicing. It has worked out very well for us. The kids’ designs tend not to be extremely complex, so slicing is quick on the Pi. Plus they get a kick out of using the Pi for something like this.

OctoPrint’s slicer is based on Ultimaker Cura 15.04.x, both that and the older versions of Cura I use can deal with the same firmware in the LB Mini. I’m concerned that if I upgrade my home system to 2.6.66, I won’t be able to slice with OctoPrint at the school anymore.

I’m not looking forward to continually reflashing my firmware every time the printer moves back and forth.

Any thoughts on this? (and yes, I know… Ideally the OctoPrint folks would upgrade the version of the Cura engine they are using, but the main developer does not have time. I’m hoping someone does take on the task of making a new Cura plugin for OctoPrint.

Well it’s a late answer but for what it is worth I did not know you had to update your firmware to use 2.6. I just installed 2.6 and started using it.

Of course, not flashing the firmware is maybe why I don’t get the clean removing support structures now as I did with Cura 21?

EDIT-- Now you made me go and violate all my core beliefes and go read the intructions! I found this line…

“We recommend using the latest firmware included within Cura LulzBot Edition to maximize long-term compatibility.”

Recommend != required.


Apparently, earlier versions of 2.6.xx did not have this warning. I believe it just showed up with 2.6.66. Scroll down the Cura LulzBot Edition page to the "Download, Installation and Removal instructions, and see the note there:

Cura LulzBot Edition version 2.6.66 contains firmware standardized for use with all LulzBot Mini 3D Printers, and contains important bug fixes. However, once your firmware has been updated to, GCode files sliced with earlier versions of Cura LE will no longer be compatible and will have to be re-sliced using the latest version of Cura LE.

It’s not really an issue unless you have a need to go back and forth between versions (as you do if some of your slicing is done in the version of Cura included in OctoPrint).

Sometimes my attempts at humor fail mightily. In case there was any doubt, I was making fun of ME for not reading the instructions on 2.6 before I installed and started using it.

Just a note with the octoprint issue. We have the communication issue sorted (from all received reports) over Octoprint with the Marlin firmware. This firmware will be included in the Cura LulzBot Edition 2.6.68 build. We are currently running through testing to ensure nothing broke with the revs, but if you want to take a look it can be found here:

If you would like to run Cura LE with older FW (not recommended) after launching Cura LE go to Preferences > Configure Cura. Scroll to the bottom, and select “allow connection to wrong machines.” This will prevent requiring the FW update in order to connect.

Brent - I’m not sure what that means for me. Does having “the communication issue sorted (from all received reports) over Octoprint with the Marlin firmware” mean that if I upgrade to version 2.6.68 and install that firmware, I will be able to send Gcode generated by older versions of Cura to my printer? If that’s the case, I’ll just wait for 2.6.68 to upgrade.

I’m mainly concerned that if I upgrade and install the new firmware, I still need to be able to slice in OctoPrint some of the time and send the resulting Gcode to my LB Mini (which if upgraded would have the new firmware).

My apologies, I thought you were referring to a communication issue reported here:

As for the old Gcode no longer being compatible, it is due to a coordinate shift in Marlin. We had reported issues of endstop interference, causing probing and first layer issues. In order to prevent that endstop contact, we now home to a different position. This will shift the coordinate plane slightly, and can cause your nozzle to hit either the wiping pad or corner pads when using old gcode. In Cura LE, we have modified the start gcode to reflect this change.

If you would like to verify if your old gcode works, we highly recommend being present to watch the probing sequence and first layer being put down. If anything appears to be off, or interference is about to happen turn off the printer. Once you verify a specific gcode file, you can be confident it will work the same way in the future.

OK. So let me verify that I am following this correctly:

If I upgrade to Cura LE 2.6.66 and flash the firmware to the current version, I may have problems when I try to slice using the version of Cura that is bundled with OctoPrint and then print on my LB mini.

OctoPrint relies on slicing profiles (.ini files) imported from a desktop version of Cura which must be based on Ultimaker Cura 15.04.x or older. In my case I’ve been using Cura LE 21.08, which has been working fine in my application (and is based on Ultimaker Cura 15.02.01, if I read the release notes correctly.) These profiles will have the start code which came with Cura LE 21.08, so will not work with my Mini if it’s flashed to the new firmware, due to the coordinate shift you mentioned.

So is making older versions of Cura work with the new firmware, is it just a matter of changing the start Gcode? If so, is there a place in the newer Cura LE versions where I can copy that start code and paste it into my old Lulzbot Cura 21.08? That way, any Profiles I save (export) as .ini files from Cura LE 21.08 could be imported into OctoPrint’s Cura slicer engine and still work with the new firmware. Unfortunately, while I can find the start gcode in Cura LE 21.08, I can’t find it in Cura LE 2.6.66. If cut and paste won’t work, are there changes I can just manually make to the Start Gcode in Cura LE 21.08 (I’m guessing these will have to be made individually in every slicing profile I export, rather than a change it once and I’m done sort of thing?)

I’d appreciate any help anyone can give in what I need to do to make the older version of Cura LE work with the new firmware. If I can’t figure this out, it’s going to slow our workflow in the elementary school where I volunteer down to a crawl.


Correct, the main issue is getting the start Gcode right. There were a bunch of problems with leveling, caused by how the newer firmware (1.1.5.xx) handles endstops, homing, and the leveling matrix. The start gcode was changed to avoid any movements on one axis while an endstop was triggered on another axis. Related issues led to changing X_Min from 0 to -3 (also changes X_Max by -3), and changing Y_Min/Max positions by 1. In some cases, the probing sequence caused a shifting of coordinates, so an extra homing operation for XY was needed after the G29 probing.

You should be ok with new firmware… As long as you incorporate changes from the new start scripts found in the version of Cura released with that firmware. Comparing the old (Cura 21) and new (Cura 2.6.66) start scripts, you’ll see small changes to X and Y coordinates, deliberate small moves away from the endstops after homing, an additional homing of XY after G29, and a few other tiny changes.

That means the Octoprint Cura plugin profiles need to be updated if using that plugin for slicing, so it adds the correct start gcode. I don’t use that plugin, so not sure exactly how to do that… But I think the right approach would be to edit/test the new scripts as part of a profiles in Cura21, then export those profiles and import them to the Cura Plugin on Octoprint just as you suggested.

In Cura2, you can find the start/end gcode under Settings, Printer, Manage Printers, Machine Settings (after clicking Machine Settings, expand the window – it opens too small to see the gcode fields). Note that there are changes to the “placeholder variables” for temperatures and such, so when copying/pasting to Cura21 you will need to change those.

Only other issue I’m aware of… There are new communication features in 1.1.5.xx which are not supported by Cura21. Not sure if that is a problem or not, as I haven’t tested it. But that’s not a concern if your connection to the printer is via Octoprint.

Hope that helps…

Thanks, Scott. That’s very helpful.

I’ll probably take a look at that over the weekend. Hopefully the changes will be obvious to someone with limited programming experience (self-taught BASIC in the mid 1970s, one Pascal night class in the early 80s - it’s been a while).

Only other issue I’m aware of… There are new communication features in 1.1.5.xx which are not supported by Cura21. Not sure if that is a problem or not, as I haven’t tested it. But that’s not a concern if your connection to the printer is via Octoprint.

This might still be an issue, since OctoPrint uses an old version of Cura? Or maybe not, since the communications with the printer in OctoPrint are not handled through the Cura engine?

Nope - The cura plugin on Octoprint just slices the file, it isn’t responsible for communication. The sliced file is then sent to the printer by Octoprint itself, just as it would send a file sliced on computer and uploaded to Octoprint. I am aware of only one communications issue between 1.1.5.xx and Octoprint, related to dual-extruder temperature reporting, and that was fixed in

Where I think there may be a problem (I don’t know, and haven’t tested) is with direct USB control by Cura21 of a printer running the new firmware… I’ve seen some references to changes made in Cura 2.6 to support Marlin’s Advanced_OK support and fix various comm errors, which I interpreted as something needed but missing from Cura21 as well. That may not be the case. Hopefully someone who has tested it will jump in here and verify one way or the other.

Hopefully, since OctoPrint is controlling - and Cura is not in this instance - revisions of OctoPrint will keep up with the changes in Marlin. (AFAIK, no one is working on an updated Cura Engine plug-in for OctoPrint. It sounds as though that is a major task, and I’m guessing not all that many people are in my situation where they really need to be able to do at least basic slicing on a Raspberry Pi running OctoPrint.)


I have sent a BUNCH of prints (sliced on computer, combination of Cura2, Simplify3d, and Slic3r) via Octoprint and haven’t had any kind of communications issue between Octoprint and the Printer. Gina is really responsive, so if there ever is an issue I’m sure there will be a quick fix. The only issue I’ve heard of with 1.1.5.xx is what I mentioned with dual-extruder temperature reports over-running the Octoprint (python actually) buffer, and slowed the dual-extruder temperature reports slightly to prevent that.

The on-board slicer (Octoprint Cura plugin) is a nice feature, but I get the impression it is used by a minority – most users are slicing on a computer, then uploading to Octoprint. But there are definitely certain use cases (like yours, with the school) where the plugin and the control it gives over profiles makes a lot of sense. With the rapid changes to the Cura2 engine, I don’t think anyone has wanted to tackle trying to adapt it for an Octoprint plugin. Hopefully as it matures and the change rate declines, that will change.

I’m already in communication with Gina about this. You’re right, she is very responsive.