Andre B wrote: >I think just leave EMC as it is and write a little app that does the >conversion off line, most any CAM system should be able to output >either format so we are only talking about a few existing old g code >programs. In my opinion the user would be better off rewriting those >programs anyway to take advantage of modern cutters anyway. ;)
I agree, leave it alone I have two controls that can run either way I always pick inc. Just my opinion Terry On Sat Nov 8 23:24 , 'Andre B.' <[EMAIL PROTECTED]> sent: >At 10:13 PM 11/8/2008, you wrote: >>Ron Ginger wrote: >> >> I have some Gcodes where the I and J are in absolute >> coordinates, EMC2 seems >> >> to like I and J in incremental coordinates, is there a simple way, or >> >> something that will enable EMC2 to read these Gcodes. >> >> >> >> Regards >> >> >> >> Dave >> > >> > Mach3 supports both, G90.1 sets to absolute mode, G91.1 sets to >> > incremental mode. Its valid to change it on the fly within a program. >> > >> >>That seems like it might be a useful feature. I've started implementing >>it in EMC2, but as usual when you look at the details, some tricky cases >>show up. >> >>Here is what I'm planning: >> >>Right now, IJ arcs require you to supply at least one of the >>coordinates, otherwise it reports an error. Things like: >> >>G2 I1 >> >>are OK - that means make a complete circle that starts where you are >>now, goes around a point 1 unit to the right, and return to the starting >>point. >> >>In the default G91.1 incremental IJK mode, nothing at all will change. >> >>In the new G90.1 absolute IJK mode, that same line is ambiguous. Where >>is the center of the circle? Is it at X=1, Y=(whatever the last J word >>was)? That might be what you'd expect, since when you omit X, Y, or Z >>from a move, it uses the current value. But for I and J the "current >>value" isn't as well defined. Is it the center of the last arc? What >>if I or J was used in a canned cycle a few lines up? Should it be that >>value? >> >>The Mach manual says "In Absolute it will, of course usually be >>necessary to use both I and J words unless by chance the arc's centre is >>at the origin." So Mach is using zero if you don't specify I or J (or >>K, depending on the plane). >> >>I don't see any clear reason for a user to expect one approach or the >>other. Whichever I do, somebody is going to be unpleasantly surprised >>when they leave out an I or J and the arc isn't where they want it. >> >>So, I'm going to require both coordinates when in G90.1 absolute mode. >>I think it is better to stop and print an error (during the preview >>phase if running Axis), than to make a cut somewhere it isn't expected. >> >>Comments and suggestions are welcome, but if you want to make I/J/K >>optional in absolute mode, be prepared to define exactly what will >>happen in all cases, and come up with very good reasons to justify the >>additional complexity. >> >>Regards, >> >>John Kasunich > > >Absolute IJK mode is just the same as absolute mode for XYZ. >The values in IJK are relative to the current work offset. The only >question is are they modal or not, I have never seen a control that >was setup to use absolute IJK words. > >I think the reasoning for absolute IJK was that when programming at >the machine from a part drawing it is more likely you can just read >the values off the drawing and avoid doing some math. > >Sounds like Mach is declaring IJK to be non modal, I would think they >would be modal and so a line with just a G2 or G3 could be perfectly >valid. I get the feeling that absolute mode IJK in arcs would >require the interpreter to do more calculations then incremental IJK >arcs resulting in slower block processing. Probably not a problem >since block rates tend to only be a problem with cam generated >programs that use many thousands of 0.0005 long G1 moves that you >want to run at 200 IPM. > >NCPlot does have a tool that will convert a program from one to the >other, also does many other conversions. It is a windows program but >well worth the cost of the license if you do any amount of macro B programming. > >I think just leave EMC as it is and write a little app that does the >conversion off line, most any CAM system should be able to output >either format so we are only talking about a few existing old g code >programs. In my opinion the user would be better off rewriting those >programs anyway to take advantage of modern cutters anyway. ;) > >______________ >Andre' B. > > >------------------------------------------------------------------------- >This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >Build the coolest Linux based applications with Moblin SDK & win great prizes >Grand prize is a trip for two to an Open Source event anywhere in the world >http://moblin-contest.org/redirect.php\?banner_id=100&url=/ >_______________________________________________ >Emc-users mailing list >Emc-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/emc-users ---- Msg sent via CableONE.net MyMail - http://www.cableone.net ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
