The safing chain¶

This page describes the discrete laser-safing hardware on the factory control board: the parts, the inputs, the outputs the SoC can drive, the logic, and what each condition does in hardware alone. It also lists what is proven and what is not established. The principle behind the chain is on Safety; the software gates ForgeFIRM stacks on top of it are on GRBL mode and the ForgeFIRM internals pages linked below.

The hardware chain is the safety boundary. Software only ever adds gates in front of it and never bypasses it.

Signal names follow the factory board's nets. GPIOx_yy is the i.MX6 GPIO; the Linux name in parentheses is how ForgeFIRM exposes it (device-tree gpio-keys switch, or glowforge.ko /sys/glowforge/cnc attribute; the attribute reference is on the kernel module).

Parts on the control board¶

Inputs¶

SoC outputs into the chain¶

Laser power (PWM2 on J1_13) is not part of the chain: it sets the tube current setpoint and is not gated. Emission permission is FIRE ∧ chain; the laser-off guarantee rests on FIRE, and the kernel drops FIRE within one tick on end-of-data or underrun. See The laser.

Logic¶

DOORS_OK      = DOOR_SW1 · DOOR_SW2                              (U17-1)
WDOG_ALIVE    = U1-1 Q, retriggered by every CHG_PUMP rising edge
HV_ENABLE     = DOORS_OK · WDOG_ALIVE                            (U17-4)  → J1_16
                ¬HV_ENABLE                                        (U24 inverter) → GPIO4_06, read back as `hv_enable`

Button latch (U23-1):
  SET   = ¬DOORS_OK + LATCH_RESET                                 (U32 OR)
  RESET = BUTTON pressed
  Q1    = 1 → fire blocked; 0 → armed

Interlock latch (U23-2):
  SET   = INTERLOCK_RESET (SoC: high while the loop reads open or is unobservable)
  RESET = interlock loop closed
  Q2    = 1 → fire blocked

LASER_ON      = FIRE · ¬Q1 · ¬Q2                                 (U17-2, U17-3) → J1_12

The CD4043B is set-dominant: while SET is high the latch cannot be cleared. That ordering is what makes the button meaningful. A press only arms the machine when the lid is closed and the SoC has already released its lock.

The chain as wired, in two halves. Hexagons are logic functions on the control board (the part reference below each). Wires carry logic levels; 1 = true as named. Physical switches are on the left, the lines the SoC drives carry a GPIO name, and the outputs on the right go to the laser power supply on J1. Software can only withhold FIRE, hold LATCH_RESET, drive INTERLOCK_RESET, or stop feeding CHG_PUMP, and every one of those makes the hardware block emission.

HV_ENABLE: the lid and the watchdog. The one-shot is retriggered by every CHG_PUMP rising edge (200 ms pulses, only while a program runs).

flowchart LR
    SW1["LID_SW1<br>J4_13"] --> AND1{{"AND<br>U17-1"}}
    SW2["LID_SW2<br>J4_12"] --> AND1
    CP["CHG_PUMP<br>GPIO3_24"] --> OS["one-shot<br>U1-1, 0.45 s"]
    AND1 -- "DOORS_OK" --> AND4{{"AND<br>U17-4"}}
    OS -- "WDOG_ALIVE" --> AND4
    AND4 --> HV["HV_ENABLE<br>J1_16"]

LASER_ON: the two latches and FIRE. Both latches are CD4043B, set-dominant: while S is high, R cannot clear them. LATCH_RESET is cnc/laser_latch (1 = lock; FIRE is also Hi-Z then). INTERLOCK_RESET is high while the loop reads open or is unobservable. FIRE is pulse-byte bit 4, Hi-Z when locked or idle.

flowchart LR
    DO["lid open<br>(NOT DOORS_OK)"] --> OR32{{"OR<br>U32"}}
    LR["LATCH_RESET<br>GPIO1_07"] --> OR32
    OR32 -- "S" --> BL["Button latch<br>U23-1"]
    BTN["BUTTON<br>J5"] -- "R" --> BL
    IR["INTERLOCK_RESET<br>GPIO4_05"] -- "S" --> IL["Interlock latch<br>U23-2"]
    LOOP["INTERLOCK loop<br>J8"] -- "R" --> IL
    BL -- "NOT Q1" --> AND2{{"AND<br>U17-2, U17-3"}}
    IL -- "NOT Q2" --> AND2
    FIRE["FIRE<br>GPIO2_30"] --> AND2
    AND2 --> LON["LASER_ON<br>J1_12"]

The SoC also reads the chain: doors (EV_SW 3, GPIO1_00) and door1 / door2 (EV_SW 0 / 1, GPIO4_14 / GPIO1_06), charge_pump_alive (GPIO1_08, the one-shot's inverted output), hv_enable (EV_SW 4, GPIO4_06), button_latch (GPIO1_03, = Q1), interlock_latch (EV_SW 6, GPIO1_02, = Q2), laser_on (GPIO1_05), and laser_pgood (GPIO4_21, the supply's power-good line on J1_14). These are readbacks for monitoring only; none of them adds an emission path.

What each condition does, in hardware alone¶

hv_enable (GPIO4_06) is a readback of this chain's own output, not an input: it is inactive on an idle machine and active for the duration of any kernel run, the window in which the charge pump is fed and HV_ENABLE is alive. Nothing in ForgeFIRM gates on it; it is telemetry. (The factory design labels the net E-STOP; no Glowforge model has an e-stop input, and a retrofitted one belongs in the lid-switch chain, where the hardware enforces it.)

Software layers on top¶

Every software layer sits in front of the chain: it can only withhold FIRE, hold the lock, or starve the charge pump. None can produce emission the hardware would not allow.

• glowforge.ko owns the laser latch (locked by default; every close of /dev/glowforge relocks), feeds the charge pump only while a program runs, drops FIRE at end-of-data and underrun, drives the interlock latch, arms a dead man's switch on the pulse device, and safes the pins on a kernel panic. See The kernel module.
• The grblHAL controller adds the operator-armed window, the disarm grace, the coolant fire gates, the safety-door handling, and the button semantics. See The grblHAL driver and GRBL mode.
• forgectrl holds the pulse device, relocks the latch on every transition out of a running controller, publishes the cooling verdict, and refuses to start a controller on a machine whose motion is not proven. See forgectrl.
• Cloud mode runs behind the same kernel latch, charge-pump, backstop and dead-man rules. See Cloud mode.

What is proven, and how¶

The proof comes from bench drills with a probe on the PSU-connector LASER_ON pin and the kernel readbacks. The repeatable ones are in the acceptance catalog, which runs them at every release (Acceptance).

• Latch locked: 40,000 streamed FIRE bits → PSU pin flat, laser_enable
• The lock severs the FIRE drive entirely.
• Latch unlocked, chain unarmed (no button press): laser_enable 1 mid-window, PSU pin flat, laser_on 0. The AND gate holds.
• FIRE drop at end-of-data and at true underrun: ≤ 1 tick, both termination paths.
• A latch unlock inside an acceleration ramp does not restore the FIRE drive for the in-flight run; a locked latch survives a stop + resume replay.
• Armed kill mid-FIRE: emission tail equals the ring in-flight only (15 to 171 ms), the latch relocks, the burn line ends abruptly.
• Switch bits 0 to 3, 5, 6 verified against physical state; bit 4 (hv_enable) characterized live: inactive at idle, active through any run, and it flips together with charge_pump_alive on both edges (HV_ENABLE = DOORS_OK · WDOG_ALIVE observed).
• Interlock latch drive: with the connector unjumpered, interlock, interlock_latch_reset and interlock_latch all assert within one 50 ms sample and all clear when the loop is closed again.
• Watchdog period, measured directly from the SoC pins (cp_watchdog_timing.py: every CHG_PUMP pulse latched by the GPIO edge detector, the ¬Q and ¬HV_ENABLE pads polled at ≈ 0.2 ms): Q falls 451.8 / 455.6 ms after the last pulse (t_w = 454 ± 3 ms, matching R·C); Q rises on the priming pulse and HV_ENABLE falls with Q within one sample; the kernel feed period is 199.98 ms (199.87 to 200.07). A feed late by more than ≈ 254 ms therefore drops HV_ENABLE.

Not established¶

Nothing on the readback or sense side. Every input in the table above has a measured meaning, including the supply's power-good line on J1_14.