ToolChangerImplementation

Tool Changer

NOTE: this page is largely obsolete, as there is no longer any *io stuff. These have been replaced with the userspace "io" component which is commonly seen as iocontrol.0.xxx in your hal files. The Mazak has been retrofitted with EMC and the toolchanger works - would someone like to link the current documentation here?

Contents

1. Outline of Existing Tool Change Code in EMC

1.1. G and M Codes

1.2. INI File Variables

1.3. Tool Change Sequence

2. Proposed Combination of G-Code macros and PLC

3. Description of retrofit of Hardinge lathe tool turret.

1. Outline of Existing Tool Change Code in EMC

The EMC uses NML messages to communication tool change information. Whenever the gcode interpreter processes a tool code in files or receives one from MDI it prepares canonical commands that instruct the task controller to add these specific commands into the motion and IO streams. Both motion and IO commands must be considered for any tool change.

The IO NML messages are processed by one of three executables, bridgeportio, minimillio, or tkio. Each of these executables works to interpret and add IO logic to the NML messages as they are received. You can think of these files as the software (Programmable Logic Controller) PLC for the EMC. Bridgeport and tkio are supposed to work the same. They add estop and spindle pins so that the end user can control these functions from a running EMC. Minimill uses no external IO other than those home and limit pins assigned to each axis.

The logic of NML within the EMC causes messages to be sent out from task or wherever and received by processes that need them. These messages must cause some other process to respond to them by forwarding another NML message. This second message is to a status array where the state of the EMC machine is kept. In many cases if the response is not seen by other processes, the EMC will wait until it's state changes to match commanded.

Regardless of whether tool, estop, spindle, etc commands are needed, they are sent. This means that EMC will stall out after some time has passed. The IO executables have the job of seeing the command and sending the state change message. If there is no tool changer in the system, these files will simply see the command and prepare and send the appropriate state change message. Nothing really happens. Where one of these executables has a bit of additional logic, say pull a pin high when the spindle forward command is received, it does that before it forwards the appropriate state change message.

What this means is that all of the IO executables handle tool change messages already. They just don't do anything "real" to the hardware when that message is received. All that is needed to make them do something is to insert that something between the reception of the message and the sending of the update status message. This is rather easily done with tkio because it requires no compiling. With a bit of study of the relevant chapters in the Developers Handbook we can locate the appropriate place to insert specific tool change logic.

The default behavior of bridgeportio and tkio is to work with a parallel port at the address setup in the [emcio] section of the INI file. In there are the pin definitions, polarities, and numbers that allow you to use estop, spindle, lube, and coolant commands. With appropriate external hardware connected to that parport these commands can do what is appropriate.

Other kinds of IO can also be addressed by these executables. A simple ISA DIO card or PCI card can be addressed if they have been correctly configured external to the EMC and the INI file. Some of these cards can be configured using commands that are addressed to the hardware and embedded in tkio itself. None of this is done for the end user and is considered an integration or developer task.

1.1. G and M Codes

There are two tool commands available to the gcode programmer. Tool preparation is a txx where xx is a positive integer between 0 and 32 although larger numbers can be used with little modification. Tool change is an m6 command. It commands a change to the most recent tool prepared. A command like t2 m6 in the same block is taken apart by the interpreter/task manager and the t2 is executed as soon as the interpreter's look ahead encounters it. Once the tool is prepared and the status is updated, the M6 will change to tool 2 when all the prior motion has been taken care of and the next tool has been prepared.

1.2. INI File Variables

There are two ini file variables that are used to move the spindle into position for a tool change and move between tools. If these variables are not found in the ini file, the tool change will be done wherever the machine is when it runs out of motion commands before the M6 IO command. These commands are placed in the [emcio] section of the ini file and are named TOOL_CHANGE_POSITION and TOOL_HOLDER_CLEAR. The values for these commands have the form xlocation ylocation zlocation where each is an axis position number.

1.3. Tool Change Sequence

This section describes the action of the EMC when the tool change and tool holder parameters are included in the ini file. Their values are;

TOOL_CHANGE_POSITION = 0.0000 0.0000 -3.0000 TOOL_HOLDER_CLEAR = 0.0000 0.0000 0.0000

I'll use a command t2m6 on a line by itself and have tool 1 loaded and running.

• interpreter finds t2 and issues tool 2 prepare
• IO systems moves tool 2 into position while tool 1 is still working
• intrpreter finds m6 and waits for all tool 1 moves to finish
• motion executes the move to tool change position
• task signals IO
• first part of tool change logic here
• io returns complete
• motion moves to tool holder clear position
• task signals IO
• second part of tool change logic here
• io returns complete
• motion returns spindle to tool change position
• task signals IO
• last part of tool change logic here
• io returns complete.

All of the signals sent to IO are identical tool change messages. The io controller will need to take stock of where it is in the change process and do the next part of the task.

If the tool holder clear parameter is not set in the ini, then the following pattern is used.

• interpreter finds t2 and issues tool 2 prepare -> sets HAL output pins (bit tool-prepare) and (short tool-number)
• IO systems moves tool 2 into position while tool 1 is still working <- awaits HAL input pin (bit tool-prepared)
• intrpreter finds m6 and waits for all tool 1 moves to finish
• motion executes the move to tool change position
• task signals IO -> sets HAL output pin (bit tool-change)
• first part of tool change logic here -> usually done in CL (classicladder)
• io returns complete <- awaits HAL input pin (bit tool-changed)

This second pattern is what we expect to implement with the Mazak at Cardinal Engineering. That machine has a full carousel, intermediate tool arm, and tool transfer arm. The IO logic is more complex but the tool change motion is a single move to the tool change position.

2. Proposed Combination of G-Code macros and PLC

Based on a discussion at EMC Fest 2005

Idea:

• if the command M6 appears the interpreter will call a special G-Code file writen by the machine integrator
• The G-Code file is the main program for tool changing and does all the motion of the machine axis (XYZ)
• special M-Codes causes the PLC to move the PLC axis (toolcarousel, Pneumatic drives, ..)
• the interpreter will wait for a signal from the PLC that it has finished with it's program

Realisation:

• improvement of the interpreter macro and programming support
  • Requires the interpreter to be able to call external user defined macros.
  • Requires the interpreter to be able to store variable such as the current position.
  • Requires the interpreter to be able to wait for a variable/return value from the PLC.
  • A number of M-Codes will be exported as HAL pins to trigger the PLC Program or to output I/O directly from the program via the PLC.
• integration of a PLC as a HAL module

Advantages:

• Keeps the motion at interpreter level and makes for rapid programming and changing external functions and logic
• G-Code and Ladder(optionally) are the languages of machine integrators

3. Description of retrofit of Hardinge lathe tool turret.

This section describes a current application of the existing IO structures within the EMC to a lathe tool changer. The Hardinge tool turret is eight position, air driven. The turret lays horizontal atop the cross slide. Below are the input and output signals required. When operating properly, the turret can make a complete rotation is about a second.

• Drive signals are 12 volt to two Clippard rotary air valves.
  • Back valve drives the turret up and powers air motor for rotation
  • Front valve pushes a stop dog and air shock into the rotating turret
• Sensors are 12 volt to signal position
  • Eight position encoder sends binary 1-8 on four wires
  • Hall prox switch activates when turret is fully seated

We chose an ISA 24 DIO Winford board for the tool and spindle interfaces. Port A is configured for output, B and C are configured for input. (0xbase +3 = 139) Only the relevant tool signals are delt with here. I'll refer to these signals as below rather than as specific addresses.

• pos1-4
• tool_ready
• air1
• air2

We worked our software into iosh and tkio which gives us access to EMC's NML messages for tool change and direct access to the pins on the Winford board. We also use an ini file variable to locate the position of tool changes.

• Pin Access Commands
  • inbinb <address> Reads and returns the byte at <address>. If address begins with 0x, it's interpreted as a hex number, otherwise it's decimal.
  • outb <address> <value> Writes the byte <value> to <address>. If address or value begins with 0x, it's interpreted as a hex number, otherwise it's decimal. Returns nothing.

• NML Messages after iosh
  • emc_tool_prepare %d
  • emc_tool_load
  • emc_tool_unload
  • emc_io_status_tool_prepped <number>
  • emc_io_status_tool_in_spindle <number>

• INI file tool change location variable.
  • [EMCIO] TOOL_CHANGE_LOCATION = (x,y,z)

The logic looks a bit like this. When a tool word (txx) is encountered by the interpreter it places a toop prep message on the stack. Task gets to this tool prep and issues an NML messge to prepare tool #xx. Iosh picks up that message and passes the info to tkio where the tool prep action is taken and a tool prepped status message is kicked out.

When the interpreter encounters a tool change word (m6) it places that on the stack. When the task encounters the tool change it generates an NML tool change command. Iosh sees that command and passes a tool load message to tkio.

Bridgeport logic does not have provision for tool changing so when bridgeportio or it's cousin tkio see a tool change message they simply return an "okay I did it" to status. A tool prep xx returns a tool prepped xx. A tool load command returns a tool loaded status. In order to make tkio do more than this we need to interleave the actual tool change bit-banging between the reception of a message and the return of the status message. (more as I get the time)