nallath

Could you in the future report bugs on github (https://github.com/Ultimaker/Cura/issues/new/choose)? Other than that, could you also share the logs?

Correct. It moves the nozzle a certain distance and then checks the change in capacity. At some point you will have a "knee point" where a given move doesn't result in an as great value change. We fit 2 lines on this and the intersection is the z distance. The z offset plugin wasn't written for Ultimaker printers in mind but for printers that don't have auto bed leveling (it was also not written by us, but that doesn't mean it might not be usable for Ultimaker printers of course)

This is somewhat intentional. The current way that the area is computed is fairly complex and in order to keep the complexity somewhat in check, we used the more naive solution.

Could you try to manually add the printer in Cura (eg; by IP instead of using the detected list)?

We're going to release a 4.4.1 where this issue should be fixed.

It should send them once you are connected. I'm not quite sure if it also allows you to select them on the UM3 though. The screen "realestate" is a bit more limited when compared to the s5 / s3

Cura should already attempt to do that though.

It could also be an issue with the sidebar plugin. I've just tried to load your project twice, and it works as expected.

I have no idea what could cause that. There shouldn't be a difference for this on the operating system.

Well, there is your problem. Ryzen has had a slew of bad driver updates. Depending on the behavior of the program, it breaks or slows down dramatically. Apart from re-writing the behavior of the entire program, there is little we can do about it, since it's Ryzen that is at fault here.

It isn't. Cura can't have this as an option, since how would Cura know if the printer ran out if it's printing on its own. Theoretically it could be possible for the machine to do this, but it will be very tricky to get right. A more general solution is the material station, which is the one we went for in favour of the others. This does leave you in a bit of a limbo state for the moment though.

It's sending some g-code to the printer, so I doubt that would void your warranty (I don't think that would even be legal in a lot of countries)

The cheap printers are not known for their customer service, but this is pushing it. You can definitely do this. A quick google query already showed me how: https://www.mpselectmini.com/howto/steps_per_unit_mm

If everything (including the z) is off by that, regardless of the material used, it's the firmware that is wrong. You can fix this by changing the steps per mm.

A welcome flow should be handled by adding a machine action, which can be triggered when a machine is added. An example of this can be found in the custom fff printer (custom.def.json). When that is added it always shows the machineSettingsAction (It does this by setting "first_start_actions": ["MachineSettingsAction"]) You could just have a machine action that in itself has a few steps.

Getting the label indeed gets the untranslated one. You can translate it by passing it though the localisation catalog (i18nCatalog) It would look a bit like this (it's untested code, so it might not work) from UM.i18n import i18nCatalog catalog = i18nCatalog("Cura") untranslated_label = Application.getInstance().getGlobalContainerStack().getProperty("layer_height", "label") translated_label = catalog.i18n(untranslated_label)

There is no setting that does that. You could try to make a plugin that does that though. The auto orientation plugin that I made does something like that; it has the option to calculate the orientation for every model that is loaded. If you're interested, you can have a look at the code on https://github.com/nallath/CuraOrientationPlugin

Well, as you might notice from the warning error, we really, really don't expect this case to happen. It's more as a cheek in tongue kind of remark that there is an error at all. What we do is we ask the opengl drivers if they support vertexArrayObjects. If it does, we create one. That's also the moment that this error occurs; The drivers say that it's supported, but it fails to actually provide us with a vertexArray. I've added a bit of code that at least should prevent the vertexArrayObject from being used if it wasn't created correctly, but that will only be in the 4.6 release. Since I don't actually have the issue, it might also not actually resolve it.

The alignment is pretty naive. It takes the biggest object and puts that in the center. From that point on it tries to find a spot (any spot) for the remaining models. It doesn't try to rotate them.

Could you create a bug report on github and provide your configuration folder? See https://github.com/Ultimaker/Cura/issues/new/choose

Well, it really helps to report all bugs on github. It's way easier for us to keep track of them there.

No worries, you didn't lose all your work. The not supported thing is added if your machine says it has quality profiles per variant / material, but it can't actually find one. So could you try switching material and / or nozzle? If that still doesn't work, could you share your configuration folder with me?

I don't think we will have this feature in the near future. It's a feature that I really want, but I'm not the one setting the priorities.

You can find it in the appdata folder (Windows key + r, type in %appdata%/cura) There is some more info about that on https://github.com/ultimaker/cura#logging-issues (the full logs are on the same location)

Okay, could you share the logs?