Treating G0 and G1 differently
-
Hello!
I wonder why G0 and G1 are not affected differently by the feedrate. AFAIK G0 and G1 both exists exactly to tell the firmware the type of move, so it knows when a move is just a travel and when it is for real (effectively using the tool).
That way, I would expect the feedrate to affect only the move, not the rapid move. Makes sense? If I'm printing at 70mm/s and the travel is 150mm/s (because that is the faster the printer can move without troubles), and I decide to up the print speed to 100mm/s using the feedrate (142% in this case), I would expect the travel to STAY THE SAME, not being increased to 213mm/s along with the print speed.
But, Marlin did not do that and the RRF also does not do that. From the Duet G-Codes documentation:
RepRapFirmware treats G0 and G1 as the same command, since it's just as efficient as not doing so. [3]
Efficient, maybe.... but does not seem right, and yet most firmwares do. Why is that, when it seems so easy to make this distinction?
-
Sure! Separate travel speed from printing speed might be very useful!
-
In CNC mode, G0 moves are always done at full speed in accordance with the NIST standard. In one of the beta firmware releases I did this in FDM mode too, but it broke some prints because some slicers assume that G0 and G1 use the same feed rate.
-
When there is a lack of standardized behavior, it’s important to take the more conservative route. Slicers are inconsistent in use of G0 and printer firmwares typically don’t do true CNC style “rapid travel” moves. There’s no guarantee that people have properly tuned their “max speed” parameters, and no guarantee that the slicer is putting the nozzle in a safe position to run all axes at their max speeds without consideration of kinematics (eg delta or scara bots). So the firmware risks causing collisions / machine damage if it interprets G0 as a CNC style rapid move. The default of G0=G1 is smart.
Now, should there be an alternate config’d gcode flavor mode to accommodate CNC milling style code? I don’t have much of an opinion on that, personally.
-
@rcarlyle said in Treating G0 and G1 differently:
Now, should there be an alternate config’d gcode flavor mode to accommodate CNC milling style code? I don’t have much of an opinion on that, personally.
There already is. CNC mode.
Therefore, I'm assuming you are proposing a NEW mode that is still "3D Print" mode, but also treats G0 as a rapid. That might be nice, but I'd like to see David's opinion on the amount of work involved.
-
@danal personally, I’m fine with different types of fabrication machinery using different flavors of gcode and expected behaviors. 3D printing is waaaay off from compliance with any kind of gcode standard. Bothers some people though. I do know a few people who want their printer gcode to comply with mill usage, but that’s an outlier.
-
I understand there is not standard and better not going full speed for rapid travel, etc.
But I still think that those two could be different in respect of feedrate only. Or, at least, have a config option to differentiate them. It's equally dangerous to up the speed from 70 to 100 (using feedrate) and having the travel speed going nuts because of that. Capping the travel moves to a certain speed would also help, but maybe this approach is simpler.
-
@token47 Slic3r allows one to set different speeds for various print moves as well as a different speed for non print moves. I assume that most other slicers would do that too. Also, the firmware allows one to set different accelerations for print and non print moves. So I think we currently have the tools to achieve what you are asking without having to use G0 ( unless I've misread something).
-
@deckingman None of them would fix the problem. The problem is very simple, I am printing with 70mm/s and travel of 150mm/s. When I dial up the feedrate from 100% do 200%, I expect the print speed to go from 70mm/s to 140mm/s, but the travel speed to stay the same. The printer will not handle 300mm/s of travel speed. None of those features help achieving this. The slicer only has to differentiate travel moves from print moves for this to work.
As @dc42 said, this could break expectations from some slicers. I feel that the benefit coluld be greater than the downsides, depending on what they really are on practice. That's why an option to turn this on would be nice to test this extensively, if that's not too much work.
-
@token47 if you set a maximum axis speed to 150mm/s using the M203 command in your config.g it will probably do what you want.
Any rapids trying to go faster will be capped at the 150mm/s, but slower print moves will still see the increased speed up to that limit. -
@nhof Exactly so.
-
@nhof said in Treating G0 and G1 differently:
@token47 if you set a maximum axis speed to 150mm/s using the M203 command in your config.g it will probably do what you want.
Any rapids trying to go faster will be capped at the 150mm/s, but slower print moves will still see the increased speed up to that limit.That is a good workaround..... Set the maximum axis speed as the travel speed. This will solve the feedrate issue as it will never go higher than the max
-
Well, that will help. Thank you!
