To do

45 open, 26 settled, 6 to buy. 27 of the open ones are the next things to happen.

⌛ The Tecnos came out of the Housing on 31 Oct 2026. 8 items needed the old board driving the machine and can no longer be answered. They are kept at the bottom of this page rather than deleted, each saying what replaces it.

Generated from site/scripts/todo_items.py and rebuilt on every push, so it is current with the repo rather than with anyone's memory.

⚠️ The tick boxes are yours alone. They are remembered in this browser on this device only - they do not reach the repo, another device, or Claude. Use them as a scratch pad at the machine; tell Claude what actually got done.

Clear my ticks

🔴 Do now

The next things to happen.

While the Housing is open

Read the silkscreen on BOTH Rev A cards against the tablesgrant⚠️ The 7I76EU and the 7I84U are BOTH Rev A, and NO errata could be found for either - but mesanet.com is outside this session's allowed network domains, so Mesa's own current errata page was never read. Absence of evidence, not a clean bill. The swapped-silkscreen fault has only ever been a 7I77 Rev A problem, and ours is Rev B. ✅ Ten seconds closes it: 7I76EU TB6 17-24 should print outputs 0-7 and TB5 17-24 outputs 8-15; 7I84U TB3 1-16/17-24 inputs 0-15/outputs 0-7 and TB2 1-8/17-24 inputs 16-23/outputs 8-15. ⭐ Definitively, once LinuxCNC is up, mesaflash --readhmid reports the pin assignment from the firmware, which outranks any printed label. CN10 is already landed on the 7I84U across both blocks, so this is worth doing before power-up rather than after mesa-card-reference

Does an input LED light with the ribbon UNPLUGGED?grant30 seconds, and the machine is in exactly the right state to test it. Press the pedal and look at IF1's input LED with the ribbon off. pre-strip-survey claims input LEDs only light with the rack intact, and that claim is UNVERIFIED. ⭐ NOW THE GATING QUESTION FOR THE 41-INPUT WALK, because the Tecnos is out and the diagnostic screen went with it: if the LEDs light without the ribbon, the walk can be done today with a meter and a pair of eyes. If they do not, the walk waits for Mesa and LinuxCNC to read the inputs instead - which is self-verifying and arguably better pre-strip-survey

Photograph while the machine is still powered: 4 thingsgrant5 minutes, all in one trip. (1) The -CH1 hour counter - machine history, and it informs spindle life planning. (2) The main air regulator AND the Z counterbalance regulator gauges - machine.json regulator_pressure_bar is null and the Z servo gains were commissioned at that pressure. (3) The HMI About/version box. (4) The Panasonic dP_id. ✅ ALL FOUR SURVIVE THE TECNOS COMING OUT - the hour counter and the gauges are cabinet and pneumatic, the Panasonic has its own display, and MW310 still opens on the rp5800 even with nothing on COM1. ⚠️ The gauges need the air back on machine-layout

🔴 Measure an INPUT ribbon conductor - NOW A BLOCKER, not a detailgrant🔴 THE SEQUENCING FAILURE FOUND 12 Sep. pre-strip-survey marks this 'cannot be answered after strip-out' and the machine is ALREADY PART APART - two of four ribbons unplugged. Outputs are now known (24 V through passive relay modules, driver on the Tecnos board). INPUTS ARE NOT: where the input receivers live is unestablished. If an input module presents 5 V logic referenced to a Monoscheda-derived rail rather than a 24 V signal, Mesa's input threshold reads EVERY INPUT FALSE FOREVER - which the bring-up README names as the worst failure mode, because it looks exactly like broken field wiring. Power an IF module, and meter one way with its field contact open and closed, referenced to ways 25/26 and to wire 12. ✅ RE-ASSESSED 31 Oct 2026 - THE BOARD COMING OUT MADE THIS EASIER, NOT IMPOSSIBLE. The I/O modules stay in the cabinet on their own 24 V, the field wiring is untouched, and the Housing end of every input ribbon is now FREE - so a probe goes straight onto a conductor with nothing on the other end to confuse the reading. Make the field contact and read it. TWO OUTCOMES, BOTH ACTIONABLE: if the conductor swings (24 V or 5 V to 0 V), the module drives its own logic level and Mesa reads it directly - note the voltage and the polarity. If it reads 0 V in BOTH states, the logic side is passive (open collector) and the Monoscheda supplied the pull-up - fit a 10k to 24 V, re-measure, and Mesa's field power takes that job over. 🔴 UPGRADED 1 Nov 2026. CLAUDE.md called this 'measure, but not a blocker' on the reasoning that a 5 V ribbon could just have its input block run at 5 V, since the 7I84 sets its threshold at 50% of field power. THE ALLOCATION CLOSED THAT ESCAPE AND NOBODY NOTICED: every block carries BOTH inputs and outputs, the outputs force VFIELD = 24 V (proven at the bench, the relays do not pull at 12 V), so the threshold is 12 V everywhere and there is no output-free block to move the inputs to. A conductor actively driving 5 V would need LEVEL SHIFTING ON 24 INPUTS - it cannot be pulled up. ⚠️ Conductor positions are the same in all three outcomes, so landing the ribbons is safe; the measurement decides what ELSE is needed, and it is far cheaper to know before the Housing is closed housing-connectors

🔴 Decide and fit the 24 V power entry into the Housinggrant🔴 RAISED BY GRANT 1 Nov 2026 - it was MISSING FROM THE PARTS LIST ENTIRELY. The Monoscheda ran on 24 V AC off -T2 and its fascia carried FUSE 1 and FUSE 2; both leave with the card, so the Housing has no feed and no protection. ⭐ The Housing needs a DISTRIBUTION POINT, not just a connector: ~11 terminals on +24 V (VFIELD x5, VIN x3, three D-sub pin 7 feeds) and ~10 on 0 V (GROUND x3, both ribbon return pairs, three enable returns). Load is ~1.25 A worst case, design 2 A. ⭐ Phoenix COMBICON 5.08 mm 3-pole with screw flanges recommended; a gland and terminal block is more reliable still. 🔴 NOT a D-sub - four axis D-subs are already on that panel and a fifth carrying 24 V is a mis-mating hazard. 🔴 FEED IT STRAIGHT OFF -G3: no switch, no breaker, no relay contact, a fuse only. The instinct to drop Mesa power on E-stop is WRONG - the E-stop already drops the drives in hardware without the controller, and switching VFIELD browns out all three cards. Fuse 2-3 A at the CABINET end. See mesa-wiring-schedule §9b mesa-wiring-schedule

🔴 Land the 0 V RETURN PAIR on CN10 and CN13 - ways 25 and 26grant🔴 DELIBERATELY DEFERRED 1 Nov 2026, so it is written down rather than remembered. Both output ribbons' signal ways 1-24 are landed; the shared negative on each is not. ⚠️ WITHOUT IT NO OUTPUT WORKS AT ALL - every energised relay returns through that pair, up to about 480 mA per ribbon with all 24 on at 20 mA. It will look like dead cards, not like a missing wire. Land on the cabinet 0 V rail or a dedicated two-way terminal, NOT a Mesa TB1 GROUND screw, which also carries the card's own supply. 🔴 Never both conductors on one screw - the doubling is the current rating. ⚠️ Gated by the two meter checks below: the coil-common isolation, and which rail lands on UF1's common housing-connectors

Confirm the pin-1 END of each DA-15S, and spot-check a secondgrant🔴 THE ONE WAY LEFT TO GET THE AXIS CONNECTORS WRONG. The map was verified by reading the connector by eye, which settles the interleave but not which end is pin 1 - and on a FEMALE mating face pin 1 is top-RIGHT, not top-left. Get the orientation backwards and every pin shifts. Ring the brown conductor through to a socket and confirm that socket mates with pin 1 of the male loom, or check the moulded 1 on the shell. ⚠️ Then spot-check one more connector: they should be the same part and the same map, but it costs a minute and the failure is silent. ⚠️ And while terminating, count conductors from the BROWN EDGE, never by colour - green appears at pin 3 (Encoder B) and pin 8 (Analog +), yellow at pin 10 (Encoder /B) and pin 15 (Analog −). Mistake a band and the velocity command lands on an encoder input, which presents as a dead drive rather than as a wiring error mesa-wiring-schedule

Check wire labels against the I/O chartgrantThe chart's wire numbers are my transcription of the diagrams and have never been checked against a physical label. If one disagrees, the diagram reading is the suspect io-map

Settle the input side — logic voltage and sourcing or sinkinggrantThe only ribbon unknown left. Outputs are fully settled — sourcing, 24 V, 18.5 mA. ✅ CORRECTED 31 Oct 2026: this does NOT need the machine live. It needs the I/O modules powered and a field contact made, both of which survive the Tecnos coming out. Same trip as the ribbon-conductor measurement above - one meter reading answers both housing-connectors

Photograph the I/O boards — connectors, part numbers, silkscreengrant✅ NOT LOST WITH THE TECNOS. The IF1-IF6 / UF1-UF6 modules are on DIN rail in the CABINET and they are STAYING - the retrofit boundary never touched them. The ribbon pinout may be printed on the boards themselves, which would shortcut the ribbon mapping, and with the Housing end of every ribbon now free the connectors are easier to photograph than they were pre-strip-survey

Check every parted Housing connector got labelled both halvesgrant🔴 TIME-CRITICAL AND MAY ALREADY BE PAST. The Housing was parted on 31 Oct 2026. If both halves were labelled as they came off, tick this and move on. If they were NOT, label them NOW from housing-connectors' pin-by-pin schedule while which loom came off which header is still in living memory - four 26-way ribbons and four AXIS D-subs, and the two input ribbons are indistinguishable by eye pre-strip-survey

At the machine

🔴 Feed VFIELDA and VFIELDB 24 V on EVERY cardgrant🔴 SHARPENED 1 Nov 2026 - the symptom is worse than 'will not start'. Mesa's own forum guidance: a 7I84U with only one field supply connected is NOT DETECTED AT ALL by the host. The 7I77U will not start either, even with one block unused. ⚠️ And the two rails feed OPPOSITE blocks on the two cards: on the 7I77U VFIELDA->TB7 and VFIELDB->TB8, on the 7I84U it is reversed, VFIELDB->TB2 and VFIELDA->TB3. 🔴 If a card does not appear at first power-up, check BOTH field rails before suspecting the card, the SSerial cable or the firmware. CN10 is landed across both of the 7I84U's blocks, so one missing rail presents as half the outputs being dead rather than as an absent card mesa-allocation

Which rail lands on UF1's common - 8 or 8A?grant🔴 THE REPO CONTRADICTS ITSELF AND IT BIT US ON 24 Oct. io-map says UF1 runs from rail 8A; housing-power says 8A is gated by KA; and KA's coil is driven by OF.1, which is a UF1 output. All three cannot be true or the machine could never bootstrap - OF.1 must be fed from rail 8, UPSTREAM of the KA gate, because it is the output that CREATES 8A. ⚠️ It matters for fault-finding: if OF.1 were fed from 8A then A201 reading 0 V would be a symptom of KA being out rather than a cause, and you chase your tail. One meter reading at UF1's common settles it safety-and-enable-chain

🔴 Re-read Pn000 on ALL THREE drive panelsgrant🔴 drive-parameters.md CONTRADICTS ITSELF and the repo cannot say which reading is right. Its capture table has column order Z|X|Y and gives Pn000 as 0,1,1 = X and Y reversed. Its decode text says Y and Z reversed. The table's column order IS corroborated - the Pn001 row matches HANDOVER's independent note - and the decode is corroborated by nothing. 🔴 This sets the sign of the 7I77U analog command per axis, and the retrofit ALSO flips Y and Z in software, so the two readings give a different net sign ON EVERY AXIS. Write down which drive you are standing at drive-parameters

Which side of the drill block is the router physically on?grant🔴 SETTLES WHETHER EVERY HEAD OFFSET IS SIGN-FLIPPED. Offset.prm puts 'Left horizontal drill' at X +63.40 and 'Right horizontal drill' at X -2.00 - the Left bit to the RIGHT of the Right one. Front/Rear inverts the same way in Y. Both pairs inverted, consistently, which is what you would see if the file stores the CORRECTION TO ADD rather than the tool's own position - meaning every dx/dy must be NEGATED before use. Nothing in the repo tests it against a physical fact. One look at which side the router sits fixes the sign for every head drills-and-saw-on-linuxcnc

Is the output module coil common isolated from -G2 and earth?grant🔴 THE ONE REAL ELECTRICAL RISK in landing -G3 in the Housing. -G3's 0 V is bonded to protective earth at CN5P pin 5 (settled 9 Sep, blue and green/yellow crimped into one ferrule). So if the coil common is NOT isolated, landing -G3 bridges the regulated supply to the unregulated -G2 rails through earth. Interposing relays exist precisely to keep the two sides apart, so all three are probably open - but it is the one measurement that turns a clean job into a puzzling one housing-power

Measure the standing current out of the Cabur -G3grantBefore adding the Mesa load. What -G3 already supplies is NOT established - only the three servo drives are confirmed, and rail 14, which sources every dry-contact input on the machine, may or may not come from it. Measure at X1A, idle and running. Under about 3 A and there is nothing to think about housing-power

Measure the drill ram strokegrantZ sets the block height and the ram plunges a fixed distance, so depth = stroke - (tip to surface at that Z). One measurement makes every drilled depth calculable. Until it exists no generated program can cut to a stated depth drills-and-saw-on-linuxcnc

Settle which physical spindle is T1 - file and photo disagreegrant🔴 Offset.prm and the head photograph DO NOT AGREE on the drill order. By X the file reads 5,5,5,5,5,broken,8mm,(none); the photo reads broken,8mm then six 5mm. Reading the file from the other end does not reconcile it - that puts the 8 mm before the broken one. 🔴 This decides which physical spindle each T number fires: get it wrong and every hole lands one or more 32 mm steps off AND THE PROGRAM LOOKS CORRECT. One look settles it - stand at a known side, count from a known end, note which is the broken one and which is the 8 mm. machine.json's drill map is frozen until then drills-and-saw-on-linuxcnc

Change the axis direction labels on the machinegrantThe retrofit uses the standard convention - Y+ away from the operator, Z+ up - which is REVERSED from the plates on both. X is unchanged. Until the plates change, the machine says one thing and the screen says another, which is worse than either convention applied consistently machine-layout

Measure the spoilboard face against the machine's Z zerograntZ zero is at the TOP of travel, not the table, so the workpiece surface is a large negative Z - around -180 wherever the board actually sits. The generator refuses to run without it rather than defaulting to 0, which describes a surface that does not exist machine-layout

Record the Z counterbalance regulator pressuregrant🔴 A gauge reading that exists nowhere else and goes the moment someone bumps the knob. The Z servo gains were commissioned on a carriage balanced at this pressure - lose it and the Z tuning has to be re-derived from scratch instead of starting from the machine's own known-good numbers. Also the first thing to check if Z ever behaves differently up versus down servo-drive-interface

Decide

Photocells: live from first power-up, or phase 5?grant🔴 THREE POSITIONS IN THE REPO and the standing brief carries the oldest. CLAUDE.md 9 (31 Aug): dropped initially, return at phase 5 with pendulum working, never run pendulum without them. HANDOVER 2 Sep: photocells and both zones stay live from the start, removing that caveat. pre-strip-survey 6 Sep: pendulum is Tecnos policy not machine fact, so LinuxCNC decides whether to do it at all - which dissolves the phase 5 the coupling was attached to. control-logic-spec.md and HAL section 7 still follow the 31 Aug version. One sentence from Grant into CLAUDE.md 9 and everything downstream follows zones-and-loading

Which homing model - reproduce TEA's origin, or a fresh one?grant🔴 THE REPO CONTRADICTS ITSELF AND THE INI PICKS A SIDE SILENTLY. homing.md: 'LinuxCNC reproduces it exactly' - search vel, latch vel, index latch, Q.TARAT offset. zones-and-loading.md and survey item 4: the retrofit homes on its own terms so the new origin will NOT sit where the old one did. Meanwhile tuchop-sim.ini has HOME_USE_INDEX = NO on all three joints, which quietly chooses 'fresh origin'. ⭐ It matters beyond tidiness: with the index latch and Q.TARAT the old origin is reproducible and the zone midline need NOT be re-measured; without them HOME_OFFSET = -10.0 is a number from a datum being abandoned homing

Decide the groove width the saw has to cutgrant⭐ THIS CHOOSES THE BLADE, and it is a shop decision not a machine one. The groove is exactly as wide as the blade is thick, so 'what do we groove' comes first - 3.6 mm hardboard backs and 6 mm ply drawer bottoms want different blades. Nothing in the capture records a blade size; the machine never stored one drills-and-saw-on-linuxcnc

At the desk

Build a bring-up config that loads Mesa but NOT motionclaude⭐ The single most useful thing to build before the cards go in. Outputs can be exercised with ZERO possibility of axis movement, because motmod is never loaded - so stages 2 to 4 of the bring-up plan run with the gantry electrically incapable of moving. Also needs a printed I/O walk sheet, 44 in and 41 out, to tick off at the machine bring-up-plan

Actually RUN the simulation, end to endclaude🔴 Still never done, and it gates everything. It is also the rehearsal: every halcmd used in the first four bring-up stages works identically in the sim, against LEDs instead of valves. Learn the tools where nothing can move bring-up-plan

Queued

Wanted, but not blocking the Mesa install.

At the desk

Add the saw cut-direction term to the HAL guardclaudemachine.json has cut_direction '-' since 10 Sep. tuchop-io.hal section 5b still says 'THE CUT DIRECTION IS NOT GUARDED HERE ... when machine.json saw.cut_direction is set, add the third term'. The trigger condition has been met and nobody went back. ⚠️ Layer 2 (the linter) DOES enforce direction, so this is a defence-in-depth gap rather than an open hole - which is why it is 'next' and not 'now'. Needs a signed X velocity, so it wants doing deliberately, not in a hurry drills-and-saw-on-linuxcnc

Wire motion.homing-inhibit into the drill and saw guardsclaude🔴 GAP FOUND 12 Sep: feed-inhibit covers G-code and jog-inhibit covers jogs, but NOTHING holds a HOME command. A home with a drill down moves the axis. motion.homing-inhibit exists and appears nowhere in tuchop-io.hal (grep: zero matches). Whether the watchdog trip catches it depends on motion.current-vel being non-zero during a homing move, which is not established linuxcnc-motion-pins

Give the [GUARDS] thresholds a provenance, or mark them made upclaudeMOVING_THRESHOLD 2.0, OFFAXIS_THRESHOLD 1.5, TRIP_DELAY 0.02 and HOLD_WATCHDOG 1.50 are invented numbers with no source and no 'measured': false. They moved from machine.json into the INI to avoid drift and lost the provenance convention on the way. They must be set against real following-error jitter, and nothing currently says so drills-and-saw-on-linuxcnc

Make the post use the router ram as the rapid, not Zclaude⭐ Cycle time. The original set the depth ONCE on Z then plunged and retracted with the ram at every position, moving Z only when the depth changed. A pneumatic stroke beats a ball screw for a short repeated move - it is why point-to-point routers are built this way. A naive post that raises and lowers Z between every feature spends the difference on every hole and pocket. Needs grouping by depth, same as the drill generator already does what-lives-on-the-board

Rebuild the horizontal-drill anti-collision in the generatorclaudeThe original had it (ISO M106/M107) and ENABLED BY DEFAULT, which says Masterwood thought it mattered. There is no trace of it in MW310.PLC, so it was a compiler or board function and is lost with the PC. Firing a head drives the non-cutting bit out into free air, and that is the one that hits clamps, fences and the far side of narrow panels. Belongs in the generator where the part geometry is known, not in HAL drills-and-saw-on-linuxcnc

Settle how the 7I77U's differential enable drives /S-ONclaudeENA0-2 are differential pairs; the SGDH /S-ON is a sinking input against +24V-IN. Those are not the same shape, and it is a design question rather than a wiring one servo-drive-interface

At the machine

Hit the REMAINING E-stop stations, rope switch -SQF1 includedgrantOne station is confirmed with the PC off; the survey asked for every station. -SQF1 is the one nobody looks at and the one that latched on 31 Aug. Ten minutes, no motion, nothing to set up - and it has to happen before the Monoscheda comes out pre-strip-survey

Find what -F14 and the Housing's FUSE 1 / FUSE 2 protectgrantThree fuses with no recorded function. -F14 is 1 A at sheet 3.7 and is the one thing that could contradict the finding that the 24 V DC rail is unfused. FUSE 1 and FUSE 2 are 1 A on the violet wires at the Housing panel, and are the only unaccounted load on the 24 V AC feed that is about to be removed fuses-and-protection

Record which of the six 5mm spindles are reverse rotationgrantRed-marked bits are the reverse ones. All ten run off the one motor and adjacent spindles are geared to counter-rotate, so a reverse spindle needs a LEFT-HAND bit. Fit a right-hand bit to one and it rubs and burns rather than cutting. The 8mm and the 10mm are recorded as reverse; the six 5mm are not drills-and-saw-on-linuxcnc

Replace the broken 4mm drill, spindle 1grantSnapped off. The optimiser now excludes it, so any 4mm hole is refused outright rather than being planned onto a spindle that would drill nothing drills-and-saw-on-linuxcnc

Confirm which axis the horizontal borer pairs point alonggrantANSWERED that they point OPPOSITE ways, one bit each end, and one output fires both - so it is a choice of direction, not two holes at once. Still open: whether the pairs run along X or Y. pargen.prm's Q_ANTICOLL_V is a V-axis number which hints Y, but that is a hint not a fact. Also needs their offsets from the router spindle drills-and-saw-on-linuxcnc

Check the ten drill bits against the machine's own tool tablegrantMostly ANSWERED - tabuten.tmp lists T1 4mm, T2 8mm, T4 35mm (the hinge-cup borer), T5 10mm and T6-T10 all 5mm, and those are now in machine.json. T3 has no entry. This is the table as captured on 31 Aug, not a measurement, so it is a tick-off against the head rather than a survey drills-and-saw-on-linuxcnc

Photograph the spindle motor nameplategrantThe pole count is the last thing between 400 Hz and a real 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 pre-strip-survey

Prove all six overtravel switches, both pathsgrantThe cabinet LED proves the PLC path; the drive's P-OT/N-OT proves the hardware stop. The second one is what protects the first jog pre-strip-survey

Measure the saw housing clearance and arbor centre heightgrantThe other two things that decide blade diameter: what clears the aggregate housing sets the maximum, and the arbor centre height above the bed at full ram stroke sets how deep a given blade can cut. Bore is fixed at 20 mm by the arbor so that is not a choice. Easiest with the cover open drills-and-saw-on-linuxcnc

Carousel drive, when convenient

Re-read step 24, and read steps 25-28grantStep 24 is the one irregularity in the pocket table — SEL 3 on a zero coordinate. The walk stopped at 24 of 28 carousel-indexer

Find which P-IN pin carries which bit weightgrantThe manual lists pins 35-31 without saying whether that is MSB-first. Set one bit at a time and read IN-7 in decimal. A minute, and it needs no controller carousel-indexer

Read in-4 (STB) at rest, and dP_idgrantdP_id should echo the front-panel rotary switch, since PA 00 reads 0 carousel-indexer

Deferred

Settled during commissioning, on the new control.

At the machine

🔴 Fire ONE drill and watch IF.10 - the interlock depends on itgrant🔴 IF.10 DID NOT MOVE when every head on the machine fired, three times over, in the reset self-test captured 31 Oct. The drill interlock in tuchop-io.hal was designed on 'IF.10 goes false on every plunge' and drills-and-saw-on-linuxcnc.md states that as the founding fact. ⭐ The capture is sound - IF.11 (saw) and IF.26/27 (horizontals) DID drop and return in the same frames. So either SQ201 watches something other than the drill block, or the heads never physically descended, or the series chain held it high. ⚠️ The HAL hold's FIRST term (any drill COMMANDED down) does not use IF.10 and is safe either way. ⚠️ CANNOT be done before strip-out - MW310 has no screen that fires a single output (Grant, 31 Oct). At Mesa commissioning it is trivial. ⚠️ Note the direction: IF.10 is stuck ON, everything-retracted, the FAIL-DANGEROUS way for an interlock to fail reset-sequence

Establish the DRILL length datum by touching one drill offgrant🔴 THE BLOCKER ON USING TAB01.DAT's DRILL LENGTHS. Gauge line, spindle nose and block face all give plausible numbers and differ by tens of mm. A confident tool length against the wrong datum drills every hole to the wrong depth AND LOOKS RIGHT ON SCREEN. ⭐ The ten drill lengths cluster at 67.80 to 69.00 mm, so the datum is common to the head and ONE touch-off should correct all ten. ⚠️ Skip T1 - it is the broken 4 mm and its 67.80 predates the break. Until this is done tool.tbl stays zero rather than carrying numbers of unknown origin mw310-operating

Measure all 8 carousel tool lengths from scratchgrant🔴 EIGHT, not five. The cutter bits have been REMOVED from the tapered holders and Grant is loading all 8 pockets (12 Sep), so TAB01.DAT's five lengths describe tools that are gone and the other three pockets were never configured at all. NOT a datum problem - it applies whatever the datum resolves to, and unlike the drill block there is no single common offset to find. Eight separate measurements, one per holder mw310-operating

Confirm the arbor turns anticlockwise seen from the nut facegrant🔴 A right-hand nut only self-tightens that way: under load the blade lags the arbor and friction drags the nut backwards relative to it. Turn the other way and the nut unwinds itself in service and throws the blade. ⭐ It is also a free cross-check on the cut direction, which is still only DEDUCED from a photograph and which machine.json and the generator are both built on. If the two disagree, one of them is wrong. Settle it before a blade ever runs drills-and-saw-on-linuxcnc

Deferred to commissioning

Watch IF.28 when a horizontal head is first fired on MesagrantIF.28 (SQ133, horizontal unit 3) dropped on the FIRST of the three self-test cycles and not on the second or third, while IF.26 and IF.27 toggled on all three. Either a sticky sensor or a head that stopped returning fully. ⌛ The reset self-test that would have shown it again went out with the Tecnos on 31 Oct 2026, so this moves to the first Mesa firing of horizontal unit 3. Not urgent, but it is the kind of thing that becomes a mystery fault later, and reset-sequence has the frame numbers to compare against reset-sequence

Resolve IF.21 - drawbar piston, or spindle index?grant🔴 TWO READINGS OF THE SAME WIRE. MW310.EQU:505 calls IF.21 'PISTONE C.U. 1 GIU' (tool-change piston down); HANDOVER:225 calls it a spindle zero/index sensor; control-logic-spec:191 says unresolved. JOB 48 waits on it after EVERY drawbar release, so if it is really an index pulse the M6 remap will hang or race. ⭐ Evidence for the EQU reading: no S-axis command appears anywhere in JOB 48, so the Tecnos does not orient the spindle. Two minutes inside the filmed tool change settles it - watch whether the LED follows the drawbar or pulses with rotation atc-operation

Measure the ROUTER ram stroke, separately from the drill block'sgrantTwo different rams, two different strokes, and they were sharing one placeholder in machine.json until 11 Sep. The router ram is the one that plunges the spindle relative to the carriage - it sets how far below the Z position the cutter actually reaches. Same test cut that settles the drill stroke what-lives-on-the-board

Derive the 35mm and 10mm spindle offsets from a test cutgrantMOVED from a tape measurement (Grant, 11 Sep: measuring it accurately off the router centreline is difficult). Deriving it is also the BETTER method, not just the easier one: drill a test hole at a commanded position, measure where it actually landed, and the difference IS the offset - tooling runout and any squareness error included. Same technique settles the horizontal head offsets. Until then the generator refuses any 35mm or 10mm hole rather than guessing drills-and-saw-on-linuxcnc

Confirm which output fires which physical drill spindlegrantThe numbering in machine.json is the obvious reading, not a rung-out fact. ⌛ MW310 had no screen that fires one output, so this was never doable on the original (Grant, 31 Oct 2026). ✅ On Mesa it is trivial and safe: air off, one output at a time from halshow, watch which spindle drops. Same trip as the IF.10 test io-map

Find out whether SQ201 sees the saw and router headsgrantIF.10 is one magnetic sensor with six PLC symbols aliased onto it. The original PLC uses it as the head-up confirm around the ROUTER PLUNGE, so the router head almost certainly breaks it - and the motion hold has to exempt the router or ordinary routing becomes impossible. Whether the saw breaks it too is unknown. The hold is written to be correct either way, but this decides whether those exemptions are doing anything drills-and-saw-on-linuxcnc

Re-check the homing search directions on Y and ZgrantReversing an axis reverses which way 'towards the switch' is in sign terms, so HOME_SEARCH_VEL and HOME_LATCH_VEL on JOINT_1 and JOINT_2 may need flipping. They were placeholders anyway, but do not assume they are right just because the limits now are. X is unaffected machine-layout

Walk all 41 inputs, proving EIN n = IF.ngrantFact-checks the largest inherited artefact in the project - the io-map chart, which is a transcription of the diagrams and has never been checked point by point against the machine. ⌛ The route planned for this is gone: the MW310 diagnostic screen went out with the Tecnos on 31 Oct 2026. ✅ TWO ROUTES LEFT, and the better one is now the default: read the inputs off the Mesa card in LinuxCNC (halmeter or halshow), which is self-verifying because it proves the ribbon landing AND the address in one walk. ⭐ The module-LED route is available sooner if the LEDs light without the ribbon - see that item. 🔴 Nothing jogs until this walk has passed on the overtravel and E-stop inputs at least pre-strip-survey

Watch dP_IO on the Panasonic during the first Mesa tool changegrantIN-4 is STB and IN-7 shows the pocket number in decimal. Monitor mode leaves I/O control enabled carousel-indexer

Tighten the drill and saw dwells on halscope, if cycle time mattersgrantLargely ANSWERED - the machine's own numbers came out of pargen.prm (TIME02 300 ms drills, TIME04 100 ms saw after the up-sensor drops, TIME11 500 ms stops) and are now in machine.json. They are the PLC's ceilings, so a halscope trace can still tighten them - but nothing is blocked on it machine-timings

Set the saw off-axis velocity thresholdgrantWith the blade down the HAL guard trips if Y or Z moves at all. Following error puts small non-zero numbers on a velocity pin that is nominally at rest, so the threshold has to clear that without letting a slow drift through. Easier than it was - there is no legitimate Y or Z motion to accommodate linuxcnc-motion-pins

Axis scaling — set an arbitrary scale, jog, measure, correctgrantCross-check against Pn201, which gives pulses per motor rev. If measured and calculated agree, the number is not in question pre-strip-survey

Direction sign on each axisgrantSame jog session. Start mid-travel, smallest increment, and know the overtravels work first pre-strip-survey

Homing — two-stage search, method already chosengrantRapid to the switch, back off until the signal drops, slow re-approach. HOME_SEARCH_VEL and HOME_LATCH_VEL pre-strip-survey

Re-measure the zone midline after the first homegrant1833.70 is a Tecnos coordinate and the datum moves. It is hard-coded in tuchop-io.hal and wrong for the real machine until re-measured zones-and-loading

Vacuum sense polarity, when the pump is installedgrantWatch IF.9 change state as the pump pulls down. Do not let the simulator's assumption become the config by inheritance pre-strip-survey

🛒 To buy

Not tasks. Plant and parts the job needs.

Purchase

Saw collets and arbor nutgrant✅ RIGHT-hand M20 x 2.5, 20 mm arbor diameter, blade bore therefore 20 mm (Grant, 11 Sep). Neither collets nor nut came with the machine. The thread hand is settled, so this is no longer blocked. ⚠️ The flange set has to suit the arbor and the blade bore together, and there may be a drive pin or keyway to match drills-and-saw-on-linuxcnc

Spring-return key-switch for the guard overridegrantSetup and jam clearing genuinely need to move with a drill down, and an interlock with no override gets permanently bypassed by whoever is in a hurry. It must be SPRING-RETURN - the 'clears itself when you let go' property has to come from the hardware. A latching switch left on is how an override becomes permanent linuxcnc-motion-pins

Shop plant

CompressorgrantEvery clamp, stop and the tool-change ram is pneumatic. Nothing on this machine moves without air

Air dryer for the compressorgrantWet air into the valve blocks and cylinders is how pneumatics die slowly. Worth buying with the compressor rather than after the first failure

Dust extractorgrantA 400 Hz router in MDF. Also keeps dust out of the cabinet and off the new electronics

Vacuum pumpgrantAdded by Claude, not asked for - flagging because it is a known gap rather than a suggestion. The machine holds work by vacuum, and the vacuum sense polarity item cannot be closed until a pump can pull down pre-strip-survey

⌛ Gone with the Tecnos

These needed the old board driving the machine. It came out of the Housing on 31 Oct 2026, so they can no longer be answered. Kept, not deleted, each with what replaces it - otherwise they get re-opened.

Run briefs/rp5800-observation-brief.md on the shed PCgrant⭐ ANSWERS THE PARAMETER-SET QUESTION WITH NO HARDWARE AT ALL. If MW310 reads Param/Syncro.prm during startup it is sending it, so the disk file is what the board runs; if it never opens the file, the board has its own copy and the disk file is only what someone last chose to send. That is a filesystem question, answerable with a PowerShell FileSystemWatcher - no serial tap, no install, no risk. ⭐ Startup DURATION is a second independent test: at 19200 baud the 352 KB PLC takes ~3 min and the parameters ~3 s, so a sub-30-second start means no upload happened. Also captures which process holds COM1, any new SV32.log lines, and what changes during a program run. ⌛ LAPSED 31 Oct 2026 - the board is out, so MW310 opens COM1 and talks to nothing. ✅ THE QUESTION IT EXISTED TO ANSWER IS ALREADY ANSWERED, by measurement rather than by file-watching: X cruised 1292.87 -> 2756.03 mm in 3.00 s = 488 mm/s in the 31 Oct capture, which matches VEL max 30000 mm/min in the LIVE Param/Syncro.prm and rules out both 40000 sets. The board ran the disk file. ⚠️ What is NOT answered and now never will be from the original: Q.TARAT, the X homing offset. Treat HOME_OFFSET as a commissioning measurement, not an inherited number what-lives-on-the-board

LISTEN-ONLY serial tap on ONE MW310 cold startgrant🔴 THE HIGHEST-VALUE THING LEFT, and the reason the tap was dropped does not cover it. THREE DIFFERENT parameter sets are on disk: live Syncro.prm (X 30000/1200, Q.TARAT -1000), the backup (40000/2000, -1000) and Sv/PARM.PRM.tilde (40000/1400, 🔴 Q.TARAT 0). Parameter and PLC transmission are EXPLICIT operator actions in messaggi.txt, not startup behaviour, so the board holds its own copy and may match NONE of them. Q.TARAT is the X homing offset - if the board runs the third set, HOME_OFFSET should be 0 and our -10.0 homes X ten mm out. ⭐ SV32.log shows the board handing its parameters back to the PC in 2008 ('Richiesta Parametri Macchina a Syncro' then 'Lettura parametri ricevuti'), so they ARE readable out of it. ✅ Safe: 3-wire null modem, no handshake, so a passive Y-tap needs no com0com, no hub4com and NO Mw310.ini change - nothing to roll back. Note the startup duration too: at 19200 baud a 352 KB PLC upload is ~3 min and 5 KB of parameters ~3 s, so a fast start means the board runs its own copies. ⌛ LAPSED 31 Oct 2026 - a tap needs the board on the other end of the cable. ✅ The parameter-set question it was the highest-value answer to was settled by measuring X cruise against the live Syncro.prm instead. ⚠️ Q.TARAT stays unanswered; HOME_OFFSET becomes a commissioning measurement what-lives-on-the-board

Two tool changes to DIFFERENT pockets, filmed, six-point watchgrant✅ (b) is answered - rotary, confirmed by Grant 12 Sep, so drop it. Watch for: (a) does X move to a different position per pocket - ⭐ a rotary magazine presents at ONE point so it probably does NOT, which is worth confirming; (c) does the spindle creep to an angle before the gripper engages; (d) does IF.21 change with the DRAWBAR or pulse with spindle rotation; (e) does Y park at one fixed value; (f) phase durations. 🔴 machine.json's tool_change has Y and Z but NO X, and toolchange.ngc has no approach move at all - nothing settles whether the change X is per pocket. ⚠️ Offset.prm's C rows step 50.00 mm per pocket and the Panasonic steps 100000 pulses = 10 motor revs = 50 mm on a 5 mm screw, which fits a LINEAR TRAVERSING magazine at least as well as the 80:1 worm that carousel-indexer.md marks 'inferred, not read' - ✅ now settled as rotary, which makes the 80:1 arithmetic rather than merely typical. ⌛ LAPSED 31 Oct 2026 - the original never ran a tool change for us in eight weeks of trying, and the board is now out. ✅ What the 31 Oct reset capture banked instead: OF.42 vs OF.43, the carousel home, and the real phase durations of the pneumatic self-test. ⚠️ (a) change X per pocket, (c) spindle orientation, (d) IF.21, (e) Y park and (f) ATC phase timings are all now first-light-on-Mesa measurements. Build the M6 remap to MEASURE them, not to assume them atc-operation

Reference plot from the ORIGINAL, on paper, before it goesgrant⭐ THE ONLY BEFORE-AND-AFTER BENCHMARK WE WILL EVER GET. Marker in an empty ISO30 holder (the bits are already out), paper taped to the spoilboard, vacuum check toggled off, run P20000.PRG - two rectangles, 800 x 500. KEEP THE SHEET. bring-up-plan Stage 8 makes the first cut a measurement but has nothing to compare it against. ⭐ Syncro.prm has COMP ctl = 0, so the original never compensated backlash - the plot shows the mechanics, not the control, which is exactly what you want to compare against. ⌛ LAPSED 31 Oct 2026 - it needed the original to run a program, which it never did for us. 🔴 CONSEQUENCE, STATED PLAINLY: there is no before-and-after benchmark and there never will be. bring-up-plan Stage 8's first cut is now an ABSOLUTE measurement against the machine's geometry, not a comparison. Judge it against a square and a tape, and do not read a Stage 8 error as 'the retrofit made it worse' - nothing establishes what it was before bring-up-plan

Watch one tool change - does Z travel between two heights?grantSettles the coupling/releasing question by observation without needing the numbers. ⌛ LAPSED 31 Oct 2026. ⚠️ The coupling and releasing heights are therefore UNKNOWN NUMBERS, not inherited ones: the M6 remap has to jog to them under hand control at commissioning and have them written down, with the carousel empty and the drawbar watched atc-operation

Get a tool change to run, and film itgrant✅ The OF.42/OF.43 half is already closed - settled 31 Oct by watching a carousel home at 56 fps (reset-sequence.md), no meter needed. What a tool change would still close: cycle durations and the mechanical sequence. Load P20000.PRG, press F5 = ESECUZ, call a T25/n pocket that is not mounted. ⌛ LAPSED 31 Oct 2026 - timeboxed, tried over several sessions, never ran, board now out. Cycle durations and the mechanical sequence move to commissioning pre-strip-survey

If the ATC will not run, film what does movegrant✅ SUPERSEDED RATHER THAN LOST. The 31 Oct reset capture filmed every stop, drill and saw moving, decoded to the frame - a better record than a phone video would have been. See reset-sequence pre-strip-survey

Photograph the Housing front panel with everything seatedgrant⌛ The photograph you cannot retake, and it was not retaken - the Monoscheda came out 31 Oct 2026. ⚠️ If a photo of the seated panel exists on the phone or in Drive from any earlier trip, say so and it goes in housing-connectors; otherwise the pin-by-pin schedule in that page is the only record of what was plugged where pre-strip-survey

✅ Settled

Kept as the record of what was answered.

At the machine

Check the 7I77U board revision BEFORE landing CN4grant✅ CHECKED 1 Nov 2026 - it is Rev B. Mesa's errata, where the TB7 and TB8 silkscreen labels are SWAPPED, applies to Rev A only. The allocation puts an entire input ribbon (CN4) and two thirds of an output ribbon (CN13) across those two blocks, so a Rev A board would have misplaced 40 conductors. Board print and tables agree, and the allocation is used exactly as written. ⚠️ The 7I76EU is Rev A with no errata found anywhere reachable - see the new revision table in mesa-card-reference mesa-allocation

E-stop drops the drives with the PC offgrantCONFIRMED 11 Sep. The safety chain is INHERITED, not rebuilt: OF.1 is a watchdog alongside it, not load-bearing inside it, so the E-stop keeps working once the Monoscheda comes out. This was the item that protected every other item on the pre-strip survey, and it passed pre-strip-survey

Map D-sub pins to rainbow ways on the IDC adaptersgrant✅ ANSWERED 1 Nov 2026. Grant terminated one DA-15S onto 16-way rainbow and read the colour at every pin. All fifteen match the generic interleave: conductor 1 to pin 1, NOT mirrored. ⭐ Conductor 16 lands on no pin, which independently confirms the ribbon went on the correct end. The build table in mesa-wiring-schedule is now confirmed as written rather than predicted. Open since September as the one thing on the axis connectors that could not be answered from paper mesa-wiring-schedule

Investigate the power supply in the HousinggrantDECIDED 11 Sep: the cabinet's -G3 (Cabur CS6, 6 A 24 V DC) feeds the Mesa cards. No new supply is bought, and the 24 V AC on wires 9/10 is simply not replaced - it fed the Monoscheda alone and the Monoscheda is leaving. Nothing downstream of the output modules changes. The two checks that still gate the wiring are listed separately: coil-common isolation, and the -G3 standing current housing-power

Check whether the saw arbor thread is left or right handgrantANSWERED 11 Sep: RIGHT hand. Order a right-hand M20 x 2.5 nut. The findings page had predicted left-hand on the general rule that saw arbor nuts usually are - wrong here, and corrected drills-and-saw-on-linuxcnc

At the desk

🔴 Reconcile the TWO Mesa landing plans - both claim authorityclaudeRESOLVED 31 Oct, with the cards going in. mesa-allocation.md is the authority for which card and terminal every ribbon way lands on: it is later, written against the MEASURED way map, and it is what build_docs.py, gen_bringup.py and the bring-up panel consume. mesa-wiring-schedule.md is marked superseded for card/terminal assignment; its Housing connector pinouts, wire numbers and the address-to-terminal-to-wire chain stay good and are not duplicated elsewhere. ⚠️ The trap that made this urgent: under the schedule IF.7/8/9 land on 7I76EU TB6 terminals 5/6/7, which is exactly where the allocation puts the three home switches mesa-allocation

Measure the drill block pitchclaudeANSWERED 12 Sep from Param/Offset.prm, already in the capture. The pitch is 3200 = 32.00 mm on eight spindles, in the machine's own parameter file, so it is no longer an assumption. ⭐ The same file also carries the 35 mm hinge borer offset (+32.00, +32.00) that was deferred to commissioning as hard to measure - it may only need confirming, not measuring drills-and-saw-on-linuxcnc

Find the drill-to-router and drill-to-saw offsetsclaudeANSWERED 12 Sep from Param/Offset.prm - every head is in ONE table with ONE origin, named via tipoute.txt -> messaggi.txt. Router (type 98) is dx -89.10, dy +294.60, dz -10.70 from vertical drill T1; saw (type 6 'Saw blade on X') is dx +32.00, dy +168.00, dz +10.90. ⭐ Also settles that the three horizontal heads do NOT share one axis: two bore along X, one along Y. ⚠️ dx/dy solid, dz still the datum question drills-and-saw-on-linuxcnc

Read VRot.10V off the router spindle screenclaudeANSWERED 12 Sep from Param/Offset.prm row 24 - it was in the capture after all, not only on the HMI. 🔴 V10V = 24000, so 10 V COMMANDS 24,000 RPM, which is the LinuxCNC spindle analog scaling number. ✅ Three corroborations: VMAX = V10V = 24000 so the scale is linear to full speed; 24,000 rpm is the HSD M200's rated max; and UTE_SIM = 25 ties the row to the carousel, confirming it is the router. The drill rows carry VMAX = V10V = 0, right for a fixed-speed motor with no inverter - a mis-parse would not produce that drills-and-saw-on-linuxcnc

Check if Value 1 / Value 2 are even used, on the HMIclaudeANSWERED 12 Sep - they are on disk, in Offset.prm's C rows. UtensileCU.def lists exactly 7 fields and each C row carries exactly 7 values in order. 🔴 AND THEY ARE NOT COUPLING AND RELEASING HEIGHTS, which is what this list called them. Value 1 is constant at -4.32 and Value 2 steps a uniform 50.00 mm: they are the POCKET POSITION, nothing to do with the tool change Z moves. ⭐ So there is no per-tool pair and the tool change is built on the machine-level pair alone (53.60 coupling, 0 release) - which was the open question. ✅ Also EIGHT pockets, numbered 0-7, a third agreement with EN_CU_6 = 8 and Grant's physical count drills-and-saw-on-linuxcnc

Find the tool lengths and diametersclaudeANSWERED 12 Sep from Param/TAB01.DAT, already in the capture - no HMI trip needed. All 10 spindle tools and all 5 carousel tools, in hundredths of a mm. ✅ The diameter column is PROVEN: 400/800/3500/1000/500x5 against drills independently known from the head photo to be 4/8/35/10/5x5 mm, ten out of ten. ⚠️ The length column is INFERRED - 67 to 89 mm is the right order and it varies per tool, but nothing says what it is measured FROM. See the next item mw310-operating

Settle which way the saw cutsgrantANSWERED 10 Sep from the head photo, without needing a blade fitted: the arbor rotation shows cuts run from X positive towards X negative, so cut_direction is minus. The generator and linter now enforce it drills-and-saw-on-linuxcnc

Build the HAL motion guards, layer 3claudetuchop-io.hal section 5b. The guard is a conjunction - a drill is down AND the machine is actually moving - because IF.10 goes false on every legitimate plunge. Plus a watchdog on the photocell HOLD chain, which drives motion.feed-inhibit, a pin that M49 silently disables. Every pin verified against the LinuxCNC 2.9 source first linuxcnc-motion-pins

Write the G-code generator and the preflight linterclaudegen_drill.py emits the drilling and sawing with the gang optimiser; ngc_lint.py refuses any file that moves an axis with a drill down, cuts a diagonal with the saw down, skips the IF.10 proof after a retract, or fires a drill with OF.9 off. 44 tests, every rule proven to fire. The linter caught four real defects in the existing drill demo on its first run drills-and-saw-on-linuxcnc

Settled

Output relay coil current, and the ribbon return pairgrant18.5 mA per relay, so about 1 A for all 48 points - every Mesa and supply limit has an order of magnitude of headroom, and output allocation is unconstrained. Ribbon ways 25 and 26 are joined on the board and are the shared negative, doubled for current capacity housing-connectors

Ribbon way to I/O address, all four ribbonsgrantThe single biggest gap in the project. The module blocks sit on each ribbon in reverse order, which no guess had allowed for. Verified against all 96 points, zero mismatches housing-connectors

Mesa allocation and the landing listclaudeEach input ribbon on one card, each output ribbon across the minimum two, every group of eight contiguous, and way number equal to terminal number. 96 ribbon rows plus the axis blocks, generated from the allocation and the way map so neither can drift mesa-allocation

The drill heads ride on the Z carriagegrantOpen since the PLC dig, and it decided the whole drilling model. Z sets the block height, a pneumatic ram plunges it, so depth is a G-code number rather than a spanner job drills-and-saw-on-linuxcnc

All three SGDH servo drive dumpsgrantPn300 differs on every axis — 475, 477, 500 against a factory 600 — so the analog gain could not have been assumed drive-parameters

Panasonic carousel indexer — full parameter capturegrantEight pockets at exactly 100000 pulses. Confirmed three ways: EN_CU_6, the drive's step table, and a physical count carousel-indexer

VS-606V7 spindle VFD — full constant capturegrant0-10 V to 0-400 Hz at factory gain and bias, a hard 104 Hz speed floor, S3 wired as an emergency stop, and overtorque set to stop the drive spindle-vfd

Output field supply confirmed at 24 VgrantA relay pulled in at 24 V and did not move at 12 V. VFIELD is 24 V on every block carrying outputs, sourcing housing-connectors

Syncro configuration failure diagnosedgrantSerial cable in the wrong port after the RAM install mw310-operating

The carousel pocket codeclaudePlain 5-bit binary, closed contact is a 1, pockets 1-8 use four bits. Code 31 is origin return, which resolves POS_RESET carousel-indexer

Feed override switch decoded from the PLCclaudeStraight 4-bit binary, wire colours carry the weights, 16 detents at 10 % each io-map

Mesa terminal reference from all three manualsclaudeEvery connector, terminal by terminal, plus the four manual errata to check against the physical boards mesa-card-reference