On 19.02.12 09:29, Kirk Wallace wrote: > In looking at the wiki APT page: > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?AptProgrammingForEMC > > there is a link: > http://www.nfrpartners.com/nfraptlang.htm > > What comes to mind is that APT may not be easier for simple g-code > tasks,
Kirk, you've probably won the intergalactic grand prize for understatement, there. During a break from the gcode translator, I've just taken a peek at that link, and I am stunned. Viesturs was right. APT is (I think) just too laborious to compose or interpret, due to unbelievable prolixity (and therefore lexical complexity which is beyond human comprehension, unless an impractical amount of time and sweat is invested in mentally merging and resolving the disparate sections.) The example at the link demonstrates the language's complexity problems quite well. To generate just 4 arcs and 4 straight lines, it uses 47 code lines! Gcode does that in 8. It is clearly a CAM language, with a high level of flexibility. But it is a pig to read, too great a quantity of mire to wade through, and I can't help thinking it's overkill for any simple job. > but if one had a part where features are connected, such as the > example with connected arcs, if one feature is changed, APT > automatically changes related features(?). Plus it seems to handle 3D > features, which to me doesn't seem reasonable to do with hand g-coding. Dunno that I'm immediately convinced that the enormous price is offset by significant benefits. If we need to move a gcode arc, because the straight line leading into it grew by half an inch, then it is moved automatically if the arc centre position is relative, isn't it? If the arc is 90°, and we exit to another straight line, then it has to be manually moved to be tangent again, if that is what we want. But there might not be meat out there, and the new design might need an S-bend, i.e. a second arc in the opposite direction (or some other fiddle), to come back to the exit line. No amount of language smarts can predict the size and shape of the new casting which will roll in the door, so the motion tweaking has to be manual in any event, I suspect. > It looks like APT360 is usable, it might be worth while to formulate > ways to make it more convenient to use, and go from there. Weeelll, for various values of "worth while", making it more convenient to use would have to be an improvement. But as ancient Irish wisdom has it, "If I was going there, I wouldn't start from here." Gcode seems good for expressing machine motion, except that it is at the other extreme - it is too terse, and in no way mnemonic. In another break from adding gcode translation, I've just added handling of included files. That allows common machine initialisations to be stored in files, and included in new programs by a single line. It also allows collections of related subroutines in a single file (named as the user pleases), which become part of the including program, at the point of inclusion. The next step is to add an alias (or #define) command, which will allow the user to give meaningful names to #5400 and its friends. Without explanatory comments, I'd be surprised if anyone could walk up to a gcode program and instantly know what an expression using #5400 and/or #5410 is doing. A meaningful variable name can fix that. And wouldn't it be more useful to be able to use something along the lines of Workspace[2,Z] instead of #5243? ISTM that APT is a Bridge Too Far, and incremental improvements in what we have are more achievable. Erik -- C hasn't changed much since the 1970s. And let's face it it's ugly. Can't we do better? C++? (Sorry, never mind.) - Rob Pike ------------------------------------------------------------------------------ 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
