Improving homing accuracy on the Linuxcnc Bantam lathe?

Recently I've been messing with the CNC-converted Bantam lathe. This uses the Probe Basic Lathe GUI and I've been beta testing an add-in component that provides a conversational interface, for when you want to run fairly simple operations without needing to create full blown CAM toolpaths in Fusion.

The author (Chris Polanski) suggested I look at using the index pulses from the servo drive to improve accuracy of homing. Currently I have a proximity switch on the Z axis and a microswitch on the X axis but I know these have rather limited accuracy and repeatability. Given the state of the machine, that's not been an issue to date, not least due to my limited use of the thing. However, as I have closed loop positional control based on feedback from linear encoders, it seems a shame not to improve what is the main weakness in this setup. 

This is a well established concept - on the face of it, you hit the home switch, then look at the status of the Z (index) output from the servo drive. This output is software generated within the FPGA and can be scaled to suit your system. So no matter what the resolution of the encoder within the servo motor, you can generate and output the output pulse per rev (PPR) that suits your installation. This also outputs the "index" pulse that indicates when the motor has made one complete revolution.

The problem here is that LinuxCNC expects the index pulse to come from the same source (encoder) as the position signal. Trying to use the position info from a linear encoder along with the index pulse from the servo isn't quite as straightforward as you might hope.

Rather than try to "research" this subject myself, hoping to learn from other peoples' struggles, I thought I'd ask my mate Claude to do some legwork. I got the responses formatted for Blogger, since Blogger doesn't retain formatting when you try to copy and paste from a Claude chat session - and here they are:

Homing a CNC lathe on servo-drive index pulses (LinuxCNC)

Setup: linear encoders on X/Z for closed-loop feedback, no index output on the scales themselves, homing currently done with microswitches. Servo drives do provide Z (index) outputs. Controller: LinuxCNC on Mesa 5i25 + 7i76 + 7i85.

Why this is harder than it looks

1. Index detection has to happen in hardware, not software. An index/Z pulse is too narrow to be reliably caught by LinuxCNC's servo/base thread polling a GPIO — it has to be latched by a hardware encoder counter (e.g. on a Mesa FPGA card).
2. LinuxCNC's standard homing assumes the index belongs to the same counter as position feedback. In this setup the index comes from the drive's motor-side encoder, while position feedback comes from an independent linear scale — two different physical devices.
3. The drive's index repeats every motor revolution, not once per axis stroke, so it can't be an absolute reference by itself — a microswitch is still needed to select the correct revolution before latching to index for fine repeatability.
4. Gating nuance: hardware encoder counters typically only latch index when A/B are in a defined state, which normally assumes A, B, and Z all come from the same device.

Prior art

• Homing on Linear Scale Index
• Index pulse home — same problem: servo drive index, no encoder wired for position
• Help please - Linear Scale only homing
• LinuxCNC Homing Configuration docs
• Fail to homing (mechanical switch + index pulse) — contains a working solution, see below

The working approach: gate the switch with the index, don't cross-correct positions

You don't need to reconcile the drive's index position with the linear scale's count. LinuxCNC's normal HOME_USE_SWITCH homing already captures the joint's real position feedback (the linear scale) at the instant home-sw-in transitions. The drive index just needs to produce one clean, hardware-latched, repeatable edge to replace the mechanical switch's mushy trip point.

A small halcompile component from the LinuxCNC forum does exactly this, confirmed working by multiple users (one reported repeatability to 1.5 tenths / 0.00015" / 3.8um):

component index_toggle "extends the limit switch area to the next index pulse";
pin io bit index-enable "connect to the index-enable of an encoder counter";
pin in bit home-sw-in "connect to the home switch input pin";
pin out bit home-sw-out "connect to the motion controller home switch input";
function _;
license "GPL";
;;
static int old_sw = 0;
if ((!old_sw) && home_sw_in) index_enable = 1;
home_sw_out = index_enable;
old_sw = home_sw_in;

Install with:

sudo halcompile --install index_toggle.comp

Logic: when the microswitch trips (rising edge), it arms index-enable on a spare encoder counter. The hardware counter auto-clears index-enable the instant it sees the next index pulse. home-sw-out mirrors index-enable, so the motion controller sees a clean transition timed to the hardware-latched index event instead of switch bounce.

Why the 5i25 + 7i76 + 7i85 stack fits well

The 7i85 provides 4 differential/TTL-selectable encoder channels. If the two linear scales already occupy channels 0/1, channels 2/3 are free — wire each drive's index (Z) output there. Since index_toggle only cares about the index-enable/detect event, that channel doesn't need to carry real position feedback; it's purely a trigger source.

Gotchas to plan for

• A/B gating on the index — wire the drive's full A/B/Z encoder-follower output into the spare 7i85 channel, even though its count is ignored, so the index gate condition is satisfied cleanly.
• Signal type match — confirm whether the drives' encoder-follower output is differential RS422 or single-ended TTL/open-collector and set the 7i85 channel mode accordingly.
• Stale index-enable state — one forum user saw the axis home to its power-up position instead of true home, traced to a stale latch rather than a fresh index event; verify in HalScope.
• Switch bounce — a bouncy microswitch could re-arm index-enable early; a debounce or tof component ahead of home-sw-in is cheap insurance.
• Use HOME_USE_SWITCH, not HOME_USE_INDEX — since the trigger arrives via home-sw-in, configure normal switch-based homing in the INI, not the same-device index mechanism.

Where are we today?

Before getting totally carried away with this business, let's just see where we are starting from today.

Using a decent (Mitutoyo) 10um DTI, I find that ~90% of X homing moves result in a positional accuracy of around 1-2um (the needle is barely off the zero mark) - and the remaining ~10% are out by +5um, which is the minimum incremental move that my machine can make due to the linear encoder resolution. The homing switch in this axis is a reasonably decent quality microswitch. I'm happy with that result, so should let that particular sleeping dog lie.

The Z axis is a different matter, as I chose to use an Omron proximity switch for homing, despite them not really being appropriate for precision homing. And sure enough, the home position typically varies by around 30-40um, which is pretty shit.

This sounds like an ideal application for "homing to index marker", using the servo motor's encoder index. As the leadscrew pitch is 5mm and the belt reduction is less than 2:1, I should be able to significantly improve the homing accuracy. So it perhaps makes sense to implement this method on the Z axis but not bother on the X axis. No point making unnecessary work for myself.

And another thing - placing those proximity sensors face up like this, just below the toolpost doesn't get much dumber. As you can see (if you look closely), they form a nice ledge for swarf to land and trip the limit switch (the LH one). At which point the machine stops, as it should when the axis limit is exceeded.

For now, I may simply disconnect the Zlim switch but should also check what happens if the Zhome switch is triggered during operation. And the longer term solution requires some form of shielding to keep swarf away from these devices. That could simply be a bit of bent sheet metal attached to the underside of the carriage.

Let's have a go at implementing this idex mark scheme on the Z axis....

Plumbing the depths

Our Worcester Bosch 440 High Capacity boiler stopped working this morning, just after lunch. Code D5 means the condensate pump isn't functioning correctly, either due to a blocked pipe or some issue with the pump itself. This pump has a reservoir that collects the condensation from the primary heat exchanger (gas flame), then periodically discharges itself via a small pipe that ends in a drain outside the house.

The Worcester Bosch 440 High Capacity installation manual is pretty comprehensive and well written and includes a good parts lost, various exploded views and installation / replacement instructions.

The HC models have a "heat store" (item #44) ie a mini hot water tank (45 litres / 10 gallons), as well as a larger water-to-water heat exchanger (item #17) that allegedly allows more than one bath or shower to be used simultaneously. Consequently, it's a floor standing device, rather than the more normal wall mounted installation.

This thing is 10 years old now, so perhaps the pump is getting a bit long in the tooth. I've also bought a replacement water-to-water heat exchanger (item #17), as I'm not convinced it's working quite as it used to. Finally, I've got an auto bleed valve for the heatstore (item #42), as the original shows signs of leakage. They all weep to some degree but as they are pretty cheap, it's something to be done when the thing is drained down and in pieces.

Let's go. The control panel and bladder (the orange pressurised tank) both swing out of the way on hinges:

The pump is the off white box at top left with the clear-ish hose emerging on the top. When powered up, it shows a constant red LED indicating a problem "not emptying" issue.

A bit of a fiddle to extract but here's what you find. The lid just lifts off. There's a float (back left) with a Hall sensor to detect when the tank is full. Then there's a tiny pump hidden under the removable cover at the front, driven contactlessly through the plastic body.

The 240V power and the level switch (or possibly status output) come to the cotrol board through this array of cable grips.

Sensor / status input to the control board:

240V input, including protective earth. The cowboy plumbers who originally installed the boiler had barely trapped any of the conductor under the clamp. It's a good thing they had done their "competent person" training that allows them to do electrical installation work. I replaced the entire cable and used ferrule crimps.

Here's the original shitty mains wiring, although it's hard to see what is happening here. Take my word for it though - it's not pretty.

The old and new pumps are absolutely identical. Even though their date codes differ by almost a decade, the version number is the same and the manufacturer's name is show on the PCBA (Xylem).

Here's the puny motor.

It has a special connector for the Glow Worm control board.

The Glow Worm cable actually has 3 connections but one is just live with a resistor. Cut them off and you have the same terminations.

I'll be swapping out this heat exchanger while I'm at it.

And the auto bleeder that sits on top of the heat store. Getting it off wasn't easy, as the thread was stiff and spanner access was limited.

All done. Connected back up, refilled and powered up. Result.

Machining the ballnut bracket using Probe Basic Lathe conversational

I cut the stock to size previously, so just need to centre it in the 4-jaw and drill the 25.5mm pilot drill ahead of sending the boring bar in.

I've not used the DTI directly in a centre hole before. It's strictly approved to do this, as the probe tip can only move in one plane but once the workpiece is close, this works well. Besides, I'm just blasting a hole in some steel. Despite that, I seem to have got it within about 40um total runout

I've put some polycarbonate shielding around the work area so I don't get hurt again.

And - in with the big fatty, following a 10mm pilot:

Now to set up a new (bigger, fatter) boring bar. I used a girlie 12mm SCLCR with a CCMT06 insert last time but now I will be using a 20mm SCLCR with a bigger CCMT09 insert. The approved workflow is to create the tool in Fusion, then import it into Linuxcnc as a json file. This includes all the dimensions for the bar, insert, tool angles etc, which are used in the conversational add-in to do sanity / safety checks.

Ready to run the conversational boring operation now. We'll have a go at that next time.....

Machining the ballscrew and setting up the 4th axis to machine hex flats

Need to machine down one end of the SFU3205 (32mm dia, 5mm pitch, single ballnut) ballscrew to fit the thrust bearing (25mm through bore) and put some flats on it so I can drive it with a 17mm socket and cordless screwdriver or impact driver. Firstly, the bearing fit and the major diameter for the hex.

Got the ballscrew set up in the Tree CNC lathe, which has a 2" through bore in the spindle. This is hardened Chinesium steel, so could be hard on the insert. Using a Korloy trigon insert that should be reasonably robust. Furthermore, it's double sided, so I get 6 tips per insert and even if I nadger a few of them, it's no big deal. These inserts only cost me ~£3 each - 50p a corner.

Off we go. 

Ooof. I was a bit ambitious / aggressive with the speeds and feeds (1mm DOC, 0.1mm/rev and 100m/min). Although these values accord with the manufacturer's recommendation, they probably didn't anticipate dealing with hardened steel with interrupted cuts. Either way, the tip fractured, the axial cutting force went up and the stock slipped back in the chuck. The chuck key is cleverly designed to make it difficult to use an extension to overtighten - and it was about as tight as it would go. It wasn't a matter of not tightening it up properly.

Reduced to 0.25mm DOC, 0.05mm/rev and the same 100m/min constant surface speed:

That worked out better:

And a manually machined a 2mm groove for a circlip:

I managed to not cock up the position of the groove:

Machining hex flats on the ballscrew:

I recently upgraded the CNC12 software used on the Tree lathe but it seems I didn't bother to set up the 4th axis. NVM - I still had the previous installations to refer back to and was able to read off the appropriate parameters. There's actually a blog page from back in July 2020 that shows the correct values when I was setting up the Yaskawa Sigma servo drive that drives the 4th axis. It uses a belt reduction and a harmonic drive, so the overall reduction ratio is a calculated value built in to the servo drive setup.

And yes, the 4th axis has a sufficiently large diameter through bore to take the 32mm ballscrew. I'll just machine those flats manually, rather than bugger about generating toolpaths in Fusion. Currently I have a 19.3mm diameter boss end (fnaaaar!) and require 17mm a/f, ie touch off and descend 1.15mm, then rotate 60 degrees, repeat 5 more times etc. 

The circumscribed circle of a regular hexagon with a 17mm inscribed diameter is approximately 19.63mm or exactly 34 / SQRT(3). I've deliberately reduced that OD by 0.33mm so that I don't have sharp edges - sockets don't have them.

50mm face mill with APMT inserts:

Looks good. 2 passes, total 1.15mm stepdown:

Socket is a good loose fit:

Flats are 17mm a/f as good as dammit:

It's still pretty hard, even several mm down. It's obvs through hardened, not just surface hardened. Took a bit of work with a fine file to debur the edges but it's looking good now.

All done and back in its bag for now. 

I need to machine up the thrust brackets for this bearing and the ballnut now.

"Hydraulic pump" issue fixed - senior moment!

Here's another illustration of the danger of letting The Stupid Fat Bloke loose in the workshop. As well as being the kind of idiot who knows it all and rushes in to do shit without thinking things through, he's also prone to simply forgetting simple things. He should be called The Stupid Old Fat Bloke.

The issue with the Tree installation isn't anything to do with the hydraulic pump motor or indeed a failure in any of the other mains powered components. It's simply because said SFB forgot to plug in the mains isolation transformer.

The issue is that I have a series of converters and inverters and EMC filters all leaking current into the chassis. Mainly, this is through their Y caps but also through the insulation in the motors, solenoids etc. Given that the consumer units in the house are mandated to have 30mA RCDs, there's a limit to how much cumulative Y caps can be tolerated before nuisance tripping becomes a major issue.

The mains in the UK seems to be climbing ever higher these days. I'm measuring 256Vrms on several DVMs and short of examining the actual waveform with a scope, I have no reason not to believe that's what we are seeing. This raises the leakage current from the nominal, which I think (from memory) is specified at nominal voltage.

The current is a Y cap with 230Vac across it is  

I = 2 πfCV         (where f = 50Hz & V = 230Vrms)

So, if we were to run leakage of 30mA entirely down to the Y capacitance, we'd be able to tolerate a value of ~415nF. Of course, that would be pretty stupid as it would allow no additional leakage anywhere downstream of the workshop consumer unit RCD.

Here's the Schaffner EMC filter that comes with the spindle VFD, which is a 4kW Yaskawa GA500:

They estimate ~5mA leakage for this filter. There's also some Y cap in the VFD itself. In the manual for the GA500, it says "If you turn on the internal EMC filter, the leakage current of the drive will be more than 3.5 mA"

"Use a high frequency RCM/RCD at the power input side of the drive and make sure that each drive has a minimum cumulative sensitivity amperage of 30 mA. The specialized breaker detects only the leakage current from frequency bands that are dangerous to humans.

If a device does not have protection against high frequencies, high frequency leakage currents can cause the device to malfunction. If you have a malfunction on a device that is not protected, decrease the carrier frequency of the drive, switch to a better breaker, or use an RCM/RCD with a minimum cumulative sensitivity amperage of 200 mA for each drive."

There's no mention of filter compt values or leakage currents in the Lichuan servo drives. The Meanwell SMPS PSUs claim <2mA each at 240V (there are 2 of them). 

Bottom line - measuring the capacitance between live and ground suggests a total of around 850-900nF, which will deliver a leakage current that is well above that nominal 30mA threshold. A measurement from neutral to ground wouldn't be relevant, as neutral is held at ground, so shouldn't normally be causing any significant leakage.

My solution to this was to run the lathe from an 230:230V isolation ("site") transformer - with a strong earth bond of course. Then, any leakage within the installation would be isolated from the workshop consumer unit.

What Fat Boy forgot to do was install that isolation transformer between the wall socket and the machine. It got misplaced when the machine was last moved a few months ago. This realisation struck me during the night (as it does) and today I've gone about convincing myself if / that this is what the issue was. After some buggering about with insulation and continuity testers, it's clearly what the problem was. With the transformer back in circuit, everything is fine. 

What now, Fatty?

So now, I have to reconnect the hydraulic pump assembly and and refit it into the machine. No harm done (hopefully I haven't nadgered any of the venerable hoses) but at least I know the thing appears to be in a reasonable state - and understand what I'm looking at.

Hydraulic pump repair or electrical issue? Tree CNC lathe tripping breakers

When I enable the circuit that powers the VFDs and servos, I'm finding that the main MCB and/or RCD trip. This seems to have been an intermittent feature of the hydraulic pump for some time now, as far as I could tell. But now I can't even get it to power up regardless. What's going on here - time to get to the bottom of it.

I reckon it's likely to be the pump motor. And access to the VFD wiring is a bit of a PITA, so perhaps the thing to do is simply remove the hydraulic "power pack" and see what's up - assuming that's there the problem is. Besides, I'd like to have a closer look at this part of the machine. (More later!!)

The front fixings for the oil tank are easily accessible. I hope TF there aren't any rear fixings, as this thing is tight against the wall and weighs several tonnes (thought to be around 3).

By stretching my arm to the back, I can see where any rear screws would be. Can't see anything, as it's too dark. Getting in to that area would be an absolute nightmare. The machine frame is solid cast iron with only a few apertures, mostly internal at that.

If I remove that adjustable foot bolt thing, perhaps the tank will pull clear?

Yes! Indeed, there's nothing holding it in at the back, so clearly there are no rear fixings - TFFT! Shouldn't need any, as it's not likely to walk on its own.

Regardless of whether there's anything wrong with it, let's have a look in more detail.

Here's the hydraulic pump block that is responsible for the operation of the turret and tailstock (I don't use the collet chuck). It's a Sperry Vickers H1J PVB6A-RS-20-0A-11 Can I find any specs for this? 

Oooof - bingo! There's an exact match available of the shelf (new old stock):

Let me just think about that price for a few seconds. Ok, done, now move on - I'm probably not going to cough up £2k for one of these. Besides, mine works fine, even if I think it's a bit noisy (and what would I know, that may be normal).

That's driven by a fairly straightforward 3-phase motor rated at 2hp / 1.5kW / 230V. It's 4 pole, so would run at 1800rpm in the US but 1500rpm in the UK, where it's been running fine - I set up the turret timing with the way it worked in this installation. It's pretty large by today's standards, given its limited power output but hey.

It seems to be a variable displacement pump, so presumably it regulates the displacement in order to regulate the output pressure. In this application, it spends most of its time simply providing a static head.

"The Sperry Vickers (Eaton) part number PVB6A-RS-20-0A-11 designates a variable displacement, inline axial piston hydraulic pump delivering a rated flow of 6 GPM (22.7 L/min) at 1800 RPM." That sounds like a swash plate type pump. I was expecting a "gerotor" type pump but this makes more sense, as it will avoid roasting the oil by recirculating it against a relief valve at full flow rate.

Here's an exploded view of the "pressure compensated inline piston pumps" and a parts list, with part number description:

And another site gives some blurb about how it's used:

The PVB6A-RS-20-CA-11 pump belongs to the PVB Piston Pumps series and is produced by Vickers for use in hydraulic automation circuits where controlled flow is required. It is an axial piston, variable-displacement unit, so delivered volume adjusts to system demand and reduces wasted input power. Clockwise shaft rotation aligns with common right-hand drive layouts found on mobile and industrial machinery. A geometric displacement of 13.81 cm³ per revolution establishes the fundamental output capacity, while a rated flow of 22.7 L/min is achieved at 1800 rpm for moderate actuator speeds. The rotating group tolerates a maximum shaft speed of 1800 rpm, allowing direct coupling to standard four-pole electric motors without gear reduction. Pressure regulation is handled by a pressure compensator control that trims displacement as the outlet approaches the 140 bar limit, preventing overload. System piping connects through 11/16-12 UNF-2B SAE O-ring main ports, providing reliable sealing for high-pressure service.

The swashplate operates on one side of center, giving a single-direction displacement zone that simplifies motion control logic in closed-loop circuits. Case drainage is routed through a 9/16-18 UNF-2B SAE O-ring port to keep housing pressure low and protect shaft seals. Suction conditions must remain under 1.0 bar absolute inlet pressure to avoid cavitation during high-speed operation. The pump is specified for ambient temperatures from −20 °C to +70 °C, accommodating both cold-start field equipment and warm factory floors. An operating viscosity window of 220 to 13 cSt is permissible, with a recommended range of 54 to 13 cSt offering optimum efficiency and reduced wear. Power transmission to the drive train uses a 4.8 mm square by 25.4 mm long shaft key, ensuring positive torque transfer to standard couplings without custom hardware.

Technical Specifications

Case Drain Port Thread

9/16-18 UNF-2B (SAE O-ring)

Control Type

Pressure Compensator (C)

Displacement Zone

One Side Of Center (S)

Geometric Displacement

13.81 cm³/rev (0.84 in³)

Main Port Thread

11/16-12 UNF-2B (SAE O-ring)

Max Ambient Temperature

+70 C

Max Inlet Pressure

1.0 bar (15 psi)

Max Outlet Pressure

140 bar (2000 psi)

Max Shaft Speed

1800 rpm

Min Ambient Temperature

-20 C

Pump Type

Axial Piston (Variable Displ.)

Rated Flow @1800 Rpm

22.7 L/min (6 gpm)

Shaft Key Size

4.8 mm sq x 25.4 mm long

Shaft Rotation

Clockwise (R)

Viscosity Range (operating)

220 to 13 cSt

Viscosity Range (recommended)

54 to 13 cSt

Anyway, enough of that. The pump's probably fine, so I need to just focus on the motor itself. First show that (if) the motor itself is the issue that is causing the RCD and MCBs to trip. I don't imagine I need anything like 1.5kW just to operate the turret....

The pump is driven by an Oldham coupling and of course, given this motor's parentage and vintage, it has a 1" shaft. That could be a royal PITA.

The motor itself is foot mounted, with a flange mount for the pump assembly. So if the motor is shagged, I'll need a foot and flange motor with imperial measurements. Enough doom scrolling - let's disconnect the motor and see if the fault has gone away - and the Yaskawa drive isn't buggered.

Good news and bad:

Turns out there's nothing wrong with the pump motor, it seems. Disconnected the motor entirely and the breakers trip when I close the switch to the VFDs and servos. I guess I can now start to disconnect the various branches from that node and see where the fault lies......

Machining the SFU3205 ballscrew on the Tree lathe - or not, as the case may be...

I need to machine down the ballscrew to fit the thrust bearing. The ballscrew OD is 32mm and the bore of the bearing is 25mm. I also need to machine some 17mm hex flats on the end so I can drive it with a socket, either on a handle or an impact driver.

The Bantam is barely man enough on a good day but on this occasion, it's not even a starter, as the through bore is just over 1" (25.4mm). So the Tree will come to the rescue, as it has a through bore of just over 50mm - probably 2" from memory.

The end of the shaft I will machine initially looks like this:

But to keep life simple, I'll create a simple model:

I'm going to use a "trigon" insert, as this will be a hardened ballscrew which could be tough on more delicate inserts. Note that these toolholders have been machined down to 19mm, due to the machine being an imperial relic on account of its US heritage, so an off the shelf 20mm tool will be 1mm too high.

Machine sort of flashed up OK - until I turned on the hydraulic pump, at which point the various circuit breakers tripped, depending which ones I reset, others would trip. I've previously had trouble with this motor and sort of bodged it by fitting a site transformer (voltage isolation) with a local RCD so that the consumer unit wouldn't trip out. It was clear that there was a lot of leakage somewhere, most likely the hydraulic pump motor, given that almost all the other mains stuff had been replaced.

I'm thinking that the motor insulation has finally broken down enough that the leakage current will trip anything in its path. I just hope I haven't fucked the Yaskawa drive that powers it.

Of course, access to the end of the machine that houses the pump isn't dead easy although that's due to the fact that I've got lots of crap piled up against it. In reality, access should be pretty reasonable once all that crap is moved out of the way.

I'm hoping that simply disconnecting the motor will clear / demonstrate the fault, in which case a new motor will be the solution. The hydraulic pump is pretty noisy, so it's possible I may also get myself a new pump in the process - how long's a piece of string?

Chips with Probe Basic Lathe Coversational!

Despite the AliExpress tracking info showing the ballscrew sitting at the China consignment hub, look what turned up a few days ago.

Yes, SFU3205 (single ballnut, 32mm OD, 5mm pitch). It even came with a transfer tube(?) to allow you to remove the ballnut without sowing the ball bearings across the length and breadth of the workshop.

Thusmost:

Anyway, time to drill the pilot hole in the stock for the bearing bracket. Centre drill, then 8mm drill, then 25.5mm drill.

There. Ready for the boring operations.

Then set up the first boring operation in the PBL Conversational screen (open out from 25.5mm to 50mm):

At this stage I was thinking I should check the spindle speed. This machine originally had a 1500 / 3000rpm motor and if you wanted the max spindle speed of 1600rpm, you needed the motor to be running at 3000rpm (that's the no-load, synchronous speed - slightly lower when under load).

The motor fitted to the machine is a 4 pole (ie 1500rpm) 3kW induction motor. That's a bit OTT but I had it kicking about and it saved having to buy another one. HWIW, it originally powered an air compressor on an electric urban bus to power the brakes and air suspension.

If I'm running this motor much above its 1500rpm base speed, it's going to be well down on power. And in the Linuxcnc .INI file, there's a spindle scaling factor that translates / scales the 0-10Vdc output from the Mesa 7i76 board to actual spindle speed. I've disable the I (and D) term in the PID controller so that the motor speed is a direct function of the analogue control voltage from the 7i76's digital potentiometer.

The only simple way to independently measure the spindle speed is using the "Machtach" device that I procured, built and installed on the machine some years ago. 

This uses an optical sensor to detect markers on the spindle nose and calculate the rpm. Those markers are still present on the spindle nose and the device itself seems to work once powered up.

True, there's an encoder on the spindle that reports back the actual speed but I'm not 100% convinced it's set up correctly - I suspect it is but now would be a good time to check.

You may notice that the motor pulley is rather larger than the original - it's actually the biggest I could fit under the cover. That's because I swapped it out when upgrading the motor. 

This was before, with the original, smaller pulley:

And after, with the oversized pulley:

The result is that I can actually get over 1500rpm at the spindle from this setup, with the motor operating below base speed ie not field weakened. And the scale factor is bang on - I'd clearly frigged it to get the exact correct values. And the reported spindle speed displayed (from the encoder) is sot on.

On with cutting chips, then. The operation is broken down into 2 steps - bore through at 50mm, then counterbore at 62mm. If I ran both operations together, I believe the conversational feature would merge them and avoid duplication (air cutting). However, this is the first time out for Chris Polanski's "Intuiturn" conversational macros, so one step at a time etc.

That seems to be going well so far: 

Oooof, even with the rear and top chip guards fitted, this was a painful business. Blue hot chips are flying out in all directions. Rather than stop the process, I grabbed a handy cardboard box and hid behind it.

That was almost manageable, containing perhaps 90% of the hot chips. And a good result. In fact, I must have screwed up the touch off step a bit, as the bore came out almost 0.4mm undersize. Easily managed by a final (manual) pass.

Good result.

So there we have it - the first use of the (Internal Turning) conversational macros. I need to fit a more sensible chip guard that will enclose the front of the machine, so I don't get burned and the workshop isn't sprayed in tiny chips.

Arguably it would be sensible to connect up the coolant pump but the same thing goes - I need a guard to contain the mess, so it's simpler to just run dry for now.