Rainer Schmidt wrote: > As I understand the parsing > G1z1x1y1 > is the same as > g1z1 > x1y1 > or > g1z1x1 > y1 > or > g1 > z1 > x1 > y1 > > I am sure that a end of line or cr/lf or any combination is not part > of the parser rules regarding a command structure. I have generated > gcode which has no line breaks in 4MB of gcode. But that runs under > mach3... > That is certainly not the case with EMC; and RS274NGC specifies a thing called a block that corresponds to a line in EMC. The maximum length of a block is 256 characters (or maybe 255).
My understanding is that: g1 z1 x1 y1 is NOT the same as g1x1y1. g1 does coordinated motion. That means it moves in a straight line from its current position to its target position. The line with just the x1 on it is equivalent to g1x1 because the interpreter "remembers" the previous g1 command. ----- Ken ----- > g1z1 > g1x1 > g1y1 > > are the same as > > g1z1g1x1g1y1 > > I'll verify that a bit later when I am in the shop. > Rainer > > > On Fri, Jun 12, 2009 at 10:12 PM, Jon Elson<el...@pico-systems.com> wrote: > >> K.J. Kirwan wrote: >> >>> 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?) >>> >>> >>> >> It is not in the .ini file because there is no "in position" tolerance. >> There is a following error tolerance, but that causes a program abort. >> EMC does not wait for an axis to be "in position" before continuing. >> >>> 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) >>> >>> >> It DOES have asliding scale for following error. >> >>> 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? >>> >>> >> EMC2 computes how far before the end of a move it needs to decelerate >> based on >> velocity and the max_acceleration parameter for that axis in the .ini >> file. As soon as >> the currently moving axis begins its deceleration, the next axis to move >> will begin to >> accelerate when in G64 mode. In G61, that is defeated, and the move >> must be completed before >> the next move starts. >> >> Jon >> >> ------------------------------------------------------------------------------ >> 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 >> >> > > > > -- Kenneth Lerman Mark Kenny Products Company, LLC 55 Main Street Newtown, CT 06470 888-ISO-SEVO 203-426-7166 ------------------------------------------------------------------------------ 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
