Working documentation

This page is generated from the project's working notes. It records a real retrofit in progress, corrections included. Anything marked 🔴 or ⚠️ is unresolved or carries a caveat - read those before acting.

Could the retrofit be software only - LinuxCNC talking to the Tecnos?

2 September 2026. Grant's question: the reason for the retrofit is the Masterwood software, the hardware is fine, so what are the chances of getting LinuxCNC to talk to the cards in the Housing and doing the whole thing in software?

The short answer

Two of the three ways to read that question are closed, and the third is not LinuxCNC. But the premise is right, and the Mesa build already answers it - see "The reframe" at the end.

Why: the Tecnos is not a card set, it is a complete CNC

This is the fact everything else turns on, and it is settled from the machine's own disk, not from assumption.

Evidence on the rp5800	What it proves
Param\Syncro.prm per axis: KEP 190 (position gain), KVINT, LAG max 5500, VEL max, ACC max, TOLL.POS	The Tecnos closes the position loop and generates the velocity and acceleration profile
Param\Syncro.prm interpolation block: VEL_INT 25000, ACC_INT 150, ARMAX 45000, TOLLER 100, EN_OVER 1	The Tecnos does multi-axis interpolation and look-ahead
TXFLASH.EXE + Sv\SyMono.sc0	It runs its own flashable firmware
MW310.BIN, compiled from MW310.PLC	The PLC runs on it, not on the PC
Profi.exe	Machine parameters live on it
Mw310.ini: COM1 Syncro=ACKNACK, Modo assi=N.C.	The PC talks to a numerical control, not to a DAC

MW310 on the PC is a WOP front end and a loader. It draws parts, generates programs, and pushes programs, parameters and the PLC binary down the wire. It does not do motion.

LinuxCNC is also a complete CNC, and its value is precisely the job the Tecnos already occupies: trajectory planner, look-ahead, interpolation, and the position loop at 1 kHz. The two do not stack.

Reading A - LinuxCNC commands the Tecnos over COM1

❌ Closed, on arithmetic.

Link capacity	19200 baud, 8-N-1 ≈ 1,920 bytes/s
A 1 kHz servo loop, four axes, needs	order of 24-48 kB/s for commands alone, before feedback
Shortfall	more than 20x, before latency or determinism is even discussed

It is a program-feed and command channel, not a motion bus. That is not a limit to engineer around - it is the wrong kind of link.

And even at infinite bandwidth, LinuxCNC has no architecture for this. Every external-motion project - Mesa's own cards, Remora, the ESP32 controllers - keeps LinuxCNC's planner and delegates only the last step: pulse generation or a DAC value, over a fast deterministic link. None of them delegate interpolation. There is no driver, and writing one means removing the part of LinuxCNC that is the reason to use it.

What you would actually be building is a bespoke replacement for MW310 that happens to be written on top of LinuxCNC. That is reading C.

Reading B - LinuxCNC talks to the Syncro axis card directly, bypassing the M68K

❌ Effectively impossible.

The Syncro is a proprietary daughterboard on a 2002-vintage 68000 bus (M68K_99AC_01). To drive it from a PC you would need to:

1. Reverse-engineer an undocumented bus from the silicon
2. Build a physical host interface to a bus that has no host connector
3. Write a realtime kernel driver for it

That is a multi-year project, the result is a one-off nobody can support, and there is no guarantee at any stage. Public search finds no documentation of the Tecnos bus or its serial protocol anywhere - the only hits are eBay listings for the boards themselves.

Reading C - keep the Tecnos, replace only MW310

⚠️ Genuinely doable. Not LinuxCNC, and a bigger job than the Mesa build.

This is the honest "software only" option: leave every board in place, reverse-engineer the serial protocol, and write new PC software that speaks it.

What it costs:

Protocol, read side	The tap plan already exists, and a cold-start capture yields a full parameter dump. A weekend
Protocol, write side	Safely commanding motion on a machine with an 8 kW spindle and 2.8 m of travel. Months, and a malformed frame is a real hazard
Then	HMI, program loader, tool table, and a CAM post for the Tecnos dialect - all from scratch
You inherit	The Tecnos interpolator, its look-ahead and its limits. The machine still behaves like a 2002 machine
Support	None. No community, no documentation, nobody to ask
Still true afterwards	Single-source on a 24-year-old board with a battery-backed parameter store
Also	The Mesa cards are bought and become redundant

The one fair argument for keeping the Tecnos

It is already tuned. Under Mesa, LinuxCNC closes the position loop and three axes need PID tuning - that is the main commissioning risk left in the current plan. The Tecnos has that solved and proven over a decade.

KEP 190, KVINT 605 / 905 / 3200 and LAG max 5500 give a starting point for the LinuxCNC PID, and the drives themselves stay in their own proven velocity loop, which is the harder half. So the risk is real but bounded, and it is one commissioning session rather than a rebuild.

🔴 The reframe - the Mesa build already is the software-only retrofit

Grant's premise is right: the hardware is fine and the software is the problem. But the Tecnos is not hardware in the way the drives are. It is a computer running proprietary software - firmware in flash, parameters in battery-backed RAM, a PLC binary. It is the same class of problem as MW310, not part of the healthy hardware.

And the Mesa build keeps everything that is genuinely healthy:

Stays
All three Yaskawa drives	In their existing analog velocity mode, parameters untouched
All four motors, the spindle, the VFD, the carousel indexer	Untouched
Every sensor, valve, switch, photocell and the rope switch	Untouched
Every field wire and every field termination	Untouched
The IF1-IF6 / UF1-UF6 I/O modules	Untouched - Mesa connects at the ribbon
The safety chain, the Z brake, overtravel, the drive-OK relays	Hardwired, untouched
The homing method	Reproduced exactly, on the same switches and the same index

Exactly one board is replaced - the one that runs the obsolete software. Eight connectors and three cards.

That is the software-only retrofit. It just also swaps the computer that runs the software, for one that is documented, supported, and still made.

What would change this answer

If the Tecnos were a dumb DAC-and-counter card with the PC doing motion	Reading A would open up. The Syncro.prm interpolation block rules it out
If someone had published the Tecnos protocol	Reading C would get much cheaper. Searched 2 Sep 2026: nothing public
Photos of the Housing boards	Would not change the verdict - this is answered by what is on the disk, not what is on the board. A close photo of the Syncro daughterboard's chips would tell us whether motion is done in a standard motion-control IC or in the 68000, which is interesting but does not create a host interface

Related

• serial-port.md - the link, the protocol names, and the tap plan
• mw310-recon.md - Syncro.prm, pargen.prm and the full software inventory
• plc-toolchain.md - TXFLASH.EXE, Profi.exe, Comdrv.exe and what each reaches
• retrofit-boundary.md - what the Mesa build actually touches
• mesa-wiring-schedule.md - the build itself