[F.R.] Auto Define M557 Mesh Bounds from GCODE
-
Hi guys, I think this would be a very useful feature:
Rather than arbitrarily probing the entire bed, it makes more sense to probe only the area used during the first layer of the print. You could increase the mesh density and still save time with this approach.
If the M557 code itself could have a parameter added to trigger automatic mesh bound generation. This would make the process seamless across any slicer (perhaps with different layer labeling).
Essentially, it would have to read through the current gcode file between:
;LAYER:0and
;LAYER:1to parse minimum and maximum values for X and Y, then use these values (maybe with a "padding" value to expand this rectangle) to define the mesh bounds.
-
To be completely honest, this seems like something that should be added slicer side -
I definitely reassign the mesh parameters on a per-print basis, and could easily be added to a post-processing script in common slicers (hasn't been done, you're right) but seems far better in the slicer environment.
-
Actually, something along these lines was discussed a while back when RRF3 and the DuetSoftwareFramework were being planned. The idea was that the DSF could call filters to calculate stuff like this. The original premise was calculating the bounds of a print so a large bed with multiple heat zones would only need to have the zones turned on that were needed for a specific print.
We're not quite there yet.
-
@Luke-sLaboratory said in [F.R.] Auto Define M557 Mesh Bounds from GCODE:
To be completely honest, this seems like something that should be added slicer side -
I definitely reassign the mesh parameters on a per-print basis, and could easily be added to a post-processing script in common slicers (hasn't been done, you're right) but seems far better in the slicer environment.
Where it should be done is subjective. It certainly could be done either way.
To me it makes more sense to be written once in the firmware, rather than written over and over, for each individual slicer.
But, in my opinion, pressure advance should be written in the slicer instead.
@gtj0 said in [F.R.] Auto Define M557 Mesh Bounds from GCODE:
Actually, something along these lines was discussed a while back when RRF3 and the DuetSoftwareFramework were being planned. The idea was that the DSF could call filters to calculate stuff like this. The original premise was calculating the bounds of a print so a large bed with multiple heat zones would only need to have the zones turned on that were needed for a specific print.
We're not quite there yet.
Glad to hear it is something that has been discussed before.
I'm a much better mechanical designer than I am a software dev. One of my interns wrote a program for me in C++ to parse gcode (from 4/5 axis millturn CNC machines that I program) and spit out min and max values for each axis. I could donate that source code if it would be a helpful framework and there is interest from the Duet devs to add this feature. @dc42, any interest?
-
If anyone is interested, my friend and I developed a Cura post processing script.
You pass it a single parameter (mesh spacing), and it parses the first layer gcode for min/max X and Y coordinates, and then replaces the M557 line in your start gcode.
Just remove the .txt, and drop it here: C:\Program Files\Ultimaker Cura 4.5.0\plugins\PostProcessingPlugin\scripts\
You must have a static mesh leveling command in your start gcode, like: M557 X0:200 Y0:200 S20
-
Referenced by
supernovae
