mirror of
https://github.com/openglow-org/forgefirm.git
synced 2026-09-27 16:51:12 -07:00
Homing is lid-gated in practice; only the cloud hunt is not
MOTION said jogs, homing and hunts were all ungated. Jogs are: gfsw_visible withholds the door signal while the core is idle, jogging or homing, so a jog both starts and runs with the lid open. Homing is not. With homing_mode = gfcloud - the only method that works today - $H hands the cycle to a cloud homing session, and its move to the home corner is an ordinary motion action taking the default lid_gated=True: refused with the lid open, stopped on a lid edge mid-run. Only the lens/Z hunt inside that session passes lid_gated=False, and that session is also the only place a hunt happens in GRBL mode - there is no hunt outside one. BRINGUP gains item 18: GRBL pause and resume should leave no gap in the cut, the way the factory's does. The beam stops at the start of the hold (disable_laser_during_hold, on by default), so the head travels the whole deceleration dark and the resume restarts from a standstill where the decel ended - an unburned length, then a dwell through the accel that M3 shows as a deeper spot. The kernel waypoint backtrack cloud mode uses is refused with EPERM on a live-streamed ring, so the equivalent has to be built above the ring, where grblHAL still holds the planned path the kernel has already overwritten. Two wording fixes: the cooling verdict is described as a report rather than a file, and gfcloud homing as using the machine's builtin credentials. Documentation only - no behavior change, so no acceptance-catalog consequence.
This commit is contained in:
@@ -1207,6 +1207,35 @@ Open items only. Anything closed is in `CAMPAIGN-LOG.md`.
|
||||
byte in the stream today, and the feeder contract forbids back-to-back
|
||||
power bytes, while under FIRE dithering the duty is a constant sent once
|
||||
per run and a per-pixel level change costs no stream byte at all.
|
||||
18. **Gapless pause and resume in GRBL mode (planned).** A pause leaves a mark
|
||||
in the cut. With laser mode on, the core stops the beam at the start of the
|
||||
hold (`disable_laser_during_hold`, on by default), so the head travels the
|
||||
whole deceleration dark, and the resume re-accelerates from a standstill at
|
||||
the point the decel ended — an unburned length, then a restart that dwells
|
||||
through the accel. At constant power (`M3`) that restart is a deeper spot
|
||||
you can see; `M4` scales power with velocity and mostly hides it, but
|
||||
neither closes the gap. GRBL mode should pause and resume with no
|
||||
discontinuity in the cut, the way the factory does.
|
||||
|
||||
Cloud mode already does, on the kernel's waypoint resume: controlled stop,
|
||||
laser-off backtrack (`cloud_pause_backtrack_ticks` 2000), then a laser-off
|
||||
lead back up to speed on the next press (`cloud_resume_lead_ticks` 1950),
|
||||
so the beam returns only once the head is retracing ground it already cut
|
||||
and is back at feed. That mechanism cannot be borrowed here: the kernel
|
||||
refuses a negative `resume` with `EPERM` once the ring has been
|
||||
live-streamed (`UAPI.md`), because the bytes to back into have already been
|
||||
overwritten.
|
||||
|
||||
So the equivalent belongs above the ring, where grblHAL still holds what
|
||||
the kernel does not — the planned path. Shape to evaluate: capture the
|
||||
point where the beam went off at the hold; on the resume plan a laser-off
|
||||
retrace back along the path and a laser-off accelerate-in, and unmask FIRE
|
||||
only once the head is at feed and has passed the captured point. Open: how
|
||||
far back is enough (2000/1950 ticks is a reference, not a transferable
|
||||
number — the tick rates differ), whether the retrace can reuse planner
|
||||
blocks or needs a synthesized one, what a hold inside an arc or a raster
|
||||
line does to it, and how it composes with the armed window's disarm grace
|
||||
across a long hold.
|
||||
|
||||
**Deliberately not gated:** an armed GRBL job after an underrun cuts at the
|
||||
stale origin unless homing is required (GRBL mode permits unhomed cutting; the
|
||||
|
||||
+1
-1
@@ -59,7 +59,7 @@ is running — GRBL or cloud — is a client of it, over two channels:
|
||||
Two properties of that split are worth understanding, because they explain the
|
||||
machine's behavior in odd situations:
|
||||
|
||||
**A missing verdict is a bad verdict.** If the file is absent or more than two
|
||||
**A missing verdict is a bad verdict.** If the report is absent or more than two
|
||||
seconds old, a controller treats it as *fire blocked, hold*. The engine going
|
||||
away looks exactly like a fault, never like permission.
|
||||
|
||||
|
||||
+14
-4
@@ -293,8 +293,18 @@ ForgeFIRM reproduces the factory machine's behavior:
|
||||
- **Idle lid cycles are ignored.** Opening the lid to load material, or
|
||||
powering up with it open, does not leave the controller parked — senders
|
||||
connect normally.
|
||||
- Jogs, homing and hunts are not lid-gated (the beam is blocked in hardware
|
||||
regardless).
|
||||
- **Jogs are not lid-gated.** The core is blind to the door signal while it is
|
||||
idle, jogging or homing, so a jog both starts and runs with the lid open —
|
||||
the beam is blocked in hardware regardless.
|
||||
- **Homing is lid-gated in practice**, even though the core does not see the
|
||||
door during `$H`. With `homing_mode = gfcloud` — the only method that works
|
||||
today — the cycle is a cloud homing session (§5.7), and its move to the home
|
||||
corner is an ordinary motion action: refused with the lid open, and stopped
|
||||
if the lid opens partway through. The camera steps need the lid closed
|
||||
anyway. Only the lens/Z **hunt** inside that session ignores the lid (§6.3),
|
||||
which is where hunts happen in GRBL mode — there is no hunt outside a cloud
|
||||
homing session. Under `homing_mode = switches` a Z reference would just be
|
||||
part of the core homing cycle.
|
||||
|
||||
The next job re-arms with a fresh button press — the same press the hardware
|
||||
button latch itself requires, which is why software and hardware cannot
|
||||
@@ -310,8 +320,8 @@ The homing method is a setting (`homing_mode`), chosen in the web panel:
|
||||
|
||||
- **`gfcloud`** — camera homing through the Glowforge web service, the same
|
||||
cycle the factory machine runs. `$H` suspends the stream engine, runs the
|
||||
session, then hands the machine back. Takes roughly a minute and needs a
|
||||
signed-in Glowforge account.
|
||||
session, then hands the machine back. Takes roughly a minute and uses the
|
||||
machine's builtin credentials.
|
||||
- **`switches`** — the future limit-switch cycle. Not enabled yet; brackets for
|
||||
the switches are in the project's `3d-models/` directory.
|
||||
- **`none`** — `$H` is rejected.
|
||||
|
||||
Reference in New Issue
Block a user