On Wed, Feb 8, 2012 at 6:02 AM, Viesturs Lācis <viesturs.la...@gmail.com>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, > The first descriptions are generally geometry. Part or contruction geometry. Currently this is normally a very small part of an APT program as the part geometry is imported as a model. You will see some geometry descriptions in almost all APT programs but this just facilitates motion description. > 2) then it describes the lines and their mutual relations - which is > parallel or perpendicular to some initial "base" line; > More geometry description here. > 3) only then it describes the motion along the lines, arcs; > After the part geometry is described then the tool is told how to proceed along and around the geometry. In APT the programmer explicitly tells the tool EACH move to make. APT packages differ in the 'enhancements' offered. > 4) in order to understand the described motion, I have to revert back > to all the previous information; > Yes - that is correct - but in all CAM systems this is the case. > 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. > If you have the geometry on the screen you can interrogate the model as in any CAD/CAM system. > In g-code those points would be stated as G1 or G2/G3 endpoints, here > The geometry descriptions generally do not coincide with the toolpath endpoints. The toolpath endpoints are usually at lease a tool radius away from the geometry. > 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. > Yes, in simple geometry case it can be simpler to just write the code. YES - verification is a problem, that is the point of my earlier comments about complex geometry and finding problems in the cut part rather than on screen or with a verification suite. > 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. > There is a significant learning curve. As in anything the simple stuff is easy to learn, the complex builds on that. Learning to do 2D profiles is usually very easy and quick. > 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. > APT is CAM package. APT was developed when the CAD packages were drafting tables. > > 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 > -- dos centavos ------------------------------------------------------------------------------ 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
