nallath

Please also share the model (preferably in a project file, that way we also have your setup available!)

I've also found an issue with the autosaving in 4.6 (which I guess has been there for a while, but I didn't check), that would cause it to save much much more frequent than it should. I've fixed that for 4.7. I hope that it will fix these issues.

Nope, not possible. It's also not very likely that we will build that any time soon.

If you want to translate/transform the data, you can just use the getWoldTransformation of a SceneNode.

Search through the forums a bit. This has been posted a few times before.

Perhaps. You could try turning that off and see if it still does that?

Are you logged in? Did you try disabling the um3network plugin? Do you have the octoprint plugin? Did you use camera streams?

What version of Cura is that?

Officially, Cura only supports Ultimaker printers. All other printers (and profiles) have been added as contributions from community members. We only test if these profiles don't crash Cura and a tiny bit of sanity checking, but that's it. We simply don't have the resources to create / maintain / test profiles for all printers.

Nope, sorry. We got a bunch of reports about this from other users, but we haven't looked into a fix for this yet. See https://github.com/Ultimaker/Cura/issues/7970 for some more discussion about this

That seems to be pretty standard coasting behavior to me.

The latest umo one on the repository that I linked should be fine.

Why are you using an ultimaker profile as the base for that? Just select a custom fff printer and modify that. Those grey areas are specific to the ultimaker you selected. There is no way to remove those in the interface.

I really don't see what your issue is. Could you elaborate a bit more on this? What are you trying to do? What did you expect would happen? What happend? Could you also share a project file? That would help with diagnosing what is going on here.

You can find all the firmware hexes that cura uses here: https://github.com/Ultimaker/cura-binary-data/tree/master/cura/resources/firmware There isn't an active attempt to brick any UMO's or anything. I guess it's just that moving from one system to another (we recently moved from home built / default cms system to zendesk) that older support articles simply didn't get as much priority. The UMO also hasn't had any firmware updates in a while now, so as a rule of thumb, updating it really isn't needed.

It's not using any QT environment variables for the fonts. Instead, it's using what is defined in the theme files. You can find them in the app image inside resources/themes/ The default one is cura-light and you chan change the fonts used in the theme.json file.

Is there a specific reason you're not just using the appimage? That is the version that we control / support.

Currently? Nope. I do think this will be something that we will add, but i wouldn't count on it any time soon.

Cool, did you also release the source code?

Did you force your layerview to compatibility mode? You can check this in preferences.

I've tried this on a nightly version of Cura and it does what you would expect it to do. See the attached image. Could you share your project file? I can have a look to see what is going wrong.

I've written a guide on how the setting system works: https://github.com/Ultimaker/Cura/wiki/Profiles-&-Settings

Correct. It's the combination of a quality & material profile that defines the settings.

The write UFP gode is called from a job, which means it's started from a non main thread. The @call_on_qt_thread ensures that it is later called on the main thread. The problem seems to be that when the snapshot is directly called from the main thread, it gives the weird results. That's also why i suggested the job work around. So to get this to work: Create a "WriteScreenshotJob" (subclass off Job), let the screenhot take happen in the run and ensure that the snapshot bit is run in a function with the call_on_qt_thread decorator.

Because most of the printers that Cura supports are marlin based (and marlin flat out refuses to accept higher temperatures). The change made here is indeed intentional. We recently did a security test and this was one of the remarks (eg; it could potentially be used to create files that cause very high temperatures, which can cause damage). Anyway, a machine definition file can change the maximum values, so the high-temp printer manufacterer can just set it to a higher value.