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
