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¶
⌛ CLOSED 31 October 2026. The Tecnos is out of the Housing.¶
This page is now history, not a task list. Read it to understand what was and was not banked while the original control could still drive the machine. The live to-do list is on the to-do page; eight items on it are marked Gone with the Tecnos, each saying what replaces it.
What this survey actually banked, and it is more than the tier list suggests:
Banked How ✅ Ribbon way ↔ I/O address, all 96 points Grant's colour walk, 9 Sep. Zero mismatches ✅ The E-stop drops the drives with the PC off Tested 11 Sep. The chain is inherited, not rebuilt ✅ Which parameter set the board ran Measured, 31 Oct: X cruise 488 mm/s matches the live Syncro.prm✅ OF.42vsOF.43Observed at 56 fps, 31 Oct, no meter needed ✅ The whole pneumatic self-test, decoded to the frame reset-sequence, 128 transitions✅ Drive parameters, VFD parameters, the disk image, the file capture Aug-Sep What was lost, stated plainly rather than buried:
Lost Consequence 🔴 The reference plot on paper There is no before-and-after benchmark and never will be. Stage 8's first cut is an absolute measurement, not a comparison 🔴 Q.TARAT, the X homing offset the board actually ranHOME_OFFSETbecomes a commissioning measurement⚠️ A filmed tool change: ATC phase durations, coupling and releasing heights, change-X per pocket, Y park All become first-light measurements. Build the M6 remap to measure them, not assume them ⚠️ The seated Housing front panel photograph housing-connectors.md's pin-by-pin schedule is the only record⭐ Two items the survey called unanswerable after strip-out turned out to be EASIER with the board gone, because the I/O modules stay in the cabinet on their own 24 V and the field wiring was never touched: the input ribbon conductor measurement and sourcing vs sinking. The Housing end of every input ribbon is now free, so a probe goes straight onto a conductor with nothing on the other end. 🔴 Both must be done before 24 conductors are crimped onto a Mesa card.
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. ✅ DONE — ribbon way ↔ I/O address¶
Grant mapped all four ribbons by colour, 9 September. This was the single biggest gap in the project and the only thing blocking the Mesa build.
🔴 The guess was wrong. This item assumed ways 1-24 in address order. They are not: each ribbon carries three modules of eight, and the module blocks sit on the ribbon in reverse — third module on ways 1-8, second on 9-16, first on 17-24 — while the points inside each block ascend normally.
✅ Verified against all 96 points: zero mismatches, each ribbon using ways 1-24 exactly once. Formula and colour table in housing-connectors.md; every point now carries its ribbon, way and colour on the I/O lookup page, generated rather than transcribed.
What is left of this item¶
| 🔴 | The input side — logic voltage in both states, and sourcing or sinking. The only ribbon unknown left, and it still needs the machine live |
| Meter every input for high or low while the meter is on it |
⚠️ Outputs are fully settled: sourcing, 24 V, 18.5 mA per point.
2. ⬇️ DEFERRED TO COMMISSIONING — axis scaling¶
Grant, 6 September: "We can do this once the Mesa cards are in. No need to capture this now."
✅ Right, and it is how the job is normally done. Axis scale does not have to be inherited from the old control. Set an arbitrary SCALE in the LinuxCNC HAL, jog a known number of units, measure the real travel, and correct the number. One or two iterations settles it to whatever precision you can measure.
So this comes off tier 1 entirely. It never needed the Tecnos — it needed a machine that moves, and the retrofit provides one.
⚠️ The one thing it costs. The first motion happens on a guessed scale, so a commanded 10 mm might be 50. Standard precautions apply on that first jog: lowest velocity, short moves, well clear of both ends, hand on the E-stop. Not a reason to do it earlier, just a reason to be deliberate on the day.
✅ And there is a free cross-check when the time comes. Pn201 from the SGDH capture gives pulses per motor revolution, so the scale can be calculated from encoder counts, ballscrew pitch and any reduction — then compared against the measured figure. If the two agree, the number is not in question. If they disagree, there is a gearbox or a factor somebody has not noticed, and that is worth knowing before cutting.
3. ⬇️ DEFERRED TO COMMISSIONING — direction sign¶
Grant, 6 September: "Defer. It's standard CNC tuning." Deferred with item 2 — it is the same jog session.
If an axis runs backwards, flip the sign in HAL or invert Pn000.0 in the drive. Nothing about the Tecnos has to tell you which way is plus.
⚠️ It is more dangerous to get wrong than scale is, and in a specific way. A wrong scale on a first jog means overshooting and stopping. A wrong direction means the axis heads for the end of travel instead of away from it — before homing, with no soft limits configured, and with only the hardware overtravel switch and reaction time in the way.
🔴 So the first-jog rules are direction rules, not scale rules: start each axis mid-travel, jog in the smallest increment the interface offers, and know the hardware overtravels work before you begin.
✅ Pn000 is on record for all three axes from the SGDH capture. That does not say which way is physically plus, but if a direction has to be flipped later, the original setting is written down.
4. ⬇️ DEFERRED — homing, with a method already chosen¶
The home switches (BOX / BOY / BOZ) come back on AXIS n pin 6 and appear nowhere in the PLC, so the software never could tell us anything about them.
Grant, 6 September:
"My preferred way of homing a machine is to rapid until home switch signals, back off until signal drops then slow back to home switch signals again. I've inspected the mechanism that the home switch uses and this concept will work perfectly."
✅ That is the standard two-stage home, and it is what LinuxCNC does natively — HOME_SEARCH_VEL for the fast approach, then HOME_LATCH_VEL in the opposite sense for the slow re-approach. Repeatability comes from the slow pass, so it is governed by the switch's own behaviour at low speed rather than by stopping distance at rapid.
So there is nothing to copy from the Tecnos. The old machine's homing profile stops being interesting the moment the new one is defined rather than inherited. Item closed.
🔴 The one consequence, and it is not about homing¶
The new machine origin will not be the Tecnos's machine origin. A different sequence lands the axis in a different place, probably by a small amount, certainly not by zero.
That matters because some numbers already in this repo are expressed in Tecnos machine coordinates:
🔴 QMAX_Z1 = 1828.30, QMIN_Z2 = 1839.10 |
the two zone boundaries from the PLC |
| 🔴 X = 1833.70 | the computed midline, and it is hard-coded into the comp-midline block in tuchop-io.hal |
Those are only meaningful relative to where the Tecnos thought zero was. After the retrofit homes on its own terms, the midline has to be re-established by measurement, not carried across as a number.
✅ It is an easy thing to fix and a very easy thing to forget. Recorded here and in zones-and-loading.md rather than left to be discovered when a sheet gets clamped in the wrong zone.
⚠️ Optional refinement, if the encoder index reaches the Mesa¶
The SGDH drives output A/B/Z from their PG port. If Z (index) is wired to the Mesa along with A and B — which it may well be anyway for the encoder feedback — then LinuxCNC's HOME_USE_INDEX can latch the final position on the index pulse instead of the switch edge. Repeatability then becomes a fraction of a motor revolution rather than switch hysteresis.
No extra hardware, one config line, and it can be added later. Offered only because the wiring decision that enables it gets made during the Mesa build, and it costs nothing to land the Z wire while the loom is open.
5. ✅ REVISED — prove the overtravels work, don't record their positions¶
Grant, 6 September: "From memory they light up an input LED in the cabinet when pressed. Leave on the list, record which inputs the overtravel switches are on. Good to check they all work."
✅ Correct on both counts, and the wiring confirms it. They are PLC inputs, so they do light a cabinet LED.
The positions are dropped. They would be Tecnos machine coordinates, and the datum moves at the retrofit (see item 4) — so they would have to be re-measured anyway. Soft limits get set during commissioning against the new origin.
The test stays, and it is the safety net under items 2, 3 and 4, all of which now end in "we will sort it by jogging the machine".
The inputs, from the drawings¶
| Axis | Switches | PLC input | Wire | Path | Sheet label |
|---|---|---|---|---|---|
| X | -SQX + -SQX-. in series |
IF.22 |
E122 |
=BM+X43, -X43 E122, Harting -B 6 |
EXTRACORSA ASSE X |
| Y | -SQY + -SQY-. in series |
IF.23 |
E123 |
=BM+X4, -X4 E123, Harting -C 10 |
EXTRACORSA ASSE Y |
| Z | -SQZ + -SQZ-. in series |
IF.24 |
E124 |
=BM+X4, -X4 E124, Harting -C 11 |
EXTRACORSA ASSE Z |
Rack 3, ways 6, 7 and 8.
⚠️ Both ends of an axis share one input, wired in series. So IF.22 says "X hit an overtravel" and does not say which end. Nothing to fix — just know it when testing, because tripping either end of X lights the same LED.
🔴 The part that matters more: they also go straight to the drives¶
io-map.md: "The axis limit switches have two contacts each. One pair goes to the drives'P-OT/N-OT(sheets 7-9, as-SQX+/-SQX-); the other pair comes here in series asEXTRACORSA. Both paths are inherited by the retrofit."
✅ So the overtravels stop the axis in the servo drive itself, independently of any controller. That is a hardware backstop that survives the Tecnos coming out, survives LinuxCNC being misconfigured, and needs no software to work.
And the drives see the two ends separately — P-OT and N-OT are distinct inputs — so the direction information the PLC input throws away is still there at the drive.
🔴 This is what makes the deferred first jog acceptable. A wrong direction sign on the first move runs into a switch that cuts the drive, not one that merely tells a controller. Worth confirming it is intact before relying on it.
The test¶
Press each switch by hand and confirm two things — a meter and one hand, no controller needed:
The cabinet input LED lights (IF.22/23/24) |
proves the PLC path |
🔴 The drive's P-OT/N-OT responds |
proves the hardware stop, which is the one protecting the first jog |
Six switches, both ends of all three axes.
6. ⏳ ONE TIMEBOXED ATTEMPT — real durations, folded into item 8¶
Grant, 6 September: "I'm going to spend a bit of time on this next weekend but if I can't get it to change tools I'm going to drop it and figure it out in commissioning. Leave it on the list."
✅ Right call, and the timebox is the important half of it. Everything here is a timeout, and a timeout can be set generously and tightened later once the real thing has been watched. Convenient to have, not necessary.
🔴 One successful tool change closes three items at once — 6, 8 and 9. So the weekend attempt is worth making, and worth making once, properly prepared. If it does not go, nothing downstream is blocked.
🔴 The prep, so the attempt is not spent rediscovering the software¶
Full detail in mw310-operating.md. The short version:
| 1 | Load a program. PROG\P20000.PRG is the simplest on the machine — 800 × 500 × 16, two rectangles, both T25/2 |
| 2 | 🔴 Press F5 = ESECUZ. Nothing arms until a program is loaded with F5 — not the pedal, not the start button, not the tool changer. This is the step that is easy to miss and it makes the machine look dead |
| 3 | A tool change fires when a G172/G173 block asks for a tool that is not the one mounted. That raises OS.51, which starts the PLC's cycle |
| 4 | T25/n = the router with carousel pocket n. T25/2 is the 9.5 mm MDF cutter. So load with a different tool in the spindle, or edit a block to call a pocket that is not currently mounted |
⚠️ No vacuum pump is needed to try this — see mw310-operating.md. The clamp interlocks gate the cut, not the tool change.
What to capture if it does run¶
One video, from a fixed position, with a visible clock or the phone's own timestamp. That single recording answers all three items:
| Item | What comes out of it |
|---|---|
| 6 | Full cycle duration, and each phase — spindle stop, Z to change position, air ram, carousel rotation, grip, return |
| 8 | The mechanical sequence itself, which nothing in the PLC source shows |
| 9 | Watch dP_IO on the Panasonic panel during the change: IN-4 (STB) and IN-7 (P-IN, the pocket number in decimal) settle the OF.42/OF.43 question |
🔴 Carousel rotation is the number most worth having — one pocket and right across. The 25 s in the simulator is a ceiling invented for the sim, not a measurement, and it is the only fabricated timing in the whole model.
If it does not run¶
Drop it, per Grant's call. Set generous timeouts in LinuxCNC at first and tighten them once the retrofit performs its own tool change. Nothing else on this list depends on it.
The original note¶
🔴 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~~ ⚠️ 500 ms, corrected 11 Sep (TIME11, pargen.prm). The 1500 ms came from time.prm, the wrong file. The one exception is the 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. 500 ms is the machine's own dwell (⚠️ this read 1500 ms until 11 Sep; time.prm was the wrong file); 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. ✅ DONE — Z brake¶
⚠️ 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 the wiring already answered it. See "What the wiring already settles" below.
Everything this item asked for is captured. Both halves closed on 5 September:
| ✅ It is a motor holding brake in the Z servo | Grant's reading, confirmed three ways by the paper — see below |
✅ Pn506 = 50 |
Brake reference, servo-OFF delay |
✅ Pn507 = 100 |
Brake reference output speed level, rpm |
✅ Pn508 = 50 |
Brake timing during motor operation |
✅ Pn50F |
Captured with the rest of the dump — confirms the SO2 allocation |
Z drive only. X and Y have no brake, and no values against these. Full table in drive-parameters.md.
✅ And the Z-drops-on-disable risk is settled either way¶
⚠️ One small uncertainty remains: Pn506 and Pn508 are in units of 10 ms on this drive family, so 50 reads as 500 ms — but our copy of the manual does not reach the appendix that states it, so 1 ms units cannot be strictly ruled out.
✅ It does not matter for the thing that would have mattered. Pn506 is the delay from the brake being commanded until the servo is switched off, so the servo holds torque after the brake applies — at 500 ms or at 50 ms, the sequence is the safe way round. Z will not drop on disable, and there is nothing to adjust unless it is observed to.
Not worth another trip to the drive. If Z ever does sag at machine-off, Pn506 is the parameter, its current value is on record, and the units resolve themselves the moment anyone changes it and watches.
✅ It is a motor holding brake in the Z servo¶
Grant's reading, and the paper agrees three ways:
- The drive sequences it.
-KAF's coil returns through the Z drive'sCN1pin 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. -FR.Zis 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.- 24 V DC with a
1N5402flyback. 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:
-
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/14Areset circuit), so this is a deliberate per-axis allocation, and it is the standard Yaskawa/BKholding-brake arrangement. -
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. ➡️ MERGED INTO ITEM 6 — ATC full cycle on video¶
Same attempt, same weekend. The capture list lives in item 6 so it is in one place.
What video adds beyond the timings: the PLC source gives the order of operations — JOB 48 is the tool-change cycle, JOB 50 the carousel rotation — but it cannot show the mechanics. How the air ram lifts the spindle, how the gripper engages, whether the carousel indexes before or after the spindle clears.
🔴 The retrofit has to reproduce this exactly, because the carousel drive and every pneumatic actuator stay as they are. LinuxCNC will issue the same outputs in the same order, and the video is the only record of what "correct" looks like once the Tecnos cannot demonstrate it.
Multiple angles if practical. And if a tool can be made not to seat, the recovery behaviour is worth having — but that is a bonus, not a reason to extend the timebox.
⚠️ If the tool change will not run but the machine is otherwise alive¶
Film whatever does move. A jog, the pedal clamp cycle, the stops going up and down. Those are items 11-14 further down this list, they are cheap, and the same fixed camera covers them. A wasted trip to the machine is the only real cost here, and this avoids it.
9. ✅ LARGELY ANSWERED — the pocket code came from the Panasonic manual¶
6 September. Grant asked whether the pocket-selection code could be got from the Panasonic rather than deduced from the Tecnos. It could, and it is in §12-1 of the main manual as a full table.
✅ Plain 5-bit binary. The inputs are named by weight — P1IN, P2IN, P4IN, P8IN, P16IN — and a closed contact is a 1. Pockets 1-8 are codes 1-8, so only four bits do the pocket work; P16IN exists to form 31, the origin return command.
🔴 That also explains POS_RESET = 31 in the PLC, which has been an unexplained constant since the first dig. It is not step 31 — the step table stops at 28. It is the drive's origin-return code.
The full table, the handshake timing from §12-6, and 🔴 a latch-up trap in the BUSY signal that would otherwise have become a bug are all written up in carousel-indexer.md.
Why this mostly retires the item¶
The dispute was whether OF.42 is the go command or SVON. The retrofit does not inherit the Tecnos's outputs — it drives the Panasonic's connector directly, so what matters is which Mesa output goes to which CN I/F pin, and that is a wiring decision made fresh against a pin list we already have.
✅ And it is self-verifying. dP_IO shows IN-7 as a decimal number. Drive the bits, read the number off the panel. No Tecnos, no meter, no inference.
What is left¶
| ⚠️ | Which physical pin carries which weight. The manual lists P-IN as pins 35·34·33·32·31 without saying whether that is MSB-first. Set one bit at a time and watch the panel — about a minute, and it needs no controller |
| The live observation during a Tecnos tool change is still worth doing if the weekend attempt runs, but it is now a nice-to-have rather than the only route |
10. ✅ ANSWERED FROM THE SOURCE — feed override code¶
6 September. The item assumed the code had to be read detent by detent because there was "no guarantee the machine uses a plain binary sequence". The PLC settles it: it does.
BLOAD places each of IF.12-IF.15 at its own bit position, which is plain 4-bit binary — if the switch were gray-coded the PLC would have to convert it, and there is no conversion anywhere.
| Input | Wire | Weight |
|---|---|---|
IF.12 |
E112, verde |
1 (LSB) |
IF.13 |
E113, marrone |
2 |
IF.14 |
E114, grigio |
4 |
IF.15 |
E115, bianco |
8 (MSB) |
🔴 The wire colours carry the bit weights, so the physical mapping is settled as well as the encoding.
16 detents, 0-150 % in 10 % steps. The PLC's own line ;se 0 forzo override al 10% fixes the units — a value of 1 is 10 %.
Full decode, including the software slider that multiplies on top for interpolated moves, in io-map.md.
✅ Nothing to do at the machine. And for the retrofit it barely matters — LinuxCNC has its own feed override. If the physical switch is kept, it is a plain 4-bit binary encoder and the percentage is the value × 10.
11. ⬇️ DEFERRED — vacuum sense polarity¶
Grant, 6 September: defer. Reasonable — the pump is not installed, so the "vacuum present" state cannot be produced to compare against, and the reading would only ever be half a test.
The sim assumes normally-closed, true = healthy, and carries a ⚠️ about it.
✅ The assumption is the fail-safe one, and it matches this machine's conventions elsewhere: the clamp outputs OF.2/OF.3 are energised to release, and the VFD's S3 emergency stop is an NC contact. This builder used fail-safe consistently, so a vacuum switch closed on good vacuum — where a broken wire reads as "no vacuum" and stops the cut — is what the rest of the machine predicts.
⚠️ It is still a prediction, not a reading, and the cost of it being wrong is a sheet moving mid-cut.
🔴 It resolves for free when the pump is commissioned, which has to happen before any vacuum work anyway. Watch IF.9 change state as the pump pulls down, and the polarity is settled in the moment it first matters. Nothing is lost by waiting, because nothing can be cut on vacuum until then.
⚠️ Do not let the sim's assumption become the config by inheritance. The LinuxCNC vacuum interlock should be written the day the pump runs, against an observed transition, not carried over from the simulator.
12. ✅ ANSWERED FROM THE SOURCE — spindle pot¶
6 September. The item wanted to confirm -R6 scales the controller's analog output rather than being the speed source. Both halves are now settled without a meter.
✅ -R6 is passive and in the output path |
Settled 2 September by the resistance ratio — a 2.5 k pot in series with 330 k across +12 V gives ~90 mV, nowhere near the 0-10 V FR expects, so the +12 V rail cannot be the source |
| ✅ No software override competes with it | pargen.prm has FONDOSCALA = 0, and the PLC's potentiometer-override routine exits on its first line with the coefficient forced to 1000 = 100 % |
🔴 The analog chain is now characterised end to end — controller output, passive divider, VFD gain and bias, and the 104 Hz floor. Nothing scales the spindle command anywhere that is not written down. Full chain in spindle-vfd.md.
⚠️ The FR-FC measurement while turning -R6 remains a nice confirmation if the machine runs anyway, but it is no longer needed and it does not gate anything.
13. ❌ REMOVED — pedal, with no program running¶
Grant, 6 September, deleting it:
"The pedals definitely light up an LED on the input so we can program them to work however we would like once recommissioned. This is a software only issue, nothing to learn from doing this."
✅ Correct, and it corrects two things this project had wrong.
First, the pedal is not inert. mw310-operating.md said F5 leaves the pedal doing "genuinely nothing". The input is live and lights its LED on every press — what F5 gates is the PLC's response, not the signal. Corrected there.
Second, there is no behaviour here worth preserving. The two-press clamp protocol and the F5 arming rule are Tecnos software. The pedal is an input on a card, and the retrofit decides what it does.
⚠️ And a claim of mine was simply wrong. I argued the loading workflow should be reproduced because operators have muscle memory for it. Grant: "there are no previous users of this machine. So no muscle memory. This machine will be programmed to operate how I would like it to." There is no incumbent workflow to protect. Removed as a consideration everywhere it appeared.
14. ❌ REMOVED — zone release at the midline¶
Grant, 6 September: delete. Same reasoning as item 13.
Pendulum working is Tecnos policy, not machine fact. The zones are defined in its parameters, the midline is computed by its PLC, and the release is its decision. LinuxCNC decides for itself whether to work in pendulum mode at all, where the boundary sits, and what crossing it does.
✅ What is worth keeping is already kept. The zones are real hardware — two sets of clamps, two sets of stops, separate photocells — and all of it is in io-map.md and zones-and-loading.md. The mechanism survives; the policy does not need to.
⚠️ One pattern worth carrying forward as a design idea, not as an inherited implementation. The photocells are armed per zone (MCONTR_FOTOC_Zn) — the loading zone's photocells are masked while that zone is being loaded, so an operator's hands do not trip a guard that is not guarding anything at that moment. That is a safety design pattern, and it is already modelled in linuxcnc-sim/tuchop-io.hal. Whatever LinuxCNC does about zones, it needs an answer to the same question.
15. ✅ KEEP — I/O LED confirmation, and it is a full walk, not a sample¶
Grant, 6 September: "worth taking some notes on the LEDs before decommission. Leave it in."
🔴 Why this one survives where items 13 and 14 did not. Everything deleted so far was Tecnos policy — behaviour the retrofit gets to redefine. This is not. This fact-checks the largest inherited artefact in the project. Every point in io-map.md is derived from drawings and PLC source, and none has been checked against the physical machine. A wrong drawing propagates into mesa-wiring-schedule.md, the HAL sim, and the wiring itself.
⚠️ And it needs the rack assembled and powered. Item 1 works by injection with the controller gone; this one uses the module LEDs as the readout, and input LEDs only light from real field events while the rack is intact. Once the ribbons are off, that readout is gone.
✅ Cheap and safe — pressing buttons and tripping sensors, watching LEDs. Nothing actuates, nothing moves.
⚠️ Correction — the scope is 82 points, not "200-odd"¶
An earlier version of this item recommended a spot-check on the grounds that a full walk of "200-odd points" would take hours. Grant challenged the number and was right. Counted from MW310.EQU and io-map.md:
| Inputs | 41 |
| Outputs | 41 (the OF.254/255/256 sentinels are not-present markers, not points) |
| Total | 82 |
🔴 That changes the recommendation. Walk all 41 inputs. At fifteen or twenty seconds each that is well under an hour, and a full pass removes the whole class of doubt rather than sampling it.
How to split it¶
| Inputs — all 41 | Trip each by hand and watch its LED. No controller interaction needed beyond the rack being powered |
| Outputs — all 41 if the diagnostic screen can be found | They have to be commanded. If the MW310 diagnostic screen does not turn up, ✅ item 1's injection method covers outputs later with the Tecnos gone — so outputs are not the reason to hurry |
So the thing that genuinely expires with the Tecnos is the 41 inputs. That is the pass to make.
16. ✅ CLOSED 11 Sep 2026 — E-stop drops the drives in hardware, with the PC off¶
Grant, 11 September 2026: "E-stop drops the drives with the PC off." ✅ Tested and confirmed.
⭐ This is the item that protected every other item on this list, and it passed. The safety chain is inherited, not rebuilt. OF.1 (CNC OK) is a watchdog alongside the chain, not load-bearing inside it, so the E-stop keeps working the moment the Monoscheda comes out.
What it upgrades: safety-and-enable-chain.md traced this on paper and reached the same conclusion, but a drawing reading is not an observation. It is now an observation. The retrofit's core safety assumption is evidence-backed.
⚠️ One thing the confirmation does not state: how many E-stop stations were tested. The procedure below called for every station, including the rope switch -SQF1, which is the one nobody looks at and the one that latched on 31 Aug. If only one station was hit, the others are still worth ten minutes before the Monoscheda comes out. Not a blocker; a loose end.
Original text kept below for the record.
~~The entire retrofit assumes this. safety-and-enable-chain.md traces the chain on paper and concludes the E-stop drops the drive enables through hardware contactors, independently of the CNC — but that is a reading of a drawing, not an observation.~~
~~🔴 If OF.1 (CNC OK) turns out to be load-bearing in the safety path rather than a watchdog alongside it, then the E-stop stops working the moment the Monoscheda comes out — and nothing announces it.~~
Why it goes first, ahead of everything else on this list¶
Every other item is about knowing something. This one is about whether the machine is safe once the controller is gone — and the rest of the list involves working on a powered machine, jogging axes on a guessed scale (items 2 and 3), with a spindle that reaches 400 Hz.
It is the item that protects the other items.
The test¶
1. Shut the rp5800 down completely
2. Machine powered, drives enabled
3. Hit each E-stop
4. Confirm the drive contactors and the main contactor drop
⚠️ Every E-stop station, not just one. Ten minutes, no motion required, nothing to set up.
✅ The PC being off is the point — it is the closest available simulation of the Tecnos being gone.
~~🔴 If it fails, that is the most valuable finding on this list. It means the safety chain has to be rebuilt as part of the retrofit rather than inherited — a design change, not a wiring change, and one that wants knowing before the cards are on the bench rather than after.~~
✅ It did not fail. The chain is inherited. No design change.
Tier 2 — parameter dumps. No PC needed, safe any time¶
17. ✅ DONE — SGDH ×3, full dumps¶
Captured 5 September 2026. All 19 parameters on each of X, Y and Z, decoded in drive-parameters.md.
✅ It justified itself: Pn300 differs on every axis — 475, 477 and 500 against a factory 600 — so the analog gain could not have been assumed. The capture also proved the SGDH digit convention (Pn000.0 is the rightmost digit) from the machine's own data against the manual's stated defaults.
Whole tier 2 is now complete.
18. ✅ DONE — VS-606V7 VFD dump¶
Captured 6 September 2026. Full constant list and decode in spindle-vfd.md.
Three things it turned up that nothing else would have:
| 🔴 | n034 = 26 % — a hard speed floor at 104 Hz. The spindle will not run slower whatever LinuxCNC commands |
| 🔴 | S3 is programmed as an emergency stop, NC contact, not the "EXT. FAULT" the drawing labels it. Fed from the braking-resistor breaker |
| 🔴 | Overtorque detection stops the drive at 200 % for 0.3 s |
✅ The analog scaling is the easy case: 0-10 V → 0-400 Hz, gain and bias both factory.
🔴 One item added to the photography tier: the spindle motor nameplate. The pole count is the last thing standing between 400 Hz and a spindle RPM, and it is not in any drive.
19. ✅ DONE — Panasonic MSS083A1XP indexer dump¶
Captured 5 September 2026 from the drive's own front panel — no console needed. Full table in carousel-indexer.md: step data (the pocket table), speed data, NC data, offset data, servo parameters, and the error history. 63 readings.
The finding that mattered: eight pockets at exactly 100000 pulses each, plus an origin offset of exactly one pocket pitch. That is the whole disaster-recovery case for this drive, and it is now written down.
✅ The three encoder-communication errors in its history were explained on 6 September — Grant had powered the machine up before the carousel was plugged in. No wiring inspection needed, and the log is now proven to record real events in correct order.
What is left on it is small: count the physical pockets to confirm the eight-pocket model, re-read step 24, and read steps 25-28.
The original reasoning follows, because it still applies to anything else in this cabinet that holds its own memory: the SGDH drives and the VFD are being kept but re-commanded, whereas the Panasonic carousel indexer keeps running exactly as it is, with its own encoder, its own homing and its own internal parameters. 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.
Tier 3 — one photography item¶
Grant, 6 September: "Since the re-fit will be entirely in the housing there is very little getting disturbed on the machine, so capturing photos before anything gets pulled apart is a much smaller item."
✅ Right, and it collapses items 20-24 into one. The original list treated the machine as if it were coming apart. It is not — the retrofit is confined to the Housing, so the cabinet, the terminal blocks and the field wiring stay where they are. Photography stops being insurance against losing the machine's own wiring and becomes a short record of the few things that do get parted.
20. Photograph before anything is unplugged¶
| 🔴 The spindle motor nameplate | The one real finding in this tier. The pole count is the last thing between 400 Hz and a spindle RPM, and it is in no drive. It also decides whether the VFD's n035 = 20 is a divide-by-ten display trick or a genuinely 20-pole machine — very different machines. Capture the whole plate: poles or synchronous speed, rated frequency, voltage, current, kW, make and model |
| The Housing front panel, everything seated | Every connector in place and labelled, before one is parted. The photograph you cannot retake |
| The I/O boards | Connectors, board part numbers, silkscreen. ⚠️ Worth doing before anything is unplugged for a specific reason: the ribbon pinout item 1 needs may be printed on the boards themselves |
| Label both halves of every connector before parting it | Only applies to the Housing connectors now, which is a short list |
Dropped: the cabinet overview and every-terminal-block sweep. Nothing in the cabinet is being disturbed.