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?|
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.
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.
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.
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.
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.
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.
Based on a discussion at EMC Fest 2005
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.
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.
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.
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)