Cura 4 vs. Lulzbot edition

So way over on the Ultimaker site, Cura is up to version 4.4.1 while we’re sitting back on 3.6.21. Is the only real difference the ability to customize the z-axis offset? If there are other differences, any idea when the big version hop will happen?

CuraLE is a fork of Ultimaker Cura with quite a few LulzBot-specific changes. CuraLE is still 32 bit while Ultimaker Cura is now 64 bit.

I believe the CuraLE changes are significant enough that merging them with the Ultimaker sources is a non-trivial task. It’s a shame that the two development groups can’t settle their differences and merge the two projects.

Cura supports “plug-ins”. There are a few LulzBot-specific plug-ins in Cura 3 that don’t exist for Cura 4. More… from what I can tell, it looks like Ultimaker (the author of Cura now works for Ultimaker) how the plug-in system works so I don’t think you can just copy the plug-ins and expect them to work.

But the most notable difference I found when trying to use Cura 4 is that the start G-code has several variables in it for things like:

  • Material soften temperature
  • Material wipe temperature
  • Bed level probe temperature

And there are others.

The ‘wipe’ temperature (just to pick one example) varies by material … so would you could hard-code those temps into the start g-code, you’d need to edit the start g-code anytime you change filament type.

Part of the reason other slicers don’t support this is because I am not aware of any other printer that has wiper-pads for the nozzles – so they don’t need it. But wiping the nozzles is needed because of the automatic bed leveling system (which is based on electrical conductivity … and that requires a clean metal-to-metal contact). Other printers historically did not have automatic bed leveling (although they do now … just not based on electrical contact).

I ran into an issue (bug) with support blockers in Cura 3.6 and had to use Cura 4.4 to get around it … and that’s when I learned that none of the start g-code variables worked and I had to hard-code everything.

So you can use other slicers. But when you copy the start g-code from Cura LE to wherever you want to use it… just make sure you check all those variables (they are always in curly braces {}) and be prepared to hard-code them with the actual values if the slicers doesn’t support the variables.

I just installed Ulitimaker Cura to see what it’s all about. It looks like you can add the start and end g-code for the printer, but like you said you’d have to add those variables specific to lulzbot cura. Is it worth the extra hassle or maybe even making a plugin to make this even easier?

By the way what settings did you use for the Printhead Settings?

Printhead and gantry height are based on collision possibility when printing multiple parts on the build plate “one at a time” instead of all-at-once. It will depend on the printer.

If the nozzle is all the way down printing layer #1 … measure from the print bed to the X-axis gantry (bars that hold the X-axis carriage) … that’s the gantry height. The idea being that if you printed multiple parts and one was sufficiently tall, then when the Y-axis attempts to move forward or backward, the bars might collide with the part.

The print-head settings for X min/max & Y min/max are based on the distance from the extruder nozzle to anything on the print head that might collide with a part (the cooling fan, the duct surrounding the print-head, etc.).

BTW, it does not use this information to be clever enough to route around a collision… it only uses the information to tell you that parts can’t be printed because it would result in a collision. But you can use this information to increase spacing between parts or choose not to build as many parts at the same time or not use “one-at-a-time” mode.

I actually introduce the concept as “polishing” when introducing new users to the printer. It really helps prevent users from let it go into wiping with a giant ball of PLA stuck to the tip.

I do personally own Simplify3D, but Cura is what we support at the makerspace (free is good). It sounds like I have to just hope the non-trivial task of updating will eventually be undertaken!

It would be great if BOTH versions of Cura could introduce a more intuitive material profile system, because what they have now seems confusing and buggy. Took me 3 tries to create a new material profile and make it “stick” (on both LulzBot AND Ultimaker), and even then the 3 LulzBot print profiles (fine/medium/fast) had to be re-created separately, despite my having based the new material off of an existing material. And sometimes when changing materials and adjusting individual settings, I won’t get prompted to keep/discard but instead they appear to get applied from the previous material to the new, and/or I won’t get an option to update existing profile from current settings, etc etc. On Ultimaker, one of the new materials I created actually loaded itself into the Ultimaker on-board menu (yay), though Cura will still bug me that it’s “unknown/unsupported”, whereas another material profile I created the exact same way refuses to load itself onboard the Ultimaker. Anyway, there seems to be room for improvement in both versions.

The differences you point out like wipe temperature would have to be part of an effort to merge both versions of Cura, but I’m not aware of any CuraLE specific changes that would preclude doing a merge. I’d like to believe that a merged version would be beneficial to both parties and especially the entire Cura user base.

Couldn’t this be something done by the user community since both are open source? Basically compile the requested changes and sent to Cura developers.

One correction. At least on the Mac LEcura is 64 bit - it works with Catalina.