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.

What lives on the Tecnos board, and dies with it¶

10 September 2026. Grant's question: "Ideally we copy all machine behaviours from the old machine, but there might be some behaviour that is stored on the Tecnos board."

⭐ He was right, and the boundary is sharper than this project had assumed.

The architecture, in one line¶

The PC compiles ISO into an executor-language program and streams it to the Syncro board, which runs four concurrent executors. The PLC never sees a toolpath.

   MW310 on the PC  ──compiles──▶  P001.SBL  ──streams──▶  Syncro board
        (ISO in)                  (executor            (4 executors:
                                   language)            motion lives here)
                                                              ▲
   MW310.PLC  ──── CMD "!n ..." strings, and RDQ ─────────────┘
   (sequences)      is the ONLY way the PLC touches motion

🔴 So the split is clean, and it is good news and bad news at once:


✅ Everything sequence-shaped is in the PLC	Interlocks, ATC choreography, HOLD behaviour, fault recovery, zone logic. All of it is captured and portable
🔴 Everything motion-shaped is on the board	Interpolation, blending, following error, in-position windows, the spindle as an axis, E-stop deceleration, override arithmetic. None of it comes across

⚠️ The board's behaviour is configured by Param/Syncro.prm, which is captured. So the numbers survive even though the code does not.

What the retrofit must now implement itself¶

	Lives on	What it is	LinuxCNC equivalent	Effort
B1	PC + board	ISO → executor language, streamed	The interpreter and trajectory planner. Native	Low
B2	Board	Four concurrent executors. The PLC moves axes on `!2` during the tool change while the program runs on `!1`	Collapses — the `M6` remap runs in the one queue. Only the blocking behaviour needs reproducing	Low
🔴 B3	Board	Position loop, feedforward, following error, in-position window, E-stop decel	PID + `FERROR`/`MIN_FERROR` + homing	Medium — needs measurement
B4	Board	Blending, lookahead, corner rounding	`G64 P<tol>` vs `G61`, emitted by the post	Low-Medium
B5	Board	The spindle is an axis. Speed is a DAC ramped as axis S	`spindle.0.speed-out` to the 7I77 analog, with a `limit2` for the ramp	Low
B6	Board	Override applied on the board from the switch bits	`halui.feed-override`	Low
🔴 B7	PC compiler	Spindle-on overlapped with the approach; entry/exit decel; anti-collision; air gap	Generator and post-processor rules. This is the one that quietly costs cycle time if forgotten	Medium
B8	PC HMI	Tool table, per-job clamping toggles, spoilboard thickness, the F5-arms-everything model	GUI work	Medium-High

🔴 B3 is the one that needs real work¶

Syncro.prm gives the board's own servo settings, and they are worth reading before tuning from scratch:


`KEP 190`	Position loop proportional gain
`KVINT` / `KAINT` / `KDINT`	Interpolation feedforward. ⚠️ W is much higher than X and Y (3200 / 1250 / 1100)
`LAG max 5500`	🔴 Following-error trip at 55 mm. That is a very loose limit by LinuxCNC standards
`TOLL.POS 200`	In-position window, 2.00 mm
`DECEMG 40`	Emergency-stop deceleration
`COMP ctl 0`	🔴 No backlash compensation. The machine has never used any

⚠️ The absolute units are still unproven — see mw310-recon.md. Treat the ratios as sound and the absolute figures as pending the axis scaling measurement.

⚠️ sy621.prm and Sy420*.prm are templates for other hardware, not this machine's live set. sy621.prm has VEL max 55000, which is not this machine.

⭐ B7 is the cheap win that is easy to lose¶

The compiled program overlaps spindle spin-up with the approach move:

P001.SBL:44-47   MOR U V        (start the rapid, do not wait)
                 WTQ V2.65      (wait until V is within 2.65 mm of target)
                 SEO 3 / WTT 3  (only THEN start the spindle job)
                 WAM U V

The window is Q_ANTICOLL_V = 265 in pargen.prm. ⚠️ In LinuxCNC the equivalent is to issue M3 before the rapid and gate only the first feed move on spindle.at-speed — not to wait for at-speed before moving at all, which is what a naive translation does and what costs a second on every part.

Also lost with the PC, and all of it belongs in the generator or the post: M111/M112 entry and exit deceleration for vertical boring, the Q.ARIA V air gap, SORMONTO, DCOMPENS. None of these have VP symbols — the PLC never sees them.

⭐ Use the router ram as the rapid, not the Z axis¶

Grant, 11 September: "There is a second air ram that can drive the router up and down, which could be used for rapid router movements whilst the z axis remains stationary."

✅ That is exactly what the original machine did. plc-sequences.md records the PLC plunging and retracting OF.24/OF.23 during ordinary cutting, not just at a tool change.

   set the depth ONCE on Z
   then plunge and retract with the RAM at every position
   Z only moves when the DEPTH changes

🔴 A pneumatic stroke beats a ball screw for a short repeated move, which is why point-to-point routers are built this way at all. A naive post that raises and lowers the Z axis between every feature throws that away and spends the difference on every single hole and pocket.

⚠️ The ram goes to a hard stop — it is binary, not positionable. Depth comes from Z; the ram only supplies the stroke at that depth. So the pattern only works while consecutive features share a depth, and grouping by depth is what makes it pay — the same grouping the drill generator already does.

⚠️ Its stroke is a different number from the drill block's, and had never been recorded — the two were sharing one placeholder in machine.json until 11 September.

🔴 And the one with teeth: horizontal-drill anti-collision¶

ISO.TXT:340   M106  DISABLES THE ANTI-COLLISION FUNCTION OF THE HORIZONTAL DRILLS
ISO.TXT:342   M107  ENABLES  ... (default condition)

⭐ Enabled by default, with an explicit code needed to turn it off. Masterwood treated this as a real hazard — and they had the machine in front of them.

Why it matters more than it looks: each horizontal head carries a bit on each end, pointing opposite ways, and one output fires both. Only the bit facing material cuts; the other swings out into free air. ⚠️ The bit that is not cutting is the one that breaks things.

🔴 No reference to it anywhere in MW310.PLC — compiler or board function, gone with the PC. ⭐ Rebuilding it is real retrofit work, and it belongs in the generator, where the part geometry is known, rather than in HAL.

⚠️ What this does NOT change¶

The retrofit boundary is unaffected. retrofit-boundary.md still stands: eight connectors on the Housing's front panel, no field wiring touched. This page is about software behaviour, not wiring.

And the PLC is still the specification for everything it covers. The sequences, the interlocks, the timings, the fault recovery — MW310.PLC is captured, readable, and it is the machine's real design. The board only ever did the moving.

Worth settling before the PC goes¶


`VRot.10V` on the router spindle screen	The rpm at 10 V. Sets the analog scale for the retrofit, and it is on the HMI, not in any file
The HMI "Coupling value / Releasing value", and each pocket's "Value 1 / Value 2"	The ATC's per-tool Z and Y positions. See `atc-operation.md`
Watch one tool change	Does Z visibly travel between two heights? Settles the above without needing the numbers

machine-timings.md — the PLC's own durations, and why time.prm was the wrong file
atc-operation.md — the tool-change choreography
mw310-recon.md — the unit question on the axis figures
retrofit-boundary.md — the wiring boundary, which this does not change

🔴 WHICH parameter set is the board actually running? Three differ on disk¶

Found 12 September 2026 by review, and it undercuts a lot of this page.

Every "the machine's own value" claim about axis velocity, acceleration and homing offset assumes the live Param/Syncro.prm is what the board holds. Three different sets are in the capture:

File	X `VEL max`	X `ACC max`	X `Q.TARAT`	Y `VEL max`
`Mw310/Param/Syncro.prm` (live)	30000	1200	−1000	25000
`Mw310-Copy-backup/Param/Syncro.prm`	40000	2000	−1000	35000
`Mw310/Sv/PARM.PRM.tilde` (`#384`)	40000	1400	🔴 0	35000

⭐ The third set is not just the pre-detune pair. It has its own acceleration (1400, matching neither) and, more importantly, Q.TARAT = 0 where the other two say −1000.

🔴 Q.TARAT is the X homing offset. homing.md says "Q.TARAT on X is −10.00 mm, not zero. Carry that offset into HOME_OFFSET or X will home 10 mm out." If the board is running the third set, HOME_OFFSET should be 0 and the current INI value of −10.0 homes X ten millimetres out.

🔴 And the parameters are NOT sent automatically at startup¶

English/messaggi.txt shows parameter and PLC transmission as explicit operator actions, not startup behaviour:

Line	Message
5	"Execute general data transmission?"
6	"Parameter transmission"
7	"PLC transmission"
158	"Save and transmit parameters"
159	"Send PLC"
441	"QUIT AND START AGAIN MW310 TO ENFORCE THE PARAMETERS SET!"

⚠️ So the board keeps its own copy and a disk file is only what someone last chose to send. The three files could be a working copy, a backup, and a set that was edited but never transmitted. Nothing on disk says which the board took.

⭐ But the board will hand its own set back, and it has done so before¶

Sv/SV32.log records exactly that, on 5 March 2008:

17:49.8  - Richiesta Parametri Macchina a Syncro...      (request machine parameters from Syncro)
17:49.20 - Lettura parametri ricevuti...                 (reading received parameters)

Twelve seconds apart, board to PC. The parameter set is readable out of the board over the serial link.

🔴 This reinstates the serial tap, for a different reason¶

HANDOVER.md dropped the tap: "software-only is dead, so there is nothing to tap." ⚠️ That reasoning does not cover this. Speaking the protocol is dead; listening is the only way to learn what the board holds, and the board is about to be thrown away with it.

✅ A listening tap is cheap and safe. serial-port.md establishes the PC-to-Tecnos cable is a three-wire null modem with no handshake lines, so a passive Y-tap needs no com0com, no hub4com, and no change to Mw310.ini — there is nothing to roll back.

What to do, once, before the board goes:

Y-tap COM1, two spare serial ports, listen only. 19200, ACKNACK.
Cold-start MW310 and record. Note how long startup takes.
If a service tool can safely issue "Richiesta Parametri Macchina", capture that too. ⚠️ Read-only. CLAUDE.md warns the Sv tools speak TCBIN, not the HMI's ACKNACK, and service tools can write.

⭐ Startup duration alone is informative. At 19200 baud a 352 KB PLC upload takes about three minutes and 5 KB of parameters about three seconds. A fast start means the board is running its own copies of both.

🔴 What is lost if this is skipped: which parameter set the machine actually ran for twenty years. That is the reference every axis constant in the retrofit is being set against, and it cannot be recovered from the disk.