mirror of
https://github.com/openglow-org/forgefirm.git
synced 2026-10-15 17:19:55 -07:00
558889659c1ec9c3acec2f00c02c682451fd4eb1
162
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 ScottW514
|
107676b77d |
laser_lifecycle_test: the lid cancels a job held on the button
Rule 16, hold-lid-cancel: a travel job held by a press, then the lid opened. The controller reports "lid opened - job canceled", prints the reset banner, raises no alarm, and returns the head to the job start (MPos X within 0.05 mm of where the job began); a press once the lid is closed again resumes nothing (Idle, the position unchanged). This is the part of motion.lid-cancel-home no host test held: the lid during Run is test_lid_cancels_and_returns, and the kernel playing the return stays with laser.pause-resume-lid-cancel's live lid phase (check_kernel_returned). Proof: the whole harness passes on the null-sink build as grblHAL's CI builds it (-DGFMCODE_WAIT_S=5.0): every earlier case, then hold-lid-cancel, lid-hold and sigterm-mid-job. Acceptance cost: none. scripts/bench/ is outside every fingerprint. |
||
|
ScottW514
|
6594f57362 |
Catalog: motion.port-jog and motion.tray leave; two leftovers of the audit
Two catalog tests leave for the host proofs that carry them; the catalog goes from 80 to 78 (78 @test in forgetest/forgetest/suite/). - motion.port-jog. forgectrl's tests/host_routes.sh (7b2f629 on e69d967) runs the controller port's routes against the port's stand-in: a jog refused without the token, a jog that is no number 400 with nothing on the port, a numeric jog on the port as G91 G21, cancel, release and energize each one line, GET /motion/state passing the port's state on with state and sender, GET /motion/sender 200. The port beside a sender, its polls, the cancel, the client first and the bound are grblHAL's ctlport_test.py and forgectrl's grblport_test; motion.release keeps the physical currents. The helpers before it (_port_state, _port_idle, _words) stay: bedsize, laser and motion.job read them. - motion.tray. host_routes.sh holds POST /motion/tray (tray=in on the port, tray=up 400) and the panel page's switch (id="traybtn", trayToggle, /motion/tray); grblHAL's tray_test.py the mode, its offset, its persistence and its frame; forgectrl's tray_test the daemon's side. suite/tray.py held only it: the module and its import go. The coverage lint then named forgectrl src/tray.c and src/tray.h, and nothing else; grblhal-glowforge's src/glowforge_tray.* stays covered by another catalog test, so it gets no row. One HOST_TESTED row takes forgectrl's, to forgectrl:tests/tray_test.c on forgectrl:.github/workflows/build.yml, which the pin c274f19 runs (./build/tray_test). Two of the audit's leftovers, in the same change: - test_manifest.py's ImplementationHashTests sat after the __main__ guard, so running the file directly skipped it. It is above the guard now, byte for byte: python3 -m unittest test_manifest.py and python3 test_manifest.py (from tests/, where its helpers import resolves) each run its 7 cases, and 34 in all; before, the direct run ran none of them. - laser_lifecycle_test.py's test_lid_open_in_wait said an alarm is raised; the docstring now says what the test asserts: the lid-open cancel is reported and no alarm is raised. The assertions are unchanged and the harness was not run. The coverage lint on the tree manifest finds no uncovered path and no host-tested row problem across the 78 tests; its one finding is setup.check-lens's empty src/lensfind.* entry. pyflakes reports nothing on motion.py, manifest.py, test_manifest.py or laser_lifecycle_test.py. The full forgetest suite was not run. Fingerprints, measured against the parent: 17 tests move with motion.py's shared text: the 11 left in motion.py, and homing.manual, laser's four and setup.check-envelope, whose modules read it. The pending pin bumps from forgectrl c274f19 and forgeext 2d0391e already owe all 17; this deletion adds none to the owed list. The two leftovers move no fingerprint. releases/ is unchanged. |
||
|
ScottW514
|
8e1fe5090d |
Harnesses: the null-sink cases other tests prove leave
The grblHAL harnesses keep what only a running controller shows; the cases a host unit test in grblHAL-glowforge proves, and the log and reply wording, leave. - laser_lifecycle_test: test_arm_waits_for_the_fans goes. laser_arm_test case A4 (grblHAL-glowforge) proves the fan grace stretching the arm's acknowledgment budget, on the same arm path. The docstring names it. - xy_mode_test: case_x32, case_invalid and the log checks go; the default, x16 and the low tick stay. xy_scale_test holds each mode's tick and the not-a-mode parse. - planner_blocks_test: one restart, at $398 1000; the 400 pass and the fresh-store probe go. - ctlport_test: test_poll_lf and test_crlf go (the CR LF poll stays); in test_sender_out the network turn-away goes (serial_test holds it), and the busy gating, the grant and the outlives-client part stay. test_port_dark is whole. - mcode_test: the timeout case runs on the host build's 5 s GFMCODE_WAIT_S (grblHAL-glowforge's CI configures it; the image keeps 30 s) and still shows the hold, at 5.1 s; 5 s outlasts the 3 s test_dark watches the wait; test_table refuses one form per parser branch. test_timeout_holds and test_dark stay. - envelope_test: test_unset and test_bounds go (lens_home_test holds the clamp); test_armed and the open, apply and close cases stay. - manual_home_test: the out-of-range offset block goes, a repeat of gfhome_clamp_home_mm (lens_home_test); the modal-M3 FIRE check and every release and energize case stay. - cool_report_test: one non-hex secret and one CR LF injection stay; runner-malformed and the exact header-set checks go. A bad secret is never sent and a good one is. - tray_test: test_offset keeps 20 mm; test_errors keeps a bad P and a bad axis; the frame shift, envelope, barrier, persistence, port op, unreferenced lens and camera home stay. Proof: with grblHAL-glowforge's matching commit, the eleven harnesses its CI runs pass under Linux against the null-sink build: nine on a build with a 1 s M-code wait, and mcode_test and tray_test, the two that wait at an M-code, on the 5 s build CI configures (-DGFMCODE_WAIT_S=5.0). pyflakes reports nothing in the nine changed files. Push this before grblHAL-glowforge's commit. Acceptance: none; host harnesses only. |
||
|
ScottW514
|
8536ae7076 |
laser_stream_test: the analog copies, the in-run levels and the curve run leave
The analog dose model runs on no machine; the density sessions beside these prove the same rules on the shipped model. - Sessions J and K (M5 at idle, the next job's first cut) run under density only. - Session C (churn, analog) goes; its pad budget (no runaway pad across cycle churn) moves onto session G, density-churn, which already held FIRE, termination and the gaps on the same job. - Session H (a level change inside a run costs no byte) goes: every density power byte is already held at full duty by check_density; the byte count was a cost, not an energy rule. - Rule 19's end-to-end curve run goes: laser_arm_test.c case P pins the curve's mapping. The rolloff sessions keep the curve in force. - The constants only those sessions read go (CURVE_DEFAULT, curve_density_for, CURVE_S, JOB_CURVE, JOB_LEVELS); the header's rules 11, 16 and 19 say what the harness now holds. Proof: laser_stream_test passes whole on a null-sink build of the grblHAL-glowforge working tree under Linux (23 sessions). pyflakes is clean. Acceptance: none. The harness runs in grblHAL-glowforge's CI. |
||
|
ScottW514
|
09cf9242a9 |
laser_lifecycle_test: the sessions the unit tests and the stream prove leave
Each case below repeated a rule another test in CI already proves, read assertion by assertion next to it in the 2026-10-13 test audit: - test_job_window: laser_arm_test.c case I (S changes, and now M5 then M3, inside the window never re-prompt; df7087b) and laser_stream_test session K (M2 closes the window, the next job re-arms). - test_hold_grace: test_resume_after_grace makes the same assertion. - test_verdict_blocks_arm, test_arm_waits_for_engine_ack, test_arm_proceeds_on_a_late_ack: laser_arm_test.c cases C, A2, A3 and cooling_test.c's arm-time gate. test_arm_waits_for_the_fans stays. - test_sender_change: laser_arm_test.c case H; the disarm on a client change is unconditional. - test_jog_does_not_extend_window: laser_arm_test.c case S10. - test_verdict_fail_tier_ends_job: laser_stream_test rule 25 and laser_arm_test.c case V2. - test_verdict_pause_resumes_without_press: laser_stream_test rule 24, which now counts one arm across the pause, and case V1. - test_sender_change_mid_job: merged into test_sender_change_holds_and_rearms, which takes its "held inside the move" position check. - test_sender_change_then_reset: the window is closed and the latch locked by the sender change itself (case H); a reset from Hold is not energy. The header's rules 1, 2, 5, 11, 12 and 14 keep their numbers and name the tests that now prove them. Proof: laser_lifecycle_test passes whole on a null-sink build of the grblHAL-glowforge working tree under Linux (17 sessions), and laser_stream_test with it. pyflakes is clean; no helper was left without a caller. Acceptance: none. The harness runs in grblHAL-glowforge's CI. |
||
|
ScottW514
|
280ceee849 |
laser_stream_test: rule 24's pause holds the window open: one arm
Rule 24 proved the pause tier holds lit to the stop, masks FIRE while held, never writes the latch and resumes lit on the clean verdict. What only laser_lifecycle_test's verdict-pause session held was that the window stayed open through it: the resume armed nothing new. Rule 24 now counts the arms, so that session can leave. - verdict-rehold: exactly one "laser armed" across the pause, the re-hold and the resume. Proof: laser_stream_test passes whole on a null-sink build of the grblHAL-glowforge working tree under Linux. pyflakes is clean. Acceptance: none. The harness runs in grblHAL-glowforge's CI. |
||
|
ScottW514
|
8149a44f93 |
laser_stream_test: session B's FIRE-gap check moves to its density twin
Session B ran JOB_M3_TERM under the analog model; session F runs the same job under density and checked its span, density and termination, but not check_fire_gaps (no stepless run carrying FIRE), which B alone held. F now runs it, and B goes: analog never runs on a machine, and the analog ladder keeps its own termination and gap checks. - check_fire_gaps on density-full, its worst gap in the PASS line. - Session B's run and checks go; the JOB_M3_TERM comment names F. Proof: the harness passes whole on a null-sink build of the grblHAL-glowforge working tree under Linux, density-full with a worst fire gap of 270 ticks. pyflakes is clean. Acceptance: none. The harness runs in grblHAL-glowforge's CI. |
||
|
ScottW514
|
c91f6daa9e |
laser_stream_test: rule 14 runs under the density model
Rule 14 (a level set while the stream is idle still cuts at that level) ran only under the analog model, which no machine runs: its check counted fire ticks per analog duty. Under the shipped density model the level is the FIRE density at full duty, and nothing proved a stale level there. - Session I runs JOB_IDLE_S under DENSITY_CONF_FLOORED and judges it with rule 18's check_density: every power byte at full duty, and each move's span at its own S's density (23/127, 46/127, 81/127), not the one before it. The stream still ends dark. - The header's rule 14 says the level is judged as the FIRE density. Proof: the harness passes whole on a null-sink build of the grblHAL-glowforge working tree under Linux (densities 0.1812, 0.3624, 0.638 against 0.1811, 0.3622, 0.6378). A control judging the same stream against the levels in reverse order fails. pyflakes is clean. Acceptance: none. The harness runs in grblHAL-glowforge's CI. |
||
|
ScottW514
|
a0a4edb322 |
laser_lifecycle_test: a travel job takes the button toggle and lands on its target
Rule 7 proved the button's pause/resume toggle on an armed job only, and nothing checked that the move resumed from the hold reaches its target. The catalog's motion.button-hold-resume held both on the machine with a travel job; it can leave the catalog once the host does. - test_button_pause_resume, after its armed half, runs the catalog's job: M5, G91, G1 X40 F300 (8 s). It must reach Run without asking for the arm press; a press holds it part-way; a second press resumes it to Idle within 0.05 mm of +40. - Rule 7's line in the header and the case's docstring say so. Proof: the case passes on a null-sink build of the grblHAL-glowforge working tree under Linux (the armed half as before; the travel job held at 8.747 mm and resumed to 39.999 mm). A control, the same job held and soft-reset instead of resumed, ends at 8.747 mm, which the landing check fails. pyflakes is clean. Acceptance: none. The harness runs in grblHAL-glowforge's CI. |
||
|
ScottW514
|
d7379d9fc0 |
laser_stream_test: rule 18 reads $31 and the floor off the controller
Rule 18 proved a typed $35 is overwritten at the arm and the ladder
renders through the floor key, but took the shipped settings on faith:
the harness mirrors $31 = 0 and the board's 10 % floor as constants. The
catalog's laser.power-floor read them off the machine; it can leave the
catalog once the host does.
- The floor-derived session reads $$ on the fresh controller (no floor
key: the shipped default) and again after the arm overwrote the typed
$35. Both reads must show $31 = 0 (the floor, not $31, sets the bottom
of the S range) and $35 = the board's floor, and that floor must land
at PWMSAR_FLOOR_MIN (12) or above.
- A set floor key is laser_arm_test.c case J's (12.5 honored, an
out-of-range key falling back to 10, 0 honored). forgectrl keeps no
default for laser_floor_density: an absent key is the controller's
own floor, so there is no second default to compare.
Proof: laser_stream_test passes whole on a null-sink build of the
grblHAL-glowforge working tree under Linux ("$31=0 and $35=10 (PWMSAR
12) fresh and after the arm"). A control session with a floor key of 5
reads back $35 = 5 both times through the same parse, which rule 18
would fail. pyflakes is clean.
Acceptance: none. The harness runs in grblHAL-glowforge's CI.
|
||
|
ScottW514
|
ef15c55577 |
laser_stream_test: the verdict's holds ship no FIRE while held
Rules 24 (the pause tier, held and held again) and 27 (a stale verdict) asserted the deceleration into each hold ran lit to the stop, the stretch between the holds dark, and the cut lit after the clear, but not that the stream is dark inside a hold: the central claim of the catalog's laser.verdict-cut, which can leave the catalog once the host proves it. Rule 21 proved it only for a plain feed hold. - check_hold_dark: no FIRE tick inside a hold's stationary stretch, its edges aside (one step pulse straddles each edge: rule 21's margin, HOLD_EDGE_TICKS, 120 ticks at x8 scaled to the mode: 480 at the x32 default). - Rule 24 checks both of its holds; rule 27 checks its one hold. - check_fire_gaps runs on both sessions, as on rule 21's. - The header's rules 24 and 27 say so; their PASS lines report the held stretches. Proof: laser_stream_test passes whole on a null-sink build of the grblHAL-glowforge working tree under Linux: verdict-rehold dark while held for 22620 and 22622 ticks, verdict-stale for 22621, check_fire_gaps clean on both. A negative control on check_hold_dark: a dark 5000-tick hold passes, and one FIRE tick inside it fails. pyflakes is clean. Acceptance: none. The harness runs in grblHAL-glowforge's CI. |
||
|
ScottW514
|
571f702113 |
forgetest: the emission witness samples a rapid after its M5; m5-rapid-dark leaves
The rule that a rapid after an M5 ships no FIRE is the host's (laser stream rule 16). What only the machine shows is LASER_ON staying off with FIRE clear while the chain can fire; kernel.fire-line's dark sample runs with the chain unarmed. laser.m5-rapid-dark held that sample in a test of its own, with its own arm and press. The emission witness, which every campaign runs, now holds it. - The square ends at M5 with no program end, so the window stays open. - The dark point: the LASER_ON count reads 0 after the M5, the window still armed, and the SoC lock line released (laser_locked false: the engine's armed flag can read true after the latch has locked, and a dark reading with the latch locked is the unarmed case). All three are checked before anything else is sent. - Only then is the rapid sent: G0 X20, a 2.5 s dwell, G0 X-20, a 0.5 s dwell, the program end. Sending it after the dark point keeps the mid-square dwell's own zero from being taken for the dark point. - The test samples until the window closes (a dwell reports Idle, so Idle cannot end it), with the controller's machine X beside each sample. - Every sample from the dark point until the window closes reads no emission, and the HV current stays at its idle reading (HV_DARK_MAX); the reports show the head out at +20 mm and back at the start inside that stretch, and the latch reads released on the sample at +20 mm. - The square still has to show emission and an HV rise, judged on the samples before the M5; the beam detector is judged there too. - The job-based disarm is timed from the head being back: under 10 s, where the idle grace is 60 s. - The rapid's list and its sampler live inside the test, and the deletion takes only m5-rapid-dark's own lines (decorator through body), so laser.py's shared text is byte-for-byte unchanged. - live_fire_drills.py's m5dark note and the bench README say the emission witness now carries the drill's check. Proof: the fingerprint parts of laser.py before and after: the shared text unchanged, every other test's own text unchanged. In the controller, glowforge_laser.c keeps the latch unlocked from the job's first laser-on through M5/M3 toggles and relocks it at program end or after the laser_disarm_s spindle-off grace (60 s by default), so the dark point and the rapid fall inside the window. The coverage lint reports 0 uncovered paths over 110 tests (its one failure is setup.check-lens's src/lensfind.* entry, which the forgectrl pin bump clears); pyflakes adds no finding; the forgetest host suite passes under Linux. Acceptance: only laser.emission-witness moves, and as an always-required test it must pass on the bench in the next campaign before a release can inherit its PASS. |
||
|
ScottW514
|
bef1bf9902 |
z_envelope_test: a move refused past the bed ships no step
The homed cases asserted that a move past X max, Y max or X min draws ALARM:2, and the harness's own description said "before any motion", but nothing checked the motion. The catalog's motion.soft-limits held that half on the machine, by the kernel counters; it leaves the catalog with this harness as its proof. - Every session mirrors the shipped stream (GFSINK_DUMP) into its work directory; steps() counts the tick bytes with an X, Y or Z step bit, as ctlport_test.py does. - Each refused move is judged by the step count across it: unchanged, or the case fails with the ticks that shipped. - The move inside the bed must ship steps: the control that shows the count sees motion at all. Proof: z_envelope_test passes on a null-sink build of the grblHAL-glowforge working tree under Linux, every case including the three refusals before any motion and the control. Acceptance: none. The harness runs in grblHAL-glowforge's CI. |
||
|
ScottW514
|
cd84786fc5 |
tray_test.py and motion.tray: the crumb tray's mode on the null-sink controller and on the machine
- scripts/bench/tray_test.py, run by the driver's CI: M103 P1 and P0 move Z and its envelope by tray_offset_mm on the lens step grid, tell the sender, write and remove the marker beside the shared config, and ship no step; a missing P, P2, P0.5, P-1, and an axis word are errors that change nothing; the switch behind a move waits for the move; the port's tray op with a sender connected, its count exact, refused out of form, during a program, and at a package's M-code; the mode across a soft reset and a killed controller, a start over the marker taking the lens reference in the tray-out frame; the offset's range; an unreferenced lens; a camera home in both modes handing the runner the same park. The kernel-idle half of the barrier needs the pulse device: a null sink is always idle. - scripts/bench/ctlport_test.py: the dark case carries tray out and in under an open armed window. - forgetest: motion.tray in its own module, suite/tray.py, so no other test's fingerprint moves. It switches the mode both ways through the panel's route and through M103 from a Grbl client and judges each switch: /status's mode, Z, and reach moved by the offset's grid, the port's state, the marker, the reference and its source unchanged, the client told, the kernel's counters unmoved. A jog to the Z the lens read before a switch is refused in the other mode and taken back in the mode found; a setup card started with the tray out is refused in the operator's words; the panel page carries the switch. The mode goes back as found in a finally. It does not restart the controller, which would drop the X and Y reference: persistence is tray_test.py's. - The bench registry and README list tray_test.py. Proof: tray_test.py ALL PASS against the driver with the mode, and six driver copies each missing one part of it fail. The driver's whole CI harness list passes. The forgetest unit suite: 500 tests OK. The coverage lint over the working trees: nothing uncovered, 126 tests. On the bench reference, with the binaries hot-deployed on the fx18 image: motion.tray PASS, and FAIL against the driver whose anchor lost its source word on the second switch. Acceptance. motion.tray is new; the suite and bench files are in no other test's fingerprint. |
||
|
ScottW514
|
6e71ac86f0 |
forgetest: exthost.sender-keep-out, camera.lid-privacy for local viewers, and ctlport_test's keep-out
- suite/extsender.py (new module, so no other test's fingerprint moves): exthost.sender-keep-out. A reference package whose service claims the Grbl sender out as it starts, installed with the sender.keep_out grant (and refused without it), on an idle GRBL-mode machine with no sender connected. It checks the holder and the ext: lease of the extension kind, the host's claim file fresh past forgectrl's grace, a sender from the machine's LAN address turned away with the message and one from the loopback admitted, the operator's release (lease gone, network welcomed, the package reading released), a new claim after a restart, and the stale end with the notice after a disable; everything is put back as found. - camera.lid-privacy: the head camera answers the panel's token and the extension host's header with the lid open, and refuses the cloud client's form (no token, no header) and a stream for no local viewer; the lid camera stays refused to everyone. covers gains src/auth.*. - scripts/bench/ctlport_test.py: test_sender_out on the null-sink controller build (Sender(host=) and closed, own_address(), generation()). Proof: forgetest's unit tests pass; the coverage lint passes against the working trees' file lists. Against the current pins it reports src/senderout.* as selecting nothing until forgectrl's pin moves to the revision that adds it, which lands with this. On the bench reference with the suite mounted: exthost.sender-keep-out PASS (first run found the check racing the host's first write; the test now waits for the file and holds past the grace), and camera.lid-privacy passed every check of its body (its hand-back failed only on the controller gated by the privacy advisory's Revision 5 before it was accepted). ctlport_test.py passes in the driver's CI. |
||
|
ScottW514
|
1727b819cb |
homing.manual and the harnesses: the gantry stops by name
The parts the manual home rests against are the gantry stops in homing.manual's title and comments, in manual_home_test.py's docstrings, and in a comment of the baseline's hand-back. No check changes. Acceptance: homing.manual's own text changed, inside its function, so no other test's fingerprint moves. manual_home_test.py passes against the driver. |
||
|
ScottW514
|
b494bbecb5 |
homing.manual and the host harness: the manual home jogs to an offset origin
homing.manual runs two homes. With manual_home_x and _y unset, $H plays no byte and declares X0 Y0 (the checks it had). With 5 and 3, $H declares the head at minus them and jogs it to X0 Y0 before it answers: the sender is told the declared position, the kernel plays the move, Grbl and forgectrl read X0 Y0, and a jog behind the origin draws error:15. The test restores homing_mode and both offsets as found, and returns the head by what the machine read, so a move cut short still comes home. The change stays inside the test's own function. manual_home_test.py: case 7 is the offset's new meaning (declared at minus the offset, the move dark under a modal M3, the port's home, the clamps); a new case cancels the move with a jog cancel and expects it to stop short with $H saying where; case 8 reads the declared position from the sender's message. The bench README says so. Proof: manual_home_test.py ALL PASS against the driver change (ten cases), and its cancel case fails against a build with the driver's cancel hook left out. On the bench reference, fx14 with the driver change and this suite file in place of the image's, homing.manual PASS in campaign c-20260926000059-e731: with no offset no byte and X0 Y0; with 5 and 3 the sender was told X-5.002 Y-3.000, the kernel played 1067 and 640 steps, Grbl and forgectrl read X0 Y0, error:15 behind the origin; settings restored and the baseline clean. The forgetest unit tests pass. Acceptance: homing.manual is the test; its covers are unchanged (the driver's src/**, forgectrl's status and main.c). |
||
|
ScottW514
|
d40ebb090e |
cool_report_test: the homing runner is handed the report secret
The runner case asserted that the homing runner the controller starts does not inherit GF_REPORT_SECRET. The runner is the reporter while a gfcloud $H holds the machine (the controller sends no report then), so the assertion described the defect: every camera home ran with nobody reporting, and the cooling engine's hung-controller dead-man stopped the session's first motion. The case now requires the runner to be handed exactly the controller's secret, and two new cases require that it be handed none when the controller was started with no secret (runner-none) or with one that is not 32 hex digits (runner-malformed). The harness's descriptions in scripts/bench/README.md and in the bench page's catalog say so. Proof: all 11 cases pass on the driver that hands the secret over (grblHAL-glowforge, "gfhome: the homing runner is handed the report secret"); the driver before it fails the runner case: "the homing runner was handed [], not '0123456789abcdef0123456789abcdef'". Acceptance: a host harness in the driver's CI; no catalog test runs it. forgetest/forgetest/bench.py changes one description string, which no test judges. |
||
|
ScottW514
|
853f862f03 | Update release | ||
|
ScottW514
|
ac2456261e |
The measured envelope's harness, and setup.check-envelope
scripts/bench/envelope_test.py drives the null-sink controller with the scripted sender and port client of ctlport_test.py, homing manually: unset keys are the axis travel; envelope_x_mm and envelope_y_mm are the far edges at a home and are held to 50 mm up to the travel plus 30 mm; the port's envelope open is refused before a home and under an open armed window, and lets the port's jogs reach the travel plus 30 mm; envelope apply puts the keys' edges back without a home; a status poll and an empty line leave an open envelope open, while the sender's first line closes it before the core reads it (a jog into the margin draws error:15), a running port jog canceled first; a soft reset and the port client going away each close it. It is registered in the bench registry as a CI harness, not a bench-page tool. setup.check-envelope (suite/bedsize.py, its own module): with cloud mode on, the machine is homed with the camera, and the Bed size check runs with its jog prompts answered as the page would, out 60.1 mm in X and 61.1 mm in Y from the home. The ends it reports are the home plus those, the far edges 1 mm short of them are written as envelope_x_mm and envelope_y_mm, and the controller holds them at once: a panel jog 0.5 mm short of each edge runs, and one 0.5 mm past it is refused with nothing moved. A second run is opened, and while its first prompt waits a Grbl client sends one line, which draws the controller's word that the envelope closed and then ok; the port then says the envelope is closed, the next answer ends the check in words, and the keys are as the first run left them. The head is jogged back to the home, and the keys, the homing mode, and the setup record are put back as found, the record under a restart. Proof: envelope_test.py ALL PASS on the host build of the controller of this change. On the bench reference, with that controller and forgectrl of the same change bind-mounted: the first two campaigns found flaws in the test, not the check (jogs of 20 mm made an edge below the 50 mm forgectrl refuses; the second run started while the machine was still busy; the head was not returned to the home), then setup.check-envelope PASS, with forgectrl.auth, kernel.latch-locked-idle, motion.pacing, motion.jog-roundtrip, and motion.port-jog PASS in the same campaign, and cloud.mode-switch, motion.soft-limits, and homing.cloud-offsets PASS after it. forgetest's unit tests pass (452), and the coverage lint passes with --enforce. |
||
|
ScottW514
|
99d9830991 |
The M-code barrier's harness, and exthost.mcode
scripts/bench/mcode_test.py drives the null-sink controller with the scripted sender and port client of ctlport_test.py: the port's mcodes table and its refusals, error:20 for a number nothing answers, an answered M-code's wait (the head still, the port's state naming it with its words, a port jog busy:mcode, stale and out-of-form answers refused, the answer's words on the console), a refusal and a timeout each holding the job, a soft reset ending the wait, and a wait under an open armed window with M3 S500 shipping no FIRE tick. It is registered in the bench registry as a CI harness, not a bench-page tool. exthost.mcode (suite/extmcode.py, its own module): a package with the reference id that asks for mcode:160 and job_time.run, the one granted, and whose service answers POST /mcode on its call socket. The host's status names it as the one that answers M160. A dark job (out 5 mm, M160 P1, back) through POST /job waits at the M-code with the port's state naming it and the head still over 1 s (the kernel's counters and the port's position), the service answering after 2 s; the job then ends done, every line acknowledged, the head back, the service asked once with the code and its words, no discharge. A job naming M161 fails at that line with error:20 and nothing moved. A job at M160 P2, which the service refuses, is held, and is aborted from there. A job left running by a failed check is aborted before the put-back. Proof: on the bench reference, with the controller, forgectrl, and forgeext of this change bind-mounted, exthost.mcode first FAILED and found the controller announcing the M-code before the kernel had played the last move (the driver now waits for the kernel to go idle), then PASS; exthost.service, motion.job, exthost.page-call, exthost.motion-jog, motion.port-jog, and exthost.package-routes PASS on the same daemons. mcode_test.py ALL PASS on the host build. forgetest's unit tests pass, and the coverage lint passes with --enforce. |
||
|
ScottW514
|
d410c6f696 |
manifest-from-tree: forgeext is a component
forgeext ships from its own repository with its own recipe and pin, and 62 covers entries across the catalog name it - but the tree manifest the coverage lint runs on did not know the component existed, so every one of those entries selected nothing. The lint exits 1 on an empty entry, so the merge would have failed on it; worse, until then forgeext's sources were not coverage-checked at all. A pin nothing has been pushed to yet (SRCREV all zeros, which is how a work branch carries this component until the merge) names the component with no files instead of failing the whole manifest. The lint then reports its entries as empty and exits 1, which is what an unbumped pin should do, and the script stays usable in the meantime. Proof: the script names forgeext and says its pin is not set; with the component's file list stood in, the 31 empty (forgeext, ...) entries become zero, and the 32 that remain are forgectrl and grblHAL paths that do not exist at their pinned commits yet - the pre-push state the work branches are in. |
||
|
ScottW514
|
2894269115 |
The deny rules: the machine itself is never a destination
The way through the extension sandbox's deny rules is an allowlist, and an allowlist names addresses. The machine's own LAN address is not a fact anybody can pin: a new DHCP lease can turn a peer's address on some package's list into the machine's, and with it open the Grbl port or forgectrl's listeners to that package. ffx.nft now refuses it structurally. Everything a host sends to one of its own addresses, the LAN one included, leaves through lo, so chain pool refuses `oifname "lo"` before it looks at the allow map; the two refusals (a reset for TCP, a drop for the rest, both counted) move into chain refuse, which pool jumps to from both places. No kernel option is new: oifname is in the nf_tables core. scripts/sandbox-rules-test.py gets a destination that is not the machine: a second network namespace joined by a veth pair, with listeners of its own. A pool uid is refused on loopback, IPv6 loopback, its own LAN address, and the peer; an allow chain opens one port of the peer to one uid and nothing else; with loopback, IPv6 loopback, and the machine's own address added to that list the uid is still refused at all three while the peer still answers; a reload closes it. It needs ip and nsenter now. exthost.platform reads its counters from chain refuse, holds the rule's place ahead of the map, and adds the case on the machine: an allow chain for the last pool uid that names forgectrl on loopback and on the LAN address opens neither, and the chain is removed. Proven. The rules test passes with nft 1.0.9, and four controls each fail it: the range one uid short, the TCP reject turned to accept, the delete-table line removed, and the lo rule removed (the uid then reaches all three of the machine's addresses). On the bench reference, image 20260920211625, this rule file loaded from /tmp with nft -f and this suite file mounted: exthost.platform PASS, uid 831 refused at 127.0.0.1:443 and 172.16.1.97:443 with both on its allowlist, the counters [0, 0] to [12, 4]. Against the image's own rules the same test fails on the rule's absence, which is the control. The image's rules were reloaded after. The unit suite passes (422). Acceptance. exthost.platform gates the rule on the machine; sandbox-ci gates the file. The rule file is layer content, in the platform identity of every fingerprint. |
||
|
ScottW514
|
d627ee32f1 |
The extension sandbox platform: accounts, cgroups, and the deny rules
What the image holds ready before any extension package exists, so that
the first one starts inside it.
forgefirm-sandbox (new recipe, on both images):
- the account pool: ffx0 to ffx31, uid and gid 800 to 831, one group
each, /nonexistent, /bin/false, locked. Below 1000 on purpose: the
forgefirm-users render replaces only the accounts from 1000 up, so an
account reset leaves the pool alone and the read-only rootfs never
needs an account made at run time. The image's dynamic system ids
count down from 999 and stop at 997.
- an rcS script at S30: cgroup v2 mounted at /sys/fs/cgroup, the cpu,
memory, and pids controllers handed down to /sys/fs/cgroup/ffx, and
ffx marked idle-class (cpu.idle; the kernel refuses a cpu.weight on
top of it, so none is written). The firmware's processes stay in the
root group. `status` reports both halves and exits nonzero when
either is missing.
- /etc/forgefirm/ffx.nft, loaded by the same script, before the network
starts in rc5: table inet ffx, an output-hook filter with policy
accept that sends uid 800-831 to chain pool; pool looks the uid up in
the verdict map `allow`, then answers TCP with a reset (a drop would
leave a connect to time out) and drops the rest (the sender sees
EPERM), both counted. The map is the one way through: a uid mapped to
a chain of that package's destinations. Loading the file again
replaces the table, allowlists included: it fails closed.
nftables comes in as its runtime dependency, trimmed in the distro config
to the binary and its library with JSON output: no interactive shell, no
Python binding. gmp and jansson were on the image; libmnl and libnftnl are
new. The release rootfs goes from 34.5 to 34.1 MiB free.
scripts/sandbox-rules-test.py, and the workflow sandbox-ci that runs it:
the rule file loaded into a network namespace of its own and sent at from
real uids. Root, 799, and 832 are not touched; 800, 815, and 831 are
refused on 127.0.0.1 and ::1 at once, UDP with EPERM, and a receiver hears
nobody from the pool; an allow chain opens one port on one address to one
uid and nothing else; a reload closes it.
exthost.platform (new suite module exthost.py): the platform proven on a
probe process, not read off a config. In a probe group under ffx, as the
last pool uid: held to cpu.max, stopped by cgroup.freeze and running again
after, stopped at pids.max, killed by the group's own OOM at memory.max
while forgectrl keeps its pid. The 32 accounts as the boot's render left
them. Pool uids 800 and 831 refused TCP to forgectrl on loopback (both
ports, IPv4 and IPv6), to the LAN address, and to the Grbl port, at once,
UDP EPERM, with the rules' counters moving by at least the attempts, while
root reaches the same listeners. A root probe under landlock loses /etc
and TCP connects and keeps /usr; a seccomp filter returns EPERM for the
filtered call. The probe group is removed whatever happens.
Proven. The rules test passes with nft 1.0.9, the image's version, and
three controls each fail it: the range one uid short, the TCP reject
turned to accept, the delete-table line removed. The unit suite passes
(422) with no undefined name. Image 20260920211625 carries all of it (read
back from both rootfs images: 32 accounts in passwd, group, and shadow,
S30forgefirm-sandbox, the rule file and the script byte-identical, nft
with its libraries and no Python binding). On the bench reference, that
image: exthost.platform PASS (5.0 percent of the core under a 5 percent
cpu.max, 0 us frozen and 87358 us thawed over 1.5 s each, 5 of 12 forks
then EAGAIN, rc -9 with oom_kill 1 at a 24 MiB memory.max, the counters
[0, 0] to [12, 4], landlock ABI 6), and forgefirm-sandbox status reports
both halves in place.
Acceptance. exthost.platform gates the platform; sandbox-ci gates the rule
file. The recipe, the rules, and the distro option are layer content, in
the platform identity of every fingerprint.
|
||
|
ScottW514
|
965f7c3ca9 |
The cooling report secret: a driver harness, and two catalog tests
forgectrl's POST /cool/state now asks for the secret the supervisor hands the running controller at its spawn; both controllers' cooling clients send it. scripts/bench/cool_report_test.py is the driver's host harness for it (null-sink controller, a stand-in for forgectrl's listener on FORGECTRL_PORT): every report carries the secret and no other new header; none does when there is none; a value that is not 32 hex digits, a CR LF with a header behind it included, never reaches the wire; the homing runner the controller starts does not inherit the secret. It is in the bench registry and the bench README, and the driver's CI runs it. forgectrl.auth: the loopback case used to assert that any local peer is accepted. It now asserts the three answers: no secret 403, a made-up secret 403, and the running controller's own secret 200, read as only root on the machine can read it, out of the controller's environment, and never logged. The LAN cases carry the secret too and are still refused. cooling.report-channel is new, the drill the change exists for: M8 opens a run session, three forged idle reports from this host (no secret, a made-up one, a made-up one with a forged Host) are each refused, and over the next five seconds the engine stays in phase run and no commanded fan duty drops; M9 ends the session on the controller's own report. Proven. The harness passes on the host-built controller, with three negative controls that each fail as they should. The unit suite passes (421) with no undefined name. On the bench reference, forgectrl and both clients hot-deployed over image 20260920152153: forgectrl.auth PASS, cooling.report-channel PASS (phase run throughout, the exhaust at 65535 and the intake at 43278), and cooling.fans-quiet-after-motion and motion.job PASS on the same binaries. Acceptance. forgectrl.auth and cooling.report-channel are the gate for the report channel's secret; cloud.dark-print gates the cloud client's side. |
||
|
ScottW514
|
b29bb9e023 |
bench: the controller port and manual home harnesses
Two host harnesses for the grblHAL driver's null-sink build, in the bench
registry and the README with the others. The driver's CI runs them.
ctlport_test.py drives the controller port beside a scripted Grbl sender
that counts every ok and error it is sent, which is the only way to see a
status routed to the wrong source. 13 cases: the socket's mode; a port
jog's status going to the port with the sender's count exact and the jog
run whole under the sender's '?' polls; a port error the sender's next line
does not inherit; the sender's line canceling a fast port jog and drawing
its own ok (fast on purpose: a slow jog stops at once and would pass with no
hold at all); a sender line queued right behind the port's; the refusals;
one client, and five reconnects right after a close; the status hook across
a soft reset; the dead-man; a CR LF sender; a sender that polls the way
LightBurn does, '?' with an end of line behind it, LF and CR LF (every port
jog accepted, a 60 mm port jog run whole with the polls landing inside it,
one ok per poll, a real line still canceling a port jog); and every
operation of both sets under an open armed window with M3 modal and S500,
where the dump must hold no FIRE tick.
manual_home_test.py reads the stream dump (GFSINK_DUMP) and the attribute
log (GFSINK_ATTR_LOG), so it can say that nothing was shipped and which
current was written, and how many times. 9 cases: a manual $H ships no step
and no FIRE tick and declares the offsets with the soft limits on and Z
kept; $H refused in a cycle; $MD refused under an open armed window with
nothing written; every motion source and $X refused while released; each
energize written exactly once; the port's panel operations; both pairs of
home offsets, alone and at once; and a controller killed under a release,
whose replacement writes only 0 and 0.
Both pass against the driver's extensions tree. The poll cases fail against
the driver without its empty-line rule ("8 of 8 port jogs were refused under
a status poll"), which is the defect they were written from: it was found
on the bench reference with LightBurn connected, and the sender these
harnesses had until then polled a bare '?'.
|
||
|
ScottW514
|
d482e76402 |
installer: a download that resumes and retries, and an install log
A field install failed on "firmware download failed", and worked after a reboot. The download was one bare curl -fL: no retry, no resume, no bound on a stalled transfer, and nothing on the machine recorded what had gone wrong. The download. download_fw makes up to five tries, 5, 15, 30 and 60 seconds apart. Each try resumes the partial file (curl -C -) and is bounded: 20 s to connect, and a transfer below 1 KB/s for 30 s ends the try. The file is written as forgefirm.fw.part and takes its name only when curl finished; the signature check that follows is what vouches for its content. A full disk (curl 23) and a release that is not there (HTTP 404) end the tries at once, because waiting cannot fix them. A partial file the server will not resume (curl 33 or 36, HTTP 416) starts over. The loop is the installer's own rather than curl --retry: the factory curl on the bench reference is 7.69.1, whose --retry does not count a resolver failure or a dropped transfer as retryable, and older factory builds carry older curls. The owner sees the reason in words with each retry, and the final failure says that a re-run goes straight to the download, because the archives are kept. The log. Every run appends to /data/log/forgefirm/install/install.log, in the log tree's own line format (UTC, program "install"): the installer's md5 (which revision ran), the factory version and the slots, the owner's answers, each archive, each download try with curl's exit code, the HTTP code and the reason, the machine's clock at each try (a wrong clock breaks TLS), and after a failed try the address, the default route, the resolver and whether github.com resolves; then the signature and identity checks, the write, the boot selection, and the reason for any failure through die(). The log is appended across runs, so the run that failed is still there after the run that worked. Logging never fails the install. forgectrl's log export carries the directory (forgectrl 0dae758). Proven: tests/test_installer.py runs the installer's own functions under sh against a scripted curl - a clean download, a resolver failure and a dropped transfer that resume to the full file, the tries running out, 404 and a full disk ending them at once, a stale partial file starting over, the TLS reason naming the clock, every log line in the tree format, die() leaving its reason, and an unwritable log not failing the run. The whole host suite, 409 tests, passes under Linux and the coverage lint is clean. Bench: the same functions under the factory firmware's own shell (busybox 1.31.1 ash, the factory slot of the bench reference in a chroot) resumed, retried, ran out of tries and logged exactly as under sh. Acceptance: logs.tree-tail-export now plants a probe file in the install directory and requires it back in the export bundle, its line intact and its MAC and IPv4 address redacted, and requires an install log in the bundle when the machine has one. The installer itself is not on the image: the install page fetches it from master, so it is live with this push. |
||
|
ScottW514
|
260f466400 |
release.sh: no slot size gate on the dev path, which is SD-only
check_size guards the 200 MiB eMMC slot. The dev path called it against the
release rootfs until
|
||
|
ScottW514
|
cd4c176a87 |
Finish the x32 xy_microsteps default in the baseline test and the stream harness
The x32 default landed in forgetest/baseline.py and the driver, but two callers still judged the machine at x8 and both failed on the host. forgetest/tests/test_baseline.py: setUp seeded the fake machine from the x8 FIXED_SYSFS literals while enforce() compares against fixed_sysfs() of the resolved mode, so x_mode, y_mode, step_freq and ramp_rate read as deviations on a clean machine - 23 failures across BaselineTests and TransientNotLeftoverTests. It seeds from fixed_sysfs() now, and the tick expectations come from it (DEFAULT_TICK) rather than a typed 28160. The xy_mode_of and ref_xy_mode unset/invalid cases expect 32, with an explicit "8" case added that had no coverage. Two reference_preconfig dumps taken on an x8 machine carry xy_microsteps = 8, because the markers are read at the reference's own mode. wait_configured wrote the static CONFIGURED_MARKERS where the function watches configured_markers() of the mode in force, and the held-controller jog typed 221 steps for "4.144 mm", which is 1.036 mm at x32; both derive from the mode now. 69 tests, all pass. scripts/bench/laser_stream_test.py: STEPS_PER_MM was the x8 53.333, so the X-peak check failed at 2133 steps against an expected 533. The whole harness now derives from XY_MICROSTEPS_BASE/DEFAULT the way glowforge.h and baseline.py do, which uncovered five more x8-only expectations behind the first: the machine tick, the fire-gap limit (it grows as sqrt(k), not k - a finer mode shortens the accel interval by sqrt(k) while speeding the tick by k), the rung split in fire_spans, the density period and minimum burst (laser_pulse_ticks is in x8 ticks and the stream scales it, so the config keeps the x8 numbers and the measured lengths scale), and the decel/hold budgets. Run against the null-sink build: all stream emission rules hold. xy_mode_test.py's docstring still described the no-key case as x8 while its own assertions had moved to x32. No behavior change and no acceptance-catalog consequence: these are test expectations and a bench harness, not image component sources. The coverage lint is unchanged at 0 uncovered paths. |
||
|
ScottW514
|
8850adcc5e | Update release | ||
|
ScottW514
|
fbac17a485 | Updated release to guard against publishing without source bundle | ||
|
ScottW514
|
0eb764bf75 | Added SPDX | ||
|
ScottW514
|
9a288b175b |
Track the x32 xy_microsteps default in forgetest and the bench tools
Acceptance baseline: XY_MODE_DEFAULT 8 -> 32, split out XY_MODE_BASE (8) for the tick/ramp scaling, matching the driver. The mode-aware comparisons (fixed_sysfs of the resolved mode) judge an unset machine at x32. Host CI: xy_mode_test.py default and invalid cases expect x32/213.333/112640. Bench tools: raster_dry.py and xy_pattern_accel.py set_mode() cleared the key for mode 8, which relied on clear == the x8 default; clearing now yields x32, so they set the mode explicitly and restore to x32. live_fire_drills STREAM_RATE_HZ is the 28160 Hz laser reference tick, the same at every mode. |
||
|
ScottW514
|
2f2a4160af |
Stream and motion robustness: harness rules, catalog tests, the hand-back's counter scale
The GRBL driver's stream engine and its motion envelope change (grblHAL-glowforge: the shipper writes outside the lock, a clamp inside an armed window faults, the X/Y soft limits follow the home, the machine's settings are pinned, the homing keys are clamped). This commit carries the host rules and the catalog tests that hold them; the driver commit follows, because its CI fetches these harnesses unpinned. scripts/bench/laser_stream_test.py: - Rule 28: a 300 ms producer stall while armed faults the stream with ALARM:17, the kernel sees no step burst (at most the planned steps per 100 ticks), the stream ends dark, the latch sideband ends on the lock. The same stall unarmed is a warning: the move completes with every step, the clamp visible as the burst the kernel counts. - Rule 29: a 300 ms stall of the sink's write leaves the producer on pace: no clamp, every step, lit through, dark at the end. - The stand-in engine takes GFSINK_STALL_MS and GFSINK_WRITE_STALL_MS, null-sink only. scripts/bench/z_envelope_test.py: - Rule 10: homed (a gfcloud home), a program move past X max, Y max or the near edge alarms with ALARM:2 before any motion, a jog past the bed is refused with error 15, a move inside the bed runs, and a $20 write keeps the limits. The core repeats the last error for the line after a refused jog until an empty line clears it, so the rule sends one. forgetest/forgetest/suite/motion.py: - motion.soft-limits (kind auto, no emission): homes through the cloud suite's gfhome homing when the machine is not homed, then the three refusals (ALARM:2, the kernel counters still), the refused jog, the inside move, and the return to the corner read at rest. - motion.deadman phase 2b: a 100 ms SIGSTOP mid-move, inside the kernel's queue: no underrun, the controller's log warns of the clamped late events, the move completes with every step (read at rest), the latch stays locked. The armed clamp is proven on the host (rule 28). forgetest/forgetest/suite/cloud.py: - gfhome_homing drains the driver's answer to $H once the session ends: it sits behind the status reports and passed for the reply to the caller's next command (a setting read as None). forgetest/forgetest/baseline.py: - The hand-back reads the position counters at the kernel's own microstep mode (cnc/x_mode, read before the sysfs restore puts the settings' mode back). At the x8 constant, an x32 machine's 30 mm read as 120 mm, beyond the return bound, and the displaced head was left in place. The dead band scales the same way. tests/test_baseline.py holds both. Proof. Host: stream rules 1 to 29 and z_envelope rules 1 to 10 against the null-sink driver, the forgetest unit tests. Bench reference: motion.soft-limits passed (X 495 and Y 279 refused with ALARM:2 and 0.000 mm of kernel motion, X-1 the same, the jog error:15, the inside move ran, back at the corner 0.0/0.0 mm); motion.deadman passed with the new phase (92 late events clamped, max behind 92.3 ms, no underrun, 30.0 mm counted, latch locked) and the hand-back jogged the head back under the x32 scale. |
||
|
ScottW514
|
e9d5f3c842 |
Laser harness rules and catalog tests for the emission gates
The GRBL driver's emission gates change (grblHAL-glowforge: the per-tick fire gate, the latch with an owner, the cooling verdict's two tiers, and the arm-flow gates). This commit carries the host rules and the catalog tests that hold them; the driver commit follows, because its CI fetches these harnesses unpinned. scripts/bench/laser_stream_test.py: - Rule 24 is the verdict's pause tier: the client holds the job under the open window, the first deceleration runs lit to the stop (the dark lead before the stop is at most 1000 ticks: the producer's lead plus one shipper period), a resume under the standing verdict moves dark and is held again, the clean verdict resumes lit with no press, and the latch sideband carries only the arm's unlock and the program end's lock. - Rule 25 is the fail tier: AIRFLOW mid-cut ends the job with ALARM:3, the stream ends dark well short of the line, the sideband ends on the lock, and a resume under the clean verdict that follows resumes nothing. - Rule 26: a sender change mid-M3 holds the job with the deceleration dark: the gate follows the window on every tick. - Rule 27: a verdict that goes stale holds the job at the cache's own expiry, lit to the stop, never a poll later; the engine's return resumes lit. - The stand-in engine publishes the verdict name and has a stale mode; the session steps gain expect_text, reconnect and a wait_state timeout; every session reads the latch sideband (GFSINK_LATCH_LOG). scripts/bench/laser_lifecycle_test.py: - Rules 11 to 15: the pause tier resumes with no press and no prompt, the fail tier ends the job and nothing resumes it, a sender change during a re-arm cancels it, a jog does not hold the window open, and a press counts only after the button has been seen up. The stand-in engine takes a live verdict dict. start_armed_move waits for a fresh prompt and a fresh armed message: a press that lands before the wait has begun is not consent, and the old stale match let one land early. forgetest/forgetest/suite/laser.py: - laser.verdict-cut (kind live, one press): a 40 mm M3 line; the test pauses the daemon for 3.5 s so the verdict goes stale (the settings route is idle-gated and the engine reloads its gates at a session start, so no setting can trip a pause mid-cut; the crash tiers need a physical knock). The controller must hold with the SoC latch and the hardware button latch both clear in every sample, emission must read 0 before the resume, and the clean verdict must resume the cut lit with no press and no prompt; M2 disarms as usual. - laser.armed-kill asserts that the respawned controller comes up with the latch still locked. Proof: both harnesses pass against the driver change on the host, and the forgetest unit tests pass. On the bench reference, laser.verdict-cut passed with no gap in the cut (held at +1.71 s after the pause began, both latches clear in every sample, emission 0 at +2.06 s after the hold, resumed lit at +4.0 s with the beam detector 678 counts over idle, kernel drift 0.0 mm, disarmed 0.1 s after Idle) and laser.armed-kill passed (emission 0 at +1.8 s after the supervisor's stop and +2.1 s after the SIGKILL, latch locked, respawned with the latch locked, button dark). Two earlier verdict-cut runs shaped the driver: a pause that locked the latch resumed dark, because a lock sets the hardware button latch, and a hold taken a poll after the gate closed left a several-mm gap. Catalog: one test added and one extended; both cover src/** of the driver through the existing laser covers. |
||
|
ScottW514
|
c0d4302d73 |
ForgeFIRM v0.0.4
FORGEFIRM_RELEASE 0.0.4. The acceptance record that authorizes this build: campaign c-20260912182427-e1ee on dev image 20260912180956 (manifest 8bb5b6f3), 85 tests, 85 satisfied, 0 required, exported 2026-09-12T19:21:35Z. The release notes in releases/v0.0.4/notes.md name this the first public beta; the pipeline takes a release's notes.md, when it carries one, in place of GitHub's generated notes. |
||
|
ScottW514
|
7b8f72b632 |
Run the commissioning sheet as a fresh machine, and pin forgectrl 0.1.18 (the lens frame)
forgectrl f8ddb17 puts the lens frame in one place and writes the focus window before the card's controller starts, after two commissioning cards ended in ALARM:2 on a Z the wizard sent from one source while the controller's Z limit stood on another. The acceptance run had passed only because the bench's settings already held the stops from an earlier focus run, so the run is now a fresh machine's. commission.sheet clears the three lens settings inside its Restore before the cards, checks that the frame runs in the fallback window, and, after the focus card, that the settings hold the window the ladder ran in (the stops found or the fallback), that every ladder height lies in that window's reach, and that the program served now agrees with /status. Every served program's Z is checked against the reach /status reports before the card starts, so a stray Z fails the test with nothing burned. The test covers src/lens.*. The host mock in tests/test_commission_sheet.py mirrors the daemon (the /status lens block from the settings, the ladder served from the settings, the window written at the focus start); two regression tests reproduce the defects: a focus result naming a window the settings do not hold, and a served program with a Z beyond the reach. 10/10 green. scripts/bench/z_envelope_test.py, the grblHAL CI harness, adds the referenced-lens cases: with forgectrl's marker and the shared settings, the fallback window and a 14/20 window run to the ends of their reach and two half-steps past either end alarms, and a count of 41 falls back on its side alone. Passed on the null-sink build. The bench page's description of the harness follows. The forgectrl pin moves to f8ddb17 (0.1.18); every test covering forgectrl re-runs. |
||
|
ScottW514
|
d898b5659d |
Give the release version its own file, outside the layer content hash
Setting the release number was a platform change. FORGEFIRM_RELEASE sat in forgefirm-image.bb, the recipe hashes as content of meta-forgefirm, and a change to the content of a layer invalidates every acceptance result. So a version bump threw away the campaign that was meant to authorize that very release, and the number therefore had to be decided before the image the campaign ran on. Nothing said so: the release-flow page went straight from the kas configuration to the artifact and the pipeline, while the gate quietly required the recipe value, the rootfs stamp, the archive's meta-version and the tag to agree. v0.0.1 was cut on a tree whose number happened to be right; the next one would have cost a second campaign to discover the rule. The number moves to forgefirm-release.inc, which carries it and nothing else, and the manifest leaves that file out of the layer content hash exactly as it leaves out the component pin files (FORGEFIRM_MANIFEST_VERSION_SUFFIX, and the same list in scripts/manifest-from-tree.py, which computes the identity on a workstation and must agree byte for byte). release.sh reads the number from the new file. The version is metadata, not platform content, and this only makes the manifest say what it already meant: the version string was already outside the identity hash, and it was the file carrying it that defeated that. Nothing is weakened. release.sh still requires the number to equal the rootfs stamp, the .fw meta-version and the release tag, and image.health still compares the stamp on the running machine with the manifest's. Proven: the tree manifest is byte-identical across a bump from 0.0.1 to 0.0.2 (identity a64e51b8e5ecca0af683d4f0 either way, the meta-forgefirm layer hash unchanged), where before the two differed. bitbake resolves FORGEFIRM_RELEASE=0.0.1 and FORGEFIRM_VERSION_STRING=v0.0.1 for the release image through the new require, and the dev image still overrides the string with its build timestamp. |
||
|
ScottW514
|
64301d3221 |
Keep the configuration files inside /data/forgefirm; pin the three components
ForgeFIRM's own files live under /data/forgefirm; two configuration files did not. The machine settings sat at /data/forgefirm.conf, in the root of /data beside the factory's own files, and the cloud-mode configuration sat at /data/etc/gfhome.conf, inside a directory the factory owns. Both move: /data/forgefirm.conf -> /data/forgefirm/forgefirm.conf /data/etc/gfhome.conf -> /data/forgefirm/gfhome.conf There is no migration: only the bench has ever run this firmware. /data/etc now holds only the factory's wpa_supplicant.conf. The acceptance check of the file modes reads the settings file at its new path, and the two bench tools that read it directly follow. The pins move to the revisions that carry the change, forgectrl also bringing the fix that reads the module's disabled state as idle: forgectrl 468ee21 (0.1.12) grblhal-glowforge 9ee624b (0.1.10) forgefirm-app 56f134a (0.1.28+git) The lock moves meta-openglow to b7ad6d9, which pins python3-gfhardware on the same revision. The four upstream layers stay where they were: `kas lock --update` moves every floating repository, and a release is not the place to take poky, meta-openembedded and meta-freescale along for the ride. |
||
|
ScottW514
|
0107c2cad4 |
Remove the cold-build workflow: Yocto builds on the build host only
The yocto-cold-build workflow and its kas/ci.yml overlay built the release image on a hosted runner as a reproducibility probe. It never ran to completion, its first dispatch (2026-09-09) stopped on the runner's user-namespace rule, and a probe nobody runs is a trap. Every Yocto build, the release included, runs on the build host; the release proof is the local pipeline (release.sh) and the bench campaign. The pre-publish checklist loses its self-containment line to match. |
||
|
ScottW514
|
8af8b197ee |
Mount the rootfs read-only on both images
The rootfs mounted read-write, so a slot ran with its own files open to change, and the factory-slot mounts rode along on the release image. Both images now carry the read-only-rootfs feature: the ro root line and the rcS default, the volatile links made at rootfs time, a writable copy of /var/lib at boot, a build failure for a post-install that needs the machine, and the removal of shadow, base-passwd, update-rc.d and update-alternatives. What must last or change at run time is handled file by file: - forgefirm-users renders the four account files from the record into /run/forgefirm/accounts and bind-mounts each copy over its /etc file (useradd and the rest are gone with shadow); a render writes through the mount, and the image's own files apply until the first render. - forgefirm-banner bind-mounts a copy of /etc/issue and writes the address block through it. - sshd keeps its host keys under /data/forgefirm/ssh, so the fingerprint survives updates; both sshd configs carry the same HostKey lines. - forgefirm-logging passes logrotate a state file under /var/run (logrotate refuses to run without one). - forgefirm-persist points the boot timestamp and the random seed at /data/forgefirm. The dev image appends the /factory slot mounts, without nofail (busybox mount hands it to the kernel, which rejects it). The rootfs command entries lose their semicolons: on scarthgap the value is the task's vardeps, split on whitespace, so "name;" left the function body out of the signature and a changed body did not remake the rootfs; with the bodies tracked, the dev image's DATETIME string needs a vardepsexclude. release.sh gains the read-only gate (root ro, no /factory line, ROOTFS_READ_ONLY=yes, host keys on /data). image.health checks the mounts, the account binds, the banner bind, the host keys and the dev-only /factory mounts. Proven on the bench reference (dev image 20260909140901): / ro, /data rw, /var/lib a tmpfs copy, the four account files and /etc/issue bound from tmpfs, the host keys in /data/forgefirm/ssh, no "Read-only file system" line in any log; forgectrl.auth and commission.account-login (a temporary account rendered, logged in over HTTPS and removed again), kernel.latch-locked-idle and motion.liveness-probe PASS; logrotate runs with the volatile state. forgetest unit tests 335 OK; both images build clean, and debugfs on the built rootfs shows every setting above. |
||
|
ScottW514
|
093a7bbbde |
Stage the lens reference in the laser-stream harness
The Z session used to reference the lens itself with M103, which is gone: the daemon sweeps the lens onto its hall edge before a controller starts and leaves a marker, and the controller opens the Z envelope on that. No daemon runs behind the harness, so nothing wrote the marker and every Z move was refused, which is what the session's first move ran into. The runner now writes the marker the daemon writes, and the session pins lens_hall_edge_z_mm so the moves are counted from a known height: Z3 is 9 half-steps on the screw and Z4 is 12, so a 1 mm move up and back is 3 steps each way. This is also the check that caught the controller overwriting its own referenced Z at start, which the panel could not show. |
||
|
ScottW514
|
5f19ae01cd |
Follow the lens reference into the harness and the catalog
The lens now takes its hall-edge reference before any controller starts, so Z is referenced on every start and M103 is gone. The laser-stream harness opened its Z session by referencing the lens the way a commissioning card did; it no longer has to, because Z is already open by the time the session runs. forgectrl.panel-serves gains the assertions for the per-axis reference: homed_axes is an axis mask, homed agrees with it, and with a controller running Z is referenced and reads inside the lens reach the same document reports. That last check is the one that catches a panel showing nothing for a Z the controller holds. commission.check-motion already exercised the new path, because the motion wizard's probe runs the same sequence the supervisor does, so its covers map gains lenshome.c and its description names the lens reference and the hard fault behind it. |
||
|
ScottW514
|
c2ca2686a7 | Assignment | ||
|
ScottW514
|
e36a322ec5 |
Retire BRINGUP.md and CAMPAIGN-LOG.md
Every fact in the two documents is now on the documentation site, which is the single source of truth. This repository carries no project documentation any more: it is the build and release base plus the acceptance tool, the bench tools and the fixture firmware. BRINGUP.md was the runbook, the hardware facts bank and the open-work list. CAMPAIGN-LOG.md was the dated record of how each result was obtained. What replaces them: the site for present state, and the commit message for the record of what a change did and how it was proven, so the change and its record stay together. Local open work is the developer's own file at the tree root and is not tracked here. README.md becomes an index card: what this is, build, test, and where the documentation is. The release pipeline tags the documentation. Firmware on a machine needs the documentation that agrees with it, so release.sh now tags the forgefirm-docs checkout with the same v<version> as the release, and prints the command that pushes the tag with the release. The checkout must exist and be clean, which is a new gate before the signature. FORGEFIRM_DOCS_DIR names the checkout (default: the sibling one) and FORGEFIRM_DOCS_SKIP releases without a tag, loudly, and is never the default. The tag is made at staging and pushed with the release, never before: a documentation tag for a release that never shipped is worse than no tag. No catalog consequence. release.sh is host-side and is in no image. The commission.py change is one sentence of a test description, not behavior. accel_crash_probe.py and the kas header lose pointers to the retired files. Checks: bash -n and sh -n on release.sh, and the tracked trees carry no reference to either retired file. |
||
|
ScottW514
|
59c4516c00 |
The planner buffer depth harness; the XY microstep set is in
scripts/bench/planner_blocks_test.py restarts the null-sink controller at $398=400 and at 1000 on one settings store and requires an answer on the port, the depth in the status report and a move to Idle. It runs in the grblHAL repo's CI; registered on the bench page and in the README. BRINGUP: $398 runs over its whole range, the spin item is closed, and the XY microstep item is committed, pushed and pinned. CAMPAIGN-LOG: the landing and the index fix, with the host and bench proof. No catalog consequence beyond the core submodule the motion tests already cover; the coverage lint is clean. |
||
|
ScottW514
|
8fc5250d6d |
XY microstep modes: the baseline, the catalog test and the bench tools
The baseline derives x/y_mode, step_freq, ramp_rate and the configured markers from the xy_microsteps setting; ramp_rate joins the GRBL controller's set (the driver writes it; the cloud client runs at the module's). motion.microstep-modes cycles 8, 16 and 32: the save restarts the idle controller, the kernel reads the mode with its tick and ramp, $100/$101 are the mode's and a typed $100 is overwritten, a 40 mm jog at top speed returns to Idle with the kernel counters over the mode agreeing with the commanded travel and the accelerometer seeing the head move; the setting is put back as found. Bench tools: xy_mode_test.py (the null-sink harness the grblHAL CI runs), raster_dry.py (a top-speed raster per mode), xy_pattern_accel.py (the operator's pattern from home with the machine silent and the head accelerometer listening), arc_tolerance_sweep.py (a $12 ladder on the 9 in circle: the chord rate the protocol loop feeds, about 300 a second, is the ceiling, not the core), and the xymode and xycircle live drills. BRINGUP carries the present state and the facts; CAMPAIGN-LOG the dated record, including the planner-blocks spin (a $398 of 255 or more loops forever at start, a core bug) and its recovery. |
||
|
ScottW514
|
bfb5cb27d8 |
The tail after Idle is one queue depth, and it does not grow
The open item "Idle before the kernel drains" asked to decide between holding Idle until the kernel drains and stopping the continuation pads growing the lag. Measured first: on the machine, four chained 50 mm jogs against cnc/state give 171, 175, 177 and 176 ms after Idle. One queue depth, flat. The growth the item described is gone, so neither driver change was made and the item is closed. Host side agrees and says where the mechanism lives. Stream bytes are the time axis, so a dumped stream's length is how long the machine plays it: chained jogs produce 35755 bytes each with no growth, and the churn session holds at 64790 bytes at a producer lead of 2 or 10 ms. Only above the lead ceiling does it inflate. Rule 17 now holds that stream to a budget derived from the job rather than to a recorded number, so the inflation regime cannot return unnoticed; it fails at 5899 and 8005 ms with the ceiling lifted and passes at 2301 against 3800. BRINGUP carried a second error. It said every forgectrl path that stops the controller after motion waits for cnc/state idle. super.c says outright that POST /controller/stop is not idle-gated, because it is also the emergency lever, and safes the machine with cnc/stop and the latch before the signal instead. The mode switch, the cooling gate and the daemon shutdown do gate on machine_is_idle(). Both the tail figure and the gating claim are corrected, and CAMPAIGN-LOG carries the measurements and the decision not to hold Idle. Acceptance: rule 17 is a host harness rule in the grblHAL repo's CI, not a catalog case. The catalog is unchanged because no machine behavior is: the driver change is a bound on an out-of-range knob. |
||
|
ScottW514
|
79d2c07734 |
The Z envelope survives a settings write
The Z soft limit belongs to the driver, not to $20. glowforge_homing.c owns sys.work_envelope, sys.homed and sys.soft_limits for Z, because Z is always referenced, to the lens hall edge or to where the lens stands, and the core knows neither. The core recomputes both masks from the settings and drops Z when it does: $20 clears the soft-limit mask inside its setter, and a $13x write clears the homed bit for the axis as well. z_envelope_test.py drives the null-sink controller over TCP and holds the rule. It checks that an unreferenced Z is collapsed to where the lens stands and refuses a move each way, that X and Y stay free so the reassert is Z's alone, and that neither write frees Z. It restores $132. The harness runs in the grblHAL repo's CI, next to the laser stream and lifecycle harnesses. |
||
|
ScottW514
|
b0fa4ccaf5 |
A release publishes the source of the software it installs
The release build merges kas/source-bundle.yml, which turns on the Yocto archiver: the upstream source of each recipe as upstream publishes it, the patches with their series file, and the recipe with its includes. The overlay adds tasks only, so the image manifest is unchanged and an acceptance result still applies; proven on the build host, where the archiver build and a plain rebuild of the same tree give the same content_sha256. scripts/source-bundle.py packs forgefirm-source-v<version>.tar.gz: the archives, both license manifests, the license texts, the ForgeFIRM layers, the kas configuration, the layer revisions and the build identity of the image. What the bundle must hold comes from the image, not from a list in the script: every recipe of license.manifest and image_license.manifest whose license is in the include list must have an archive, or the release stops with the recipe named. release.sh attaches the bundle and covers it with sha256sums.txt; FORGEFIRM_SOURCE_SKIP=1 bypasses deliberately. On the build host: 68 of the image's 111 recipes carry source, 313.7 MiB, under the 2 GiB limit of a release asset. No acceptance catalog consequence: the change is release tooling on the build host and puts no file and no behavior on the machine. The host-side proof is forgetest/tests/test_source_bundle.py, which holds the license decision, the choice of archive and the refusal. |