nallath

Look, I can't help you if I only get information that it crashes. I need things like logs, reproduction steps and information about your computer specs.

By the looks of it, Cura is still loading it when you closed the screen.

The upgrading through the Olimex board, as far as I know, should happen automatically. I'll ask someone from the embedded team to give you an answer.

The files you downloaded are the packages that are installed on the ARM board on the machine. The mainboard is updated by the ollimex (the arm board).

Could you share the logs?

Most of the "weird" settings (surface energy, adhesion tendency) are used only with quality profiles. So these only matter if you duplicate a profile. FDMMaterials does have a XSD schema that validates if the .xml.fdm_material has at least the right format.

Also; What works for one model (setting wise) will probably not work for another. Since we (explicitly) don't send models with the slice data, we don't know what features the model has. We do look at the data (quite a bit actually) and use that to update / improve our default profiles.

I only got the story in second handed (I'm not in the firmware team anymore for quite some time now) but the G92 not working has to do with the bed leveling.

Ugh, logs don't show anything. Could you try disabling "send slice data" in the preferences? On some machines the SSL certifications cause crashes.

If no-one added the configuration for it, your best best it to add a custom machine and set the values such as size yourself (or create the config files yourself and share them with us by means of a pullrequest)

Could you also share the log files generated by Cura?

Yup Did you also change the GUID of your custom material? If you duplicated it from PLA it will still have the same GUID as generic PLA.

The profiles on the machine are only used for maintenance procedures. The settings used during the print are fully defined by the job you sent to the printer.

Currently, it shows the material of the job as a whole, so not what it actually used. As for aborting a print, those should show up in the history (That's also how it keeps track of the completion rate in the dashboard). If I remember correctly, the unit in for the material extruded is mm3

It keeps track if you dismissed the message or not. If you never dismissed it, it will keep mentioning it until you did.

Well, you don't *have* to provide all quality profiles. Cura is pretty adaptive in that regard. The fdm_materials are actually used by more pieces of software than just Cura, so the material profiles mostly just describe a bare bones version of the material. We might extend on that in the future, but right now quality profiles are the way to go.

Yup. But then it's probably going to give the same error, as nothing actually changed. You might need to check what went wrong and try to fix that first.

Well, all 3d party printers are contributed one way or another. We don't actually have the machines, so they don't get tested by Ultimaker in any way. If you want these things changed in the next release of Cura, please make a pull request.

Cura doesn't actually use the wallthickness, it's a convenience function for wall line count (eg; the engine only uses wall line count, not the thickness). So if you manually change the wall line count, it doesn't auto compute it from the wall thickness anymore, which is why it's greyed out (since it stopped having any effect what so ever)

Well, i've tried it on Fedora, where it does work. Could you try if putting the files from the attached zip in the config folder works? 3.6_fixed.zip

It's in your configuration folder in a zip. You can find it via help-> show configuration folder

Would you also be so kind to make a pull request for these profiles? That way it's way easier for others to also benefit.

You can also make material specific quality profiles. The UM3 and S5 have those. So it's already entirely possible to do this.

Normally it should do this automatically from one version to another. For some reason, this didn't happen on your system. You could try deleting the 3.6 folder and see if re-triggering it works.

It wasn't reported on github yet, but it was reported on the forum before (It's already in our sprint).