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.

The survey to do before the Tecnos comes out

5 September 2026. Everything that can only be learnt while the original controller is still in the machine and driving it. Once the Monoscheda is out, the ribbons unplugged and the axis D-subs parted, none of this is recoverable — the machine cannot be commanded at all until LinuxCNC is running, and LinuxCNC cannot be commissioned without most of what is on this list.

⚠️ The rp5800 is the single point of failure for this whole phase. The Tecnos cannot be commanded without a PC running MW310. Everything in tier 1 needs the machine live, so bank tier 1 before anything else, and do not defer it on the assumption the PC will keep working.

⚠️ Standing rule, unchanged. Nothing is actuated, no program is run and no controller file is written without Grant confirming that specific action. Everything below is his to do or decline; meter probes and one hand.


Tier 1 — needs the machine live. Irreversible if skipped

1. 🔴 Ribbon way ↔ I/O address, and the logic domain

This is the one column missing from mesa-wiring-schedule.md, and it is the only thing blocking the whole Mesa build.

Four ribbons, 26 ways each. The likely answer is ways 1-24 are the points in address order and ways 25-26 are the module logic supply, but that is a guess and the schedule cannot be finished on a guess.

Test four ways per ribbon, not twenty-four:

How
Outputs Drive a known output from the MW310 diagnostic screen, meter the matching way at the Housing header. OF.1 (CNC OK) is on continuously and is a free reference
Inputs Press a known button and watch the way change. IF.29 end-cycle, IF.30 jog−, IF.31 rapid, IF.32 jog+ are the four white pendant buttons

Capture at the same time, because they set the Mesa field-power domains:

  • Logic voltage in both states (not just "24 V" — measure both the high and the low)
  • Sourcing or sinking

2. 🔴 Axis scaling — commanded versus actual

The one measurement standing between here and a LinuxCNC axis that moves a known distance. Command the longest clean move each axis will take, measure the real travel, record both numbers.

Do all three. Do X over at least a metre — a short move buys you a poor ratio.

3. Direction sign

For a + command on each axis, which way does the machine physically move? One observation each. This is Pn000.0 confirmed by eye rather than trusted from a parameter, and getting it wrong is a crash on first motion.

4. 🔴 Homing behaviour, watched not assumed

The home switches (BOX / BOY / BOZ) come back on AXIS n pin 6 and appear nowhere in the PLC, so the software cannot tell us anything about them. LinuxCNC has to reproduce this from observation alone.

For each axis, record: which direction it seeks, roughly how fast it approaches, whether it backs off and creeps, and where it finally sits. Video is better than notes here.

5. Overtravel trip positions

Jog each axis to its limit and record where IF.22 / IF.23 / IF.24 trip. Those numbers become the LinuxCNC soft limits, set a little inside.

6. 🔴 Real durations — the thing the PLC source cannot give

time.prm is mostly ceilings the PLC waits up to, not measurements of how long anything takes. The one exception is the 1500 ms stop dwell, and only because there is no sensor to wait on. Everything else has to be timed:

Time Why it matters
Stops up, and stops down The stops have no retracted sensor. 1500 ms is the machine's own dwell; confirm it is actually enough
Router ram plunge, and retract Sets the M103 / M104 waits. The retract timeout in the sim is currently 2500 ms
Carousel, one pocket versus right across The 25 s in the sim is a ceiling, not a rotation time
ATC gripper up, and down
Spindle run command → IF.25 at-speed Sets how long a program should wait before cutting
Vacuum pump → IF.9 healthy Same reason

A phone stopwatch is fine. Ranges are fine. Ceilings are not.

7. Z brake — read the parameters, and look at the motor

⚠️ An earlier version of this item asked for stopwatch timing of the brake, on the assumption that Z sags under gravity when it sets or releases. That assumption was not evidenced, and mostly the wiring already answers the question. See "What the wiring already settles" below.

What is actually wanted:

Pn50F on the Z drive Confirms the brake really is allocated to the SO2 output on CN1-27/28 as /BK
Pn506 Brake reference — servo-OFF delay
Pn507 Brake reference output speed level
Pn508 Brake timing during motor operation
~~One look at the Z servo motor~~ Settled (Grant, 5 Sep): it is in the Z servo motor. A motor holding brake. See below

Pn506-Pn508 are the brake timing. They are already set in the drive, they were set by whoever commissioned the machine, and they are more trustworthy than anything a stopwatch will produce. Read them rather than measure them.

Add them to the SGDH dump in item 17 and this item costs nothing extra.

✅ It is a motor holding brake in the Z servo

Grant's reading, and the paper agrees three ways:

  1. The drive sequences it. -KAF's coil returns through the Z drive's CN1 pin 27. A drive only needs to know about a brake it has to sequence against its own servo-on and servo-off, which is what a motor brake is.
  2. -FR.Z is a separately catalogued connector, 025MSC0016, and it exists on Z alone. X and Y have motor and encoder connectors only. The builder specified a brake motor for the vertical axis and nothing else — the normal choice.
  3. 24 V DC with a 1N5402 flyback. That diode is 3 A, so the coil is well under it — the right order for a servo motor holding brake, and far too small for anything caliper-sized.

🔴 Two practical consequences, both easy to trip over

Z will feel seized during the retrofit, and that is correct. The brake is applied whenever rail 8A is dead. With the Tecnos out and nothing driving OF.1, 8A is dead, so the brake is on and Z cannot be turned by hand. Anyone who tries to hand-crank the axis during strip-out will find it locked and conclude something is broken. It is not. Releasing it deliberately means energising the brake coil, and that should not be done with the motor uncoupled or the carriage unsupported.

LinuxCNC must not try to control the brake. /BK is the drive's output. LinuxCNC never commands it and must not be given a HAL brake pin or a machine-off delay that assumes it can. In particular, Pn506 is the parameter that decides whether Z drops on disable — it lives in the drive, not in the INI, and it is the one to adjust if Z sags when the servo goes off.

What the wiring already settles

rail 8A --> -KAF coil --> wire 35 --> Z drive CN1 pin 27
rail 8A --> KAF contacts --> wire 34 / 7 --> -FR.Z brake coil

Two things follow, and together they answer the operational question without touching the machine:

  1. The brake is under the drive's control, not the PLC's. -KAF's coil returns through the Z drive's own CN1 pin 27 — a general-purpose sequence output. The same pins on X and Y do something else entirely (the -SB15 / 14A reset circuit), so this is a deliberate per-axis allocation, and it is the standard Yaskawa /BK holding-brake arrangement.

  2. There is no brake output anywhere in MW310.EQU. The PLC has no per-move control of the brake at all. It cannot apply it for a cut and release it for a move, because it has no way to command it.

🔴 So the brake cannot be engaged during cutting. /BK releases the brake whenever the servo is on, and rail 8A gates it on the controller watchdog. Brake released = servo on and controller healthy. Brake applied = servo off, drive alarm, watchdog dropped, or power gone.

It is a power-off holding brake. Whatever holds the carriage against cutting forces while a program is running, it is not this.

🔴 The question underneath, which matters more than the brake

The plunge reaction and the cutting forces push the carriage up through a ball screw, and a ball screw is backdriveable. With the brake released — which it is, throughout every cut — the only thing resisting that is the Z servo holding position under closed loop.

That makes it a servo stiffness question, not a brake question, and it lands on Pn100-Pn103, already in the dump list. Carry it into commissioning: if Z creeps up under load, the answer is in the gains.

⚠️ Worth watching for on the original machine too, while it can still be compared against. If Z holds depth cleanly today, the existing gains are the target to match.

8. ATC full cycle on video, multiple angles

Including — if you can force it — a tool that does not seat, so the recovery behaviour is on record. The sequence is translated already; what video adds is the physical choreography and the real timings from item 6.

9. 🔴 Ring out OF.42 and OF.43 to the Panasonic terminals

Five minutes with a meter, and it decides the whole tool-change design. The PLC uses OF.42 as the go command with five position bits on OF.43-OF.47; the wiring diagram reads OF.42 as SVON with the strobe on OF.43. The subroutine is parameterised so it is a one-line change either way — but only once you know.

10. Feed override code

Read IF.12-IF.15 at each detent of the override switch. Four bits, sixteen possible codes, and no guarantee the machine uses a plain binary sequence.

11. Vacuum sense polarity

IF.9 with the pump off, then on. The sim assumes normally-closed (true = healthy) and carries a ⚠️ about it. One reading settles it.

12. Spindle pot

Meter FR-FC while turning -R6. Confirms it is an override scaling the controller's analog output rather than the speed source. Expected, but unconfirmed.

13. Pedal, with no program running

Press it. Watch what moves. This settles whether the machine was left in AUTO or PEDAL stop mode, and confirms the two-press cycle: press-and-release once to raise the stops and float the panel, again to set it down and clamp.

14. Zone release at the midline

Run a program that crosses X = 1833.70 mm and watch the far zone's lamp and pedal come alive as it passes. That confirms pendulum working end to end, and confirms the midline is where the PLC arithmetic says it is.

15. I/O LED confirmation

Walk MW310.EQU against the IF1-IF6 / UF1-UF6 module LEDs. The map is complete on paper; this is the check that it matches the metal.

16. E-stop drops the drives in hardware, with the PC off

The entire retrofit assumes this. Power the machine, leave the PC off, pull the rope, and confirm the drives and the main contactor drop.

If it turns out the Tecnos is in that path in any way, the safety design changes and it is far better to know now than after the cards are on the bench.


Tier 2 — parameter dumps. No PC needed, safe any time

17. SGDH ×3, full dumps

Pn000, Pn100-Pn103, Pn201-Pn203, Pn300, Pn50A, Pn50B, Pn50E, Pn50F, and on the Z drive additionally Pn506, Pn507, Pn508 (the brake timing — see item 7).

Pn201 and Pn300 are the two that matter for commissioning — encoder scale and analog gain. The rest is so a working machine can be restored if anything is ever disturbed. Pn000.1 is already settled from the drawing; reading it is a five-second confirmation, not a task.

18. VS-606V7 VFD dump

19. 🔴 Panasonic MSS083A1XP indexer dump — nobody has listed this, and it is the one that survives

The SGDH drives and the VFD are being kept but re-commanded. The Panasonic carousel indexer keeps running exactly as it is, with its own encoder, its own homing and its own internal parameters — and there is no record of any of them anywhere in this project.

If it is ever factory-reset, loses its memory, or has to be swapped, the carousel is dead and there is nothing to restore from. Dump it before anything else in the cabinet is touched.


Tier 3 — photography and labelling, before anything is unplugged

20. The Housing front panel, everything seated

Every connector in place, labelled, before a single one is parted. This is the photograph you will want and cannot retake.

21. Cabinet overview, every terminal block, every tag

22. The I/O boards — connectors and board markings

Ribbon connectors, board part numbers, any silkscreen. The board markings matter because the ribbon pinout in item 1 may be documented on the boards themselves.

23. Label both halves of every connector before parting it

Not just the loom end. Both halves, so a connector found loose in a box is still identifiable.


Off the list — do not spend time on these

Why not
The serial tap and the framing bits The software-only option is dead — LinuxCNC cannot drive the Tecnos over a 19200 baud link. There is now no reason to tap it. This was previously a high-value item; it is not any more
Opening the servo D-subs to record pin-to-pin The drawing gave the complete pinout. Nothing needs unplugging
Reading Pn000.1 as a decision Settled from the wiring three independent ways. Confirm it in passing during the parameter dump
Chasing the horizontal borer and saw "off" faults IF.26, IF.11. Both pneumatic, both expected with the air off

  • mesa-wiring-schedule.md — the build document item 1 completes
  • homing.md — why item 4 can only be observed
  • machine-timings.md — why item 6's ceilings are not durations
  • zones-and-loading.md — items 13 and 14
  • servo-drive-interface.md — item 9