Skip to content

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.

🔴 CORRECTED 10 September — this page was reading the wrong file

Everything below was taken from Param/time.prm. The PLC never reads that file.

⚠️ time.prm is a PC-side table edited by the Timing32 tool (Timing.lng: "Punto OS / Punto T / Tempo (ms)"). No VP symbol maps to it. The machine's own durations are in Param/pargen.prm, reached through the TMnn symbols in MW310.PLC.

⭐ The PLC names the parameter in its own comment, which is as direct as evidence gets:

MW310.PLC:1637    EQU  TM11 ,VP.941 ;Tempo attesa battute giu' allo START
MW310.PLC:53450   DELJ 2,TM11       ;e attendo TIME11
pargen.prm:135    "TIME11      " 500
This page said Actually
🔴 Stop dwell 1500 ms 500 ms (TIME11)
🔴 Vertical drill descent 100 ms, "the PLC's ceiling" 300 ms (TIME02)
Saw / horizontal drills 1000 ms 100 ms (TIME04) — ⭐ and after a confirmation, not a blind dwell

The mapping is cross-checked two independent ways: TM42/TIME42 = 300000 ms matches error 1031's text ("not positioned against stop within TIME42"), and TM24/TM25 match the lube interval and pulse.

✅ The machine's real durations

Parameter Value What it is
TIME01 15 s CNC-OK delay after an emergency
TIME02 300 ms Vertical drill descent. 🔴 The only guarantee there is — no down sensor
TIME03 1000 ms Router ram plunge ("tempo lancio")
TIME04 100 ms Horizontal drills and saw, after the up-sensor goes low
TIME05 / TIME06 1000 / 200 ms Counter-pressure pulse ON, then OFF settle
TIME08 1000 ms Drill-motor restart delay after a HOLD
TIME11 500 ms Stops down at START
TIME24 / TIME25 6000 s / 8000 ms Ballnut lube interval (running time) and pulse
TIME40 200 ms Tool-present debounce before the presence test
TIME51 300 ms After drawbar release, before waiting for piston-down

⭐ This closes most of "the durations still to measure". They are not guesses and not stopwatch figures — they are what the machine has run on for years. ⚠️ They are still the PLC's ceilings and settle times, so halscope remains the way to tighten them if cycle time ever matters.

🔴 And one of them is not a dwell at all

The saw does not guess. MW310.PLC:41681: it commands the head down, then waits for the blade's UP sensor to go LOW — proving the head actually left the top — and only then waits TIME04.

⭐ That is strictly better than the blind dwell this project had written, and it uses a sensor that was already in the I/O map. nc_subs/saw_engage.ngc now does the same. There is still no blade-down sensor, so it is not proof of depth — but "it left the top" is a fact, and 1.2 seconds was not.

The machine's own timings

3 September 2026. Param/time.prm is a plain-text table of the machine's timer values, with descriptions. Combined with two constants in MW310.PLC it gives the real numbers for almost everything the retrofit has to reproduce.

None of this needed the machine running.

🔴 The stop dwell — the number my interlock was guessing at

EQU  TM11, VP.941    ;Tempo attesa battute giu' allo START
                     ;"wait time for stops DOWN at START"

 OS   T  Time Description
  6   6  1500 Battute giu'

~~1500 ms~~ — SUPERSEDED, see the correction above

🔴 CORRECTED 11 Sep 2026: the stop dwell is 500 ms, not 1500 ms. The 1500 ms came from time.prm, which is PC-side and was the wrong file. The machine's own value is TIME11 = 500 ms in pargen.prm, and tuchop-sim.ini uses STOP_DWELL = 0.50. Text below that still says 1500 ms or 2 s is superseded.

✅ This confirms the interlock design and corrects the number. The spindle interlock in linuxcnc-sim/tuchop-io.hal waits after the stops are commanded down before permitting — which is exactly what TM11 is for. I had used 2000 ms with a note saying "start here and reduce by measurement".

~~The machine's own value is 1500 ms, and the sim now uses it.~~ ⚠️ SUPERSEDED: 500 ms (TIME11, pargen.prm). time.prm was the wrong file.

⚠️ Note what kind of number this is. There is no sensor on the stops, so this cannot be a timeout waiting for a confirm — it can only be a delay, allowing time for the air to act. That is why it is directly usable as the interlock dwell rather than as a maximum.

The two global timeouts

EQU  TIMEOUT  ,7000      ;7 seconds
EQU  TIMEOUT2 ,25000     ;25 seconds

Every WAITTIM in the PLC uses one of these:

Used for Value
Gripper up/down, change piston, tool present TIMEOUT = 7 s
Carousel position reached, carousel home TIMEOUT2 = 25 s

🔴 toolchange.ngc was using 10 s for everything. Corrected: 7 s for the gripper and piston waits, 25 s for the carousel. The carousel gets far longer because it may have to index most of the way round.

The rest of the table

Function Time Notes
Punte Up/Down — drills 100 ms Very fast, consistent with a short pneumatic stroke
Lama aggregati Up/Down — saw 1000 ms
Pantografo su/giu' / Inverter ON/OFF — router head 2500 ms
CU4/5/6/10 — tool change 7000 ms Matches TIMEOUT
Park axes before program start, or on END-CYCLE 3000 ms
Cambia DAC 500 ms
Gestione I/O programmabili 2000 ms
Rientro lancio 2 500 ms
Fine tastatura / Tasta X / Y / Z 2000 ms Probing — not fitted here
Anuba loading, pressing, drilling 100-1500 ms Hinge unit — not fitted here
Loader bar, automatic load, workpiece transfer 1000-3000 ms Not fitted here

⚠️ Roughly half this table is for hardware this machine does not have — the Anuba hinge unit, the bar loader, the probe. As with the fault codes, presence in the table is not evidence the hardware exists.

🔴 Timeout versus duration — the distinction that matters

These values are mostly maximums, not measurements. A WAITTIM gives up after the timeout; the actual motion is usually much faster.

Where a value IS the real duration Where it is only a ceiling
Stops down, ~~1500~~ 500 ms — no sensor exists, so it can only be a delay Anything with a confirm input: gripper, piston, carousel, head retract

So:

  • ✅ Use ~~1500 ms~~ 500 ms directly as the stop dwell. ⚠️ SUPERSEDED: 500 ms (TIME11, pargen.prm). time.prm was the wrong file.
  • ✅ Use 7 s / 25 s directly as M66 timeouts — that is exactly what they are.
  • ⚠️ Do not read "Punte Up/Down 100 ms" as "a drill takes 100 ms to drop". It means the PLC gives up after 100 ms. The real stroke time still wants measuring with halscope.

⚠️ The router plunge has no down-confirm input — IF.10 only confirms up. So plunging is blind and needs a delay; retracting can wait on IF.10 with the 2500 ms ceiling. The plunge delay is the one number still genuinely unknown.

What this changed in the sim

File Was Now
tuchop-io.hal stop dwell 2.0 s 1.5 s
nc_subs/toolchange.ngc all timeouts 10 s 7 s, carousel 25 s
nc_files/drill-demo.ngc G4 P0.5 between drills G4 P0.1, with the ceiling caveat
nc_subs/router_retract.ngc 3 s timeout 2.5 s
  • machine-parameters.md — pargen.prm, the configuration switches
  • plc-sequences.md — the sequences these timings belong to
  • plc-fault-codes.md — what happens when a timeout expires