I am an unashamed proponent of APT so take these comments in that light. On Sat, Feb 25, 2012 at 11:43 PM, Erik Christiansen <dva...@internode.on.net > 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. Not an understatement, just fact. For dead simple one time projects APT is not the most efficient use of a tool. > 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.) > It is not often I must look up a word to even come close to understanding it. Prolixity got me here. Every day is a good day to learn. :) APT is wordy but it turns out prolixity is a positive. > 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. > preface to my comments - for me Latin is a pig to read - for me Russian is a pig to read The 47 lines completely describes the geometry and the process necessary to cut the part. An APT programmer can read this as someone reads a sentence in their native language. Comparing the process needed to program something more complicated than a square with filiet corners you will find APT has less prolixity and contains all the information needed to understand the current process AND to modify the current process six months later after the calculation notes are lost from the desktop. Comparing the process needed to program the same part in other CAM systems you will find APT is usually not much more 'wordy' (if you loosely define wordy to include mouse clicks). NCL (my current APT application) has the menus and mouse capability to do most things without typing much. It has the added benefit some CAM systems probably don't have - writing the language concurrent to mouse clicks. This allows you to save the process for troubleshooting and/or historical needs. > > 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? > A square plate or pocket is an overly simplified comparison. Moving the just one arc center of a square will not work in gcode. If you move both arc centers on one side of the part you must also move the end points of the G02/G03 lines a commensurate amount. If you move only one are or if you have a 4 walled pocket that the lines are not parallel to an axis you will need to get out the pen, paper and calculator to calculate new entry and exit points for the gcode. Or you can fire up a point and click CAM system to regenerate the geometry to extract the new gcode endpoints so you can implement them in the 'simpler' gcode program. Likely not a 'prolixity' reducer here. > 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." > Admittedly, since I am already here if I was going there (or anywhere past there), I would 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. > Building the bridge IS more time consuming (read expensive in time and/or money) but a bridge is much more usable then a log thrown across the creek. We have three other CAM systems here. We use one other CAM system beside our APT system. Two of the systems were tried and not used. When the part gets too complicated for the one other system we use we will use our APT system to program it. We have five programmers, of which I am one of them, four know APT and one doesn't. The programmer that doesn't know our APT system can program almost anything that comes through the door. The four programmers that know our APT system can program anything that comes through the door. Most of the time this is not a big difference but sometimes this is the critical difference. I will always push for the tool that has no limits, APT or LinuxCNC or whatever other tool without limits there may be. my caveat I, in no way, advocate the use of APT in the direct control of equipment. I believe gcode is the best machine language. Gcode is the result of calculations - APT is a step in front of the calculation. This introduces an uncertainty in the resultant machine control process. I would not want to have that uncertainty in my machine control. For simple parts not much more complicated than the previously discussed four sided part there would surely be few problems but for more complicated parts you will find problems pop up - always at the most expensive, inopportune time. I need to be clear on this point. My advocation of a linux port of APT is purely a selfish desire. This involves financial and fanatical (sometimes read as philosophical) arenas. :) thanks for listening Stuart > 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 > -- dos centavos ------------------------------------------------------------------------------ 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
