Progress on the ATC has, once again, been interrupted by higher priority work, but it is nearing completion. I've just finished getting the "sensors" working, so all that's left is getting the door mechanism going, putting on the "skirt", and doing some minor clean-up. The mechanism is working flawlessly. In fact, it's been running continuous toolchanges since early this AM - nearing 1000 just today. So far, no problems whatsoever. And, now that the sensors are in place, I believe it will correctly detect any problems, and halt operation. I've tried everything I could think of to make it fail, and it has correctly detected every failure I've thrown at it, and simply stopped what it was doing, until I manually cleared the error condition.
On a related note, the functionality of my machine has been expanding for years, and has gotten to the point that the wiring around the KFlop has become something of a rats nest, and I'm starting to run short on I/Os. A friend and I started designing a KFlop-specific breakout board, and in the process of defining what functionality to include on it, I came up with what I think is a great idea to greatly reduce the overall amount of wiring, and the amount of required buffering of signals.
The signals connecting to the KFlop basically fall into a couple of very broad categories. First is the special function and time-critical signals, like axis
drive outputs, Home/Limit/Probe/E-Stop inputs, and a very few others, which MUST be connected directly to the KFlop. These make up about 30-40% of the total signal count. The remainder are not at all time-critical, nor do they really NEED to connect directly to the KFlop. This group includes spindle and coolant controls, power drawbar and tool-changer controls, etc.
A while back, I bought a VistaCNC USB pendant, which I proceeded to rip apart, completely re-writing the firmware for the embedded PIC processor, and converting it from USB to RS232, so it could communicate directly with the KFlop. The code in both the pendant and the KFlop is dead-simple, and the pendant has worked absolutely flawlessly since the day I first put it into service months ago. It uses a very simple purpose-built serial protocol. My
new hair-brained idea is to expand that protocol to allow additional external processors to be connected to that same RS232 link, by either a daisy-chained or star connection, so that all non-critical signals can be moved completely off the KFlop to any number of external processors, each of which can then be located near the device it controls, connected by only a serial link, rather than a mass of wires. Each processor will be separately addressed, so it will accept messages targeted to it, and ignore all others. All processors will be able to send messages to any or all other processors, including the KFlop. Each will be able to accept commands from the KFlop, or other processors, and to send status message (e.g. - current spindle speed) back to the KFlop.
I will re-configure my system so that there will be one processor in the pendant (it's there now, and will just require a few minor tweaks to support the new protocol), another in the E-box for several basic machine functions (spindle controls, coolant controls, etc.), one for the power drawbar and toolchanger, and one for the control panel (this is, essentially the pendant from hell - a console with MPG, and a bunch of dedicated-function buttons...), so I can operate the machine without a mouse.
So, for example, if the user want to release the drawbar, the KFlop will send a message to the PDB/ATC processor telling it to release the drawbar. Once the operation is complete, the PDB/ATC processor will send a message back to the KFlop either confirming the operation completed successfully, or return an error code, indicating why it failed. Similarly, to turn on the spindle, the KFlop will send a message to the spindle processor, telling it what speed to set the spindle to. The spindle processor will set the spindle PWM, turn on the spindle, and send periodic spindle speed updates until the spindle is turned off.
I plan to use off-the-shelf Arduino processor boards, because they're dirt cheap (starting at about $10), highly functional, and available in a broad range of capabilities, with a wide range of plug-in I/O expansion boards. But, ANY processor could be used, as long as it supports RS232. Since each will be
controlling only "local" devices, there is little need to any extra buffering or isolation, further simplifying the wiring. This will reduce the current mass of
cables going from the E-box to the machine down to just the motor/home/limit/probe wiring, and a single RS232 cable, daisy-chained to the
processor boards on the machine.
Regards,
Ray L.