Friday, 22 May 2026

Tidy up the cabinet wiring

Previously (when I started this build a few years ago), I put work on hold while I wrestled with trying to implement Andy Pugh's macros. I spent ages on this and finally lost the will to live. It seemed that Python3 was required for correct operation, yet it wasn't expected imminently so I left it for the time being. The machine worked but the macros weren't installed and working.

Some of the wiring was lashed up for proof of function testing, so it could do with being properly tidied up at last. Here's where we are:



Looks a bit messy but it's not actually that bad by my standards. It all had to fit in this cabinet size due to the space available, so there are no cable ducts and the wiring runs on the walls and baseplate.

One key issue is the cables for the X and Z homing / limit switches. They need to run through a plug so that the cabinet can be moved without hard wired cables getting ripped out. So I cut the 2 cables and fitted a 9 pin Dsub connector:



With a mating connector in the cabinet itself. The other 3 Dsub connectors are just off the top of the picture - these are the encoders for the X axis, Z axis and spindle.

For the record, the pinouts are:

X axis:

  • Blue +24V (Dsub pin 2)
  • Green +24V (Dsub pin 3) - yes, also +24V
  • Red TB6 pin 1 (Dsub pin 4)
  • Yellow TB6 pin 2 (Dsub 5)
  • Screen (Dsub pin 9)
Z axis:
  • Blue +24V (Dsub pin 1)
  • Green 0V (Dsub pin 6)
  • Red TB6 pin 4 (Dsub pin 7)
  • Yellow TB6 pin 3 (Dsub pin 8)
  • Screen (Dsub pin 9)

I need (want) to fit a plug and socket on the spindle motor cable, as this is now the only remaining hard wired connection to the cabinet. This needs to be a 16A 3-phase (red) socket (on the cabinet) and matching plug on the motor. This has been ordered and should be here tomorrow. 

Wednesday, 20 May 2026

Replacing the Linux PC - Mesa boards and P330 Tiny PC. Magic smoke!!


Before I start, here's what we have today. There's an ASrock J1900 Mini-ITX mobo in that black box, along with a Mesa 5i25 Superport board. The breakout boards 7i76 and 7i85 are mounted on the lid. I will leave the PC in the box where it is, in case I want to flash it up later to access any files. Besides, there's no benefit in removing it and I'm not about to remount all the wiring and boards.

The 7i76 has some messy wiring on it that needs to be tidied up later. These are the limit and home switches for the X and Z axes and I clearly never got around to terminating them in a workmanlike manner.

TB6 is the "field inputs" section, where these limit switch inputs terminate.


With the lid off, we can see the 5i25, which is mounted on the case and connected by a couple of ribbon cables to a PCI-to-PCIe adaptor - the 5i25 needs an old fashioned PCI slot but the mobo only has a PCIe slot. I need to recover the 5i25, then reassemble it, leaving it operational, just in case.




Removed.




Here's the old adaptor, alongside the new one, which uses a USB-type cable to communicate with the PCIe plug. That's handy, as there's no room inside the Tiny PC for the 5i25. Both use the Asmedia ASM1083 bridge IC.


Back together again.


A quick note of the 256GB SSD and 8GB RAM:



Only one slot is occupied, so could increase memory if I have some spare.


New adaptor board in place, cover ready to go back on. Looks good to me. It could almost have been planned:



The 5i25 plugs into to the adaptor board. But when I do this, the PC won't boot and the 12V supply shuts down. Clearly something not right here. Note the brown smudge on the PCI edge connector - that PTC has let some smoke out!


The root cause of the problem is actually visible in ths pic:


This is how I assembled it, with all external connections at the same end:


But in fact, this is how it's supposed to be fitted:


From Wikipedia, it seems that this PCI board is "Universal (3.3V & 5V) 32-bit PCI Card", which can be fitted the wrong way round. If you have the mounting bracket and are fitting the board into a mobo, perhaps there's less of a risk of getting it wrong.


So because of this, the 5i25 has 2 slots, allowing it to be fitted either way round. Have I popped something? That burnt PTC ("self resetting fuse") is protecting the 5V supply to one of the BOBs. Luckily I'm not relying on that route, as they have their own dedicated 5V PSU.


No. Luckily, the PC, adaptor board, 5i25 and breakout boards have all survived. TFFT!

And yes, the PC still works and the BOBs appear to be functional. Onwards and upwards!

Tuesday, 19 May 2026

Bracket for mounting the Tiny PC

Need to come up with some means of securing the Tiny PC in the cabinet. There seems to be a variety of brackets on Thingiverse etc but nothing resembling an industrial part. Let's model something up in Fusion:


And print it on the Elegoo


There's a clip that snaps into place across the top.




Quick mod to prevent it sliding off. Not clear that it would, but better safe than sorry.


Straight off the printer. It still has supports etc that need to be removed.


Nice. 


Some 3M double sided foam tape to hold it down and it's done. That stuff sticks like shit to a blanket.

That'll do.

Monday, 18 May 2026

"New" PC for the Bantam Linuxcnc machine - installing Trixie and Probe Basic Lathe

Here's the process recommended by Chris Polanski for installing Debian 13 "Trixie" and Probe Basic. This is what I followed.

Probe Basic Trixie APT Develop Install

Probe Basic APT development install guide for Debian 13 Trixie

Important Requirements

  • Probe Basic is currently designed for 1920x1080 screen sizes only.

  • Probe Basic requires graphics hardware that supports OpenGL 3.2 and OpenGL Shading Language (GLSL) 1.50 or later.

  • LinuxCNC must be installed before installing QtPyVCP and Probe Basic packages.

Installation Steps

1. Download the LinuxCNC Debian 13 Trixie PREEMPT-RT ISO

Download from:

https://www.linuxcnc.org/iso/linuxcnc_2.9.8-amd64.hybrid.iso

This Debian 13 Trixie ISO installs Debian with the required PREEMPT-RT kernel and LinuxCNC uspace package.

2. Update the system

sudo apt update
sudo apt upgrade

3. Install LinuxCNC (if not installed)

sudo apt install linuxcnc-uspace

4. Add the Trixie develop APT repository

AMD64 for PC installation repository:

sudo apt install curl
echo 'deb [arch=amd64] https://repository.qtpyvcp.com/apt trixie-dev main' | sudo tee /etc/apt/sources.list.d/kcjengr.list
curl -sS https://repository.qtpyvcp.com/repo/kcjengr.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/kcjengr.gpg
gpg --keyserver keys.openpgp.org --recv-key 2DEC041F290DF85A

ARM64 for Raspberry Pi 4 and 5 installation repository:

sudo apt install curl
echo 'deb [arch=arm64] https://repository.qtpyvcp.com/apt trixie-dev main' | sudo tee /etc/apt/sources.list.d/kcjengr.list
curl -sS https://repository.qtpyvcp.com/repo/kcjengr.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/kcjengr.gpg
gpg --keyserver keys.openpgp.org --recv-key 2DEC041F290DF85A

5. Update repositories

sudo apt update

6. Install QtPyVCP and Probe Basic

sudo apt install python3-qtpyvcp
sudo apt install python3-probe-basic

Updating and Configuration

Probe Basic and QtPyVCP update through normal APT upgrades.

sudo apt update
sudo apt upgrade

Done. Then use the configuration files I (ie Claude) saved to my github repository to get it working with my machine. The initial install is actually a simulation version, so the next step in the process is to replace the various sim files with "real" ones.

Here's what I have from the previous sessions:

  • Machine: Lenovo ThinkStation P330 Tiny (i7-8700T), replacing Bay Trail (which had the VLP52 Intel GPU errata)
  • Hardware: Mesa 5i25/7i76, not yet moved across
  • Software: PBL installed, sim working. Config files in GitHub (pb_lathe_murray/). Custom Qt Lathe Cycles tab on branch feature/qt-lathe-macros. All .ngc subroutines fixed and tested.
  • Pending: SVG label positioning for the cycles tab, CONVERSATIONAL tab hiding

Recommended migration sequence:

Phase 1 — Software (no hardware needed yet)

  1. Clone your GitHub repo onto this machine into the right location
  2. Point PBL at the pb_lathe_murray/ config and test in sim — this validates your ini/hal before any hardware is involved
  3. Audit /usr/lib/python3/dist-packages/probe_basic/vtk_backplot.py — the new PBL install may already have the upstream fixes; compare before re-patching
  4. Check probe_basic_lathe.py for the BACK_TOOL_LATHE default view fix
  5. Verify SPINDLES=1 in [TRAJ] in your ini
  6. Hide the CONVERSATIONAL tab (the sudo python3 one-liner from previous notes)
  7. Check display config (VGA-1 primary at x=1920, HDMI-1 at x=0) — adjust xrandr/monitor setup if needed

Phase 2 — Hardware swap

  1. Power off both machines, move Mesa 5i25/7i76 (and any cabling to 7i76)
  2. Boot new machine, verify lspci shows the Mesa card
  3. Check grub params — i915.enable_rc6=0 etc. probably not needed on the P330's UHD 630; remove if present
  4. Check /etc/X11/xorg.conf.d/SWcursor/AccelMethod=none workarounds probably not needed either; remove and test
  5. Run LinuxCNC with your hardware ini, check axis homing and motion

Phase 3 — Finish up

  1. Run latency test — P330 should be significantly better than Bay Trail; tune servo thread if needed
  2. Continue SVG label positioning session for the cycles tab

Before you power anything off, let's do the pre-swap checks on this machine while it's running.

All clear:

  • Grub: clean — no old Bay Trail i915 workarounds to remove
  • Xorg: no config files — no SWcursor/AccelMethod hacks needed (good, P330 GPU is fine)
  • mesaflash 3.5.11: already installed

Hardware swap procedure:

  1. Power off old machine, remove Mesa 5i25 from PCIe slot

  2. Install 5i25 in the P330 (it has a PCIe x1/x4/x16 slot — any will work)

  3. Re-connect the ribbon cable to the 7i76

  4. Power on the P330, then run:

    lspci | grep -i mesa
    

    You should see the 5i25 listed. If not, reseat the card before going further.

  5. Then launch LinuxCNC with your config:

    linuxcnc /home/murray/linuxcnc/configs/pb_lathe_murray/probe_basic_lathe.ini

The 5i25 stores the bitfile in onboard flash, so it survives power cycles and the move. As long as you're not changing the firmware configuration (same 7i76 + 8i85 setup), mesaflash won't be needed at all.

That worked fairly well, although some finessing of the lathe cycles was required - more on this later.

Worst of all, adding the lathe cycles seems to have pushed the bottom row of buttons off the screen.

This will require some work....

Sunday, 17 May 2026

VFD speed noisy?

The spindle control on the Bantam / LinuxCNC system seems to be suffering from noise. Although I can set a constant speed demand within LinuxCNC, the VFD itself seems to be having a difficult time maintaining a nice, smooth speed. 

The VFD itself is a rather unusual device, being of New Zealand origin and dating back to the mid 1990s. I acquired a few of these after the demise of Wavedriver Ltd (a maker of electric vehicle drives and components) at the hands of Powergen (national utility company, run by a bunch of grubby thrusters). It works well and is unusual in having a single phase 240V input and a power rating of 5.5kW - most single phase VFDs max out at ~4kW these days, as you are expected to use 3-phase above that sort of power.

Luckily I grabbed a copy of the manual some years back, so I can look up the functions and connections.

Without diving into the detailed info about setting up the analogue inputs (I've already done that of course), this high level diagram tells me what I need to know:


And this is what it actually looks like in the cabinet. The cover is off the VFD and there's a scope and probe draped over the wiring, otherwise it's actually reasonably tidy in there.


And here's the signal connections on the VFD end:

The 3 wires at the VFD that I am interested in are:
  • T13: +10V reference voltage
  • T14: Analogue input 1
  • T15: Analogue 0V

And yes, the screen is already connected to the analogue 0V / ground.

At the other end of the cable, the "digital potentiometer" within the Mesa 7i76 sits on an electrically isolated island, with the signal passed across the isolation barrier by means of a high speed digital opto, followed by a low pass filter and opamp, presumably powered from the +10V analogue reference voltage (although I can't be arsed to check that).

A point worth registering is that the analogue island isn't grounded at either end. There are a few different options here:

  • Ground one or both ends of the cable, noting that the analogue ground and screen are the same (possibly not helpful?), as I seem to recall I ran out of wires in the screened cable. So perhaps grounding the VFD end of the screen would make sense.
  • Slap a cap between the analogue control voltage and the analogue ground / screen - to dampen any differential mode noise. A lossy electrolytic might work here.
  • Put some ferrite clamps on the cable - to attenuate any common mode noise.
Here's what it sounds like - and looks like on the scope. Lots of very energetic bursts of ringing going on there.


  • Result of fitting a ground wire to the screen - zich.
  • Result of slapping a cap on the analogue voltage - zilch.
  • ...and I couldn't find my stash of ferrite clamps, so this will have to wait until a load of Chinese clamps of unknown spec arrive tomorrow.
So although annoying, this isn't critical. However, it's been persisting for a long time and the current hiatus (replacing the PC) would seem like a good opportunity to fix it.

Update: slapped 5 of the ferrite clamps on the signals wires / cables. I'm assuming these are actually some kind of lossy ferrite, of course. Made sod all difference. That's with ground wire, lossy electrolytic and ferrite clamps.

I may be forced to fit a proper modern VFD here but for now I have my hands full, changing the PC from the ASrock J1900 to a Thinkstation P330. 

Saturday, 16 May 2026

Crash prevention for PBL conversational lathe cycles?

When trying out / developing / testing the conversational cycles in Probe Basic Lathe, it's been pretty clear that it would be quite easy to accidentally type in an inappropriate diameter (X coordinate) or axial position (Z coordinate). Humans are good at doing this sort of thing. But worst of all, there's currently nothing by way of a sanity check in the macros to prevent a bad crash. They are pretty robust and straightforward but they expect a degree of responsibility on the part of the user to get the coordinate inputs right.

By experimenting with different starting positions when trying out the macros with air cuts, the result of wrongly specifying X and/or Z coordinates is easy to see on the backplot. In simple terms, the positioning (clearance and positioning) moves are simply based on the starting position and the dimensions of the stock and the feature to be machined, as specified in the setup table. The macro doesn't check the tool position against the outline of the stock you have defined, yet it executes rapid positioning and clearance moves based on that info. What could possibly go wrong?

As you can see, positioning the tool as shown below results in the tool attempting retract and positioning moves within the stock - not ideal: 

Here's a tool start position at 7mm (diameter), with "10mm diameter at corner" ie stock diameter.


Looks almost sensible:


Same operation but with tool, start position at 7mm (diameter), with "10mm diameter at corner" ie stock diameter.


Oooof. Lots of retract and positioninbg moves within the stock:


We can surely do better than this, based on the information at hand.

Quite simply, the plan is for the tool to approach the toolpath from outside the stock in both X and Z. However, if the starting X and Z coords are within the stock outline, an error should be notified and the operation aborted.

Doesn't sound very tricky to implement, so I asked Claude to propose a simple sanity check. 

Good progress. Here's my
suggestion for the sanity checks:
After starting_X and starting_Z are captured (before any motion), add a block that checks:
checks:
Z-side check (wrong side of the face):
  • Front outside / Front inside: starting_Z must be > radius_z (approach from the open/tailstock side)
  • Rear outside: starting_Z must be < radius_z (approach from the chuck side)
X-clearance check (inside the stock):
  • Front outside / Rear outside: starting_X must be > radius_x (outside the OD)
  • Front inside: starting_X must be < radius_x (inside the bore)
In NGC it would look like
this immediately after the starting_X/starting_Z assignments:

o120 if [#<radius_exterior_front> GT 0]
     o121 if [#<starting_Z> LE #<radius_z>]
          (MSG,ERROR: Front outside radius - start tool to the +Z side of the face)
          o121 return [-2]
     o121 endif
     o122 if [#<starting_X> LE #<radius_x>]
          (MSG,ERROR: Front outside radius - start tool outside the diameter)
          o122 return [-2]
     o122 endif
o120 elseif [#<radius_interior> GT 0]
     o123 if [#<starting_Z> LE #<radius_z>]
          (MSG,ERROR: Front inside radius - start tool to the +Z side of the face)
          o123 return [-2]
     o123 endif
o120 elseif [#<radius_exterior_rear> GT 0]
     o124 if [#<starting_Z> GE #<radius_z>]
          (MSG,ERROR: Rear outside radius - start tool to the -Z side of the face)
          o124 return [-2]
     o124 endif
     o125 if [#<starting_X> LE #<radius_x>]
          (MSG,ERROR: Rear outside radius - start tool outside the diameter)
          o125 return [-2]
     o125 endif
o120 endif

One subtlety: the radius_x comparison for front inside is less clear-cut (the boring bar could be anywhere inside the bore), so I'd leave that one out unless you want to add it. The Z-side check catches the most dangerous crash scenario.

Want me to add this to the file?

Let's test this out and see if there are any situations where this might be a problem limiting the desired operation - and if it is actually a useful safety feature in the first place. If it looks helpful, we can then implement similar sanity checks on the other operations.

Here's the equivalent operation in the Radius macro, with this error checking implemented:


There's no machine movement and the error box pops up.

Once the tool position on the X axis exceeds the specified "Diameter at Corner" value, operation is allowed. Sounds like a good result.

Checking with the tool position on the Z axiswithin the stock bounds also works:


That is a win. 

A couple of observations / issues to fix next:

  • The macros will run with T0 ("no tool") loaded, at which point, there's no tool shape shown in the backplot. Is that a problem?
  • It would be handy to have some gridlines shown in the backplot to give an idea of scale. Perhaps autoscaled to suit the operation in hand.
So, let's get the other sanity checks implemented, then get these 2 points resolved.

Tidy up the cabinet wiring

Previously (when I started this build a few years ago), I put work on hold while I wrestled with trying to implement Andy Pugh's macros....