G0 vs G1 movement
-
If you put the Duet firmware into CNC mode by sending M453, G0 moves will be executed at full speed.
-
I actually have
M453 P20 R1 ; Set Pin 20 to run Spindle
in my config.g file. Nevertheless I experience the problems described. -
Which firmware version are you using?
-
2.02 RC3 with a little modification on M585 but that should not be relevant...
-
Perhaps I didn't understand what you meant by a "classical G0". In CNC mode, RRF executes G0 moves at maximum speed, and on SCARA machines (but not delta) the movement is not necessarily in a straight line. It still coordinates X, Y and Z motion because there is nothing to be gained by not coordinating them. I believe this complies with the NIST standard for CNC GCodes.
-
The problem comes only when bed compensation is activated. In the case of a straight Y-move the bed compensation causes that there is as well some little z-movement. Now if over the whole Y-move the according Z-move has to change direction (due to waviness of the bed) the Y-movement gets jerky. In my understanding this is caused by the coordination of Y- and Z-movement and the limitations of maximum instantaneous speed changes on Z.
Or in other words: If bed compensation is active a straight move in X / Y is not really a pure X / Y movement anymore as some Z-component comes into play and with it the dynamic limits of the Z-axis.
This is brilliant for G1 moves (typically machining moves) as you can build large CNC routers without a the need of having a very stiff and accurate frame. But at the same time it is an annoyance for G0 moves (rapid positioning moves).
-
Currently, when bed compensation is enabled, all moves are divided into segments of length approximately equal to the bed height map mesh spacing, so that the tool height can follow the height map.
I could change it so that G0 moves are not segmented in this way. The problem I see with doing that is that if you then execute a G0 move with the head at the same level as the print or the CNC workpiece, and there is a bump in the bed or (more likely) the gantry carrying the tool sags a little, then the head would dig into the print or workpiece as it passed over this bump, instead of rising over it. If the GCode commands include some Z-lift before the G0 move, then this won't matter; but except in the case of using firmware retraction, the firmware doesn't know whether you have done any Z-lift or not.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 In CNC the G0 moves are usually done at a configurable height that is called "clearance height", usually 3-5mm, with the CAM software usually raising the spindle as high as instructed and then moving to the next machining coordinate. Of course, G0 is almost always used to raise the spindle and, in specific situations, it may also be used to lower it until it gets pretty close to the material, using G1 for the last fraction of mm.
Doing G0 moves too close to the material surface is generally a CAM software (usage) mistake.
-
@dc42 Deactivating the segmentation for G0 would make perfectly sense for me. As @Catalin_RO outlined: G0 is typically used for fast positioning with a focus on the end position only vs G1 for precise coordinated movements e.g.
G0 Z5 ;retract to safety plane
G0 X600 Y2000 ; move as quick as possible to the new machining position
G0 Z1 ; go down again to 1mm above the workpiece
G1.... ; start with the actual machiningG0 should never be used for machining moves.
-
Unless other users express disagreement, I'll add it to the work list for the next release to change G0 not to segment moves solely for mesh bed compensation, when the machine mode is CNC or laser.
