nallath

The issue here is that the material type is often misused. So f you create a new material that has the type "pla" it will try to find quality profiles that belong to "pla". In most cases it can, since either Ultimaker or contributors have added those profiles. If you change the material type to "pla+" (to name just one), it tries to find quality profiles that belong to pla+, but it can't find those. At that point it defaults to an empty quality profile, which triggers the "not supported" profile. So it's not that you can't print with this material, it's just that cura tells you that it simply doesn't have any fancy smancy profiles for you.

It automatically does that (or well, it should...) . I don't know why it doesn't for you, but maybe I can find something in your log files that indicate what is going wrong.

https://support.ultimaker.com/hc/en-us/articles/4402996140946-Ultimaker-Cura-crashes-when-opening-any-file

If you're slicing on a Mac, it's single threaded. Other operating systems have certain parts that are done on parallel.

It's a mac issue, although we have been able to find a solution for this. I expect to have this included in 4.13

No idea. Please provide the log files.

I don't think we ever supported OpenGl 1.

We don't automatically learn about issues with Cura. If you don't report issues, the chances are pretty high that they are not fixed.

Cura has the option to do requests built in, see https://github.com/Ultimaker/Uranium/blob/1eacb050882b7ad63dfd1e731ee35eafbd07c93d/UM/TaskManagement/HttpRequestManager.py There are quite a few of examples in the Cura source code where we use this to get responses from a server. As for how to set up an API in PHP, i don't have any experience with that, but there are tons of examples on the internet about that.

Yep.

I'm by no means a mechanical engineer (or a process engineer), so I'm not the best person to explain the nuances of this change. I was told that it has to do with the natural frequency. Certain types of vibrations / speeds / changes simply cause more issues. In those cases it's perhaps a bit counter intuitive, but it's better to then move faster (even though that would normally decrease the quality)

Could you also check if you only disable the UM3 Network Printing?

Tuning of the profiles! We've increased the jerk a bit so that it has less vibrations in the rest of the print. We are working on more improvements like this, so expect a lot better print quality for Ultimaker printers with the next few updates of Cura. I'm pretty excited about these changes, as it shows that combining the full process makes it possible to get the best end results.

There isn't really an option for that. You could try to play around with a raft.

https://github.com/Ultimaker/Cura/issues/10249

This link shows where the log files are located: https://github.com/ultimaker/cura#logging-issues

Marketplace -> Installed Ensure that the rotate tool is enabled.

They are JSON files, not python. The distinction being that json can only store data and python is an actual programing language. Although in this case the json can contain python snippets that are interpreted by the software again, so I see why you confused them 🙂 We also have a few wiki entries about this: https://github.com/Ultimaker/Cura/wiki/Profiles-&-Settings https://github.com/Ultimaker/Cura/wiki/Adding-new-machine-profiles-to-Cura https://github.com/Ultimaker/Cura/wiki/Definition-Files-Explained

It's not in 4.12. And again thanks for making the PR 🙂

Looks like a cooling issue. Can you check if the fans are working correctly?

It's a long story, so I won't bother people with it. We are looking into changes that we can make in the interface as it is now.

Well, not always. Anyone can contribute printer definition files. I think that 80% or more of the profiles that we have were not contributed by the manufacturers

Most of the profiles are not provided by manufacturers either. The only profiles that Ultimaker provides (and maintains) are the ones for Ultimaker printers. The rest are either contributed by people that have the printer and want to make it easier to get up and running for other people or directly by the manufacturers themselves. So the reason that we didn't add it is because we simply don't have the resources (or the desire to spend them on this) to test / check / maintain third party printer profiles. We would have to double (and probably even more!) the team size to do this and buy a new warehouse to just store all the printers so we could test it. So we rely on the amazing volunteers (and in some cases other companies) that have added / test the profiles that we have now for third party profiles.

Infill line multiplier can be disabled in a few cases: infill_sparse_density > 0 and infill_pattern != 'zigzag' and (gradual_infill_steps == 0 or not zig_zaggify_infill) So the infill percentage must be non zero, the pattern must not be zigzag and you must either not use gradual infill steps or not connect the infill lines

I have no idea what this means. Do you have examples?