> ## Documentation Index > Fetch the complete documentation index at: https://docs.almond.bot/llms.txt > Use this file to discover all available pages before exploring further. # Diagnostics Dashboard > Live motor telemetry, health status, and diagnostics scripts in the browser. The diagnostics dashboard lives alongside the [web control panel](https://docs.almond.bot/guides/control-panel) at `/diagnostics` — open [axol.almond.bot/diagnostics](https://axol.almond.bot/diagnostics) (or `https://:8001/diagnostics` on the LAN) while `axol serve` is running. Like the control panel, its layout is **responsive** and works from a phone or tablet. ## Motor status A card per motor (8 per arm) shows its status, temperature, bus voltage, and live position, refreshed by the server's 1 Hz health ping. A motor reads **OK** whether enabled or disabled — only genuine error codes (over-temperature, lost comm, …) or an unreachable motor light up red. Clicking a card opens the full `motor.info` readout — model, firmware, control mode, gains, and live readings — without launching a CLI session. The buttons in this section run the motor plumbing ad hoc: **CAN setup** for the hub provisioning command ([`can.setup`](https://docs.almond.bot/cli/can-setup)), **CAN enable** for the adapter picker described below, **Set CAN ID** ([`motor.set-can-id`](https://docs.almond.bot/cli/motor-set-can-id)), and zeroing via [`motor.set-zero-pos`](https://docs.almond.bot/cli/motor-set-zero-pos) — **Zero motor** for a single motor, or **Guided zeroing** to walk joints of one arm against their end stops with step-by-step Continue prompts. Guided mode has the same joint checkbox picker as the ROM tests, so you can rezero just a subset (e.g. the wrist joints after swapping a motor). The same section also carries the motor-servicing tools that used to require the vendor's Windows software: **Dump config** ([`motor.dump-config`](https://docs.almond.bot/cli/motor-dump-config)) reads every configuration parameter from one motor — or all of them when the CAN ID is left blank — into the run log; **Set config** ([`motor.set-config`](https://docs.almond.bot/cli/motor-set-config)) tabs between reading a single parameter and writing it; and **Flash firmware** ([`motor.flash`](https://docs.almond.bot/cli/motor-flash)) overwrites a MyActuator motor's firmware from a `.bin` on the serve host. Restoring a saved snapshot stays on the CLI ([`motor.restore-config`](https://docs.almond.bot/cli/motor-restore-config)), since the browser can't hand the server a snapshot file. ## Choosing CAN adapters **CAN enable** opens the CAN adapter picker: choose which arms are attached — one adapter is enough for a single arm — and each arm's SocketCAN interface, either from the ones detected on the host or typed by name. The Axol hub's persistently-named pair (`can_alm_axol_l` / `can_alm_axol_r`, created by `can.setup`) is the prefilled default; a generic adapter enumerated as `can0` works just as well. **Save & connect** persists the mapping in the shared settings (`robot.left_channel` / `robot.right_channel`), brings the interfaces up, and (re)connects the robot link — reopen the dialog at any time to remap. The same picker is offered on the robot-link banner when the link is disconnected or failing. The saved mapping then drives the whole dashboard: every diagnostic and calibration run launches against the configured interfaces automatically — no dialog asks for an interface name, and with a single arm configured the other arm is skipped everywhere (the ROM tests get the skip flag implicitly, and the single-arm tools pre-select the attached arm). On the CLI the same is done explicitly with the matching flags (`--left-channel` / `--right-channel` and `--no-left` / `--no-right` on the two-arm commands, `--channel` on the single-motor tools, [`can.enable --channels …`](https://docs.almond.bot/cli/can-enable) for the bring-up). ## Live telemetry Position, velocity, and torque charts for the selected arm stream continuously at 10 Hz while the robot link is connected. The server keeps a 10-minute rolling buffer, so the charts backfill on page load. The filter row scopes all three charts: time window presets (30s–10m), arm, and per-joint toggles; scroll to zoom and drag to pan, which pins the view until you press **Go live**. Each chart's header button expands it to full screen (Esc to exit) for a closer look. Telemetry is sampled by the idle robot link, which is the single owner of the CAN bus. While a diagnostic or operation owns the bus the stream pauses and the charts label the gap — history is kept, and streaming resumes as soon as the bus is released. ## Diagnostics Each diagnostic — [`diag.rom-enable`](https://docs.almond.bot/cli/diag-rom-enable), [`diag.rom-disable`](https://docs.almond.bot/cli/diag-rom-disable), and the [`diag.zed-cable`](https://docs.almond.bot/cli/diag-zed-cable) camera-cable check — is a card: click it, set parameters in the dialog, and hit Run. The ROM tests expose a joint checkbox picker so you can soak a subset (e.g. just the wrist joints). The card shows the running state, elapsed time, and the latest output line; completion lands as a notification, and the full log is kept with the run in the history below. The ROM tests hand the CAN bus over for the duration of the run; the camera-only ZED cable check leaves motor telemetry streaming. On robots fitted with the powered cart's telescoping lift, the lift's [`lift.home`](https://docs.almond.bot/cli/lift-home) calibration and [`lift.goto`](https://docs.almond.bot/cli/lift-goto) install-height move appear here as cards as well. Motor-driving runs are fault-gated, but only for the motors they actually touch: a joint-subset or one-arm run (a wrist-only ROM soak, guided zeroing of selected joints, a single-motor tool) isn't blocked by unreachable or faulted motors outside its scope — e.g. a bench arm with only some motors on the bus. Hands-on steps — like clamping an item in the ROM grasp test — pause the run and surface a **Continue** button on the card with the instruction (e.g. "Position the item in the RIGHT gripper, then close it."). The test waits for you and proceeds when you click, so nothing moves until you're ready. Under the hood the diagnostic prints a `[prompt]` marker and blocks on stdin; the button writes a line back to it. (The `motor.info` / `motor.health` read set needs no action here — the motor cards above show it live.) Powering the robot host off or rebooting it is done from the [control panel's Axol Host tile](/guides/control-panel#axol-host), which carries the **Restart** and **Shut down** buttons whenever a host is connected. ## Run history Every *diagnostic test* (the cards above — not the ad-hoc CAN/calibration buttons) is recorded as a run: command, arguments, duration, exit status, log, and the telemetry observed while it executed (persisted under `~/.almond/diagnostics/runs` on the serve host; the **Clear** button deletes the history). The list is paginated newest-first (10 runs per page). The ROM test additionally writes its own 5 Hz position/torque capture, since it owns the CAN bus while it runs — opening a run charts its capture with the same joint filter and zoom/pan as the live charts.