Hi all, Wait, are you sure this is a bug?
I don't know how the motion controller works in EMC2 as far as its "in-position" system. I don't see any .ini parameters listed to set "in-position" tolerances. (Q: What *are* EMC2's in-position tolerance settings, and how are they adjusted if not in the .ini file?) But in the case of allowable following error, if the machine is moving with sufficient velocity, the allowable following error should ramp up from the low end MIN_FERROR= (Integrator manual shows as .010" default) to as high as FERROR= (Integrator manual shows as 1.0" default) (See Integrator Manual, Chapter 7.2.9, page 34) Could something like this be happening (normally) with the "in-position" tolerance values? If the machine has ramped up to max speed, and the next line does not slow things down (even if direction changes), then maybe "in-position" is reached as much as an inch "early" and the next motion (quite properly) begins? Someone who knows more about the inner workings of the motion controller (motion planner?) will have to answer this, I don't know. Just something to check. Experiments could be done to insert very small, very slow feeds in between the rapids, to see what effect that has on the motion planner's in-positions and early starts. (Without using any of the special "in-position" G codes, I mean.) Hope this helps. Thanks, Kim Eric H. Johnson wrote: > Hi all, > > It is my understanding that a rapid move (G0) should fully complete before a > subsequent motion command will start. In this case I am doing two successive > G0 moves, where in very rare occasions, the second G0 move will start to > move before the first entirely completes. > > For example: > G0 X20 Y15 > G0 Z0.1 > > In very rare instances, the second G0 move will start (based on the example > above) about 1" or so before the first G0 command has completed. But it > isn't as simple as that, it seems to depend on both a long G0 move followed > by a short G0 move followed by a number of short G1 moves (typically a > series of short G1 moves approximating an arc). At least that is the closest > thing to a pattern as I have been able to surmise based on the very few > instances in which it occurs. It is repeatable, however. > > I have found a couple of work arounds by adjusting the g-code generated > (HPGL -> G-Code), my real question is, should one be able to trust that one > G0 command will complete before a subsequent G0 command starts? > > Thanks, > Eric > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
