On 30.01.12 02:33, Steve Blackmore wrote: > On Sun, 29 Jan 2012 10:43:18 -0800, [Kirk] wrote: > > >Regarding messing with the g-code interpreter, my vote is that g-code > >should describe axis position, feedrate; and spindle speed and > >direction, and little more. Everything else should be handled with CAM, > >including canned cycles and such. Less is more.
+1 Despite being keen to work towards an optional human readable syntax, it should perform _identically_ to the current one. (All I have implemented so far is the beginnings of a filter, so it _can't_ do anything the current one doesn't.) > >If one insists on "improving" g-code, I would start over with a language > >using keywords rather than letters. The need to to extract the most > >context from single symbols is a throwback from when teletypes ran at > >300 Baud. That is what I have begun to do. The syntax might need to be whacked with a 4lb hammer to displease the least number of users, but it has a number of goals: 1) Be mnemonic. i.e. give some farnarckling clue as to what the command does. (Even "MOV" is orders of magnitude superior to "0x01" or "g01".) 2) Compress the learning curve, by making more explicit what the program does. In industry, the benefit is measurable in dollars. It accrues from 1). 3) Reduce the number of ruined $2000 workpieces. It is infinitely easier to mistype "G0" instead of "G01", than it is make "Rapid" out of "Move". No amount of error checking will pick up a destructive misprogramming in legal syntax. Someone else posted that redundancy can be useful. When it not only gives the commands explicit meaning, but also helps catch typos, then the extra keystrokes can be worth a great deal. > >Just my opinion based on very limited experience. > > Your limited experience is good, IMO. > > My experience comes from working in the commercial world for 40 yrs. > > The simpler the code, the better. It doesn't matter these days how long > the code is, but it has to be simple. The guys running CNC machines in > factories are not rocket scientists. They don't have to be. In a production environment I imagine that there is not always time to cross-check a program edit with another employee. Does it ever happen that "G0" instead of "G01" (or something even more exciting) goes in, due to a momentary lapse in mentally converting what-should-happen to those cryptic codes? > Subroutines are a big NO. They are rarely understandable to anyone else > other than the geek who wrote them, and they are impossible to recover > from if anything goes wrong. Canned cycles aren't much better! If we all had CAM, I don't think we'd labour over hand written subroutines either. It's to cope with work which would otherwise need CAM, that subroutines are a godsend to the amateur user. Erik -- Programs must be written for people to read, and only incidentally for machines to execute. - Abelson and Sussman ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
