All APT systems I have seen have a synonym table. CI can be the same as CIRCLE, etc.
On Fri, Feb 10, 2012 at 3:13 PM, craig <cr...@facework.com> wrote: > In considering progrmming languages it is worth noting that there are a > fair number of people, like me, who are clerically challenged. 80% to > 90% of my errors are typographical. The number of such errors is highly > correlated to the number of key strokes. For the most part I find G-code > nicely concise. Verbose languages although more readable by some novices > also have some disadvantages for others. > > If considering such changes it might be good to have short commands > where additional keystrokes making them more novice understandable are > optional. For example for G3 one allow CCA or CCArc. > > Note: About 80% of the g-code I use is generated by Java software tools > that make it easy to do the ( mostly 2.5D) kinds of designs I do. > > my $.02 > > Craig > > > > On 2/8/2012 4:02 AM, Viesturs Lācis wrote: > > 2012/2/8 Anders Wallin<anders.e.e.wal...@gmail.com>: > >>> I see a problem with using "gcode generating" software languages to > >>> machine complex geometries. > >>> > >> So, another conclusion from this discussion would be "Do Cutsim > instead" !? > >> > >> Joseph Coffland seems to have > >> independently made great progress at http://openscam.com/ > >> > > He named the application OpenS[ource]CAM and in the limitation list he > > writes that this is not a CAM application... > > But it does look good on simulating the cutting process. > > > > First of all, I have been following this discussion and somehow I have > > not understood the intended goal to be achieved by the change of > > language, in which the code for the machine is prepared. > > So far I have noted that only Stuart Stevenson had arguments for > > g-code limitations in describing complex surfaces. > > But the discussion started much earlier and I do not understand, why. > > My point here is that I do not mind any changes, it is just that I > > feel like their reasons are not explained well, which would result in > > much less acceptance from users. Erik argued that describing arcs with > > I and J words in current g-code is not user-friendly. I think that > > _every_ possible option will be inconvinient to somebody. I would like > > to remind a saying here: > > Write an application that is suitable also for idiots and only idiots > > then will be willing to use it. > > Erik proposed this line: > > Arc CW X0 Y1 Centre X1 Y0.5 Feedrate 25 > > Is "centre x1 y0,5" are incremental distance from current point or > > absolute coordinates of center point? > > > > When compared to "normal" g-code, it becomes clear: > > G2 X0 Y1 I1 J0.5 F25 > > > > But I do not see the difference for "amateur occasional CNC machine > > user" 6 months later, because each of these syntaxes have things that > > might be difficult to remember. > > And I do not think that possibility to forget the meaning of I and J > > should be the reason to change the code language. > > There is "Quick g-code reference" under "Applications -> CNC" just for > > these kind of situations. > > > > Secondly, I took a look at Andy's link to wikipedia about APT language. > > I have no idea about capabilities of this language and how well would > > it perform in describing complex geometries, so no comments from me on > > this matter. > > What I would like to say is that I think that this language sucks at > > the ease of understanding the code. I looked at that sample code and I > > did not like it: > > 1) at first it describes some crucial points of the toolpath - either > > corners or arc centers, > > 2) then it describes the lines and their mutual relations - which is > > parallel or perpendicular to some initial "base" line; > > 3) only then it describes the motion along the lines, arcs; > > 4) in order to understand the described motion, I have to revert back > > to all the previous information; > > 5) some things are still not obvious to grasp. For example, I do not > > know, how to quickly find the coordinates of the point, where lines > > and arcs ar joined together. > > In g-code those points would be stated as G1 or G2/G3 endpoints, here > > it just says that L2 is tangent to C3 or something like that. It is > > easier to write the code, but I find it much more difficult to verify, > > if it is correct. > > > > Since this language makes the code much more difficult for user to > > read and understand it - Erik already pointed out the comparison of > > describing an arc in a single line in current g-code or 4 lines in apt > > example. > > I am not even talking about learning curve, required to climb up in > > order to understand those commands, some of them seemed obvious, but > > not all. > > I think that 2 more additions to LinuxCNC would be needed: > > 1) CAM function to generate the code. I suspect that 90 % of CAM > > applications, currently used by LinuxCNC users do not have capability > > for output in apt language; > > 2) simulator to see, what particular code is going to do; > > 3) once more - CAM function to edit the code because, as I mentioned, > > I do not see apt to be read- and edit-friendly to users. > > > > It looks like the OpenSCAM is good at simulation > > It also looks to me that Anders has done a good work on opencamlib, so > > that it could be used as a basis for CAM function. But it would > > require work on it to make it capable using all the apt advantages > > over g-code which, as pointed out by previous posters, lies in parts > > with complex geometries and, I suspect, also in 4+ axis machining. > > > > Thirdly, I tend to agree with Steve Blackmore, who posted in another > > thread that g-code is basically a standard in cnc world with lots of > > minor variations, but the essence is the same. > > IMHO drifting away from it would considerably decrease appeal of > > LinuxCNC to new users. > > > > Viesturs > > > > > ------------------------------------------------------------------------------ > > Keep Your Developer Skills Current with LearnDevNow! > > 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-d2d > > _______________________________________________ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- dos centavos ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
