i want to share my macro/gcode manipulation G0/G1/G2/G3 ( initial base for script/macro found somewhere in the net, cant remember exactly where it was, if the person reads this, pm me so that i can credit you! )
It modifies the GCODE to set different acceleration settings for travel moves similar to M204 T in Marlin
Thanks for sharing, and for the reminder to also modify g2 and g3 for these kinds Marcos.
Just for information G0 is just an alias for G1: gcode.register_command('G0', self.cmd_G1)
So you could just call G0 in G1 with same parameters. But ofc the copy is valid one less function call
But this could be optimization: I think there is no reason for rebuild all params. You could just call:
G1.1 {rawparams}
Ofc, it will perfectly work as it is, take this as possibly interesting information
Thanks for the input, i know about rawparams, but in this macro you can also modify other things for the G0 or G1 commands so its nice to have to be able to modify different otther parameters.
This was new to me, thanks: gcode.register_command('G0', self.cmd_G1)
I know what you mean, but with this way you aren’t be able to modify these parameters anymore.
I know this is 99,9% not used/necessary, but this macro should be a complete framework for G0/G1/G2/G3 modification. If someone wants a small/easy implementation, he can use your proposal.
Thanks again for your input
Did you notice significant CPU usage increase on the Raspberry? I’m wondering because this macro will get called very often per second if the slicer generates G-Code with “high resolution” and there are lots of curves in the object.
Would it also be possible to check for first layer in the script and if it detected it’s on the first layer it’ll set lower acceleration and square corner speed values?
sorry i dont know off the cuff how to request/read the actual layer via script. maybe s.o. knows the variable how to get the current layer information?
Thank you for your macro.
I have a concert about the high value of 100 for SQUARE_CORNER_VELOCITY. This might result in rounding corners too much and therefore hitting objects if the slicer plans a motion path close to objects.
To prevent MCU overhead, why not use the slicer to set the acceleration with M204 and overload that macro to update the SQV? The advantage for overhead is big.
SuperSlicer and other slicers can set acceleration dynamically for differentiation moves like infill, perimeter and travel.