On 26.02.12 09:00, Stuart Stevenson wrote: > I am an unashamed proponent of APT so take these comments in that light.
And after reading what I've snipped below for brevity, I better understand the appeal of APT. You're on the other side of the complexity bridge from those of us yet to cross it. ... > Admittedly, since I am already here if I was going there (or anywhere past > there), I would start from here. :) You've made me more aware that there is a cross-over point between the simple one-offs of an amateur, and longer runs of more complex parts in production environments. The fact that you're using APT-based CAM tools, despite being more fluent in gcode than I'll ever be, means that it's paying off. And on other FOSS projects, I've had less than flattering thoughts about software authors belting out yet another variant of a pre-existing tool, just to do it in <insert-your-favourite-new-language-here>. Whether there's a degree of rationalising of my own motives, the current effort is aimed at providing a facility which does not yet exist, and finding out what can be achieved with reasonable effort. If existing maintainers of APT360 were to embark on a refurbishment of that tool, after I've "finished" the current translator, then I'd be better placed to consider participation. But there'd have to be some fun in it. ... > 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. Implicit in that is perhaps that you can program it in a viable time. Customers always want it by Friday, even if today _is_ Friday. Rapid response is probably second only to machining accuracy, if you have the customer base you'd prefer to be building up. (i.e. They're happy to pay for good work, done pronto.) But you still have to be able to program it fast enough to make the job pay. > 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, thanks for explaining. You're educating me, and improving awareness on the list, of when we're likely to need APT. Perhaps I've misunderstood some posts on the list, which have seemed to propose APT as a replacement for hand programming of gcode (or equivalent) by the amateur. That's the level I'm at, and making that look less fugly, and easier to read, is a lot of fun at the moment. (So much so that when I saw "$$" in dave's post, my first thought was that he's referring to the lvalue in a bison grammar rule.) My tentative hope is to come up with something which sits in the gap between gcode and APT. I see no reason why we can't add bits and pieces incrementally, to make life easier, without having to climb the APT learning curve. (Like the large man said, after getting to the crow's nest at the top of the ship's mast, "It's getting the buttocks over the futtock that's the hard part.") Erik -- The ultimate barrier is one's viewpoint. - Terry Pratchett, "The Dark Side of the Sun" ------------------------------------------------------------------------------ Try before you buy = See our experts in action! 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-dev2 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users