PDA

View Full Version : CONVERSION: Yet another Denford for the collection (Triac Retrofit thread)



m_c
13-11-2016, 11:13 PM
So, after a bit negotiation, this got dropped outside the workshop a few weeks ago - https://c8.staticflickr.com/9/8277/29760406023_03c30230cd.jpg

I'd been looking for one for a while, and this one ticked most of the boxes (enclosed, coolant, ATC, autolube). My only complaint is it's a BT35 taper, however it also came with this-
https://c3.staticflickr.com/6/5589/30420886226_1fc34b3e54.jpg
Which should be enough holders to keep me going for a while. I have possibly found a source for new holders, however I'm weighing up the options between buying new holders, or converting it to BT30.

One thing I do have to mention, is a set of machine skates has got to be one of the best things I've built. Made rolling it into place very easy -
https://c3.staticflickr.com/6/5462/30356011306_1bdb818dac.jpg

I'll gradually add to this thread, but at the current moment, the machine is still partially dismantled, mostly cleaned, and the old controller stripped from the cabinet.

m_c
13-11-2016, 11:26 PM
Since I'm still waiting for a computer to finish updating, I'll add some more.

The machine didn't appear to be in the best of condition, however on close inspection all the slides are in excellent condition, they just needed a bit clean. The spindle on the other hand didn't feel so good. Removing the spindle motor didn't improve the feel, so after removing a bit more, the problem became obvious-
https://c7.staticflickr.com/6/5624/30275686662_26ba535a00.jpg
The machine had got wet at some point, as there was rust around the spindle from where water had been sitting, so a couple new bearings, some grease, and the spindle is as good as new.
I still need to decide on the final preload of the bearings, as even the Denford guys say they were just done by feel in the factory.

The other issue, in true education system style, the mill had been used to machine wood. My lathe was the exact same, with dust everywhere, and a nightmare to clean.
https://c3.staticflickr.com/6/5770/30096723170_bff4babf8f.jpg

m_c
15-11-2016, 05:05 PM
Rather than have this thread as just another "look at what I got/done" thread, I'm wanting to explain some of the reasoning behind the choices.
.
Denford use pretty industrial type setups for their electrics, so all the control electrics in this machine already run 24V, which I'll be sticking with, as 24V controls pretty much eliminates all noise problems. (If there is demand I'll go into the details of the why higher voltage is better)
This particular machine is a VMC version (basically means it comes with inbuilt computer/display/keyboard), running stepper motors courtesy of a parker SD rack.
.
Here's a few pics.
Original control cabinet setup-
https://c4.staticflickr.com/6/5832/31003315275_ecfb66e770.jpg
.
It powers up!
https://c7.staticflickr.com/6/5597/30701843110_421461d9f2.jpg
Check the whopping 1024kb of memory and 33MHz clock speed :-)
.
I love old school tech-
https://c3.staticflickr.com/6/5829/30420901346_8f8f2ee8f5.jpg
.
Now that's how it came. Cutting edge technology for the early nineties, and would likely still work if I could be bothered finding a working floppy disk drive to create a new floppy disk. But I need this machine working, not stuck running archaic software/hardware.
.
In an ideal situation, I'd install servos, however I don't have the budget or time to rework everything to fit servos.
Instead, I'm going to stick with the original steppers for now, and using modern drivers.
I've opted for Leadshine EM806s. A lower end drive would also of worked, but I want to make this machine as reliable as possible, so the stall-detection of the EM drives gives an extra bit protection should something go wrong.

m_c
15-11-2016, 06:38 PM
Now having decided what general direction I wanted to go with the mechanics, it was time to look at controller options. For me personally, I prefer Dynomotion KFlops, as they are probably one of the most versatile controller available for the price, but this left me the problem of deciding what add-on boards were needed.
.
The first thing to consider was what input/output capability was needed.
For this purpose, I create a spreadsheet, and list every input/output I need, along with a note of the type of input/output needed. At the current count it's 28 inputs (2 analogue for SSO&FRO, 1 encoder input for a MPG, with the rest being basic on/offs), and 9 outputs (1 analogue with rest on/offs), along with the currently required 3 step/dir outputs.
.
I could of opted for a KStep board, which would of met the needs for driving stepper motors, albeit at a slightly lower voltage (it has a max Voltage of 50V), but it lacks any kind of analogue input.
.
The other option, was to use a Kanalog. Now this is primarily aimed at retrofits on machines using +/-10V servos, however as I'd like to keep my options open, it provides a good upgrade path. It also has analogue inputs, and differential encoder receivers.
It also so happens I already had a spare one sat on a shelf, along with a Konnect expansion board, which means I've got more inputs and outputs than required.
.
The only draw back was I'd like to make use of the differential inputs on the EM806's, and Dynomotion have nothing that outputs differential step/dir signals. So a solution was needed, and it came in the creation of this board-
https://c7.staticflickr.com/6/5684/30703631150_fefec9c7ee.jpg
On the KFlop, in standard configuration, the encoder pins also double up as the step/dir pins, of which 8 of them happen to go through a separate RJ45 connection (the other 8 go through one of the ribbon cables). This board takes those 8 lines, and by moving the jumpers, either routes them directly through to the Kanalog to be used as encoder inputs, or to the line driver chips on the board to be used as differential/line driven outputs.
So that was the step/dir differential outputs taken care of.

routercnc
15-11-2016, 07:44 PM
No plans to do anything like this myself but interesting to see the conversion and the thought processes as it evolves. And that little converter board looks very neat, well done.

m_c
16-11-2016, 10:56 PM
I was going to post about some of the intricacies of the machine wiring, however I'll stick with controllers for now.
.
Now I've got all the boards, I need to mount them.
The old computer, which was bolted to the control cabinet door was removed, and a suitable bit 3mm aluminium sheet was cut to size. The reason for 3mm, is it's strong enough to bridge pretty big areas with minimal support, and thick enough for drilling/tapping for directly mounting items. Thinner would be marginal for drilling/tapping, and thicker just adds expense for little to no benefit.
.
First step once the sheet had been cut and drilled for mounting to the cabinet door, was to play tetris with the various boards-
https://c1.staticflickr.com/6/5566/22830669048_bff14029c3.jpg
Which highlighted the first non-ideal thing. My lovingly designed and built differential driver board would of been better had the in/out RJ45 jacks been the opposite way around. As it stands, it just means I need to make the cables a bit longer and they'll cross.
If noise was to be a problem, I choose the shielded jacks so shielded cable could be used if needed.
.
So now things are positioned, it's a case of marking out all the various holes, followed by drilling and tapping all the required holes.
When doing this, is I like to drill the required holes slightly undersized. Everything mounts via M3 stand-offs, and Standard/Course M3 has a pitch of 0.5mm, so the ideal tap drill size is 2.5mm. Instead I use a 2.4 or 2.3mm drill, as it allows a bit margin for if the drill isn't perfectly straight, or isn't drilling perfectly on size.
I then tap using a M3 spiral flute drill in the cordless drill, before hoping my marking out and drilling was on target-
https://c7.staticflickr.com/6/5571/30707474430_99ed175346.jpg
.
Managed to only get one hole slightly off, but thankfully it was for the IDC breakout board, so a quick file and everything bolted together perfectly-
https://c6.staticflickr.com/6/5732/31009120565_93f316c470.jpg
Something I like to do here, is although I fitted all the boards on the bench, I never tightened the screws until I had the plate bolted to the cabinet door. My reasoning for this is to minimise the amount of strain placed on the PCBs should the back plate twist any when finally bolted down.
.
And you may be wondering why the IDC breakout board has been added. I may need to use a couple of the feeds provided by the Kanalogs IDC header, so it's far easier to fit the board and not need it, rather than fitting it later and risk getting some swarf somewhere I really don't want to.

AndyGuid
17-11-2016, 06:01 AM
Rather than have this thread as just another "look at what I got/done" thread, I'm wanting to explain some of the reasoning behind the choices.

Thanks m_c, I am finding the reasoning and associated detail that you're providing particularly beneficial for my edification and ultimately future build.

Andy

m_c
26-11-2016, 01:04 AM
Next problem was power for the steppers.
After finding a couple datasheets for the fitted stepper motors which listed the motor inductance, a reasonable accurate working voltage could be calculated.
The listed inductance is 3.2mH (milli Henries for those wondering what the H means) for the X and Y motors, and 5.5mH for the Z axis motor.
Now using the calculation courtesy of GeckoDrive's Stepper Motor Basics guide (http://www.geckodrive.com/support.html) (worth a read for those wanting to know more about steppers and suitable power supplies), which is 32 * vL = VMAX.
L is the Inductance, and the little v is meant to be a square root symbol, so after a bid BODMAS I.e. work out the root before doing the multiplication, we get a max voltage of 57.24V for X and Y, and 75V for the Z.
.
The original Parker SD rack ran of a transformer outputting +44,+18,0,-18 & -44V.
For those unfamiliar with how AC voltage is measured, it is commonly measured as RMS (Root Mean Square - google it if you really want to know the detail!) voltage, which in a very simplistic way can be considered the average voltage.
Taking a 44VAC voltage, in an ideal world, the peak voltage would be 44 times the square root of 2 (RMS nicely works out as root 2, or 1.414), which gives us 62V.
Off course, in the real world, that voltage will be higher. Due to mains voltage fluctuations (can be as high as 10%), and the fact the transformer voltages are at rated load meaning due to internal losses the unloaded voltage is higher (if you see voltage regulation figure for a transformer, this is what it relates to), you can end up with a peak voltage far higher than calculations.
.
However, the original transformer is marginally small to make full use of the steppers. No official ratings could be found for it, but going by a rough guestimate of it's physical size, I'd put it around the 2-300VA size, which was perfectly adequate for the original drives, running 2A on the X and Y, and 3A on the Z. Plus there would be the problem the outputs are split between positive and negative, meaning I would have to in effect create two separate linear supplies to make full use of the transformers capability.
.
So, a new supply was needed.
After a running a few calcs on commonly available toroidal voltages, I picked a 500VA 33VAC.
Given this is a mill, where every last ounce of performance is not needed (voltage only limits maximum speed), I decided somewhere around 50V would do fine. Combine that with running modern drives, and higher current, performance will be greatly increased anyway.
The 33VAC should in theory give me a peak voltage of 46.67V, and by using a higher rated transformer (a 300VA would most likely work good enough) there will be less voltage drop under load.
.
Once again, I took a bit aluminium plate, arranged a few bits, drilled some holes, and added some bit wires, to end up with this-
https://c2.staticflickr.com/6/5627/31005610401_7687319160.jpg
.
One tip here is for connecting up the transformer. As I'm paralleling the outputs, and the bridge rectifier uses faston/spade terminals, I need to get two wires into a suitable crimp. My personal preference is to use uninsulated crimps, and crimp the wires like this-
https://c1.staticflickr.com/6/5683/30976648552_115bbf5774.jpg
.
Using a single wire, the top of the crimp should crimp the insulation, which gives better support to the wire and reduces the likeliness of the wire snapping due to fatigue, however you won't get the insulation of two wires into this kind of crimp. So the solution-
https://c6.staticflickr.com/6/5600/31005588861_64e960ba18.jpg
A couple bits of heatshrink. I shrink the first bit on so it only covers the crimps, as per the lower orange/black wires, then put a second bit to act as the insulator for the terminal as per the top red/yellow wires. A single bit would do the job, but I like to provide a bit extra support for the wire.
.
One tip for all crimp terminals, is after you think you've crimped them, try pulling them of the wire. For uninsulated crimp terminals, the wire should snap before you're able to pull the connector off, however insulated crimp terminals, they're more likely to pull out.
For any size of reasonable wire, if you can pull the terminal off just by using your finger and thumb, then they're not crimped tight enough, and likely to give problems later.
.
One thing not visible in the picture, is prior to final assembly the bridge rectifier gets some heat transfer paste put on it improve heat transfer to the aluminium plate, which brings me to the final bit of linear power supplies.
A bridge rectifier also introduces a voltage drop between the input and output, which is why it needs to be attached to some form of heat sink.
I think this one was rated at 1.1V drop at load, so if I was to manage to use the full 15A output of the transformer, I'd be looking at 16.5W of heat needing removed. In free air with no heatsink, the bridge rectifier would quickly be reduced to a smouldering blob.
Now that volt drop also needs to be taken into account for out final output voltage, so in theory with the peak AC voltage of 46.67V, I should get a DC voltage of around 45.5V at the capacitor.
.
Now as I mentioned earlier about theory and real world, using a reasonably accurate multimeter, I get around 52VDC at the capacitor. That's a good 14% higher than our calculated figure. This will drop under load, but it may also rise above that under hard deceleration of motors, which is why you should always allow a reasonable safety margin between your power supply voltage and the maximum allowable stepper driver voltage.

m_c
26-11-2016, 11:46 AM
Wiring. Lots and lots of wiring.
And how do you wire a retrofit?
.
Thankfully, Denford are quite happy to make available what wiring diagrams they have for older machines. Their forum (www.denfordata.com) contains lots of information, and also a few different sets of wiring diagrams for Triac's, and having already retrofitted a Cyclone lathe, I've learnt a good bit about how they do things.
.
The first problem I knew I had to deal with was the homing sensors. Denford use NAMUR output sensors, which are a two wire sensor aimed at explosion risk applications. It has been asked on the Denford forum why they were chosen, but none of the current employees know.
They could be made to work, either through some expensive NAMUR barrier interfaces, cutting the old control board up to get the required circuit, or playing around with opamps, resistors and transistors, but swapping them out for new 3 wire sensors makes far more sense.
.
Until you realise where the wiring runs for the X-axis sensor and limit switches, and the existing 4 core cable needs an extra core. All the X-axis switches sit at the front of the table underneath the front bellows, and upon initial inspection, I thought the wiring passed down through the front of table, and I was looking at a major strip down job to run new wiring.
After a bit studying of parts diagrams, a good bit umming and arring, a start was made, with me expecting to need to remove the complete Y assembly from the mill, and possibly even the mill from the enclosure. However, after reaching this point-
https://c7.staticflickr.com/9/8410/30154103150_3ef0894ea4.jpg
A deep breath of relief was had, upon realising the wire simply passed over the top of the assembly, before going down through a hole and being cable tied to the autolube pipes underneath the base-
https://c3.staticflickr.com/6/5676/30154082410_7b34ea4a08.jpg
With some use of various pliers, side cutters, and skin removal, I managed to get the old cable removed, and a new cable fed in. For the new cable, I opted for some high oil resistance chainflex cable from Igus (CF9.02.06 to be precise), which is a similar diameter to the old cable, but with 6 cores.
Something to consider when carrying out a retrofit, is the condition of the original wiring. Although this cable was still functional, underneath the table, the wire had gone brittle, so it would of likely failed at some point fairly soon. Spending a bit extra time during the retrofit to check things can save you lots of unplanned grief later.
.
Now the biggest wiring headache on the machine has been dealt with, and the main new bits are mounted in the cabinet, it 'just' leaves this to sort out-
https://c3.staticflickr.com/6/5483/30428405834_de0b0a30c5.jpg

m_c
04-12-2016, 12:21 AM
Wires. Wires. Wires everywhere.
.
https://c3.staticflickr.com/6/5483/30428405834_de0b0a30c5.jpg
.
So where do you start with wiring a retrofit?
For me it's always the power supplies, and related circuitry.
First up was a switched mode 5V DIN rail mounted PSU to power the KFlop/Kanalog. Nice and simple, it gets a permanent live feed whenever the machine is switched on. It can just be seen on the lower DIN rail just to the left of the original cream coloured 24V supply.
.
Next is the big linear supply for the steppers, however it relies on being controlled by the E-stop circuit. As is best practise when powering stepper drivers, you only ever switch the input side, so a suitable contactor was added, controlled via the E-stop circuit, which is at the very left of the lower DIN rail.
Something I struggled with while initially deciding on how to handle E-stops and enabling on earlier retrofits, was what should be hardware controlled, and what should be software controlled. The advice I got, was keep them distinctly separate. Two main reasons for this, first is it avoids a race situation, and two, should something go wrong, you should know if it's due to a hardware or software problem.
For those not familiar with a race situation, it's more a programming term, where due to two interdependent conditions, they both get stuck because of each other.
In terms of what I'm discussing here, if you were to rely on the control/software activating the E-stop circuit, how would you initially activate it, given the control would see it as tripped due to the fact the control hasn't activated it?
.
This is where drive enable circuits come in.
The E-stop circuit cutting power should be seen as a final way to kill motion in the event of controller failure, as it will usually take a second or two for the power to drop low enough for motion to stop.
By using the enable signal to stop motion, motion should stop quicker, although by removing the enable, the motor will usually be left to freewheel to a stop. However on a stepper driven machine this is not usually a major issue.
Off course, as I'm using a KFlop, this gives me the ability to handle this aspect however I like. This gives me the option to implement a minor delay between stopping the step/dir pulse stream, prior to the enable signal being removed.
I end up with a flow like this-
1) E-stop circuit deactivated (I.e. E-stop button pressed, limit switch hit)
2) Power disabled and KFlop notified E-stop triggered simultaneously
3) KFlop immediately stops motion signals
4) 200ms later KFlop removes enables
5) Residual power drains
.
You may be wondering why I'm happy to rely on the KFlop in this way, but it's because it will do exactly what it's programmed to do. It's not like a PC which may hang due to myriad of things. At this level of operation, it's programmed as a microcontroller, with no influence from the PC. Once the system has been initialised, you can unplug the PC, and the KFlop will still react in the same way. Even if it wasn't, the removal of power will still stop motion eventually.
.
Off course, once you get into servo drives, you have other considerations, like do you really want to cut power instantly (cutting power will usually result in drives faulting and motors freewheeling to a halt), servo drives usually have the option of implementing a Stop signal, which when triggered will cause the drive to stop the motor as fast as possible.
.
The only addition I did make to the original E-stop circuit, was the Kanalog board has an enable signal, which goes active once the KFlop and Kanalog board have fully powered on. The reason for this, is during initial power up, prior to the KFlop establishing communication with the Kanalog board, the Kanalog outputs will be in an indeterminate state (i.e. they are not guaranteed to remain deactivated). I simply use the signal, which is a relay driver capable output, to power a relay, which in turn is part of the E-stop circuit. For those familiar with parallel ports/Mach/LinuxCNC, it can be thought of as a charge pump circuit.

Neale
04-12-2016, 08:44 AM
I read your description of your e-stop, etc, wiring with interest. Always good to see someone else's approach. Couple of questions come to mind.

Did you consider use of a safety relay? I managed to pick up one cheap on eBay, partly because it lets me switch a number of circuits from the e-stop switch, convenient way to configure "momentary contact" standby switch, etc. Does your e-stop connect to a latching relay or similar?

You mention limit switch triggering as equivalent to e-stop. I can see why you might want to do this, but will it give problems in separating limit and home switch operation? I use drive fault from my digital drives to trigger e-stop but limit/home switches go direct to CSMIO (similar argument to yours re dedicated firmware - no PC involvement).

m_c
04-12-2016, 11:06 AM
Did you consider use of a safety relay? I managed to pick up one cheap on eBay, partly because it lets me switch a number of circuits from the e-stop switch, convenient way to configure "momentary contact" standby switch, etc. Does your e-stop connect to a latching relay or similar?

Technically to meet the latest regs, I should use a proper E-stop relay, however it's something I've not bothered with yet, and as I'll be the only person using the machine, I technically don't need to conform to any regulations.
However, the main reason is I'd need to add an enable button, and the control panel is still a sketch in a notepad at the moment. It's something I will likely add at a later date, once I have fully functional control panel.
The real benefit of a E-stop relay is the contact monitoring, whereby should a contact stick/weld shut, it won't enable.


You mention limit switch triggering as equivalent to e-stop. I can see why you might want to do this, but will it give problems in separating limit and home switch operation? I use drive fault from my digital drives to trigger e-stop but limit/home switches go direct to CSMIO (similar argument to yours re dedicated firmware - no PC involvement).
I always use separate home switches, so homing is not a problem. I personally think it's a waste of inputs wiring the limits directly to the controller, as there is little benefit. If you can't tell what switch you've just ran into, you're doing something wrong!
What I do have though, is all the limit switches and everything else in the E-stop circuit, pass through a row of DIN rail terminal blocks, so should something fail, 30 seconds with a multimeter lets me know where the problem is. I do take the Drive fault signals to the controller, as it lets me know what drive has failed, for the reason I need to turn the cabinet power of before I can open the cabinet at which point the drives get reset.

As always, there are several ways to achieve this. The main thing to consider with any system, is what would happen in the worst case scenario, should any/multiple parts of the system fail.

JAZZCNC
04-12-2016, 11:55 AM
I don't class Limits as Emergency stop condition. They are positional errors which if talking directly to Controller and not relying on software can be handled by controller/drives safely with out any need to kill power. Soon becomes pain in the arse reseting if when approaching travel limits you accidentally trip limit.

m_c
05-12-2016, 12:23 PM
I don't class Limits as Emergency stop condition. They are positional errors which if talking directly to Controller and not relying on software can be handled by controller/drives safely with out any need to kill power. Soon becomes pain in the arse reseting if when approaching travel limits you accidentally trip limit.

You can argue both ways, but Denfords have the limit switches as part of the E-stop circuit as standard, and I don't see any point in changing it.
Provided you have soft limits working correctly, you should never hit a limit switch anyway, so if you do, it's because something has gone wrong.

JAZZCNC
05-12-2016, 03:54 PM
You can argue both ways, but Denfords have the limit switches as part of the E-stop circuit as standard, and I don't see any point in changing it.
Provided you have soft limits working correctly, you should never hit a limit switch anyway, so if you do, it's because something has gone wrong.

Yes you can and for long time I did it your way but changed my thinking over time. However don't fully agree on the softlimits point.?

Softlimits are only useful provided machine was homed first and sadly most control Software will allow you to do that. If someone forgets to home then they are completely useless.
Cslabs have nice feature where if soflimits are on then machine can't be Jogged when controller first switched on. This much safer and how it should be done IMO even without Soflimits.

Web Goblin
06-12-2016, 08:12 AM
Soft limits are a great idea but as Jazz has said they need a reference point. All of our newer industrial machines at work require a reference before you can do anything with them. The machines cant even be jogged around. Obviously this is because once referenced all of the soft limits for table positions and dimensions and limits are taken from the reference point. The machine still has limit switches at the ends of the track and between tables.

m_c
25-12-2016, 10:25 PM
Ignoring the soft limit debate for now, which I will revisit when I get onto configuring the KFlop, I'll do a little bit more on wiring.

Now that the new home switches are installed, I had to wire them into the controller.
The original wiring for the 2 wire home switches, had two of the sensors common wires doubled up, and everything else on separate pins in the main machine connector, so the original sensors used a total of 5 pins.
For the new 3 wire sensors, I needed 2 power wires, and 3 signal wires, so the same number of wires were needed.

One thing I hate is connecting multiple wires into single terminals. Although it will work, it makes future replacement and testing harder. Luckily the Triac has an extra enclosure on the rear of the machine for the pneumatics, which originally looked like this -
https://c4.staticflickr.com/1/31/30857972963_3284ac45ef.jpg

After sliding the solenoid block along, and extending some of the tubing, we end up with plenty room for some terminal blocks-
https://c3.staticflickr.com/1/525/31521963322_0ef8821475.jpg

The two double height blocks provide a GND and 24V supply for on the machine, which the new home switches use. It also gives a convenient connection point for future additions that need 24V.
The extra two blocks are for the X-axis limit switch connections, so all the X-axis cable connections are in the same place.

And now I've found a picture, here's the original X-axis switch setup-
https://c4.staticflickr.com/6/5608/30857998403_038c15be6a.jpg
Unfortunately I never took a picture of the new setup, but the only difference is a new proximity sensor, and the two way terminal block swapped to a three way. I could of used the existing setup just by soldering the limit switch common wires together, but why do that when you can make life even more awkward and fiddly for yourself?

Which while I'm on wiring, brings me to bootlace ferrules.
20085
One thing that often results in untidy wiring, are stray wire strands at connectors. Especially once a wire has been removed and put back in a couple times, the problem usually gets worse.
A bootlace ferrule, not only keeps things tidier, it also provides support for the wire, and makes inserting wiring into terminals easier.
On thin wiring, such as is normally found on sensors, this makes a big difference, as you'll often find once a thin wire has been removed and reinserted a couple times, several of the strands will get broken, so you have to cut back the wire. Using a ferrule pretty much eliminates that problem.

Tom J
05-01-2017, 12:33 AM
.
.
Now as I mentioned earlier about theory and real world, using a reasonably accurate multimeter, I get around 52VDC at the capacitor. That's a good 14% higher than our calculated figure. This will drop under load, but it may also rise above that under hard deceleration of motors, which is why you should always allow a reasonable safety margin between your power supply voltage and the maximum allowable stepper driver voltage.

Your driver EM806 has operating voltage up to +80 VDC so why 52VDC satisfy you?

m_c
05-01-2017, 09:37 AM
Your driver EM806 has operating voltage up to +80 VDC so why 52VDC satisfy you?

Because theoretically the x and y motors are only good for 57V, and running them higher could result in overheating them.
Off course you could avoid motor overheating by reducing current, but then you reduce torque at all speeds, which is counter productive to getting the best performance.

Tommy
12-01-2017, 09:21 AM
Rather than have this thread as just another "look at what I got/done" thread, I'm wanting to explain some of the reasoning behind the choices.
.
Denford use pretty industrial type setups for their electrics, so all the control electrics in this machine already run 24V, which I'll be sticking with, as 24V controls pretty much eliminates all noise problems. (If there is demand I'll go into the details of the why higher voltage is better)
This particular machine is a VMC version (basically means it comes with inbuilt computer/display/keyboard), running stepper motors courtesy of a parker SD rack.
.
Here's a few pics.
Original control cabinet setup-
https://c4.staticflickr.com/6/5832/31003315275_ecfb66e770.jpg
.
It powers up!
https://c7.staticflickr.com/6/5597/30701843110_421461d9f2.jpg
Check the whopping 1024kb of memory and 33MHz clock speed :-)
.
I love old school tech-
https://c3.staticflickr.com/6/5829/30420901346_8f8f2ee8f5.jpg
.
Now that's how it came. Cutting edge technology for the early nineties, and would likely still work if I could be bothered finding a working floppy disk drive to create a new floppy disk. But I need this machine working, not stuck running archaic software/hardware.
.
In an ideal situation, I'd install servos, however I don't have the budget or time to rework everything to fit servos.
Instead, I'm going to stick with the original steppers for now, and using modern drivers.
I've opted for Leadshine EM806s. A lower end drive would also of worked, but I want to make this machine as reliable as possible, so the stall-detection of the EM drives gives an extra bit protection should something go wrong.

Hi, Do you still have the motion control card (electronics) you stripped off the machine. Precisely, I need a working “baldor D281 motion control card for a TRIAC P. C., red 7-segment LED display type".

andy_con
12-01-2017, 09:22 AM
Hi, Do you still have the motion control card (electronics) you stripped off the machine. Precisely, I need a working “baldor D281 motion control card for a TRIAC P. C., red 7-segment LED display type".

If I was a mod on this forum Id ban you for spamming

Tommy
12-01-2017, 09:42 AM
What makes you think i am spamming. Why would i be spamming a CNC forum, is it that I dont have any job to do?

I am only posting in numerous threads that I believe are relevant to my need, which is to obtain a working denford controller card

The post by "m_c" shows an image of the card (which you might no longer be used) and that is why i replied to "m_c"'s post

So i still ask, do you still have the Triac controller card that is shown in that picture in that post. Cheers.

Tommy
12-01-2017, 09:42 AM
If I was a mod on this forum Id ban you for spamming

What makes you think i am spamming. Why would i be spamming a CNC forum, is it that I dont have any job to do?

I am only posting in numerous threads that I believe are relevant to my need, which is to obtain a working denford controller card

The post by "m_c" shows an image of the card (which you might no longer be used) and that is why i replied to "m_c"'s post

So i still ask, do you still have the Triac controller card that is shown in that picture in that post. Cheers.

andy_con
12-01-2017, 09:49 AM
Cos any normal person would go into the wanted section and make a single post asking what they wanted.

It's the whole point of a wanted section

Like I say lucky I'm not a mod

Tommy
12-01-2017, 03:31 PM
Cos any normal person would go into the wanted section and make a single post asking what they wanted.

It's the whole point of a wanted section

Like I say lucky I'm not a mod

Pls just stop with the insults. May be that is why you are not a mod. I a new to the forum, never knew there is a wanted section. May be you should tell the moderators not to allow newbies to post until they have gone thru an "intro". Just chill and pls just get off my back, unless you have the card I am looking for.

John S
12-01-2017, 07:53 PM
For F*ck's sake Tommy give it a rest.
You have posted on every web site known to man including the stray cats website.
If anyone has one of these boards they will be severely tempted to throw it in the skip just so you can't get yours hands on it.

Tommy
13-01-2017, 12:02 AM
For F*ck's sake Tommy give it a rest.
You have posted on every web site known to man including the stray cats website.
If anyone has one of these boards they will be severely tempted to throw it in the skip just so you can't get yours hands on it.

My sincere apologies to John S.

John S
13-01-2017, 12:37 AM
Graciously accepted.

andy_con
13-01-2017, 01:53 PM
For F*ck's sake Tommy give it a rest.
You have posted on every web site known to man including the stray cats website.
If anyone has one of these boards they will be severely tempted to throw it in the skip just so you can't get yours hands on it.

Piss my shit

m_c
12-02-2017, 01:00 AM
So dragging this back on topic, I'll quickly cover the seemingly mysterious world of configuring a KFlop to do the basics.

There is no denying the KFlop can appear very complex, but it's not that much more complex than using any other controller. The key thing is, whereas programs like Mach have configuration options spread over various screens which create/update your machine configuration file, you have to create the equivalent KFlop configuration file yourself. However, the included KMotion software has various screens/functions to help you create the needed parameters, and several example files are included.

I'll start with the basic file I used to get basic motion.

#include "KMotionDef.h"

main()
{

ch1->InputMode=NO_INPUT_MODE;
ch1->OutputMode=STEP_DIR_MODE;
ch1->Vel=40000;
ch1->Accel=400000;
ch1->Jerk=4e+06;
ch1->P=0;
ch1->I=0.01;
ch1->D=0;
ch1->FFAccel=0;
ch1->FFVel=0;
ch1->MaxI=200;
ch1->MaxErr=1e+06;
ch1->MaxOutput=200;
ch1->DeadBandGain=1;
ch1->DeadBandRange=0;
ch1->InputChan0=1;
ch1->InputChan1=0;
ch1->OutputChan0=13;
ch1->OutputChan1=0;
ch1->MasterAxis=-1;
ch1->LimitSwitchOptions=0x100;
ch1->LimitSwitchNegBit=0;
ch1->LimitSwitchPosBit=0;
ch1->SoftLimitPos=1e+09;
ch1->SoftLimitNeg=-1e+09;
ch1->InputGain0=1;
ch1->InputGain1=1;
ch1->InputOffset0=0;
ch1->InputOffset1=0;
ch1->OutputGain=1;
ch1->OutputOffset=0;
ch1->SlaveGain=1;
ch1->BacklashMode=BACKLASH_OFF;
ch1->BacklashAmount=0;
ch1->BacklashRate=0;
ch1->invDistPerCycle=1;
ch1->Lead=0;
ch1->MaxFollowingError=1000000000;
ch1->StepperAmplitude=20;

ch1->iir[0].B0=1;
ch1->iir[0].B1=0;
ch1->iir[0].B2=0;
ch1->iir[0].A1=0;
ch1->iir[0].A2=0;

ch1->iir[1].B0=1;
ch1->iir[1].B1=0;
ch1->iir[1].B2=0;
ch1->iir[1].A1=0;
ch1->iir[1].A2=0;

ch1->iir[2].B0=0.000769;
ch1->iir[2].B1=0.001538;
ch1->iir[2].B2=0.000769;
ch1->iir[2].A1=1.92081;
ch1->iir[2].A2=-0.923885;

ch2->InputMode=NO_INPUT_MODE;
ch2->OutputMode=STEP_DIR_MODE;
ch2->Vel=40000;
ch2->Accel=400000;
ch2->Jerk=4e+06;
ch2->P=0;
ch2->I=0.01;
ch2->D=0;
ch2->FFAccel=0;
ch2->FFVel=0;
ch2->MaxI=200;
ch2->MaxErr=1e+06;
ch2->MaxOutput=200;
ch2->DeadBandGain=1;
ch2->DeadBandRange=0;
ch2->InputChan0=2;
ch2->InputChan1=0;
ch2->OutputChan0=14;
ch2->OutputChan1=0;
ch2->MasterAxis=-1;
ch2->LimitSwitchOptions=0x100;
ch2->LimitSwitchNegBit=0;
ch2->LimitSwitchPosBit=0;
ch2->SoftLimitPos=1e+09;
ch2->SoftLimitNeg=-1e+09;
ch2->InputGain0=1;
ch2->InputGain1=1;
ch2->InputOffset0=0;
ch2->InputOffset1=0;
ch2->OutputGain=-1;
ch2->OutputOffset=0;
ch2->SlaveGain=1;
ch2->BacklashMode=BACKLASH_OFF;
ch2->BacklashAmount=0;
ch2->BacklashRate=0;
ch2->invDistPerCycle=1;
ch2->Lead=0;
ch2->MaxFollowingError=1000000000;
ch2->StepperAmplitude=20;

ch2->iir[0].B0=1;
ch2->iir[0].B1=0;
ch2->iir[0].B2=0;
ch2->iir[0].A1=0;
ch2->iir[0].A2=0;

ch2->iir[1].B0=1;
ch2->iir[1].B1=0;
ch2->iir[1].B2=0;
ch2->iir[1].A1=0;
ch2->iir[1].A2=0;

ch2->iir[2].B0=0.000769;
ch2->iir[2].B1=0.001538;
ch2->iir[2].B2=0.000769;
ch2->iir[2].A1=1.92081;
ch2->iir[2].A2=-0.923885;

EnableAxis(0);
EnableAxis(1);
EnableAxis(2);

FPGA(STEP_PULSE_LENGTH_ADD)=63; // set the pulse time to ~ 5.xus
DefineCoordSystem(0,1,2,-1);

InitAux();

AddKonnect(0,&VirtualBitsEx,VirtualBitsEx+1);

return 0;

}

It looks complex, but I'll break it down.
You have three sets of channel configuration data (one for each axis in this case). These set all the possible parameters for each channel.
To create this information, within the Config function in KMotion, you use the various dropdown boxes and boxes to select/enter the information. You can then download the information to the KFlop to test (this can be done on the fly), and then once you're happy, you can copy the information to the clipboard, and paste it into your init.c file (init.c is the generic name used to reference your initialisation file - the file can be called whatever you want, but for simplicity it's gets called this).
Although not needed for this, if you were to use some form of closed loop, there is the Step Response screen for tuning servos and carrying out test moves, an IIR Filter screen for applying filters to closed loops, and a Bode Plot screen for generating test plots to see in detail how the closed loop is performing.

For a basic step/dir system such as this, there are only 6 lines that need to be set, which I've highlighted in bold below-


ch0->InputMode=NO_INPUT_MODE; Sets open loop mode
ch0->OutputMode=STEP_DIR_MODE; Sets Step dir output
ch0->Vel=40000; Sets maximum velocity
ch0->Accel=400000; Sets Acceleration
ch0->Jerk=4e+06; Sets Max Jerk
ch0->P=0;
ch0->I=0.01;
ch0->D=0;
ch0->FFAccel=0;
ch0->FFVel=0;
ch0->MaxI=200;
ch0->MaxErr=1e+06;
ch0->MaxOutput=200;
ch0->DeadBandGain=1;
ch0->DeadBandRange=0;
ch0->InputChan0=0;
ch0->InputChan1=0;
ch0->OutputChan0=12; Configures output mode (Step/dir, Quadrature, open collector, or actively driven)
ch0->OutputChan1=0;
ch0->MasterAxis=-1;
ch0->LimitSwitchOptions=0x100;
ch0->LimitSwitchNegBit=0;
ch0->LimitSwitchPosBit=0;
ch0->SoftLimitPos=1e+09;
ch0->SoftLimitNeg=-1e+09;
ch0->InputGain0=1;
ch0->InputGain1=1;
ch0->InputOffset0=0;
ch0->InputOffset1=0;
ch0->OutputGain=-1;
ch0->OutputOffset=0;
ch0->SlaveGain=1;
ch0->BacklashMode=BACKLASH_OFF;
ch0->BacklashAmount=0;
ch0->BacklashRate=0;
ch0->invDistPerCycle=1;
ch0->Lead=0;
ch0->MaxFollowingError=1000000000;
ch0->StepperAmplitude=20;

ch0->iir[0].B0=1;
ch0->iir[0].B1=0;
ch0->iir[0].B2=0;
ch0->iir[0].A1=0;
ch0->iir[0].A2=0;

ch0->iir[1].B0=1;
ch0->iir[1].B1=0;
ch0->iir[1].B2=0;
ch0->iir[1].A1=0;
ch0->iir[1].A2=0;

ch0->iir[2].B0=0.000768788;
ch0->iir[2].B1=0.00153758;
ch0->iir[2].B2=0.000768788;
ch0->iir[2].A1=1.92076;
ch0->iir[2].A2=-0.923833;

The lines in bold, are the keys ones. There are other options, like the limit switch options, soft limit, and backlash settings that can be used in open loop mode, but nearly everything else is servo tuning specific.
I'm guessing several people will be wondering what Jerk is. Well it's a limit on how quickly acceleration can be applied, and is defined in units per second per second per second. Using a basic non-jerk limited trajectory planner, you end up with a sharp start to acceleration, and a sharp stop to acceleration. On a graph plot showing that velocity, you end up with sharp corners during velocity changes. What Jerk does is round those corners, so you get smoother motion.

After the channel configuration data, you need to enable each channel/axis, which is a simple job using EnableAxis(n).

As I'm using Leadshine drives which have a relatively long pulse setup time requirement, the FPGA line stretches the standard KFlop step pulse length to meet this requirement.

Then we finally assign each channel to the relevant axis, using the DefineCoordSystem() function. It's simply in the order of X(0), Y(1), Z(2), and as we have to declare four axes, we simply set the unused A to -1. This function allows you to set whatever channel you want to any axis, and you can even change it on the fly, by simply running another program which redefines the coordinate system I.e for if you wanted to do something like change the spindle (which is not controlled by the coordinate system) to a A axis (which needs to be part of the coordinate system).
There are 6 and 8 axis versions of this function, so you can use any combination of X,Y,Z,A,B,C,U and/or V axes.

The final couple lines of code tell the KFlop there is a Konnect expansion board attached, and what address range to use for the Konnect inputs and outputs.

And that is a breakdown of a basic KFlop init.c file.
Off course, it's been expanded on, which I will try and cover in later posts.

Clive S
12-02-2017, 08:20 AM
Things like this would be nice to copy out to a tutorial section for future reference as stickies

JAZZCNC
12-02-2017, 10:27 AM
Not sure if this a good advert for Kflop or not.? Certainly not for the beginner.! But well written.

m_c
12-02-2017, 12:00 PM
Not sure if this a good advert for Kflop or not.? Certainly not for the beginner.! But well written.

It's certainly not a simple bit of kit, however I have seen a few complete beginners manage to get some quite complex systems up and running, with not that much help. It's one of those things, that if you want to learn how to get it working, you will, and you could say the same about most controllers if you've got no experience.

Saying that, this is one part of setting up that would really benefit from a video showing the actual process, as once you know the process, it's not that hard.
There are a few Dynomotion videos showing specific parts, or for specific boards. The KStep Introduction video, from 3:55 onwards shows the software process - https://www.youtube.com/watch?v=pW-9fDLAn2s

Edward
12-02-2017, 07:49 PM
Well, I use Kflop and I was a complete beginner, my only coding experience was with Arduino which operates on a kind of simplified version of C.

I first found it daunting. But I will say this, you don't really need to know the C language to make it work, you just need to apply a bit of common sense and spend time reading forum posts and reading the instructions. I requires real determination and patience and I fear that a lot of people will give up, which is a shame because it's a fantastic controller card.It's by no means a plug and play card.

My breakthrough was when a friend sent me a basic set up file for the three motors. Very basic, but enough to get the motors going. In fact, Kmotion already includes a simple configuration file that can be used. But it is a convoluted program, you have to go from one window to the other and then back again. For instance, if the axes are disabled due to an e-stop, you can't switch them back on from within the CNC program, you have to open another program to enable the axes back again. They should amalgamate the two main programs (KMotion and KMotionCNC) into one.

But, like a lot of applications, suddenly it all starts to click and make sense, and it is not difficult to add some lines of code to the basic init file as you build up the system.

There are quirks, for example, you don't upload to the drive, you download. To reverse motor direction you set up your Gain to -1....then most of the program settings are calculated in inches, although you can work in metric when it matters.

It is a very powerful and very stable controller, but it could do with some simplification for the novice, without losing the ability of tweaking and adding once you gain the experience. I think most Kflop users have needed some help at the beginning either from the very helpful owner or from other kind users.

As for Dean's comment, he is spot on, you need to put yourself on the side of the novice to understand that even the very detailed information in M_C's post is just too daunting and a lot of people will say, the hell with it, I want a controller that works first time without all that coding palaver!

Edward

m_c
14-02-2017, 12:51 AM
Well, I use Kflop and I was a complete beginner, my only coding experience was with Arduino which operates on a kind of simplified version of C.
Arduino uses C++ (C plus plus), which is a higher level version of C. The other major version of C is C# (C sharp), which is a higher level yet.
However they all use fairly similar coding techniques/layouts, so experience of any is a benefit.


My breakthrough was when a friend sent me a basic set up file for the three motors. Very basic, but enough to get the motors going. In fact, Kmotion already includes a simple configuration file that can be used. But it is a convoluted program, you have to go from one window to the other and then back again. For instance, if the axes are disabled due to an e-stop, you can't switch them back on from within the CNC program, you have to open another program to enable the axes back again. They should amalgamate the two main programs (KMotion and KMotionCNC) into one.

KMotion is solely for configuration. KFlops are not solely designed for CNC use, and KMotion contains the functionality to configure and program KFlops to run standalone, or via software.
KMotionCNC is just a PC program to use the KFlop as a more conventional CNC controller. The full source code is provided, so if you really want, you can edit the source and recompile it.

Dynomotion provide a pretty comprehensive library for creating your own software, along with example programs for all the possible software interfacing methods (A quick scan of the directory shows Virtual Basic, C, C#, LabView and Python). The only things that are not publically provided, are the base programming for the KFlop, and the source code for the firmware and the various DLLs/dotNet framework which provide the software interface.

The key to setup, is to get a basic init.c file created as quickly as possible, then add to it as you get things configured. Taking your example about re-enabling things after an EStop, you could create a very simple init.c that simply turns outputs back on. I didn't have that problem on this machine, as during setup the EM806 drives default to enabled, but it would be a simple case to add a SetBit(xx) command to your init.c to activate the output for your drive enable.
I'll expand more on the general C program framework I use for my machines when I get time, as all I've posted so far is the bare minimum to get machine movement. Things have expanded quite a bit since that basic file, as E Stop monitoring code and tool changer code has been added. I'll also discuss how I use the multiple program threads.


There are quirks, for example, you don't upload to the drive, you download. To reverse motor direction you set up your Gain to -1....then most of the program settings are calculated in inches, although you can work in metric when it matters.
The whole download/upload thing is actually quite common in the programming world, but there is no hard and fast way to know. My day job is dealing with vehicle diagnostics, and it can be a nightmare. Ford programming software you download software updates, and upload configuration data to ECUs. GM/Vauxhall you upload software to ECUs and store configuration data. Mercedes you download updates to ECUs, and then set parameters.
The best way to think of it is the KFlop is the server, so you're uploading to it, and downloading from it when dealing with motor parameters. Off course, then you download C programs when you want to run them..

The whole imperial thing is my biggest gripe with KMotionCNC. It's natively written around inches, so if you are going to be changing between metric and imperial, you have to allow for the fact that the tool table is unitless.

m_c
17-02-2017, 10:28 PM
So getting back to the mechanics, the spindle was stripped, and rebuilt with new bearings and fresh grease. I only took one photo of it, which is this one, showing the spindle removed, but the lower bearing, and lower bearing retainer still on the spindle.

https://c7.staticflickr.com/6/5624/30275686662_26ba535a00.jpg

The process goes something along the lines of-
Remove drawbar cylinder.
Unbolt top support bearing and housing, and extract using bolts into the threaded holes provided for the purpose.
Remove spindle motor and drive belt (you have to unbolt the motor to get the belt of)
Remove notched adjustment nut, along with locking tab ring.
Unbolt the lower spindle bearing retaining/seal plate.
Knock/press the spindle down out of the head assembly.
Pull the lower bearing of the spindle.
And reassemble in reverse.

After reassembly, you need to preload the bearings. The method used by Denford was to adjust by feel.
Now as I deal with things like this occasionally, I've got a reasonable idea of how a preloaded bearing should feel, but I'll give some tips for those who've never done it before.
Once you have the spindle assembled, with the adjustment nut on, nip the nut up. Then using a hammer and punch on the top face of the nut, give it a tap at various points around the nut. Nip the nut up again.
Now using a block of wood on the face of the spindle, give it a couple taps upward, before seeing if you can get anymore movement on the nut.
Repeat a couple times until you're happy things are settled, with no more movement on the nut.
What this does, is help ensure everything is seated correctly. Given the interference fit of parts, it's very possible that you could preload the bearings, but without something seated correctly. What that would mean, is that you rebuild everything, and then after a period of time (it could be after a few minutes, or even a few months), the whatever it is will settle in, your preload disappears and you end up with a load of spindle run out, where it's flapping around in the bearings.
At this point I gave the spindle a good few spins to help work the fresh grease out from the bearing tracks.

Now taking a DTI mounted on the head (so any movement in slides doesn't affect the reading) and set against the side of the spindle, using a best guess effort as too how much pressure the spindle is likely to see, I grab the top of the spindle and pull/push it in the direction of the DTI needle.
I then adjust up the lock nut until I'm getting minimal movement. I spin the spindle a few times, give things another tap with the hammer/punch/block of wood, and recheck. Once no more adjustment is needed, I spin the spindle by hand. I then adjust up the nut until I feel a very slight bit of springiness just as the spindle starts to move. Once again, I give everything a tap, and recheck. Once I'm happy, I bend a locking tab into a notch.

The real proof in whether you've got it right, is in the running.
Once you get the motor back on, you should run the spindle at a lowish speed (I opted for about 500rpm) for 10-15 minutes to let the grease work it's way out from the bearing tracks, while also monitoring the spindle temperature.
If you run the bearings too fast too soon, they can slide on the grease, which results in premature wear and even causing flat spots on the bearings, which will lead to vibrations and poor cutter finishes.
If everything sounds OK, gradually ramp the speed up, allowing maybe 5 minutes at every step (I went up in 500rpm steps), while monitoring the temperature. If you've got the preload within acceptable limits, after an hours running the spindle/housing should of warmed up, but you should still be able to keep your hand on it. If at any point you can't keep your hand on it, you've got too much preload, so stop it and slacken the adjustment nut of a notch. If on the hand it barely warms up, you've not got enough preload, which means you're most likely going to get a rubbish finish on parts as the spindle/cutter deflects while cutting.

m_c
19-02-2017, 04:25 PM
Now basic machine movement was possible, the next step was the tool changer.

First thing was to wire up the various sensors and relays, which brings me onto the subject of the possible methods for wiring up such things.
Do you switch the positive, or negative side of relays/solenoids?

As I'm using a Konnect board which has individual opto-isolated outputs cable of switching a fairly substantial load for an interface board (250mA @ 30V max), it gives a good amount of flexibility.
However, some controllers will have output banks grouped, and sharing positive supplies (likely to be described as PNP outputs), or sharing a negative supply (NPN style outputs).

Either will work, but switching the positive feed does usually provided an extra layer of safety. Should a wire short out to ground i.e. chaffs through on the chassis anywhere, then the output should just stop working. It may damage the output chip/transistor/FET on the board due to overloading the output, but at least whatever that output controls should stop working.
The flip side is if you were to switch the negative side, and the wire was to short out, whatever that output controlled would remain active.

And as we're on outputs, I'll cover inductive loads. An inductive load is pretty much anything that involves some form of electromagnet, which covers solenoids, relays, and motors.
These all provide a couple problems for controlling them. First, they will usually cause a surge of current on activation, usually followed by a voltage spike on deactivation.
A typical 250mA output will usually quite safely handle a standard icecube sized relay (IIRC they have a constant coil consumption of around 70mA at 24VDC). The switch on spike will be multiple times that, but for CNC use, this is the size of relay expected to be used for interfacing purposes.

However the bigger problem is during disconnection. When you disconnect a relay coil, the magnetic field not only quickly collapses, but as the solenoid moves back (remember a relay is essentially a solenoid operating a spring loaded switch), it also affects the magnetic field. Uncontrolled, this sudden change in magnetic field will cause a voltage peak of several times the rated relay coil voltage, with a reverse polarity of the voltage that was previously applied.
This surge can very quickly kill electronic outputs, but not only that, it will produce a spike of electrical noise.
The solution is simple. You add a reverse fly back protection diode to the relay coil terminals. This doesn't have to be anything fancy (I use 1N4007 - 1A 1000V rating as that's what I usually have in stock), and you connect it so that the cathode (end marked with a ring) is on the positive side of the coil. It should also be mounted as closely to the relay as possible, which is why they are rarely incorporated into the interface board.
During normal power, the diode does nothing, but when power is removed, and the reverse voltage spike starts to build up, the diode causes the energy spike to recirculate through the relay coil, where it will safely dissipate.

m_c
19-02-2017, 09:34 PM
So onto getting movement from the toolchanger.
I'll start with a short video showing that it does indeed function -

https://youtu.be/-1MxrLbhfTo

I'm sure toolchangers initially challenge the best programmers, but as with all things, you just need to figure out the process required to make it work, then convert that into some form of code that your controller of choice will understand.

First is working out the process. As at the time I had a Denford Novamill running on Denford's VRMilling software, I had access to the machine files for all their modern machines, which includes the Triac.
Buried in the relevant Triac file, were all the macros for running a fully kitted out Triac, including the toolchange code-



REM ~~~~~~~~~~~~~~~ Tool Changer Routines ~~~~~~~~~~~~~~

#ArmIn
GOSUB SpindleStop
IF !comms(10) THEN RETURN : REM ignore it if we're none ATC
IF !(OUT & 1) DO : REM Check spindle is stopped
OUT3 = 1 : REM Switch the solenoid
REPEAT : REM Wait for the IN switch (inverse logic)
UNTIL !IN0 OR STOPSW
WAIT = 500
ENDIF
RETURN

#ArmOut
IF !comms(10) THEN RETURN : REM ignore it if we're none ATC
OUT3 = 0: REM Switch the solenoid
REPEAT : REM Wait for the OUT switch (inverse logic)
UNTIL !IN1 OR STOPSW
WAIT = 500
RETURN

#ArmDown
IF !comms(10) THEN RETURN : REM ignore it if we're none ATC
IF !(OUT & 1) DO : REM Check spindle is stopped
OUT4 = 1 : REM Switch the solenoid
REPEAT : REM Wait for the DOWN switch (inverse logic)
UNTIL !IN3 OR STOPSW
WAIT = 500
ENDIF
RETURN

#ArmUp
IF !comms(10) THEN RETURN : REM ignore it if we're none ATC
OUT4 = 0: REM Switch the solenoid
REPEAT : REM Wait for the UP switch (inverse logic)
UNTIL !IN2 OR STOPSW
WAIT = 500
RETURN

#DrawbarUnClamp
IF !comms(10) THEN RETURN : REM ignore it if we're none ATC
IF !(OUT & 1) DO : REM Check spindle is stopped
OUT5 = 1
WAIT = 500
ENDIF
RETURN

#DrawbarClamp
IF !comms(10) THEN RETURN : REM ignore it if we're none ATC
OUT5 = 0
WAIT = 500
RETURN

#CarouselCW
IF !comms(10) THEN RETURN : REM ignore it if we're none ATC
IF !IN3 OR !IN1 DO :REM If arm is back or down
OUT7 = 1 : REM Set Direction Output
OUT6 = 1 : REM Set the Power output
WAIT = 50
REPEAT
UNTIL IN4 OR STOPSW
REPEAT
UNTIL !IN4 OR STOPSW
REPEAT
UNTIL IN4 OR STOPSW
REPEAT
UNTIL !IN4 OR STOPSW
WAIT = 40
OUT6 = 0
Pocket = Pocket + 1 : REM Inc the Pocket Counter
IF Pocket > MaxPockets THEN Pocket = 1
ENDIF
RETURN

#CarouselHalf
IF !comms(10) THEN RETURN : REM ignore it if we're none ATC
OUT7 = 1 : REM Set Direction Output
OUT6 = 1 : REM Set the Power output
WAIT = 50
REPEAT
UNTIL IN4 OR STOPSW
REPEAT
UNTIL !IN4 OR STOPSW
WAIT = 40
OUT6 = 0
RETURN

#CarouselCCW
IF !comms(10) THEN RETURN : REM ignore it if we're none ATC
IF !IN3 OR !IN1 DO :REM If arm is back or down
OUT7 = 0 : REM Set Direction Output
OUT6 = 1 : REM Set the Power output
WAIT = 50
REPEAT
UNTIL IN4 OR STOPSW
REPEAT
UNTIL !IN4 OR STOPSW
REPEAT
UNTIL IN4 OR STOPSW
REPEAT
UNTIL !IN4 OR STOPSW
WAIT = 40
OUT6 = 0
Pocket = Pocket - 1 : REM Dec the Pocket Counter
IF Pocket < 1 THEN Pocket = MaxPockets
ENDIF
RETURN

#toolChange
GOSUB SpindleStop
if !comms(10) THEN Pocket=Comms(7) : REM store last tool if not ATC
IF (comms(7) = Pocket) OR !comms(10) THEN RETURN : REM ignore it if we're already there or none ATC
IF !(OUT & 57) DO : REM If atc is back,Up and drawbar safe
IF STOPSW THEN RETURN
GOSUB ArmIn
IF STOPSW THEN RETURN
GOSUB DrawbarUnclamp
IF STOPSW THEN RETURN
GOSUB ArmDown

REM Calculate the shortest path...
steps = (comms(7) - Pocket + MaxPockets) MOD MaxPockets
IF steps > (MaxPockets / 2) DO
WHILE Pocket <> comms(7)
GOSUB CarouselCCW
ENDW
ELSE
WHILE Pocket <> comms(7)
GOSUB CarouselCW
ENDW
ENDIF

GOSUB ArmUp
IF STOPSW THEN RETURN
GOSUB DrawbarClamp
IF STOPSW THEN RETURN
GOSUB ArmOut
IF STOPSW THEN RETURN
ENDIF
RETURN

REM ~~~~~~~~~ End of Tool Changer Routines ~~~~~~~

The official language is Mint, which is specific to Baldor/Denstep controllers, but it's very Basic like, and I'm sure by reading through it, most people will be able to understand what's going on.
The basic process is-
Move arm in.
Activate drawbar.
Move arm down.
Rotate to next tool.
Move arm up.
Release drawbar.
Move arm out.

There are various delays involved at each step, but that's the basic process.

Now with a KFlop, there are a few different ways I could of implemented this, but I'd better explain how a KFlop runs user programs.
KFlop has 7 threads, where separate user programs can be run, each getting an equal slice of time when running (for those interested in the exact details, check here (http://dynomotion.com/Help/Multitasking.htm)).
This gives you a lot of flexibility. My basic init.c file, that will also monitors things like conditions for E-stops, soft limits, and button presses, runs continually in thread 1 (for those familiar with Mach, think of it like the macropump script).
I then have 3 homing programs (one for each axis), that when activated, each run in their own threads. This means I can start homing in any order, and all axes can be homing at the same time. I'm not restricted by them having to be done in any specific order (I could program that if I really wanted, and I may change to that for simplicity, but I'll stick to separate buttons for easy testing).

What this means, is for the toolchanger, I could simply create a program that runs in it's own thread, and does it's thing. However at some point I want to add external buttons to help with changing/setting tools, which using the separate thread method, would get quite messy, with very similar code being needed in various different programs.
The solution is to incorporate the main toolchange functionality into the main init.c thread that runs permanently, but that introduces a bit of a problem, in that it has to be programmed in a way that doesn't block the main thread execution.

Blocking is something you have to consider for any programming, and I'm sure some people are wondering what blocking is.
Using the tool changer as an example, after the arm moves in and the arm in switch is activated, there should be a 500mS delay before the drawbar is activated.
If you were to program using the following simple method-


Start toolchange
activate armin
when(arm in)
delay(500)
activate drawbar

(it's not in any specific language before anybody comments!)
While the toolchange is running, the program stalls, firstly while waiting for the arm in switch to become active, then again during the delay.
Now if this was the only thing running (i.e. I had put it in it's own thread), it wouldn't be a problem. However, as it's part of the main monitoring thread, that would result in nothing else being monitored until the toolchange had completed.
This is what blocking is. The program is stalled on a single line of code, until the condition is met to move to the next line.

So how do you avoid this?
A state machine.
Now I'm sure people are now wondering what a state machine is. In it's simplest form, it's the terminology used for a process that can be halted at any time, and then restarted from exactly from where it was halted.
To apply it to the example above, you'd end up with something like this-


variable state == idle;
variable delaytime;
if toolchange started{
activate arminoutput;
state = movearmin;
}
if state == movearmin{
if armin = true{
delaytime = currenttime + 500ms;
state = armindelay;
}
}
if state == armindelay{
if delaytime > delaytime{
activate drawbar;
state = releasingtool;
}
}
.
.
.
if state == toolchangecomplete{
state = idle;
}


As you'll see, it involves a lot more code, but the key thing is, the program is never blocked.
Looking at it in more detail, you start of with a state of idle.
There are no if statements, where idle is a requirement, so everything gets skipped over.
When you command a change, the armin output is activated, and the state changes to movearmin, and everything then gets skipped over.
On each loop of the code, the if state == movearmin, then tests to see if the arm is in, if it isn't, nothing happens and the program continues on it's merry way until the next loop, where it tests again.
Once the armin input is activated, it sets the delay time.
To do this, we use a variable to store the current time, plus the delay time, and then we update the state to armindelay.
Then on each loop, within the if state == armindelay code, we test to see if the delaytime is greater than the currenttime. If it doesn't, again nothing happens, and the program continues on it's way until the next loop, where it tests again.

Now hopefully that gives you a reasonable idea of what a state machine is. Now why put yourself through the pain of creating all that extra code?
Overall simplicity. I can add buttons that the KFlop monitors, which can be activated with no input needed from the PC to swap tools, (off course various safety checks also need to be applied to ensure you can't don't when you really don't want to), and it means should something go wrong mid change, I know exactly where, and things can be resumed easily.

And for those wondering what the current code looks like, here's the first version that just provides enough functionality to carry out a tool change. I used one of the Dynomotion example files as a basis for this, and instead of using a series of If statements, it uses a Switch with Case statements.

#include "KMotionDef.h"
#include "Triac.h"

// Services Tool Changer using non-blocking State Machine approach
// The Service routines maintain their state so they can always return
// immediately and later resume from their previous state.

// T O O L C H A N G E R S E Q U E N C E
//
// define state that the tool changer may be in

#define TOOL_CLAMP_BIT 20 // IO bit number to clamp turret
#define TOOL_DIST 4250.0 // Steps/counts to move turret to next tool
#define CLAMP_TIME 1.5 // seconds to wait for the clamp/unclamp

#define TOOLPOCKETS 6 // Number of tool pockets
#define TURRET_AXIS 2 // axis channel for the turret motor
#define CRSLIN_DELAY 0.5 // seconds to delay after carousel in switch triggered
#define CRSLDN_DELAY 0.5 // seconds to delay after carousel down switch triggered
#define DRBUNCLAMP_DELAY 0.5 // seconds to wait for unclamp
#define CRSLSTOP_DELAY 0.04 // Seconds to wait before stopping carousel
#define CRSLUP_DELAY 0.5 // seconds to delay after carousel up switch triggered
#define DRBCLAMP_DELAY 0.5 // seconds to delay after drawbar clamped
#define CRSLOUT_DELAY 0.5 // seconds to delay after carousel out switch triggered
#define CRSLIDX_DEBOUNCE 0.3 //

int *ChangerState = &persist.UserData[TOOL_STATE_VAR];
int *Tool = &persist.UserData[TOOL_VAR];
int *LastTool = &persist.UserData[LAST_TOOL_VAR];

double ToolTime; // used for non blocking time delays
double PrintTime;
int ToolPockets; // used to store number of tool pockets still to move
int CrslDir; // use to remember what direction to turn carousel
int IndexState; // use this to track if we're waiting for index to go high or low

// Services Tool Change Sequence
void ServiceToolChange(void)
{
if(Time_sec() > PrintTime){
//printf(" ChangerState=%d\n",*ChangerState);
//printf("Current Tool=%d, toolpockets=%d\n",*Tool, ToolPockets);

PrintTime = Time_sec() + 2;
}
switch (*ChangerState)
{
case T_IDLE:
{
break;
}
case T_START:
{
if (*LastTool==0)
{
printf("Error Turret Position Never defined\n");
*ChangerState = T_IDLE; // go idle
}
else if (*Tool > TOOLPOCKETS || *Tool < 1)
// is requested tool valid?
{
printf("Invalid Tool Number %d\n",*Tool);
*ChangerState = T_IDLE; // go idle
}
else if(*LastTool == *Tool)
// is requested tool already in spindle?
{
printf("Requested tool already in spindle\n");
*ChangerState = T_IDLE;
}
else
{
printf("Move Z to toolchange height\n");
Move(Z,TCZHEIGHT); // Move Z to required height
*ChangerState = T_CRSLIN;
}
break;
}
case T_CRSLIN:
{
if(CheckDone(Z))
// once Z at height, move arm in
{
SetBit(CRSLINR);
if(ReadBit(CRSLIN))
{
printf("Move carousel In\n");
ToolTime = Time_sec() + CRSLIN_DELAY; // wait until this time
*ChangerState = T_DBUNCLAMP;
}
}
break;
}
case T_DBUNCLAMP:
{
// wait for time delay for carousel to settle
if (Time_sec() > ToolTime)
{
printf("Unclamp Tool\n");
SetBit(DRBR);
ToolTime = Time_sec() + DRBUNCLAMP_DELAY;
*ChangerState = T_CRSLDOWN;
}
break;
}
case T_CRSLDOWN:
{
if (Time_sec() > ToolTime)
{
SetBit(CRSLDWNR);
if(ReadBit(CRSLDWN))
{
printf("Move carousel down\n");
ToolTime = Time_sec() + CRSLDN_DELAY;
*ChangerState = T_CRSLROTATE;
}
}
break;
}
case T_CRSLROTATE:
{
if (Time_sec() > ToolTime)
{
// compute shortest rotation direction
ToolPockets = (*Tool - *LastTool + TOOLPOCKETS) % TOOLPOCKETS;
printf("ToolPockets pre direction = %d\n", ToolPockets);

if(ToolPockets < (TOOLPOCKETS / 2))
{
CrslDir = T_CW;
IndexState = T_IDX_HIGH;
ToolPockets = ToolPockets*2; // multiply tool positions by 2, as we need 2 revolutions per tool pocket
printf("Rotate CW %d steps, from %d to %d\n", ToolPockets, *LastTool, *Tool);
*ChangerState = T_CRSLRUN;
} else {
CrslDir = T_CCW;
IndexState = T_IDX_HIGH;
ToolPockets = (TOOLPOCKETS - ToolPockets)*2;
printf("Rotate CCW %d steps, from %d to %d\n", ToolPockets, *LastTool, *Tool);
*ChangerState = T_CRSLRUN;
}
}
break;
}
case T_CRSLRUN:
{
if(CrslDir == T_CW) SetBit(CRSLREV); // if we need CCW, enable CCW relay
SetBit(CRSLRUN); // and enable run relay
if(IndexState == T_IDX_HIGH && (Time_sec() > ToolTime)) // wait for index to go low
{
if(ReadBit(CRSLIDX)){ // when index goes low
printf("Index High\n");
printf("Time_sec=%f\n",Time_sec());
ToolTime = Time_sec() + CRSLIDX_DEBOUNCE;
IndexState = T_IDX_LOW; // we now need to wait for index to go high
}
}
else if(IndexState == T_IDX_LOW)
{
if(!ReadBit(CRSLIDX) && (Time_sec() > ToolTime))
{ // when index goes high
if(ToolPockets > 1)
{ // if we still need to move
ToolPockets--; // reduce counter by one
printf("ToolPockets=%d\n",ToolPockets);
ToolTime = Time_sec() + CRSLIDX_DEBOUNCE;
IndexState = T_IDX_HIGH; // and reset state so we continue
} else { // else we've reached the required position
printf("ToolPockets=%d\n",ToolPockets);
ToolTime = Time_sec() + CRSLSTOP_DELAY; // so set stop time delay
*ChangerState = T_CRSLUP; // and move onto next stage
}
}
}
break;
}
case T_CRSLUP:
{
if (Time_sec() > ToolTime)
{
//printf("Carousel Stopped\n");
ClearBit(CRSLRUN); // once timer elapsed, disable all rotation
ClearBit(CRSLREV);
ClearBit(CRSLDWNR); // disable down relay so carousel moves up
if(ReadBit(CRSLUP))
{
ToolTime = Time_sec() + CRSLUP_DELAY; // set delay and move onto next stage
*ChangerState = T_DBCLAMP;
}
}
break;
}
case T_DBCLAMP:
{
if(Time_sec() > ToolTime)
{
ClearBit(DRBR);
ToolTime = Time_sec() + DRBCLAMP_DELAY;
*ChangerState = T_CRSLOUT;
}
break;
}
case T_CRSLOUT:
{
if(Time_sec() > ToolTime)
{
ClearBit(CRSLINR);
if(ReadBit(CRSLOUT))
{ // when carousle out switch triggered
ToolTime = Time_sec() + CRSLOUT_DELAY; // set delay and move to next stage
*ChangerState = T_END;
}
}
break;
}
case T_END:
{
if(Time_sec() > ToolTime)
{
printf("Tool Change Complete\n");
*LastTool = *Tool; // remember where we are
*ChangerState = T_IDLE;
}
break;
}
}
}



This will be altered again, as it won't quite do what I'd like it do in it's current form, but it gives you an idea of the code required. There are also a few coding practises I'll discuss in another post.

m_c
17-03-2017, 12:43 AM
And now to jump back to the spindle, the motor or drive has started to die. I had been considering swapping to a servo, so this has hastened that process. However, for those with experience of Triac's, space is quite limited.

After a bit umming and arring, some measuring, some head scratching, and some mock up in Fusion360 (my first real project with it - it doesn't seem to have as nice a workflow as Solidworks, but that's currently on a computer buried in a corner), a 110 frame 1.25KW servo has been ordered.
This diagram shows the required mounting position to make it fit -

21137

As you can see, the motor has to be mounted above the head casting, so I need a spacer of about 130mm, which still puts the total height at less than the original motor. At the moment, I'm still bouncing ideas around in my head for the exact design.
My current thought until tonight, is a bit 100mm round bit steel, single bearing for support at the bottom, a rigidly mounted shaft extension on the servo, lots of the bar hollowed out, and servo mounting plate bolted on top.

I've gone through various design options.
I had thought about a welded construction, but that would introduce distortion. A flexible coupler would handle that, but then the extension shaft would have to be fully supported (i.e. lower bearing housing made about 70mm high for good support). At which point I'd be as well making the spacer from a solid bit bar and using a rigid shaft extension, so only a single bearing is needed for support.

Now tonight's thought was why not use aluminium, but then thermal expansion comes into play. Assuming a worst case temperature change of 40deg, that equates to about 0.11mm of expansion difference between steel and aluminium over the 130mm length.
Doesn't sound like much, but more than enough to put lots of pressure on bearings. Ideally I want bearings/shafts a good interference fit to avoid wear from them moving against each other.
But by using aluminium I could go back to a fully supported lower shaft with a flexible coupler. I've got 100mm diameter steel and alu available.

Weight isn't really an issue, as provided I don't go too daft, the new servo is over 6KG lighter than the DC motor, so either option would reduce weight.
Using steel, a rough guestimate weight with only moderate material removal is less than 4KG, but with a bit thought, I think I should get it under 2KG.
Aluminium should be well under 2KG, and would give better heat distribution, but the fully supported shaft adds a bit complexity to machining.

I've got a few more days to ponder this, as the servo isn't expected until next week at the earliest, but comments from others would be appreciated.

Clive S
17-03-2017, 07:52 AM
The attachment link seems not to work for me (Invalid Attachment specified)

m_c
17-03-2017, 09:31 AM
The attachment link seems not to work for me (Invalid Attachment specified)

Ooops. Should be fixed now.

m_c
21-03-2017, 02:41 PM
A bit more measuring, head scratching, double/triple checking measurements, and I finally have a firm plan-
21204

100mm diameter aluminium, machined and mounted to the original motor mounting plate, via the original countersunk bolts. The spacer contains two 6004 bearings to support a new drive shaft, which gets connected to the new servo via a flexible coupling. I would of preferred a smaller coupling, but the next smaller option was rated at less than the servos instantaneous torque, where as this one is rated at 2-3x the instantaneous with double that again for maximum torque.
There will then be a 15mm thick adapter plate bolted to the spacer, that provides something for the servo to bolt on to.

I started on the aluminium bar last night, and it so far has a big hole drilled through it, so now I have the final dimensions, I'm off to spin some dials for a while.

m_c
30-06-2017, 09:28 PM
https://farm5.staticflickr.com/4282/35248523870_466b2765eb_z.jpg
The enclosure finally went back on a couple nights ago :-)

There was a bit of a delay getting the servo for the spindle, which meant it got delivered just as I entered my crazy time of year for events, and business sales were higher than normal, so I never had much time to work on it.

The spindle mount was done ye olde fashioned way on the manual lathe. I started with a bit 4" round alu, and after a bit time spent spinning handles, resulted in lots of swarf -
https://farm4.staticflickr.com/3932/33230067580_b26515d6b7_z.jpg

A 110mm square plate was cut and then turned to create a flange on one side to fit the spacer, and a recess on the other to fit the servo. It was then drilled and counterbored to accept 8 M5 bolts. 4 would of done, but 8 looked better!
The mount was then test fitted -
https://farm3.staticflickr.com/2930/33631077875_c46aecb2d8_z.jpg

Things then stalled waiting for the servo motor, but when it arrived, assembly could begin in earnest.
The extension shaft was cut to length, and a circlip groove machined in to locate it in the bearings. The flexible coupler was then installed -
https://farm5.staticflickr.com/4241/35414982486_9942a22d8c_z.jpg

And a new taperlock timing pulley on the opposite end-
https://farm5.staticflickr.com/4216/34645154383_d0cc8f9355_z.jpg

It was then bolted to the machine, and the servo attached-
https://farm5.staticflickr.com/4288/35454919515_d0d3b5cbc2_z.jpg

The whole assembly sits at roughly the same height as the original servo, and the only modification required to the cover, was a hole cut in the side for the servo cable connections, which can be seen in the first photo. I'll get a cover made up for them at some point, but I want to work the machine for a while first to monitor how hot the servo gets, as I may add a cooling fan.

It was then a case of wiring and tuning, which I'll save for another post.

m_c
28-11-2017, 06:39 PM
I know I've been ignoring this for a while, but since the control cabinet build is finally underway, I may as well add it in here.

https://farm5.staticflickr.com/4548/38671964152_78ef1e7a7c_c.jpg

After a few ideas were bounced around, a couple sketches done, and a mock-up of the controls (http://www.mycncuk.com/threads/11431-Control-Panel-nearly-done%21)done, I had a bit of eureka moment. Rather than build from scratch, why not use a bog standard enclosure and modify it to suit. That way much of the faffing around with sheet metal is removed.

The above is a 400x300x150 box. I was originally going to mount everything on the back plate (the bog standard steel one will be getting binned, for a thicker aluminium one), however things were going to be a bit too tight, especially considering I need two 25pin breakout boards for all the required ins/outs, so the computer will quite easily mount on the door (it's easier to run 4 cables between the door and body, than 30+ individual ones if I was to mount the breakout boards). I did briefly consider hardwiring things, but 25pin cables are cheap and convenient, and the breakout boards give easy access for future diagnostics.

All that will connect between this box and the main control cabinet will be the two 25pin cables, and a USB cable. Power will be supplied directly.

Now just to drill a few holes, cut some metal, and do a bit welding..

m_c
26-12-2017, 04:55 PM
Since I'm still waiting for the rowing boat to arrive from China with a couple key parts for the control housing, I'm sat here contemplating how I'm going to wire a touch probe in, and it's got me back to thinking about tool changes.

The toolchanger has been working well. I still need to create a recovery/setup screen in KMotionCNC, so I can control it directly from KMCNC, rather than having to toggle things manually should things go wrong (what I really mean is when I screw up the toolchange position, and send toolholders flying in various directions, or jam the carousel against the workpiece...).

Like most CNC programs, KMCNC has a tool table. For every tool you can set the usual offsets, toolID, a description, image file (for if you want an accurate image shown in the viewer) and a Slot.
For a toolchanger, the slot is key. When you request a toolchange in G-code, KMCNC looks for that in the ToolID column, then tells the KFlop to load the tool in the corresponding slot. Off course, it's up to the operator to ensure the correct tool is in the correct slot.
This means you can have multiple tools stored along with their offsets, and when you load the tools into the carousel, KMCNC already knows the offsets, and all you have to do is update the slot ID.

What this also does, is give the ability to control how tool changes are handled.
I've written my changer code, so a request for slot 1-6, results in a fully automatic tool change. Then anything above 6 through to 98, results in a manual tool change, then 99 simply unloads the spindle.
Everything is tracked, so if I go from say slot 3 to 50, it'll automatically unload the tool, retract the tool carousel, and then ask the operator to insert tool 50. Or going back the way, it'll ask the operator to remove the tool, confirm it's been removed, then bring the carousel back out and load tool 3.

Now what's this got to do with a touch probe, other than needing to load it manually?
I'm going to allocate an additional series of slots (probably 95-98), which will get handled differently, and will cause the spindle to align to a known position (index mark on servo) to maximise repeatability, and prevent it from running (you really don't want your touchprobe in a spinning spindle while plugged in...).
Plus I can then force all moves while a touchprobe is loaded, to be protected moves. By protected, it means if the touchprobe gets triggered, all motion is halted, as though you were performing a G31 probing move. It probably won't stop things getting damaged at full speed rapids (I'll probably also add a feedrate override to limit rapid speeds), but it should stop issues like jogging the probe into things stronger than the probe.

Now I'm of to stare blankly at my toolchange code, and think about how I can implement this..