Open marciot opened 4 years ago
On further investigation, I found that "center_object" is checked from here:
I was able to log the value of mesh.settings.get<bool>("center_object")
and it was correctly being set to 0 when "center_object" was false.
Looking through the code more carefully, it seems like the only way to prevent Cura from adjusting the coordinates of the STL is by setting both "center_object" to "false" and "machine_center_is_zero" to "true".
It looks to me like the logic here is incorrect. Suppose we are dealing with a Cartesian printer. In that case, we would set "machine_center_is_zero" to "false". Now imagine we want to print a cube in the lower left corner of the bed (at the origin). But now Cura adds an offset of "machine_width/2" and "machine_height/2", which places the print at the center of the bed. This is not what the user requested at all.
I think the cause of the confusion here is that 'machine_center_is_zero' is a bit of a misnomer. It doesn't define the actual center of the machine, but merely where its' coordinate system has the origin. So it's the offset of 'half the machine width & height' that gets added, so the coordinate system of the machine aligns with the coordinate system of the STL.
Most Cartesian printers in our definition-files have 'machine_center_is_zero' set to false I think.
For reference, see this bit in fdmprinter.def.json
in the Cura frontend (currently starting on line 233):
"machine_center_is_zero":
{
"label": "Is Center Origin",
"description": "Whether the X/Y coordinates of the zero position of the printer is at the center of the printable area.",
...
I understand. But what Cura is effectively doing is forcing the coordinate system to have zero in the center for all printer types. This is a bit confusing to me, as on a Cartesian printer I don't expect to have the origin at the center of the bed.
I suppose this was a design choice in Cura, to place the origin at the center, but this isn't documented that well. I would have preferred to see two options, "machine_center_is_zero", which would tell Cura whether the firmware expected the zero point to be at the center of the bed and maybe "center_mesh_on_bed" which would tell Cura whether to center the mesh on the bed or not.
But what Cura is effectively doing is forcing the coordinate system to have zero in the center for all printer types. This is a bit confusing to me, as on a Cartesian printer ...
No it doesn't machine_center_is_zero = false
for most types of Cartesian printers.
"machine_center_is_zero", which would tell Cura whether the firmware expected the zero point to be at the center of the bed ...
That's what it does ... we just don't have a proper center_mesh_on_bed
.
Ideally the center_object
option would look at the bounds of the model in order to centre it in the build volume. The coordinates of the centre of the build volume then depends on machine_center_is_zero
. This is what the front-end does after all.
We didn't take the effort to do so though. This way of working is only a debugging method to us. It was much simpler to add half of the printer's size apparently. I don't see this feature getting any attention for the foreseeable future from us.
Application Version
CuraEngine, master
Platform
Linux, CuraEngine run from the command line (ENABLE_ARCUS off)
Qt
N/A
PyQt
N/A
Display Driver
N/A
Steps to Reproduce
Actual Results
In the resulting GCODE, the cube is in the center of the bed. This can be seen from the console output:
Expected results
Because "center_object" is false, I expect:
Additional Information
Changing "center_object" to "true" behaves exactly the same as when it is "false". This parameter seems to be ignored.
As a workaround, it is possible to set "mesh_position_x" to be equal to "-machine_width/2" and "mesh_position_y" to "-machine_depth/2", but this is a workaround for the fact that "center_object" seems to always be active.