Skip to content
BUSMUST
Support中文

BMCLI offline

Reference version: BMCLI 1.6.5. Command names, parameters and machine-readable fields retain their source spelling.

Offline commands are capability-driven. Configuration storage requires BM_STAT_SUPPORT_OFFLINE, on-device logging requires BM_STAT_SUPPORT_LOGGING, and device replay requires BM_STAT_SUPPORT_REPLAY. RAM-buffer download/start additionally requires BM_SUPPORT_BUFFER_API; a download to device storage also requires BM_SUPPORT_FATFS_API. Each download requires a nonzero capacity from its selected replay queue/file Stat. A missing, failed, or zero Stat is treated as unsupported_capability; hardware generation is never used as a feature gate.

When a daemon is running, all ten leaf commands below operate through its already-open channel handles. They do not attempt a second standalone open. An unqualified status survey keeps unsupported devices in the result with avail=unsupported. Device identity is UID-first, with VID/PID/SN fallback only when neither side has a UID.

offline logging shares its underlying implementation with the --hardware form of logging. On-device replay uses the explicit offline replay lifecycle; there is no duplicate replay --hardware entry.

Action Equivalent to Description
offline logging start logging start --hardware Start on-device logging (BM_SetLogging)
offline logging stop logging stop --hardware Stop on-device logging
offline logging status (per-device part of logging status) Query on-device logging state (BM_GetLogging)
offline file download — Download host ASC/BLF to replay RAM or a device /REPLAY/ file
offline replay start — Start on-device replay (BM_SetReplay)
offline replay stop — Stop on-device replay
offline replay status (per-device part of replay status) Query on-device replay state (BM_GetReplay)
offline config save — Persist the current runtime config (BM_SaveConfig)
offline config load — Load persisted config (BM_LoadConfig)
offline config clear — Clear stored config (BM_ClearConfig)
Terminal window
bmcli offline logging start --channel=<UID>/0,<UID>/1 --path=log.asc --log-format=asc
bmcli offline logging stop --channel=<UID>/0
bmcli offline file download --channel=<UID>/0,<UID>/1 --src=host.asc --dst=/REPLAY/0000.BBD
bmcli offline file download --channel=<UID>/0,<UID>/1 --src=host.blf --dst="<RAMBUF>"
bmcli offline replay start --channel=<UID>/0 --file=stored.asc --loop
bmcli offline replay start --channel=<UID>/0,<UID>/1 --ram-buffer
bmcli offline replay status --channel=<UID>/0 --format=json
bmcli offline config save --channel=<UID>/0 --items=rxfilter,txtask,route

Logging channel lists must refer to ports on one physical analyzer; BMCLI builds the hardware mask from each resolved physical port. --path and --output are aliases, --log-format=asc|blf selects the stored format, and --duration=N stops after N seconds. In daemon mode a timed start returns immediately. Closing one of that device’s daemon channels, restarting the daemon, or stopping it first stops any BMCLI-managed timed logging so no detached timer is orphaned.

Offline file replay accepts one or more channels belonging to one physical device. The case-insensitive extension selects ASC, BLF, PCAP, LOG, or BBD; missing and unknown extensions are rejected. Paths sent to the device contain only the final basename with the extension removed. The replay mask is based on the resolved physical ports, not daemon slots or selector prefixes.

offline file download is named from the Host perspective: --src is a Host ASC/BLF and --dst is the device target. The preferred storage spelling is a complete /REPLAY/name.ext path. name.ext and bare name are compatibility inputs; bare names default to .BBD, and successful structured output always reports the canonical complete path. The exact, case-sensitive RAM target is <RAMBUF> and should be quoted in shell commands. Reverse device-to-Host offline file upload is not implemented.

The command fully parses and capacity-checks the Host file before changing device state. It temporarily disables replay, selects and clears BM_REPLAYQ_BUFFER for <RAMBUF> or BM_REPLAYFILE_BUFFER for storage, writes the routed CAN/CAN FD records, then restores BM_DEFAULT_BUFFER. Failures restore the original replay configuration and clear a partial download. A successful storage-file download also restores the original replay configuration. A successful RAM download leaves the <RAMBUF> replay target disabled because reapplying an older replay configuration would invalidate the fresh queue. Start the downloaded sequence explicitly with offline replay start --ram-buffer or --file; download never starts replay or calls BM_SaveConfig. RAM buffer contents are volatile.

--items values (save/load/clear): mode, bitrate, tres, rxfilter, txtask, route, logging, replay, all (default). This is a strict comma list: an unknown or empty item rejects the entire command before BMAPI is called. load and clear refresh the daemon’s cached configuration after the device operation; save does not change the runtime cache. Runtime configuration is RAM-only until offline config save is called. Logging/replay start, stop, and file download never call BM_SaveConfig implicitly. Separate standalone commands do not inherit each other’s RAM state. To save volatile state set by a previous command, keep one daemon session running and issue both commands through it; a later standalone save may otherwise persist default, blank, or unintended state.

Source of truth: BMCLI 1.6.5 repository documentation. Run bmcli help <category> <action> --format=json for the exact contract of the installed version.