Re: 3 axis controller

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

John & Matt

(comments mixed in)

On Sat, 07 Apr 2001, Matt wrote:
> john s finnila wrote:
> 
> 
> > This simply requires that the PC based control has provision for
> > outputting a tool (T) strobe command along with a BCD or binary tool
> > number command in TTL logic.  Then the complex logic of the tool changer
> > can be written in an external PLC.
> <...>
> 
> > Does the emc allow
> > for these features.
> 
> I'm not sure if the current Linux based version of the EMC still has the 
> code in it from way back that controls a tool changer. My biggest 
> question is whether the motion system can be paused by the I/O 
> controller. Right now I do a tool change (on a machine without a tool 
> changer) like this:
> 
> N40G53G0Z0(retract quill)
> N45X0.Y0.(move X and Y to the tool change position, change as required)
> N50M05M09(spindle and coolant OFF!)
> (display a message for the operator)
> N55(MSG,LOAD TOOL #1)
> N60M00(don't move until the operator presses the S key)
> N70T1M06G43H1(change to tool 1 and get its length from the tool table)

> As you can see, I do the tool change explicitly in the g-code because  
> all the M6 does is change the active tool number. Obviously, that would  
> have to change for your application. The motion system would have to  
> send a message to the I/O controller signaling the tool change, and the  
> I/O controller would have to assert a "busy" flag that stopped all  
> motion while the tool change was in progress. 

Jan in Antewerpen showed me his pic-and-place machine with an aux
PLC.   He tapped into the keyboard from his PLC to press (s) to start the
next block of code when the PLC had finished its cycle.  The PLC is
essentially a rotary drum machine.  If memory serves he used the mist
coolant pin to trigger the PLC to cycle.  He was also planning a glue
spreader using the coolant signals for start and end gluing.  There are
some pretty creative ways around the normal limits.  

An aux parport could do the same thing with iosh easily enough since it has
access to the full range of I/O ports and the full vocabulary of the NML. 
It can pick up on commands and switch pins and can monitor pin states and
issue commands based on changes.  The big problem would be the limited
number of output pins.  A DIO-8/16/24/48 would work better.  (Linux
drivers are available for these but other brands would work as well)  Or
the aux I/O board that is being built for the EPP would do this.

One limitation of iosh is that it works in Tcl/Tk and linux time rather
than real-time but for most of the things we are talking about, that should
not be a serious problem.

>... Some machines have a tool  
> changer that uses a swinging arm to fetch the next tool from the 
> carousel (or belt if it has a lot of tools), and insert it into the 
> spindle, but others move the carousel under the spindle and raise and 
> lower the whole thing to pick up and put back tools in the pockets of 
> the carousel. There is a lot of variability in how tool changes are 
> accomplished, but I guess the basic sequence is:
> 
> 1. Turn off coolant.
> 2. Move Z to the tool change position.
> 3. Orient the spindle.
> 4. Traverse the carousel fully towards the spindle.
> 5. Raise the carousel.
> 6. Release the old tool.
> 7. Drop the carousel.
> 8. Index the carousel to the correct tool pocket.
> 9. Raise the carousel.
> 10. Clamp the new tool.
> 11. Drop the carousel.
> 12. Retract the carousel to its "home" position.
> 
> Of course there are a number of switches that have to be monitored by 
> the software to ensure that the mechanism is actually moving correctly. 
> For example, the carousel must be fully retracted at the end of the 
> cycle before we move the Z axis.

Matt's got the idea here.  He has faced some of this for the machines that
he has retrofitted.  And he is correct that M6 in the current system only
changes the interpreter's definition of tool.  But when M6 T?? is read
by the interpreter there is a whole set of cannonical commands made
available if anything is listening.  These can be used by iosh if the proper
Tcl/Tk program is written.

You can see these commands from the interpreter in a terminal window. 
Change the debug level in your ini file to 0x7FFFFFFF.  Start that EMC
using a terminal.  Bring the control out of estop and turn the machine on.
Place it in mdi mode and type "m6 t3" in the mdi window and press
enter.  What you see is what you can ask iosh to read and make available to
a program like tkio.

So your task as a retrofitter is to work out the whole sequence of steps and
ensure that you have the proper communication between the existing PLC and
the EMC software.  Adding verification to Matt's list might look like this.
(this assumes the machine that I think he has in his head)

0. John started his process with what he called a tool (T) strobe command.

> 1. Turn off coolant.
> 2. Move Z to the tool change position.
2a. Is the Z clear or in position?
(this is a point where EMC and PLC need to talk.  This is what John called
a feed hold command to the PC.)

> 3. Orient the spindle.
3a. Is the spindle oriented?

> 4. Traverse the carousel fully towards the spindle.
4a. Has the carousel stayed in the last tool's slot.
4b. is the tool slot empty?  

> 5. Raise the carousel.
5a. Is the carousel "up?"

> 6. Release the old tool.
6a. Is the old tool loose?

> 7. Drop the carousel.
7a. Is the carousel "down?"

(This is also a EMC/PLC talking point.  What John called a BCD or binary tool
number command)
> 8. Index the carousel to the correct tool pocket.
7a. Watch for in position?

> 9. Raise the carousel.
9a. Is the carousel "up?"

> 10. Clamp the new tool.
10a. Is the tool clamped?

> 11. Drop the carousel.
11a.  Is the carousel "down?"

> 12. Retract the carousel to its "home" position.
12a. Is the carousel clear. 
(Another EMC/PLC talking point.  Again what John called a feed hold remove
command to the PC)

Some folk build machines that assume that the answer to all of these
questions is "go."  I've even seen commercial machines that don't assume the
answer, but wire prox switches in such a way that a switch failure is seen
as a correct answer.  I've seen these machines throw tools at their
operator or drop them in the chip conveyor where they rip off the home and
limit switches.  

The PLC logic ladder printout for even relatively simple commercial machines
can run to many pages.  A simple question and answer list like that above
can get fairly complex.

There is one additional design constraint that I ran up against when I
wandered into Fred Proctor's office with a stack of beautiful cad drawings
for my then imaginary Hardinge machine.  The NIST thought/constraint was
that all HMI's and GUI's should use momentary contacts and pulse coders
rather than hard wired switches and resistances.  Latches and analog like
values should be held in the PC rather than in external devices.  By doing
this, other HMI's and GUI's have read and possibly write access to the
latches and values.   This NIST idea makes a great deal of sense when you
start thinking of an individual EMC-PC as part of a larger manufacturing
cell or as one component in a larger machine.  Whether we honor this NIST
design spec for our own machines is up to each of us. 

While adding in the switches to Matt's list above, it is clear to me that
a running EMC could easily be the PLC for his example tool changer.  It
could also run a very complex tool hive where tools and holders are shared
between several spindles and are cycled out for changing when they cause to
much load on a spindle.  

Hope this helps.

Ray