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
