Re: Automatic tool changing ?

[Ray Henry <rehenry-at-up.net>]

JohnD

Yea, he did!  And I'm runnin' flat out and fallin' behind.   There are
several approaches that could be taken.  Since my app is for a lathe
turret, I don't have some of the problems that you have with a spindle, a
tool hive, and a changer.  

My current approach is definitely a hack.  Written (almost done) in tcl.  I
have to place a clearance z-move ahead of the tool change line and a pause
on the tool change line so that tcl will have time to read.  I drop
feedrate to zero, drive the air solenoids to raise and spin the turret, and
watch a bcd for the right location.  Once it returns the turret in position
signal, tcl resets the feedrate.

The mill tool change is much more complex.  I'm not acquainted with the
specific tool change routine on a Milltronics PartnerVII.  Does it pick and
place tools with the spindle or are there intermediate arms?  I take it
that the hive is a drum or chain.

To do it right with a modern tool changer, you really need look ahead and a
tool number array.  From that array you can drive the hive into position
and wait for the tool change on the activeline. Many machines don't even
replace a tool in the same bin.  Then the logic splits depending on how the
previous tool is replaced and the new inserted.  All of this could be done
with NML and I suspect that a lot of it was for the test on the K&T.

But the good news is that it can all be done in tcl.  There is no time
critical activity, unless you want this thing to scream.  Auto tool change
can pause the machine or run feedrate to zero while the autoToolChange
process does it's work.   Manual tool changes manToolChange can be done
from a popup or popin with a few tk buttons and labels.  

The tcl/tk tool change program would need access to both the emcsh commands
and the iosh commands.  Phil Plumbo has been working on a marriage of these
files that he wants to use for a pendant.  He recently reported some
success at that.  The same shell file could be used with new tcl code to
produce a tool changer interface.  

If the iosh inbuf and outbuf commands could be made to see a cheapo DIO
board, I'd think that would be the easiest and most flexible approach.  If
software was available I think several list members would spend $80.00 for
a bunch of configurable I/O.  

But if someone could figure out the addresses of the extra I/O on the stg
we could use those just as easily, I'd think.

And that just leaves the orientation of the spindle.  I have no idea how
close we are to that feature in the EMC proper.  I presume that eventually
you want to be able to hard tap.  Orientation would be a near relative of
that feature.

In the meantime, we can orient that spindle mechanically, just like a lot
of the lower end tool makers do with some kind of roller and groove and an
in-position prox switch.  Dan Falck knows quite a bit about that because he
just had to repair one on a Fadal.

What we would need is a clear statement of each step in the tool change
process for your machine.  How it grabs and moves tools.  How the hive
works.  And some help with the specific pins to addresses and a wiring plan.

And you're right the puffin isn't ready.

Ray


At 09:52 PM 6/22/2000 -0400, JohnDRoc wrote:
>
>I spoke to Fred Proctor about this when I went up to NIST to visit - I think 
>he also spoke to Ray Henry about it as well.  We discussed the possibility
of 
>using a Soft-PLC with a separate I/O board to handle the non-realtime I/O.  
>This would allow for additional and more flexible I/O.  One could probably 
>devise a memory share between the PLC and Task, similar to the one between 
>Emcmot and Task (I think).  Right now I'm working on the retro-fit of a 
>Milltronics PartnerVII, with a defunct Centurion IV control and a 20 tool 
>changer.  Originally they used an Acroloop 1000 servo-I/O board and Omron
PLC 
>to run the Tool Change functions.  I don't know much about the tool change 
>(I'm still trying to get 1 axis - any axis - to work), but that Acroloop may 
>hold some potential.  I looked it up online, and it's either ISA or 
>standalone, and it has some PLC functionality built in.  I don't know how 
>much it costs, but if it isn't too bad (which is relative, I know) I would 
>think that it would be a matter of programming a standard tool change that 
>would be split by Task, which would in turn send a Pause to Emcmot and a
Tool 
>change to the Acroloop, then when it's completed, it would send a Continue 
>back to Task.  I haven't been able to find much in the way of a Soft PLC.  
>There is a relatively new project called "Puffin" at www.linuxplc.org, but
it 
>is still in the early stages of development (they have a mail list, too).  I 
>would enjoy hearing other suggestions, or if anyone knows about the ACR1000 
>board.