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
