bridge: reopen R10 — a guarded typed console in tools/z1 and the app, and our own sequence in place of Studio's wizard

Closed
  • Is something wrong?
#302 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
tauri, typescript
Domain
desktop, embedded-iot

Research direction

Start with the bridge protocol and its READABLE_PATH guard, then read tools/z1/z1.mjs and the referenced safety sections in Fabrication.md and Z1-Bridge-Protocol.md. First implement and test the guarded, explicitly sent console command in the protocol and bridge; the desktop panel is a follow-up after the harness proves that side. Done means the console records each sent line and reply, the guards hold, and the documentation references are updated; determining how the controller starts a file is explicitly research before any run button.

Written by the indexing model from the issue text.

Description

enhancement fabrication

Decision (2026-10-08, maintainer): reopen R10 — a typed console, and our own sequence instead of Studio's wizard

Why this is an issue. Makera-Parity.md R10 and Z1-Bridge-Protocol.md §8 say there is no jog, DRO, MDI or console in the app, and that "no motion without a file". That was a scoping decision made before the bridge existed ("bridge-era … we should not carry any of it as a design now"; the parity table says "refused until the bridge, then reopened for the connect/home half"). The bridge shipped in #255. It was never a firmware limit: the controller accepts console lines, which is how tools/z1 already reads config and runs md5sum. The maintainer has decided to reopen it, and to stop treating Makera Studio's five-step Machining Wizard as a precondition — that is Studio's flow, and we will run our own.

What the safety rules (/Fabrication.md §8) actually require, and keep requiring: an explicit user action for everything that is sent, and a person physically at the machine for motion. A console used by that person meets both. Nothing below changes them.

Scope

  1. A guarded console command in the protocol and bridge. One line in, the controller's reply out. Explicit send only: no polling, no background connection, no queue.
  2. Guards at the sink (same place the READABLE_PATH guard lives):
    • one line, printable ASCII, bounded length, no control characters;
    • refuses config-set, and file-destructive or flashing commands (rm, mv, format, reset, dfu, upload) — "nothing in this repo may change a value on the machine" still stands for configuration;
    • the realtime bytes (!, ~, 0x18) stay unwired. §8's reason holds: an e-stop sharing the socket of a transfer is worse than useless. The physical stop is the stop.
  3. tools/z1/z1.mjs send / console. Non-interactive send requires --i-am-at-the-machine; the interactive console asks once per session. Every line sent and every reply is echoed and appended to a trace file, so a session is a recorded trace (this is what #293 wanted).
  4. A console panel in the desktop app (follow-up, after the harness proves the protocol side): desktop-only behind canDriveMachine, send on an explicit press, the same guards.
  5. Finding out how the controller starts a file (Studio's wizard does it; it is not in our docs). Read it from the D0 traffic logs and the firmware before any app "run" button exists.

Docs this changes

Makera-Parity.md R10 and its table row; Z1-Bridge-Protocol.md §8 (the "no motion without a file" bullet and the free-text-box sentence); tools/z1/z1.mjs header; /Fabrication.md §14.4 R10 reference. #293's "Not this issue" and "Not … a G-code passthrough in tools/z1" lines are superseded by this issue.

First use

#293 Stage 1, typed through the new console with the maintainer at the machine (vise on the bed, wired Z-only probe fitted, collet empty): G28 as the only Z move, then X/Y only.

Not in scope

Jog pendants/gamepads, a DRO, overrides, and any "run this file" button — each waits for its own decision once the console has been used for real.

Related: #255, #293, #283, #208.

Dominant language
TypeScript
Stars
2
Forks
0
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SlyWombat/CaseMaker

All issues in SlyWombat/CaseMaker

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.