On Sun, 26 Feb 2012 16:43:04 +1100 Erik Christiansen <[email protected]> wrote:
> 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 > Wow! Long post but well put and all of it needed to be said. However, there are intermediate steps that might be useful. APT gets verbose when handling arcs, but it also can be induced to give up some internal information; to wit: PRINT/ 3, ALL will dump the geometry with at least some of it in cannonical form. Parse that with sed or other favorite utility and then at least the geometry becomes standard. Passing that to gnu-gsl routines might be a path to good code. Most of what I said really applies only to 2D/2.5D. The solids world gets much more complex. The only reason to do this is to make reasonable CAM available to those that don't have the $$ or are just philosophically resistant to using non-GPL software. I'm not resistant to the idea of making g-code more user friendly and more powerful simultaneously. If I follow your reasoning correctly your additions would be supported by the C pre-processor to use #define, include, etc. Is it reasonable to then go a step further and add a 'for' loop? Just dreaming, sorry. Hang in there, this kind of discussion is needed to formulate a logical design and push forward. Dave ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
