Setting up to test the rewired CNC Bantam and Probe Basic Lathe

Now that I've developed a ballscrew attachment for the JD TB3 tube bender, I need to prepare to get the new compts machined. This requires:

• Find suitable material for the 2 blocks., This should really be steel, as loominum isn't going to work so well, either in terms of strength or as a bearing material where it bears against the bender's arms. I seem to have a piece of 1" x 3" hot rolled steel of 190mm length. That's a bit shorter than I'd planned but I have little choice of material to start from. I can cut it into a 100mm length for the bearing bock and a 90mm length for the ballnut. I will modify the blocks in Fusion to suit the new reality.
• Cut the stock ready for machining. 
• Flash up some lathe tools in Fusion. Currently, most of the tools in my library are for the Tree ie LH tools, whereas I need RH tools. So to start with I will create a 25.5mm drill, a CCMT060204 tipped boring bar and a fairly conventional RH turning tool with DCMT11T304 insert, while I'm at it.
• Create the toolpaths in Fusion using the new tools.
• Export the tools from Fusion as a JSON file and import them into the PBL as the tool library.
• Import the g code for the boring operations into PBL.

I don't intend to do the predrilling as a CNC operation, as I will be using a tailstock mounted drill for that. Similarly I'm not sure I can be arsed to face off the front of the stock afterwards. So this will simply comprise the rough boring and finish boring operations.

Here's the modified bearing block. It's a fair bit thinner than before and instead of having pillars sticking out on top and bottom, I will insert short collared spacers or shouldered screws.

Similarly, the ballnut bracket has shorter pillars.

There should be enough info here for me to set up the machine:

Here's the boring bar setup:

And the turning tool:

For the CCMT060304, I will use 80m/min surface speed, 0.1mm per rev feedrate and 1mm depth of cut. This is a slender boring bar, albeit carbide, so I've erred on the cautious side.

For the DCMT11T304, I will use 150m/min surface speed, 0.1mm per rev feedrate and 2mm depth of cut. Or I would if I planned to use it here.

Note that there's no actual (internal) boring operation as such. Instead, you select Profile Roughing and Profile Finishing and by selecting the appropriate features you define a boring operation.

FFS, some of the Fusion turning toolpaths are a rite of passage. I struggled to get this done but finally found that turning "Rest Machining" off allowed the thing to generate non-empty toolpaths, which is quite helpful. The rough boring and finish boring operations, which make use of a pre-drilled 25.5mm hole:

The (not used facing operation):

The g code for the boring operations:

%

(3001)

(BRG BLOCK)

N10 G7

N11 G18

N12 G90

N13 G21

N14 G28 X0.

N15 G28 Z0.

(PROFILE ROUGHING2)

N16 T12 M6

N18 G54

N19 G97 S3500 M3

N20 G95

....

....

N127 G1 Z-16.9 F0.1

N128 X59.9

N129 X57.9 Z-15.9

N130 G0 X0.

N131 Z5.

N132 G97 S3500 M3

(PROFILE FINISHING2)

N133 M5

N134 M1

N135 G97 S2000 M3

N136 G95

N137 G0 X0. Z5.

N138 G96 D2000 S80 M3

N139 G0 Z1.014

N140 X58.922

N141 G1 X59.172 F0.1

N142 X62. Z-0.4

N143 Z-17.

N144 X50.

N145 X47.172 Z-15.586

N146 G0 X0.

N147 Z5.

N148 G97 S2000 M3

(PROFILE FINISHING3)

N149 M5

N150 M1

N151 G97 S2000 M3

N152 G95

N153 G0 X0. Z5.

N154 G96 D2000 S80 M3

N155 G0 Z-15.986

N156 X46.922

N157 G1 X47.172 F0.1

N158 X50. Z-17.4

N159 Z-25.4

N160 X46.

N161 G0 X0.

N162 Z5.

N163 G97 S2000 M3

N164 M5

N165 G28 X0.

N166 G28 Z0.

N167 M30

%

Let's get the stock set up in the 4 jaw and import the g code into PBL.

Ooof, those jaws are in the way of the boring toolpath. That's what happens when you allow The Stupid Fat Bloke to get ahead of himself and set stuff up before thinking things through. And it was all dialled in at this stage of course.

That's better. With a 4-jaw chuck you can remove 2 of the jaws and swap them round without removing the work, then do the same with the other 2 jaws. So it remains true and now has a helpful gap between the rear of the stock and the chuck and jaws. This method costs less in terms of inserts, carbide boring bars and chuck jaws.

Once I've imported the g code, I may be forced to actually machine this bearing block.....

Update Centroid Acorn Lathe to 5.4 - and modifying the PLC code to suit - sneaky gotcha!!

I've updated the Tree CNC lathe with Centroid CNC12 latest major version ie 5.42 at the time of writing. The process is still a bit clunky - you have to take screenshots of each setup screen, run the CNC12 installer (having backed up the current, working example under a different folder name), then use the Setup Wizard to replicate every option, item by item, screen by screen.

But as I also had to create a custom PLC program for my powered ATC turret, I'll need to modify the 5.42 PLC in a similar fashion. This turret doesn't use Gray Code to report its position - instead it has a single switch for each of the 8 positions. These come in via the Ether1616 expansion board. There's no default option for an "8-input" turret position feedback.

The edits I made are documented here and there was a minor edit that resulted from testing it out. I'll now need to replicate those changes. The main PLC code will almost certainly have changed since I made my changes back in August 2022.

It's worth noting that the inputs from the turret feedback signals that come in via the Ether1616 expansion board aren't set up by the Setup Wizard - they are effectively hard coded in the PLC code. If you don't make the PLC edits, the ATC turret isn't going to know correctly which tool is loaded.

The final step, after editing the SRC code file is to compile it. Using CMD window, change to the c:\cnct folder, then run the compile:

cd c:\cnct

mpu compile acorn_lathe_plc.src mpu.plc

This generates a new mpu.plc file that will be picked up by CNC12 and run.

The gotcha

Ooof.

c:\cnct>mpucomp acorn_lathe_plc.src mpu.plc

MPUCOMP v5.42 Rev 07 MPU11 PLC compiler

$Id: mpucompiler.cpp 21173 2025-07-21 17:11:10Z keith $

Copyright 2001-2018 Centroid Corp.

Input file : acorn_lathe_plc.src

Output file: mpu.plc

Error Line 6913 Col 4: Undefined label TRUE

IF TRUE THEN CurrentTurretPosition_W = 0

   ^

Error Line 6922 Col 4: Undefined label TRUE

IF TRUE THEN SV_PLC_CAROUSEL_POSITION = CurrentTurretPosition_W

   ^

Error Line 6913 Col 4: Bad Numerical Factor

IF TRUE THEN CurrentTurretPosition_W = 0

   ^

Error Line 6922 Col 4: Bad Numerical Factor

IF TRUE THEN SV_PLC_CAROUSEL_POSITION = CurrentTurretPosition_W

   ^

Compilation failed.

c:\cnct>

WTF?? Turns out they changed the rules slightly somewhere between v5.20 (my last working installation) and v5.42 (today's update):

According to Mr AI, "If you try to compile a legacy .SRC file (written during the CNC12 v4.xx era or earlier) using the new mpucomp compiler from v5.xx+, it will instantly flag IF TRUE as a compiler syntax error. To upgrade old logic to work under v5.xx software, open your old .SRC file and find/replace every instance of TRUE used in logic statements to TRUE_M."

There are only 2 instances of the IF TRUE statement, both of which I pasted in when updating the turret code using snippets of the v5.20 code:

;==============================================================================

                               ATCGrayCodeStage

;==============================================================================

; EME 2024-11-10 ATC control trials

; Input 1 on Ether1616 with A0 address = CNC12 input 33 etc

; IF Tool1Input THEN CurrentTurretPosition_W = 1

; IF Tool2Input THEN CurrentTurretPosition_W = 2

; etc...

IF TRUE THEN CurrentTurretPosition_W = 0

IF INP33 THEN CurrentTurretPosition_W = 1

IF INP34 THEN CurrentTurretPosition_W = 2

IF INP35 THEN CurrentTurretPosition_W = 3

IF INP36 THEN CurrentTurretPosition_W = 4

IF INP37 THEN CurrentTurretPosition_W = 5

IF INP38 THEN CurrentTurretPosition_W = 6

IF INP39 THEN CurrentTurretPosition_W = 7

IF INP40 THEN CurrentTurretPosition_W = 8

IF TRUE THEN SV_PLC_CAROUSEL_POSITION = CurrentTurretPosition_W

; EME end of substitution

Replaced both TRUE instances with TRUE_M. That's better:

c:\cnct>mpucomp acorn_lathe_plc.src mpu.plc

MPUCOMP v5.42 Rev 07 MPU11 PLC compiler

$Id: mpucompiler.cpp 21173 2025-07-21 17:11:10Z keith $

Copyright 2001-2018 Centroid Corp.

Input file : acorn_lathe_plc.src

Output file: mpu.plc

Compilation successful

Max stack depth = 7

Program size: 13475 tokens (82.2449% of max)

c:\cnct>

That should work. It compiles and runs OK although I'll leave the testing of the turret until tomorrow, as it's a pretty noisy, brutal mechanism and it's late and I'm supposed to be getting tired soon.

Ballscrew driver for tube bender?

Although I'm not 100% convinced the "JD Squared" tube bender is going to cut it for me with this particular exhaust task. However, it's pretty awkward to use, even with a long "helper" tube fitted to the actuator handle. Here are some observations about its use - and thoughts about how to add a power assist.

The default assumption in the US is that any man worth his salt will have compressed air in his (work)shop, so one of those "pneumatic to hydraulic" adaptors would be a fairly simple matter to connect up. This would allow a hydraulic cylinder to be fitted to the bender - and be operated from a compressed air supply. We don't do that over here so much and even if we did, there are every few of those "pneumatic to hydraulic" products available.

Here's a JD Squared (clone) bender fitted with a hydraulic cylinder. Note that although it says "$200", that price doesn't include any actual dies...

So, how about simply fitting a large Chinesium ballscrew and driving it with an impact driver? Just pulling specs out of my ass, I'm thinking a 32mm ballscrew with a 5mm pitch would suffice. Generally, these seem to rated at around 4 Chinese tonnes of dynamic load. 

Looking at a HLTNC (a semi reputable Chinese supplier of SFU3205?), I'm seeing a static load bearing capacity of ~50kN and a dynamic load of ~17kN. That's between 1.7 and 5 tonnes of force in street talk. With the kind of leverage we see on that bender of about 20:1 when fitted with a 1m helper bar (~5cm active length at the ratchet bar), I'd be needing to apply about 85kgf or 250kgf on the helper bar to exert a similar force manually. I'm pretty certain I've never come close to that, so as far as calculations go, I think we can leave it there - "an SFU3205 ballscrew will be man enough", even allowing for Chinese units of measure.

So what would it look like, this ballscrew power feeder thing?

Check the bearing loads - that looks adequate.

Here's the assembly with all joints working but not bothering with "real" pivots, fixings etc. I'm only interested in the ballnut, bearing and ballscrew at this stage.

That will do. Let's focus on making it happen.

Purge bung for 32mm tube

Unless you plan to butt weld your stainless steel exhaust pipe tube without achieving full penetration (on a 1.5mm wall thickness), you need to back purge the tube ie drive out the oxygen / air from the inside. Failure to do so will result in a shitty black oxide eruption from the back side of the weld. It's called "sugaring" and is best avoided, if only for cosmetic reasons.

The usual requirement is for some form of simple bung to wedge into the end of one of the tubes with an argon supply. Any other openings are covered, usually with aluminium foil, allowing some means for the purged air and argon to escape.

I have dual argon regulators and 2 hoses, so I should be able to adjust the flow of the torch and purge gases independently. It's a little bit crowded / messy up front here but I'm trying to run both gasses through the solenoid of the welder so that I can't accidentally leave the purge running - or forget to turn it on. 

The bottle has a sort of master flow regulator feeding the welder, so I'm hoping to be able to set the total flow rate above the sum of the individual flows and/or use the master regulator to achieve the required balance. Time will tell if that is a workable concept in practice. The individual gauges have simple needle valves, whereas the master regulator actually regulates the flow at a constant level, up a maximum (but modest) back pressure. You can see how that might work....

At the far end of the purge hose, I will fit one of these "quick connect" connections. As well as enabling the hose to be connected and disconnected from the purge bung, it closes off any flow when the connection is broken.

So tonight's challenge is to make a simple tapered bung (in black ABS again, certainly for the moment) that will accept one of those male plugs. They are 6mm and 8mm - and given that I have 2 of the 6mm, I will use that.

This should work for both 32mm and 38mm tubes. The 6mm plug should be a nice push fit into the 5.5mm hole.

Corners rounded off:

That one can join the (growing) queue to be printed.

Adjustable home and limit switch targets for the CNC Bantam

Another little job to do for the CNC Bantam. I'm using inductive proximity switches for the home and limit switches on the Z axis. These are the Omron TL-Q sensors. These use an open ended pot core to detect the presence of a conductive body within the magnetic field generated by an AC driving voltage, due to its effect on the q factor of the circuit. The target can be conductive but does not necessarily need to be magnetic - and in fact a higher conductivity body (and most likely non magnetic) gives the smallest detection distance and hence arguably the most accurate homing distance. 

Currently, for the Z axis home target, I have simply stuck a piece of aluminium angle iron onto the leaner encoder scale extrusion using a piece of double sided tape - yes, another temporary measure taken while I proved out the function. Furthermore, I haven't fitted a target for the Z limit switch, which is the further sensor in the photo. The notion was that I would be able to move that to suit the work in hand. So if I am using a big chuck with a lot of stickout, I might move the limit switch target further from the headstock. 

The alternative would be to change the software limits in the .INI file, which is hardly user friendly - or not have anything to prevent the tool flying into the headstock/work/chuck if I have left The Stupid Fat Bloke in charge of operations.

So I need a couple of (plastic) clamps that will attach to the linear scale housing and be easily adjustable for position by sliding along the housing. 

This was the initial concept. This is the reverse side. I need to be able to assemble the thing without dismantling the scale or trying to spring the clip. This will be 100% fill ABS, so shouldn't be capable of springing that much. So there's a screw holding the rear part of the clip in place:

The target will be an M8 grub screw on the underside of the clip:

Looks OK from here, although the magnet needs to be moved out so it is above the centre of the sensor. There's a grub screw that allows the clip to be locked in position. I'll either use a plastic screw or (more likely) a steel one with a plastic pad to avoid damaging the scale housing.

With some further measurement and thought, here we are. The target grub screw is now placed in the middle of the sensor, hence the joggled end. And the limit switch is simply a mirror image of the home switch, with the same clamp piece.

If this works out OK, I will need to print the mirror image part for the other limit switch ie the max travel limit. However, it takes 6.5h, so we will have to wait and see what emerges finally. Meanwhile, I've just taken delivery of another 2kg of black ABS. The Creality CR-ABS seems to work really well and is nice and solid when printed at 100% fill density.

An interesting / useful point to note is that those M8 threads are modelled in Fusion and the printer does a reasonable job of reproducing them, to the extent that you can simply screw an M8 screw into them without needing to clear the threads with a tap. Certainly good enough for the application in this case. For more demanding applications it may be necessary to fit a captive nut or threaded bar into the body, as I did on the pipe tube cutting fixture.

Mandrel bend cutting jig

I've now got myself a load of 32mm mandrel bends in 45 degree and 90 degree segments. However, I'll need to chop some of them off at other angles. They could be pretty tricky to hold while using a bandsaw or angle grinder to cut them to the required angle.

There are a few examples of 3D models that achieve this function on places like Thingiverse etc. Naively, I thought I might be able to download something that I could simply print out and use - something like these:

...but the only models I could find were expecting some form of payment, either as STL files or even as the printed items themselves, with prices ranging from ~£5 (model) to £40 (printed). Well fuck that. Apart from that being against my religion, many of them don't actually do what I need, not least being for the wrong diameter tube and none of them are parametric or even in Fusion format. Details, I know.

Fusion time:

What I want:

• Suitable for 32mm tube (ie OD, not ID)
• Settable at 5 degree increments
• Split halves, to allow easy setting and clamping
• 1mm gap between the halves so there's movement for the vise to clamp the tube
• 10mm dowels to hold halves together before being clamped
• Solid (100%) fill in ABS, so it can be solidly clamped

Like this perhaps:

Obvs you need to account for the diameter of the stop pin when setting the angular positions of the holes. Like this:

Lots of support structures in the various holes. This is my first trial attempt, using default settings (to save material). 

Came out OK but made a couple of enhancements to the design, namely:

• Rather than use 10mm dowels to align the halves, use M10 screws with captive nuts, so I can nip them up before going into the bandsaw vise.
• Use an M4 caphead screw for the tube stop. And provide a counterbore for the head on the reverse side - or in fact a whole series of them, one for each position.
• Reduce the gap between the halves from 1mm to 0.1mm. Yes, it still clamps nicely but doesn't wobble around.
• Use 100% fill, as I'm reasonably confident this is in a good enough state not to require further iterations.

And it finally printed out after 7.5 hours. Using the default fill of 25%(?) would have only saved me about 30 minutes apparently. The main difference of going for 100% fill is the cost of the material. Total usage should be around 187g. At about £15 per kg, that's about £2.85 for the final part ie not exactly extravagant.

But after some poking and pulling, it's all cleared out and working. Reamed out the holes with a couple of drills and it's a good 'un.

I will need to cut that M4 screw down to 45mm so it doesn't poke out. Later.

Also, the big M10 screws holding the halves together need to be 45mm long. Seems I have only one M10 caphead screw in my entire collection and it's about 60mm long. That's a great excuse to buy some 30, 45 and 60mm for my "stock". I'm not ready to do any pipe cutting and welding yet, so completing the final assembly of this thing can wait until I have the final delivery of u-bends from China and the screws from ebay.

Job done.

Modelling a bunch of bananas - aka downstream manifold

Modelling? Bananas?

There seem to be 2 ways to go about fabricating an exhaust system, particularly the manifold end, where things tend to be more complex: the Honda S800 has a "bunch of bananas" manifold, forming a 4-into-2 system with equal length headers.

The first method is simply to get a pile of tubes, elbow bends, angle grinder disks, welding wire etc and knock it up piece by piece. 

The second is to model up the system using standardised building blocks comprising mandrel bends and sections of standard tubing. Unless you intend to persist with the use of tube benders, you have little choice. Even then, the tube diameter and bend radius are all going to be fairly well predefined. And given that the 32mm tube I have seems to collapse when you so much as fart next to it when trying to bend it more than 30 degrees or so, my attentions have focused on the use of mandrel bends and u-bends, chopped up as required, then butt welded together to form the required final assembly.

And when it comes to modelling manifolds in Fusion 360, there are 2 approaches.

1. Make up a library of bends and tubes, then assemble them so that they replicate the real thing. Then replicate each compt on the bench and assemble / weld them up.
2. Create a 3D sketch that defines the centre lines of the headers, then finally use the "pipe" feature in Fusion to create a pipe that follows the sketch line. Alternatively, you could create your own tube section in a sketch and then use the sweep function to create your own tube / pipe. 
   

NB: Interestingly, the "Pipe" tool in Fusion should really be called a "Tube" tool, as the diameter you specify actually ends up being the OD, not the ID: if you specify a 32mm pipe diameter and a 1.5mm wall thickness, the ID measures at 29mm.

The 3D sketch method is a royal PITA but as log as you don't define the dimensions of the angles and length of the subcomponents, you can edit them in place by dragging the end points of the sketch segments in the 3D environment - assuming you have selected "3D sketch" in he sketch popup dialogue. In contrast, the "build it from blocks" approach is a different kind of royal PITA - each time you want to move the parts around, you have to either use revolute joints etc (for rotation) or edit the subcomponents for each position, noting that you will need to unlink them from the original, to avoid changing all instances at once. So you will end up with a myriad different tubes and elbows and moving each about will be the devil's work.

Here's an example of how to use the 3D sketch method. It's got no commentary but even so, you can see that it's not dead simple:

And LEAD has a similar video in that wonderfully condescending fashion so many Mercan Youtube heroes adapt.

Enough talk - time for some action:

Here's the beginning of an assembly using the "building block" method:

I soon gave up on this, as it was clearly going to become a nightmare very quickly.

Here's the "3D sketch" method, with the centre line sketch being open and edited. The blue lines are not fully constrained, so can often (sometimes?) be edited by dragging the segment end points.

If you set the sketch properties to "Show dimensions" and keep the sketches visible, you can also see the dimensions (look closely):

Changing the Display Settings / Visual Style to "Shaded with visible edges only", highlights where the different segments abut:

And of course, you can render it if you are a CAD tart. The stainless tube I bought is actually polished (it was actually cheaper than the "natural" finish), so it's actually quite close to what we might expect to see, apart from the heat discolouration.

I've concluded that the 2 lower headers may as well join before the final exit (as shown), as this would simplify the assembly and I don't imagine shortening 2 of the headers by a couple of inches will make the slightest difference. That will require some further CAD work of course and the tube is slightly larger diameter (38mm) after the 2 headers merge.

WTF is wrong with Fusion toolpath simulation - takes forever - SIMPLE FIX!

Dunno what is wrong with my PC. It takes almost forever to simulate the toolpath for the exhaust flange. It's not a large or complex part but I timed it consistently at 5:30 minutes to complete a simulation.

That simulation is the generation of the toolpath and, in particular, the stock removal. There are quite a few contributors to the processing time:

• I don't have a particularly powerful processor in my PC. It's a GMKTEK NUCBOX9 (SFF tiny PC thing) with an AMD Ryzen 5 5600U. This is considered to be broadly equivalent to an Intel Core i5-1135G7. It should be fine for my needs - and better than the previous PC I was running - which in turn seemed to be well powerful enough.
• It has an inbuilt Radeon Vega 7 integrated graphics, which is generally thought to be good enough to play "light and casual" games. I'm only running fairly simple CAD graphics here - and Fusion isn't that demanding when it comes to graphics. Gone are the days when you had to run a Quadra (CAD) or a high end gaming graphics board.
• I'm running 3 displays at 1080p aka FHD. That's not quite 2K and certainly not 4K resolution but it's fine for my needs and my monitors can't do better. The Radeon graphics should be fine with that.
• I have plenty of RAM now, having upgraded to 64GB. With Fusion running with 16GB, I was running out of working RAM, with the risk of having to use the swap file which slows stuff down a fair bit.
• It seems to be the adaptive toolpaths that really hammer the simulation times. Sure enough, the adaptive part of the operation dominates the time by far:
• Adaptive 2:55
• Bore 1:05
• 2D Contour 0:33
• Drill 0:07 (hard to time it precisely though)

But waiting for over 5 minutes to get a toolpath simulation completed is taking the piss. Some thing needs to be done - and it won't involve buying a more powerful PC.

In the interests of science - and to avoid losing the will to live during toolpath simulation, I tried changing various settings:

• Unselecting the various "Display Graphics Effects" options that are set by default:
• Ground plane
• Ground shadow
• Ground reflection
• Object shadow
• Anti aliasing

These made sod all difference.

• Then I messed with the settings within the adaptive toolpath, namely the tolerance and the fine stepdown, which seems to be set to 10% of the roughing stepdown by default. I increased it to 1mm.

That did f*ck all too, so I put it back to 0.3mm.

• Finally, I reduced the "Accuracy" setting in the Stock section of the simulation dialogue box. The slider has 10 positions and is set to 10 by default. Position #1 is "minimum accuracy" and #10 is "max accuracy".

This utterly transformed the performance - setting to mid position (#5) removes the bottle neck. Running just the Adaptive toolpath, we now get ~00:26, down from almost 3 minutes.

• You can then increase the speed of the displayed simulation without being held back by the processor trying to keep up. In fact, it can generate run the whole toolpath within ~3 seconds and it's the graphics that struggles to display the toolpath, not the processor doing the calculations. But what is the sweet spot? How much can I turn the "accuracy" slider back up before affecting the simulation time?
• Interestingly, when you change the slider position, a text appears, saying the stock generation is being completed. It seems to recalculate the stock automatically each time a change is made to the accuracy slider setting. As this stock generation seems to be the cause of the issue, we can simply focus on those times, rather than run the whole simulation each time. And here's what I found for the stock generation time for each slider setting:
• #5 < 1second
• #6 ~3 seconds
• #7 ~3 seconds
• #8 ~4 seconds
• #9 ~35 seconds
• #10 1:44 minutes.

Here's the "stock generation" text, visible at the bottom of the screen if you look closely:

These times are fairly approximate because it's actually quite difficult to measure without some sort of anal video capture approach. I have a life to live, so that isn't going to be how I do this. I just used the stopwatch on my phone.

But there we have it. Simply putting the accuracy slider to position #8 largely sorts the problem out. I'll leave it set to #7, at which point, the only bottle neck seen occurs if you crank up the simulation display speed to something dumb, where the graphics struggles to display enough FPS to give a smooth view.

So indeed there we have it. The fix is actually very simple. That feels like a result.