hey yall
ive been using octoprint for a bout a week and a half now with some trouble, mostly during startup bed leveling.
im trying to use the start code located at [Tip] Faster and more readable Mini 1 and TAZ 6 G-code in cura-um 5.5
i attempted to convert the code to UM cura, as it appears to use old settings & settings only in cura-le and cura-UM doesnt handle them right (probe temp, wipe temp, etc) theyre in <> carrots? some settings are in square brackets, lots of the internet suggests to use {} curly brackets, or square brackets. leading me to my question
which brackets go where and when in cura UM
which brackets go where in cura le?
CuraLE (4.13.4) and Ultimaker Cura (5.6.0) both use curly brackets { } to denote variables. The list of available variables differs with CuraLE having additional material variables for different temperatures.
The CuraLE start gcode is compatible with the firmware version it can install on the printer so it is best to use it as the basis for the start gcode you use in Ultimaker Cura.
The topic you referenced is almost 5 years old and is slic3r specific (i.e. uses square brackets [ ] around variables). Since slic3r is approximately as old as the topic, I suggest that you ignore both.
Ultimaker Cura does not have specific support for LulzBot printers so if you wish to use it as your slicer of choice, then start with the CuraLE settings and gcode replacing those variables that don’t exist with ones that do or constant values determined from selecting a compatible material in CuraLE. Use CuraLE to flash the firmware as well.
PrusaSlicer is based on slic3r, uses square brackets, and doesn’t have specific support for LulzBot printers so you will have to do similar configuration.
SuperSlicer is based on PrusaSlicer but I don’t think it has LulzBot specific support either.
1 Like
Note that OctoPrint has nothing to do with this discussion. My TAZ6 is connected to a Raspberry Pi 3B running OctoPi / OctoPrint and the printer specific settings should probably be a separate topic.
I guess i just explained octoprint for the sake of back story and understand that it is less relative.
You really think the startup gcode provided by cura le is the best? I usuly think someone in the community can do it better. I have been using the above code to get it done and it appears to work well on cura 5.5 after replacing the offending brackets and replacing some of the commands missing in um cura.
I was told the stock bed leveling sucks. In my experience it halts the printer quite often rather then printing, after going through the gcode posted above at the link it appears to be working fine. I manually set some values in the above code mostly: probe, wipe and retraction temps, updated first layer temp, and first layer bed temps for cura um.
Thanks for the answer!
The stock bed leveling issues have nothing to do with the gcode, it’s the nozzle-to-washer contact that is the issue, which stems back to it being a dirty nozzle issue.
ABS was “the” filament when the Taz6-era machines were developed. ABS wipes off pretty good and clean from the nozzle as it isn’t a particularly sticky filament, but PLA and PETG both love to hang on to the nozzle and delay the reading when the nozzle touches the washers, resulting in a bad reading of the bed position.
1 Like
i understand that, however i have personally seen it fail though the nozzle and washers are clean and conducting.
i was under the impression this was because of failure in my start gcode, like unfound variables, or incorrect brackets.
if there is another reason why it would fail at the first probe id love to hear about it.
have been thrown at these printers with nearly no education or documentation so im learning as i go mostly.
edit: we are printing ultra soft tpu, think its 75a, very squishy and stretchy but also print 95a
have considered using something more abrasive to wipe like scouring pad, but have been cautioned against premature nozzle wear
ill give the default start up another go for sure.
The start gcode supplied by a version of CuraLE is designed to work with the firmware supplied by that same version of CuraLE. I’m not claiming that it is the best but it is, IMO, the best starting point.
The bed leveling is a separate issue (because it all happens in the firmware when a G29 is encountered in the gcode). With proper cleaning it works most of the time and when it doesn’t, it’s usually a cleaning issue.
There may be better options for bed leveling but they require additional hardware and custom firmware.
1 Like
i suppose the start to my trouble is using UM cura instead of lulz. i was under the impression everyone had moved on from the LE edition, but this appears the be a mistake on my part.
i use UM for the other 4 printers around here and trying to manage two sets of cura projects and profiles is a little confusing and redundant.
it seems like the best option is to start using LE slicer for the taz6’s
There is nothing wrong with using Ultimaker Cura as your primary slicer but with a LulzBot printer, you will want to have CuraLE installed for firmware flashing and as a template for start gcode and material profiles.
Once you have Ultimaker Cura configured, it should provide good quality prints for quite a while before needing additional configuration.
I use CuraLE, Ultimaker Cura, Simplify3D, PrusaSlicer, and others as necessary to get the best print possible for any given object.
I’ve been using Cura LE for the Taz largely out of laziness 
But it would be really cool or Lulzbot submitted a profile for the Ultimaker Cura team
I’ve considered submitting Taz Pro and Taz 6 profiles to be included in PrusaSlicer, but the problem is that none of them I have are stock anymore, so they may be detrimental for others to use.
I believe the LulzBot team has attempted to get support added to Ultimaker Cura but the Ultimaker team hasn’t been very cooperative with merging the submitted code.
I’d be curious who they are working with. I know one of the devs there, so I wouldn’t mind being an liaison to get that done.
I believe the attempt is this Github pull request. Github says there are no conflicts with the main branch so, IMO, someone at Ultimaker is purposely holding off from committing the pull request.
I chimed in on that thread, if anything, for moral support