Change print speed in gcode
-
Hi,
I know this question it's not of this forum, but... I post for you can help me...
I have to print a piece, the first 80% there is not problem but in last 20% are curved, vaults....
I can generate the gcode, and in the layer when start vaults, reduce print speed... Maybe later height?I think that Slic3r PE, can do this...
What line I have to insert in gcode for change print speed?
Thanks
-
@peirof If you want ot reduce the speed simply for the top 20% of layers then you can add the M220 command (or the speed slider on DWC) to a lower %:
https://duet3d.dozuki.com/Wiki/Gcode#Section_M220_Set_speed_factor_override_percentageI assume though that that is not exactly what you are trying to do. Am I right in thingking you want only bridges to be printed slower? In that case it really is a slicer's job as it knows what parts of the print refer to bridges and what do not. the firmware does not know if a line it is laying down in over a gap or over a previous line.
It is probably different in all firmware, but there should be a setting for bridge speed. Cura has just introduced these settings apparently (but I have not tried them):
https://community.ultimaker.com/topic/22195-introducing-the-experimental-bridging-settings/
-
The other day, I had this idea: what about using a specific move G-code for each type of extruding move? This way, all speeds/accel/... could be changed dynamically by the firmware, while extruding.
-
@fma said in Change print speed in gcode:
The other day, I had this idea: what about using a specific move G-code for each type of extruding move? This way, all speeds/accel/... could be changed dynamically by the firmware, while extruding.
I proposed this at https://reprap.org/forum/read.php?1,803621 but I didn't get much support.
-
@dc42 said in Change print speed in gcode:
@fma said in Change print speed in gcode:
The other day, I had this idea: what about using a specific move G-code for each type of extruding move? This way, all speeds/accel/... could be changed dynamically by the firmware, while extruding.
I proposed this at https://reprap.org/forum/read.php?1,803621 but I didn't get much support.
Its another chicken and egg problem. The slicers would need to label G1 moves with the move type before the firmware could implement that...
-
I think it should be first implemented by the firmware, as it is possible to generate test g-code files with scripts, or to modify real g-code files with post-processors, to have something working.
-