Cura
Cura copied to clipboard
Ultimaker
Adding Official Profiles for LulzBot Machines
We are wanting to add official machine profiles for the Lulzbot TAZ 6, Mini 2, Workhorse, Pro/ProXT, and SideKick 289/747.
@nallath I have fixed the basic profile errors defined in the error log. We have some definitions that are not common to all printers and I was wondering if the fix would be to edit fdmprinter?
Editing fdmprinter.def.json is never the solution. It affects all printers.
Editing fdmprinter.def.json is never the solution. It affects all printers.
Alright, I figured this was the case, is there a good alternative?
I think we might just need to remove the CI check that complains if you define a setting that isn't in fdmprinter.def.json
Removed duplicate definitions Adjusted hierarchy based on requested changes
I think we might just need to remove the CI check that complains if you define a setting that isn't in fdmprinter.def.json
That check is pretty important. If a profile changes the setting that is not in fdmprinter, and that profile is then used in a different printer that doesn't define the setting, it causes Cura to crash. So individual printers can't define new custom settings unless we either:
- implement something that ignores settings that don't exist, or
- implement a way for printers to ensure that custom profiles can't get used for other printers.
I think the ignoring is probably the best option. Let's discuss it before the standup.
As expected it looks like "resources/definitions/lulzbot_base.def.json" is not a part of the "fdmprinter.def.json" as per pytest build failure. @nallath did you ever by chance get to discuss CURA-8462 or are we still pending review for merging. I am happy to help test these merge changes against my Taz 6 printer once pushed into Cura for release. I assume your going to tag v 4.11.1 for release that will include these changes? I am just trying to get a path forward when I might be able to start using Cura over Cura-LE. I don't see any major benefits keeping Cura-LE and wish that project was finished and we would merge here but I am a standard user not Lulzbot!
Thank you.
I'm not the one that sets priorities. So we can only merge this once the tagged bug is fixed. Unfortunately, we also have other things that we want / need to fix, so we have to make choices in what we do (and also what we don't do)
This will not be a part of 4.11.1, as we generally use the revision releases for hotfixes, and this is not a hotfix.
Thank you for asking the question many of us are wondering @codemonkeyrawks , and thank you for your insights, @nallath. Not exactly what I was hoping to hear, but realistic nonetheless. I will be more than happy to leave CuraLE behind once this is merged!
@InnoProd thanks for the encouragement. It does look like Prusa Slicer (https://github.com/prusa3d/PrusaSlicer) will need to incorporate these changes as well (besides the point). I will just continue on with a custom FFF profile as Cura does accept these changes and will be testing. This is an alternative path (just like in Prusa) if you copy the startup/ending correct!
Thank you Cura team and Robert (from Lulzbot) whom submitted the changes for testing/use!
Perhaps it's more realistic to forego the extra settings for now and re-introduce them once CURA-8462 is implemented?
The start and end g-codes can have calculations in them like any other setting if they override the value property. You'd then simply need to write a Python expression that generates that g-code. Simple example:
"value": "'G0 X0 Y0 Z0.2\\nG1 F' + str(skirt_brim_speed*60) + ' Y100 E4.5'"
Yours would become a very complex and long expression of course, but it's possible to make it automatically adjust those temperatures even if there are arbitrary calculations involved in getting there, like the resolve functions you're calling, so you can make them depend on the printing temperature or something. The only real disadvantage is then that it's then much harder for the user to adjust the setting.
I have some other changes as well that I would like to merge in, for now we will probably hardcode the value. Is it possible to have a notification sent to me when CURA-8462 is implemented?
I have some other changes as well that I would like to merge in, for now we will probably hardcode the value. Is it possible to have a notification sent to me when CURA-8462 is implemented?
We've linked this PR in our JIRA setup, so when it's fixed, i expect the developer that does that to post an update here (that is our informal procedure anyway)
Has there been any progress on CURA-8462? As a Lulzbot user I would love to be able to use these profiles in Cura.
Not yet. It's marked as being planned for 5.0, but from among the 5.0 issues it has quite low priority.
If a profile changes the setting that is not in fdmprinter, and that profile is then used in a different printer that doesn't define the setting, it causes Cura to crash.
Does it? If I add the following line to the [values] section of a .inst.cfg file for my currently active printer, Cura does not crash:
this_setting = "Does not exist"
Instead, I get a fairly clear warning in my logs:
[MainThread] UM.Settings.InstanceContainer.setProperty [376]: Tried to set value of setting this_setting that has no instance in container (...)
Since 5.0 is now in beta, is there any hope of seeing this merged before the release? If not, then am I right that this will have to wait until 5.1?
What / where is CURA-8462?
That is a reference to your private issue tracker.
Since 5.0 is now in beta, is there any hope of seeing this merged before the release?
No. We need to add features for this to work and we don't add new features after a Beta. We only do bugfixes.
Looking for CURA-8462 -- Sounds like a Jira issue designation. Is the issue tracker for this FOSS project not public?
The issue tracker for this FOSS project is right here on github, and public. The internal project management queue for Ultimaker developers is not. That queue also includes information about not-yet-public products, so it cannot be public. I'm a third party contributor. My personal schedule is also not published on github. That does not make Cura any less FOSS.
We need to add features for this to work
I don't think you do. Like I said, adding unknown settings to a inst.cfg does not crash Cura. If it did, my Z Offset and Linear Advance plugins would cause crashes loading projects when those plugins get removed.
Hello all,
Wondering if there had been any updates on this, as I am looking to migrate to main Cura instead of using a very outdated fork. Is there anything blocking or needing testing that someone with a Lulzbot TAZ 5 can do?
Thanks!
Is there a way I can add the files to a directory in cura to load this profile? Would I have to build the project from source to test these profiles?
What happens if you try to add a custom printer in Cura 5, with Lulzbot Mini settings?
Can you sync your fork, with our main. We have added a printer-linter tool for our printer definitions and profiles. This should help us with processing our PR's. It performs some standard diagnostic checks and apply auto-formatting on the changed files in this PR, but you can also run it locally. See https://github.com/Ultimaker/Cura/tree/main/printer-linter
If it finds issues for which it knows a fix it should post a comment with that suggested fix such that you can easily commit that fix if you're okay with it. But please use commonsense with the suggestions because the tool is still in the early stages of development
Hey @rhendersonLulzbot, we have decided that the use of settings that don't exist in fdmprinter.def.json is fine here as long as it stays limited. We would like to merge this for the 5.4 release, could you make the fixes requested by the bot and hit the "Ready for Review" button when you are finished? Thanks!
