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.

Operating the MW310 — the file model, tool numbering, and how a job runs¶

5 September 2026. From the machine's own disk: PROG\, Utensili\, Defs\, tabuten.tmp, English\ISO.TXT, English\messaggi.txt, and the MW310.PLC comments.

⚠️ This is not a manual and there isn't one on the box — the only English document on the machine is MSystem\EN - Working with DXF.doc, which is about DXF import. What follows is reconstructed from the machine's own files, including two real working job programs left by a previous owner. Where I am inferring rather than reading, it says so.

⚠️ Nothing here is an instruction to run anything. Running a program moves the head and rotates a loaded carousel.

1. The file model¶

Four kinds of file, and they stack:

	Where	What it is
Tool	`Utensili\*.utn`	One file per cutter or bit — diameter, length, speed, description
Program	`PROG\*.PRG`	The actual toolpath, in Masterwood ISO
Sequence	`PROG\*.seq`	Assigns programs to the machine's fields, with the panel size
Tool table	`tabuten.tmp`	The live list of what is loaded where. Generated, not hand-edited

A job is: tools defined → program written → program placed in a sequence → sequence run.

The tool file, `.utn`¶

Thirteen lines, no labels. Decoded by comparing several:

1        type: 1 = router cutter, 0 = drill
0
950      diameter, hundredths of a mm   -> 9.50 mm
8180     length,   hundredths of a mm   -> 81.80 mm
18000    spindle speed, rpm  (0 for drills)
0
9.5 Finishing Cutter        <- description, this is what shows on screen
Fresa 1.bmp                 <- icon
1
20
0
0

⚠️ Lines 2, 9, 10, 11 and 12 are not identified. Line 10 varies (20, 5, 25, 0) and is not the carousel pocket — see below.

⚠️ The filenames lie. 6mm router.utn contains the description "9.5 Finishing Cutter". Trust the description inside the file and the tool table, not the filename.

The sequence file, `.seq`¶

PROG\Singolo.seq, complete:

%
|
C1 0 'tool park.TLF' 800 16 500 ''
C2 0 '' 0 0 0 ''
C3 0 '' 0 0 0 ''
C4 0 '' 0 0 0 ''
R1
%

C1 to C4 are the four fields — the machine's A/B/C/D. On this machine only C1 (zone 1) and C4 (zone 2) correspond to real hardware; B and C have no stops or clamps fitted (see zones-and-loading.md).

The three numbers after the program name are length, thickness, width — 800 16 500. Confirmed because they match the |4 |5 |6 header of P20000.PRG exactly.

R1 is the repeat count.

The program header¶

Every .PRG opens with a numbered block:

|4 2700       panel length  (X)
|5 6.10       thickness
|6 1215       panel width   (Y)

Read off Window Box Facia no holes.PRG (2700 × 1215 × 6.10) and P20000.PRG (800 × 500 × 16). The other header lines are not identified.

2. 🔴 The tool numbering, from this machine's own table¶

tabuten.tmp is the live tool table, and it decodes the T word completely:

 1 : 4mm vertical drill bit
 2 : 8 mm vertical drill bit
 4 : 35mm vertical drill bit
 5 : 10 mm vertical drill bit
 6 : 5 mm vertical drill bit
 7 : 5 mm vertical drill bit
 8 : 5 mm vertical drill bit
 9 : 5 mm vertical drill bit
10 : 5 mm vertical drill bit
25/1 : 80 mm router
25/2 : 9.5mm MDF Cutter
25/3 : J Pull
25/4 : 6mm Cutter
25/5 : 9.5 Finishing Cutter

Two different things share the T word:

Form	Means
`T1` … `T10`	A fixed drill spindle. No tool change — the PLC just fires that spindle's output
`T25/n`	The router, with carousel pocket `n`. This is what triggers a tool change

So 25 is the router head and the number after the slash is the pocket. That matches ISO.TXT, which describes the T word as "Tool number (T),(Tn,m,..),Tool changer (Tn/m)" — the Tn/m form is the tool-changer form.

✅ This is the machine's own working data, not a guess. Five tools were loaded in pockets 1 to 5.

⚠️ Whether those five are still physically in those pockets is unknown. Check the carousel against this list before running anything — the tool table is software state, and if it disagrees with the metal, the tool change will fault (see atc-operation.md).

3. 🔴 How a tool change is actually commanded¶

Not by an M-code. The tool is declared in the routing setup block, and both real programs on the machine do exactly this:

G172 X9.02 Y=#902 Z0 S18 E1 T25/2


`G172`	Selection of start point, tool, speed, entry speed
`X` `Y` `Z`	Start point
`S18`	Routing speed
`E1`	Entry (penetration) speed
`T25/2`	Router, carousel pocket 2 — the 9.5 mm MDF cutter

When the interpreter meets a G172 (or G173) asking for a tool that is not the one mounted, it raises OS.51, and that is what starts the PLC's tool-change cycle. M60 unloads a tool without loading another, taking K as the spindle number.

⚠️ S18 is unexplained. The tool file for a 9.5 mm cutter carries 18000 rpm, so S18 is most likely thousands of rpm — but that is inference. Do not rely on it.

4. How a job runs, start to finish¶

Reconstructed from the PLC's own comments plus the zone logic:

1.  Choose the sequence / program
2.  Press  F5  =  ESECUZ  (Execution)
        -> runs JOB 54, which loads the program into the field(s)
        -> starts JOB 5, the supervisor
3.  JOB 5 enables that zone's pedal and lights its lamp
4.  Clamp the panel with the pedal
        press+release once  -> stops up, table floats, vacuum off
        press+release again -> panel set down, vacuum on, lamp steady
5.  Press that zone's START button  (IF.1 zone 1, IF.2 zone 2)
6.  The program runs. Each G172 with a new T25/n fires a tool change.

F5 is the execution key. MW310.PLC names it three times:

;*** JOB #54 INIZIALIZZAZIONE PROGRAMMA NEI 2 CAMPI (CON TASTO F5-ESECUZ) ***
;*** FINE INIZIALIZZAZIONE JOB 5 CON TAST F5-ESECUZ
;*** (SIA PER TASTO F5-ESECUZ CHE PER BAR CODE)

🔴 Step 2 is the one that is easy to miss. Nothing arms — not the pedal, not the start button, not the tool changer — until a program has been loaded with F5. Until then the machine does not respond, by design.

⚠️ Correction, 6 September. An earlier version of this said "the pedal genuinely does nothing", which overstated it. The pedal input is live at the hardware level and lights its cabinet LED whenever it is pressed (Grant, at the machine). What F5 gates is the PLC's response to it, not the signal. So a pedal press before F5 is read and ignored, not lost.

✅ And this is a Tecnos software fact with no carry-over. The pedal is an input on a card; the retrofit decides what it does. Nothing here constrains LinuxCNC.

5. There are two working programs already on the machine¶

Both left by a previous owner, both in English, and both perform tool changes:


`PROG\Window Box Facia no holes.PRG`	2700 × 1215 × 6.10. Several `G172 … T25/2` blocks with `G41`/`G42` cutter compensation and `G102`/`G103` arcs
`PROG\P20000.PRG`	800 × 500 × 16. Simpler — two rectangles, both on `T25/2`

P20000.PRG is the better one to read, and probably the better one to study before writing anything: it is short, it is a plain rectangle, and it shows the whole structure.

What the programs show about the coordinate convention¶

#910=DX
#911=DY
#902=#911-(683.90)
G101 X13.77 Y=#902 Z0 F20

DX and DY are the panel dimensions from the header. Every Y coordinate is computed as DY − offset, so the programs are written from the far Y edge, not from zero. Worth knowing before reading any coordinate in them, and worth reproducing or deliberately not reproducing when the CAM post is written.

G101 is linear, G102/G103 are arcs, G41/G42 are cutter compensation left/right, G40 cancels it, G120 K1 opens the working face.

6. The setup screens, with their real labels¶

The Defs\*.def files are the HMI screen layouts. Each field points at an index into messaggi.txt, so the English labels can be recovered exactly:

⚠️ Two of these screens carry heights, at two DIFFERENT levels, and it is easy to read one and think the job is done:

Screen	Fields	Scope
Tool magazine (`Magazzino.def`)	`QUOTA_CARICO` / `QUOTA_SCARICO` = Coupling value / Releasing value	One pair for the whole carousel
Carousel tool (`UtensileCU.def`)	`QUOTA1` / `QUOTA2` = Value 1 / Value 2	One pair per pocket

🔴 How the two levels combine is not known. Is the per-pocket pair absolute, or an offset from the magazine pair? Reading both settles it by inspection: values in the Z travel range (roughly -200 to 0 mm) are absolute, values of a few mm are offsets. Read both screens in the same sitting or the question stays open.

Tool magazine (Magazzino.def) — the carousel itself:

Field	Screen label
`TIPO`	Tool magazine type
`QUOTA_CARICO`	Coupling value
`QUOTA_SCARICO`	Releasing value

Carousel tool (UtensileCU.def) — one row per pocket:

Field	Screen label
`NUMERO`	Number
`TIPO`	Type
`QUOTA1` / `QUOTA2`	Value 1 / Value 2
`ANGOLO`	Ref. t.
`EN_BAND`	Enable finger curtain
`LANCIO`	Projection

Router spindle (MandrinoCU.def):

Field	Screen label
`OFF_U` / `OFF_V` / `OFF_W`	Offset U / V / W
`VMAX`	Rot.spd.
`V10V`	VRot.10V — the rpm at 10 V, i.e. the analog spindle scaling
`TIPO_CU`	T.C.
`TIPO_LAN`	Projection

🔴 VRot.10V is worth finding on screen. It is the machine's own record of how many rpm the spindle turns for a 10 V command — which is exactly the number the LinuxCNC spindle scaling needs, and it is sitting in a settings screen rather than having to be measured.

⭐ `Param/TAB01.DAT` — the tool table, and it is NOT empty¶

Found 12 September 2026. The screens above are layouts; this is the data behind them, and it was already in the capture.

First, what the two blocks ARE¶

The file has two differently-shaped blocks, and they are two different kinds of tool:

	Spindle tools (rows `1`-`50`)	Carousel tools (rows `C 1`-`C 99`)
What	The fixed spindles on the drill/saw head - the ten vertical drills	Router cutters in tapered holders, living in the carousel
How addressed	By bare number, `T1`-`T10`	As `25/n` - magazine 25, pocket n
Tool change?	None. They never move. Selecting one just fires its air ram	Yes. The ATC swaps one into the single router spindle
How many	10 configured, one (`3`) blank	🔴 8 physical pockets, only 5 configured

⭐ So "tool change" only ever concerns the carousel block. The drill block needs no tool change at all, which is why a row of shelf-pin holes is one plunge and why the drills can be used while a router tool is loaded.

🔴 The 8 comes from pargen.prm's EN_CU_6 = 8, not from this file. Only C 1-C 5 are populated here, so counting rows gives 5 and gives the wrong answer. See atc-operation.md.

✅ All 8 will be in use after the retrofit (Grant, 12 September), so the three never-configured pockets stop being a historical curiosity and become three more rows to fill.

The data¶

Two blocks in one file:

Spindle tools, rows 1-50 (10 populated). Format: n length diameter ... shape-file

n	Length	Dia	What
1	67.80	4.00	4 mm vertical drill (the broken one)
2	69.00	8.00	8 mm reverse
3	—	—	all zeros, consistent with `tabuten.tmp` having no entry 3
4	68.60	35.00	The hinge borer
5	68.80	10.00	10 mm reverse
6-10	68.00	5.00	The five 5 mm drills

Carousel tools, rows C 1-C 99 (5 populated), matching pockets 25/1-25/5:

Pocket	Length	Dia
`C 1`	88.70	80.00
`C 2`	78.90	9.50
`C 3`	79.00	50.00
`C 4`	70.00	3.00
`C 5`	81.80	9.50

Values are hundredths of a millimetre.

✅ The diameter column is proven¶

Column 3 reads 400, 800, 3500, 1000, 500×5 against drills independently known from the head photograph to be 4, 8, 35, 10 and five of 5 mm. Ten out of ten. That is not a coincidence and it fixes the column.

⚠️ The length column is inferred, not proven¶

Column 2 sits between 67 and 89 mm, which is the right order for these tools, and it varies per tool the way a length should. But nothing in the capture says what it is measured FROM. Gauge line, spindle nose, or block face all give plausible numbers and differ by tens of millimetres.

🔴 So do not load these into tool.tbl yet. A confident tool length against the wrong datum drills every hole to the wrong depth, and it looks right on screen. The datum is the open question, and it is settled by touching one known tool off a known surface at commissioning, not by more file reading.

🔴 And the five carousel lengths are now HISTORICAL, whatever the datum turns out to be¶

Grant, 12 September 2026: the cutter bits have all been removed from the tapered holders.

⚠️ So C 1-C 5's lengths describe tools that are no longer in the machine. Whatever goes back into those holders will stick out by a different amount, and the recorded 88.70 / 78.90 / 79.00 / 70.00 / 81.80 mm apply to none of it.

🔴 And it is EIGHT measurements, not five (Grant, 12 September): all 8 pockets are being loaded. Five stored lengths are stale and the other three pockets were never configured at all, so the whole carousel block is measured from scratch at commissioning, regardless of what the datum question resolves to. Unlike the drill block there is no single common offset to find, because each cutter is a different length in a different holder.

✅ The drill block block is different, and still live. Those ten spindles are fixed in the head and nothing has been taken out of them, so rows 1-10 still describe the real machine — with one exception:

🔴 T1's 67.80 mm is stale too. T1 is the 4 mm drill, and it is the broken one (leftmost in the head photograph). The table records the length it had before it snapped. It is the one row in the spindle block that must not be trusted, and machine.json already carries usable: false for it.

⭐ What the numbers are still good for¶

Even unusable as absolute lengths, they are not worthless:

The diameters are directly usable and confirm the head photograph independently.
The drill lengths cluster at 67.80-69.00 mm across ten different bits in one block. That tightness says the datum is something common to the head, and once one tool is touched off, the same offset should correct all ten rather than each needing its own measurement.

⚠️ The `.utn` filenames have drifted from the data¶

C 4 is named 3mm roter.utn and carries diameter 3.00 ✅, but tabuten.tmp calls pocket 25/4 a "6mm Cutter". C 5 is named 6mm router.utn and carries 9.50. Trust the diameter column, not the filename — the .utn file is a shape reference for the screen drawing and has been reused without renaming.

7. 🔴 Running without a vacuum pump¶

Short answer: yes, you can, and the machine has a designed switch for it.

The vacuum check is CHK_VUOTO, and it is gated three ways. It fires only when all of these hold:

Gate
`MCHK_VUOTO`	Armed by `OS.24` at program start and disarmed by the same bit at program end. Outside a running program the check does not exist at all
`MFLAG_VUOTO_A` (or `_D`)	The per-field Vacuum toggle. Off for that field → skipped entirely
`MPRGCAMPOA` (or `_D`)	That field must be the one executing
not `MEND_CYCLE_PARK`	No check during end-cycle or park

Plus a 2 second grace period (DEL1 … DUESECONDI) after it arms, so a pump still spinning up is not an instant fault.

CHK_VUOTO_04
    AND  MAPPOGGIO,MFLAG_VUOTO_A,MPRGCAMPOA
    TEST MAPPOGGIO           ;vacuum A ON *and* A executing ?
    JPNZ CHK_VUOTO_GENERALE  ;only then is IF.9 tested

If it does fire and IF.9 is low, the fault is 1006.

The switch to use¶

Turn the field's Vacuum toggle OFF on the clamping setup screen — the same screen that carries PEDALE / AUTO for the stops (zones-and-loading.md §10). It writes bit 0 (field A) or bit 3 (field D) of VTIPO_VUOTO, VV.33.

That is the machine's own mechanism for a job that does not use vacuum — a jig, a template, a mechanically clamped part — not a workaround.

ISO.TXT also lists M203 VACUUM CONTROL MANAGEMENT, taking K as a parameter list, so a program can manage it too. The parameter list is not documented on the box.

What is unaffected either way¶

Jogging, homing, setup and manual moves — no program running, so no check
Clamping and START — MBLOCCO_PEZZO is set by the pedal cycle and never reads IF.9
The tool change — JOB 48 does not test vacuum anywhere

And what the per-field sensors would have done¶

IF_VUOTO_AEI and IF_VUOTO_DHL are both on the OF.254 not-present sentinel. The only real vacuum input on this machine is the general one, IF.9. So there is a single check to satisfy or disable, not three.

⚠️ The obvious caveat¶

Disabling the check does not hold the panel down. It only stops the controller complaining.

For proving the ATC, the motion and the program structure, run with nothing on the table at all — no panel, no cutting, nothing to throw. The pedal cycle still has to be performed to set MBLOCCO_PEZZO and permit START, but it can be performed against an empty bed.

Cutting without hold-down is a different matter entirely and is not what this section is licensing.

8. ✅ "Reading Syncro configuration...fail!" — RESOLVED 5 September¶

Cause: the serial cable was in the wrong port. Confirmed and fixed by Grant; the Syncro connects normally again.

The trigger was fitting RAM to the rp5800. The PC has two onboard serial ports, and after the hardware change the cable ended up on the wrong one. MW310 opened COM1 exactly as configured, reported "done", and then got no reply — because the Tecnos was on the other port.

🔴 Label the port and the cable at the PC. This will recur every time that machine is opened, moved or re-enumerated, and it presents as a controller fault rather than a cable fault. Thirty seconds with a label maker is the fix.

⚠️ Record which port it is now, in serial-port.md, so the next person does not have to rediscover it.

The diagnosis below is kept because the reasoning generalises — it is how to tell a dead controller from a mis-plugged cable, and the two look identical from the machine's own error message.

The startup log read:

Starting COMDRV driver...done.
Opening port for Task main...done.
Opening ports for other Tasks...done.
Opening port for BARCODE...done.
Connecting to SYNCRO by RS232.
Reading Syncro configuration...fail!      <-
Reading message file...done.
Reading machine parameters...done.
done.

What the log actually says¶

The port opened. Nothing answered.

Three separate "Opening port…done" lines succeeded before the failure, so Windows, the COM port number, the driver and the PC end of the cable are all fine. A wrong port, a missing driver or a port already in use would have failed at Opening, not at the first conversation.

The failure is at Reading Syncro configuration — the first exchange where the Tecnos has to reply. So: the far end is not talking.

⚠️ MW310 carries on and finishes with "done." The HMI comes up either way, so a successful launch is not evidence the link is good. Without the Syncro there are no axes, and the axis faults will appear later.

The supply chain to check, exactly¶

🔴 The Tecnos runs on 24 V AC, and the chain is short and fully documented:

-T3 transformer  (0-24 V, 250 VA secondary)
   -> -F13   6 A GL fuse
      -> wires 9 and 10
         -> -CNC pins 1 and 2 on connector CN5P   ("ALIMENTAZIONE C.N.")

-F13 is the single fuse that kills the controller. If it has gone, everything else in the cabinet looks entirely normal and the PC reports exactly this message.

⚠️ "The controller has power" does not settle it — there are two boards¶

-CAR1 in the device list is 005TEA0062 CARPENTERIA - **SUPPORTO SYNCRO-MONOSCHEDA** — the carrier holds a Syncro and a Monoscheda, two separate boards, and both are visible in the rack photos.

The failing message names SYNCRO specifically. So a lit rack tells you the 24 V AC arrived and -F13 is intact; it does not tell you the Syncro board is running or seated. Worth establishing which board the light is on before going further, and worth a look at whether the Syncro is properly home in its connector — the machine has been moved.

Order to work through¶


1	Restart MW310 with the machine already powered	Costs nothing, no tools. The commonest cause is simply that MW310 started before the Tecnos had finished its own power-up. No reboot needed — quit and relaunch
2	Check `-F13` (6 A GL)	Isolate first. This is the one fuse in the CNC supply. ✅ Ruled out 5 Sep — the controller has power
3	24 V AC at `CN5P` pins 1 and 2	Wires 9 and 10. ✅ Ruled out with the above
3b	Is the SYNCRO board itself lit and seated?	Two boards share the carrier. A powered rack does not mean a running Syncro
4	The serial cable at COM1	The onboard rear port, not a USB adaptor. Easy to disturb when moving things
5	E-stop / rope switch	Lower down the list — the rope latched once before and caused fault `0.0.0090` — but cheap to rule out

✅ When it is right, that line reads Reading Syncro configuration...done.

🔴 What changed: the rp5800 had RAM fitted (Grant, 5 Sep)¶

That is the strongest lead, and it gives a mechanism that fits the symptom exactly.

The PC has two onboard serial ports. Mw310.ini puts the Syncro on COM1 at 19200 ACKNACK, and the auxiliary channel on COM2 at 38400 XON/XOFF. Both are onboard "Communications Port" devices, not USB adaptors.

Fitting RAM means opening the case, moving the machine, and a hardware change Windows notices. Three ways that produces this exact failure:


🔴 COM port renumbering	If Windows re-enumerated and the ports swapped, MW310 still opens COM1 and still reports "done" — but the Tecnos is now on the other port, so nothing answers. This matches the log precisely: the open succeeds, the conversation fails
The cable was disturbed	Hands were inside the case and the PC was moved. The DB9 at the back is the obvious casualty
BIOS defaults restored	If the CMOS battery is weak and the machine sat unplugged, serial port settings can revert. Less likely — the port still enumerates — but cheap to check

✅ The check that found it¶

Device Manager → Ports (COM & LPT). Note which COM numbers now exist. Compare against C:\Windows\Mw310.ini:

Porta COM=1          <- the Syncro link
Porta COM AUX=2      <- the auxiliary

If the ports have renumbered, there are two fixes and moving the cable is the safer one — it changes nothing on disk. Editing Porta COM in Mw310.ini also works but is a configuration change, and Mw310.ini lives in C:\Windows, not in the program folder.

⚠️ Look before changing anything. A renumbered port and a knocked cable look identical from the log.

It has worked before¶

HANDOVER.md records the machine powering up and homing repeatedly, with PC-to-Tecnos comms confirmed, on 30-31 August. So this is not a latent fault in the configuration — something about this power-up differs.

⚠️ Sv\sv.exe can talk to the same controller with protocol autodetection, and SV32.log shows it succeeding. It is tempting as a second opinion — but its own log shows it sending "Richiesta Inizializzazione a Syncro", so it initialises the controller. Do not reach for it as a diagnostic until the power and cable checks are exhausted.

9. What is still unknown¶


The menu navigation	Which softkey opens which screen. `F5` is established; the rest is not. This needs someone in front of the machine, or Masterwood's manual
`S18` — units of the speed word	Almost certainly thousands of rpm, from the tool file's 18000. Unconfirmed
`.utn` lines 2, 9, 10, 11, 12	Not identified. Line 10 is not the pocket number
`Posizioni.dat`	40-odd rows keyed 1-22, 98-100, 200-224, 301-305, 400+. Rows 201-224 all carry `25` in column 2 — the router — so they are probably carousel-related, but the columns are not decoded
The `.PRG` header lines other than 4/5/6	Not identified

atc-operation.md — the tool-change cycle itself, its timings and its faults
zones-and-loading.md — the pedal, the lamps, and what F5 arms
plc-fault-codes.md — all 95 fault codes in English