nallath

A user doesn't need to create a profile if they want to try something, in that case they can just be left in the "user" category. "Just silently manage" isn't "just". How would Cura know what the intent of a user is in every single case? That's almost impossible to build, let alone maintain.

Any mechanical part will have tolerances so some things will vary from machine to machine. As far as I've seen (and i've printed with quite a few UM's) is that the variance is so small that adding a calibration is more likely to make it worse than better. I think most of these guides are written with DIY machines or chinese knockofs in mind. As in those cases the tolerances (and thus the spread) are much greater, such an calibration makes total sense. Although UM doesn't have perfect quality assurance (But then again, what company does have it?), ours is pretty darn good.

We're currently in a research sprint and someone from the Cura team is working on improving this.

There is a well defined priority override system; User settings (Not saved in a profile) > Quality changes (User saved stuff to profile. This is linked to a quality type) > Quality > Material > Variant (nozzle) > Definition changes (Changes made to machine through machine settings) > Definition (machine defaults) So by default, all your settings are stored in "User". This is also how Cura knows to display the round reset icon. If you press "discard current changes" all settings in the user slot are cleared out. If you use "create profile" all settings in the user slot are moved to quality changes and stored to file.

Except that won't work, because you'd be saving the *combination* of the extruders. So you won't just have a PLA, High_quality, 0.4AA profile, you'd have a PLA / PVA, High_quality, AA0.4/BB0.4 profile. All that being said; If you can provide some logs, we could have a look at what is going wrong.

Odd. I've printed a few items with the latest UM3 firmware and they come out just fine. Are you sure it's the firmware?

What is the value of the prime tower pruge volume setting?

This is because you need to provide it with valid JSON. "newname" <- valid string, newname <- not a valid string. "maintenance" is a state it goes into when you're changing material / print cores. The RGB of the leds can be changed, but people didn't like how it looked (It was seen as damaging to the brand), so we don't use them. Personally I like them, but i understand that there are other factors at play.

We don't put SD slots in our newest printers anymore because an USB thumb drive is just more convenient. Printing via USB stream is something we stopped doing as it just causes way to much issues (and it would take us weeks of dev time to support it and it would only benefit non UM printers).

Odd. I don't see anything weird in the logs (or anything that would explain any form of crash)

Did you add a generic HT-PLA? That's what it always tries to use as a fallback material.

Right, I see what you're missing. The UM2+ has so called material based qualities. So if you only add a new material type, you're not there yet, you also need the matching quality profile. As we also have "variants" (aka; nozzle sizes), you need to make multiple new quality profiles for each of the nozzle sizes it supports (a single material will need num_qualities * num_variants) of quality profiles to be added. Adding new materials / qualities like that should not be done by means of a plugin. You don't even need to, as you can just put the files in the resources folder, which ensures that they are loaded on cura startup.

Could you share some screenshots / logs?

I'm happy to say that we've added a "maintenance needed" icon to all printers that require it for the next release. If all goes well, it will also have an option to update firmware (or at least, notify you of the fact that there is a new firmware out there). As for the instructions, it's something thats (pretty high) on our backlog. I can't give you an exact date as to when we're going to implement it, but i don't expect that it will take a very long time.

The Arcus.pyd and Savitar.pyd aren't needed if you installed them with make install.

This is a screenshot of my setup.

But what are you trying to do? Importing a single quality changes will cause issues, as you always need one for the extruder and the global profile.

In most cases we have two settings; A check-box "Should this be done in the first place" and a value "How much of the thing should be done if we do it"

There are a few mistakes that I see on first glance; The "register" function in the __init__ must return a dict. The keys of the dict must match plugin types that Cura knows about. In this case, you return an unknown type ("p_reader"). You're also basing it on a meshreader, which is, as the name implies, a plugin that's made to read meshes. It would be better to base it on the profile_reader plugin type. An example of it can be found in the LegacyProfileReader plugin.

You can just send them a project file. That stores all changes that you made and in such a way that it's easy to compare them.

Or you could use the plugin that we use ourselves for debugging the settings. It might have a bit too much features for some of you. You can find it on https://github.com/sedwards2009/cura-god-mode-plugin As for listing all settings; It's already over 500 settings. A fair number of those settings are settable per extruder, so i don't see how it's possible to have them and readable and fit on 2 a4 sheets.

It could also be an idea to just print groups of people as a single object. That way you have a bit more wiggle room. Printing multiple small objects at once also improves the quality, as cooling is usually the biggest issue. With multiple tiny objects you provide the layers with enough time to cool before a new layer is cooled.

The charts are for the 5.1 release

I"m only looking at this from a Connect perspective; In that case it doesn't matter what you use as it already has access to all metadata about the jobs (what printer is it for, what does it need, etc). So the main reason for it to be here is if you have multiple printers and use SD / USB to move the file about. Having super advanced stuff like setting with what nozzle it's done seems a bit overkill (and how do you handle multiple nozzles?). Having a way to "override" the default prefix / suffix would have my preference, but using the type of the machine makes more sense to me than the name.

It's even better; We will also start adding charts (eg; donut charts to show configuration, bar charts for material type usage, etc)