Bug Cura 4.11.0 mistakenly "remembering" deleted machine_disallowed_areas upon import of a model (as though accessing cached machine definition somewhere)

[Design8Studio 0]

I am on MacOS 10.14.6, and I'm using Cura 4.11.0.

 

I have an Ender 3 v2, which I modified using an Ender Extender 400 XL kit.

 

I created a custom machine definition json file for the modified version of this printer. It worked perfectly.

 

Originally I was using binder clips with plate glass for my print bed, so my initial machine definition file had machine_disallowed_areas values designated.

 

However, I recently upgraded the print bed to a PEI coated steel flex sheet, with magnetic base. Accordingly, I edited the machine definition file and removed the machine_disallowed_areas values in between the brackets, yet leaving the brackets, as illustrated in this CHEP video: 

 

 

Now whenever I restart Cura, the restricted "non printable" gray areas are gone, as expected. See first screen shot.

 

 

However, the moment I import a model for slicing, the old, deleted restricted "non printable" gray areas reappear, and Cura won't slice any model touching the restricted areas that should not even be shown. See second screen shot.

 

 

It's as though Cura suddenly switches to a "cached" version of the old machine definition json file stored somewhere (who knows).

 

Can anyone help me know how to get Cura to actually respect the revised definition json file properly?  Thanks for any tips!

 

Edited December 9, 2022 by Design8Studio
corrected typos

[Design8Studio 0]

OK, so on the chance that Cura was viewing the custom machine definition as inheriting values from the base Ender 3 definition, as though it was a parent and the custom was a child that derived attributes from it, I deleted the machine_disallowed_areas values from the base Ender 3 definition, and now the problem seems to have gone away. 

 

However, if I had another Ender machine that had binder clips and glass, I'd need (and expect) the base definition to be able to have machine_disallowed_areas values without them cascading down to the custom machine's attributes. 

 

So... I tried something else. I put the machine_disallowed_areas values back into the base Ender 3 definition, and I also added them into the custom definition, but changed all the values in the arrays to zeroes ("[0, 0]"). That also did not get a workable custom definition that had no non-printable areas.

Edited December 9, 2022 by Design8Studio

[MariMakes 199]

Hey @Design8Studio,

 

Your buildvolume can also be limited by settings like

• Build plate adhesion
• Travel avoid distance
• Z-hop
• Support horizontal expansion
• Infill wipe distance
• Prime blob

That might be why you only see the disallowed area show up when a model is loaded. 

You can read more about them here:

https://support.makerbot.com/s/article/1667337565436

I'm super curious 🤔, what are you trying to print that requires the complete volume of the printer? 

[Design8Studio 0]

@MariMakes

 

Thanks, however, as you can see from my documented post, the issue clearly is the machine_disallowed_areas values being improperly cascaded from an Ender 3 machine profile into my custom machine profile, as illustrated and proved by the fact the problem goes away when I remove the machine_disallowed_areas values from the Ender 3 profile as well.

 

Whenever anyone spends time and money customizing their printer for a larger build volume, they certainly are not being unreasonable to expect to be able to use the full volume they've worked and paid for. I've already had need of the full bed, and used it, for a sign. My full bed allows just over 16" x 16" in x and y.  I have a small maker shop with 8 printers, 2 laser cutters, 2 CNC router cutters and 1 CNC plasma cutter. 

[rburema 26]

First: We _really_ don't recommend the method CHEP is advocating here. Especially since we cache the definitions these days in an on disk database for faster loading. Further more, exchanging files between users may be compromised, since we expect the same definitions to be the same between the same versions of Cura. (... and we send some profile values along if a project is saved as a .3mf, so if you've opened an older file from before the edit via that method, I'm not sure what expected behaviour is then.)

 

Instead, if you (aren't developing a new profile/for Cura and) want to change those definitions for a specific machine, instead of editing the existing machine (def.json), copy it to `<appdata>/cura/<version>/definitions/` (you may need to make the definitions folder and don't confuse it with definition_changes) -- Within the copied (and suitably renamed) file, rename the printer-defintion itself (change the value of the "name" key).

 

So in essence, make a new machine. After all, this is the one of the purposes of this mechanism, to not open up files on printers that can't handle it (or have a different way of handling things).
 

Don't forget to not just disable adhesion (in the recommended settings), but _also_ set it to 'None' (in the custom settings view). Otherwise skirt will still be printed, and will be added to the disallowed areas (which is a more general thing than the machine ones of course) -- The complexity of this last bit (how adhesion interacts with disallowed areas) will fortunately be largely solved with the upcoming 5.3.