Hi Robert, If you try to do blending between feed and rapid moves, I think it needs to be an option and that it's important that the option be turned off by default.
FYI, my reasoning: Today, LCNC is a G code driven CNC implementation. C code is inherently a modal language and G0 & G1 are different movement movement modes. I've personally never seen a machine that allows a transition between modes (G0 and G1) while the machine is moving (though I suppose such an animal may exist somewhere). I believe this is rare because the modes are enforced by gcode's word/block structure and that structure disallows G1 and G0 within the same block. To refresh my memory, I grabbed my copy of Smid (2nd edition) and found this (page 50): "The purpose of preparatory commands is to select from two or more modes of operation. If the rapid motion command G00 is selected, it is a specific command relating to a tool motion. As it is impossible to have a rapid motion and a cutting motion /active at the same time, /it is impossible to have a G00 and G01 active simultaneously. Such a combination creates a /conflict /in a block. IF conflicting G codes are used in the same block, the /latter /G code will be used. N74 G01 G00 X3.5 Y6.125 F20.0 In the example, the two commands G01 and G00 are in conflict. As G00 is the latter one in the block, it will become effective. The feedrate is ignored in this block. N74 G00 G01 X3.5 Y6.125 F20.0 This is the exact opposite of the previous example. Here, the G00 is in the front, therefore the G01 will take precedence and the motion will take place as a cutting motion at the specified feedrate of 20.0 in/min." Smid's text says this is the case for Fanuc controlled machines. This implies to me that trajectory planning and blending are something that happens between moves while within the G01 mode, but not something that can happen between moves that are in different modes (G01 vs G00). I also don't see blending as relevant within the G00 mode of operation. This makes sense when we consider that there are a couple of other things that make the motion modes different (due to the mature of the machine motor hardware). G1 is commonly thought of as "feed move" and rapid as "as fast as possible". There are also other differences in that G1 is "follow the specified path from A to B at the given feed rate" (I.e. this is a trajectory controlled movement in that both path and feed are coordinated). In contrast, a rapid G0 move is "go from A to B by spinning up the motors as fast as they will go and end up at B". The _only _thing guaranteed for a rapid move is that the machine will end up at B. An important difference is that this does not say that the straight line from A to B will be followed. At least some (maybe most?) machine manuals (a Haas mini-mill and VF-1 are examples I know of) explicitly point out that the rapid path from A to B is NOT guaranteed... the path could be a non-circular curved arc (depends on motor speeds and acceleration settings etc), or a spiral that swirls in to point B etc. On heavy industrial machines this effect may not be obvious to the naked eye (for example X and Y axes will probably be close in speed and accel, so an XY G0 move will probably be close to a straight line), but on other machines (for example a little shapeoko that I use for bench top software testing) this is really apparent. On the Shapeoko, X,Y and Z are significantly different wrt to max speed and accel (X and Y are belt driven & Z is a screw). Issue a rapid command and the shapeoko will go as fast as it can for a rapid move - but not in a straight line. In fact, a 3D plot of the total "rapid path transversed" would have to include the shaking motion during the time needed for the entire machine frame to stop vibrating after it arrives at B. :-D I was taught that to think of G0 (rapid) moves as "as fast as possible" but "not planned or controlled wrt trajectory or speed". With that in mind, the benefit of a trajectory planner attempting to blend "trajectory controlled G1" and "non-trajectory controlled G0" moves is a bit of a mystery to me. So far, I only see this as of some possible use if I postulate a machine controlled by a language other than G code. (and we don't yet have a replaceable control language module in LCNC). Thus, my opinion is: G01<->G00 blending has to be an option (if you include it at all) and it has to default to Off (i.e. NO G1/G0 blending). Dave On 2/13/2014 6:43 AM, Robert Ellenberg wrote: > I can add an INI setting fairly easily, and default to not allowing blends > between rapids and feed moves. > ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
