G0 uses last G1 feedrate!
-
Although G0 and G1 can be safely treated identically, as stated in the G-Code wiki, using the last G1 feedrate for G0 is not right. I have machined a piece of Al with feedrates from 600mm/min to 1700mm/min and during the slow machining (milling some holes), all G0's were painfully slow. The screw driven WorkBee is capable of 2500mm/min rapids, so 600mm/min was quite visible.
-
No quite sure I understand the issue here but maybe I missed something. When you do any move you stipulate a position to move to and a speed at which that move should be made ( feed rate). AFAIK if the G(n) command doesn't have a feed rate, then it'll use whatever feed rate it was set to for the previous move. So I'd say it's an issue with the gcode file and not the firmware.
-
G0 feedrate is for rapids, G1 feedrate is for machining. While for 3D printing the "machining" feedrate is pretty high, thus mostly impossible to distinguish from rapid feedrate, when milling the difference might be quite significant.
The files that I have used for milling have no Fnnn in any of the G0 codes and I see very slow "rapids". The only alternative is to replace all "G0 " sequences with "G0 F2500 " in my case.
This is the first controller that I have used and requires such an approach as far as I'm concerned!
-
Sorry I'm still confused. You rightly said in your OP that G0 and G1 are treated the same by the firmware. So, I'm confused as to why you say that G0 are for rapids and G1 are for machining. For 3d printing, we generally use G1 F(nnn) so for print moves, the "nnn" value is low (say 60mm/sec), and for non-print moves it can be higher (say 300mm/sec). It's the slicer that generates the moves along with the speeds. Therefore the firmware simply uses the feedrate specified by the gcode file.
-
When machining both G0 and G1 are extensively used. G0 is normally used "when not cutting" (as specified by NIST). The firmware currently uses G1 specified feedrate also when executing G0. This is unlike any other firmware I have ever used. Also, most CAM software has support for specifying G1 feedrates but the ones I'm have no support for specifying G0 feedrates. Normally G0 feedrate is machine specific, if not specified otherwise.
Though something may be wrong only while executing a file, because when homing, G1 is slow and G0 is fast, and there is no feedrate specified in any G0's in there!
Anyway, it feels overall wrong when compared to alternatives.
-
RepRapFirmware was written originally for 3D printing applications, so we are still learning about how CNC controllers are expected to behave. Are you saying that the F parameter should only apply to G1 moves, and G0 moves should always execute at the machine limits set in M203?
-
Almost! G1 should work as it works right now. G0 should use M203 limits unless Fnnnn is specified with the code.
Right now I have tweaked CamBam to always issues the feedrate for G1 and modified the issues code to "G0 F2500" for rapids. But this is OK only as long as I don't want/need to modify the M203 limits. It is pretty easy to forget about the post processor required changes in such a case! (I will provide the post processor when this issue is sorted out!)
-
RepRapFirmware was written originally for 3D printing applications, so we are still learning about how CNC controllers are expected to behave. Are you saying that the F parameter should only apply to G1 moves, and G0 moves should always execute at the machine limits set in M203?
Yes typically G0 commands run at the CNC machine max feed rates. There is usually a switch that lets you choose to run at 100% (max) 50%, 25%, and the linear feed rate which is then controlled by the feed overide switch to drop the feed rate even slower.
I can see the issue when using the Duet for a CNC mill because almost all cam systems use G0 (rapid moves) when not actually machining to shorten run times. For example when drilling holes, you jump from say one hole to another you want the move as fast as possible.
Slicer software uses G1's set to yourt "travel" feed rate so the moves between printed parts is fast.
You just have to manually change the G0's to G1's.
