Application version
cura 4.2/4/.3
Platform
win10
Printer
BIBO2
Reproduction steps
looking at json format
Actual results
some json files use value
"prime_tower_position_x": {
"value": "195"
},
"prime_tower_position_y": {
"value": "149"
}
https://github.com/Ultimaker/Cura/blob/master/resources/definitions/ultimaker_original_dual.def.json
Other json files use default_value
"prime_tower_position_x": {
"default_value": 50
},
"prime_tower_position_y": {
"default_value": 50
}
https://github.com/Ultimaker/Cura/blob/master/resources/definitions/bibo2_dual.def.json
Expected results
which is the correct format? value or default_value
I've seen some things like gantry_height don't work correctly with default_value is that the same case with prime_tower_position_?
Additional information
BIBO users are reporting print head is crashing with dual extrusion if the prime tower is not checked in Cura. one user on FB reported prime tower position is at 218 x 198 y which is outside of the build plate area. I have also experienced this print head crashing on the switch from E1 to E2 extrusion. I suspect it's something with the Cura or BIBO provided json definitions.
default_value must be an actual value (eg 12, True). value can also have a python expression in it that can use other values to calculate it's own value (eg; layer_height * 12), but it can also be a direct value.
The reason for this is that these files need to be able to be parsed by the engine. Since the engine doesn't know / understands python, it needs to have a fallback value (so, default_value). That's why a default_value must be set (and the value is optional). If both are set, the backend will use the default_value and the frontend will use value
If both are set, the backend will use the
default_valueand the frontend will usevalue
Worth mentioning that the front-end will then send the value to the back-end and the back-end will use that, rather than default_value. value overrides default_value except when running via command line slicing because then the value can't be read (without any Python interpreter present).
@nallath @Ghostkeeper
So If I understand what you are saying. Either value should work for creating a prime_tower_position_ in the json printer definition.
that doesn't explain why we are getting print head crashes during dual extrusion printing due to the prime_tower_position_ not being at 50X 50Y but at 218X 198Y
We had a similar issue with gantry_frame_height although a default_value was set to 12 in the perter management in cura I and others would see 160. Changing to value as I saw in other examples and in the correction to the BIBO profile on github fixed that issue. As the prime_tower_position_ values on github came in both versions I wonder if this was the source of our prime tower issue in the profile.
No, the prime_tower_position_* settings define a value which will override the default_value. The value in this case sets it to align the prime tower in the far right corner by default. You need to override the value instead.
@Ghostkeeper Ok, If I'm following this correctly. the JSON printer profile definition for prime_tower_position_* needs to be value and not default_value as it's value that needs to be overridden
So I should submit a PR to fix that in the BIBO profile (and fix my BIBIO provided profiles too) https://github.com/Ultimaker/Cura/blob/master/resources/definitions/bibo2_dual.def.json
Is that correct?
Ah, yeah. It looks like those default_value overrides in the BIBO profile won't have any effect. Would you provide a PR? That'd be fantastic!
@Ghostkeeper Thank you. This is the explanation and direction I needed. I'll get a PR for BIBO made up.
Note: there are a lot of other profiles with the same error including some of the Ultimakers.
@Ghostkeeper The cases like this where default_value wouldn't have any effect might be another good one to have a warning of sorts for and something to put in your CI tests.
Yes, I actually did that two weeks ago: https://github.com/Ultimaker/Cura/commit/9316df72b3745d9ce55a5e70f9cc1320c0689c36. I found some 900 setting overrides then that had no effect.
@Ghostkeeper wow, that was a lot of overrides which were doing nothing. Looking through that list it seems some printer definitions were over defined with superfluous settings; much cleaner now that the cruft which was doing nothing is gone. Amazing work.