BMCLI channel

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

channel enumerate

List all connected BUSMUST CAN FD / LIN analyzer channels. Each result is one channel record; physical-device operations use the record’s stable serial or UID with device reset and device update.

Each record includes a canonical selector: UID/port for current physical devices, SN/port when UID is unavailable, and the exact stable name for a virtual channel. When the local daemon is running, enumeration is served from its pre-open inventory so channels held exclusively by that daemon are not mistaken for disconnected hardware. Without a daemon, discovery uses the local BMAPI runtime as before.

bmcli channel enumerate
bmcli channel enumerate --format=json
bmcli channel enumerate --format=csv

channel info

Show channel information. Standalone mode reports static enumeration fields (name, SN, firmware, VID/PID, capability). Daemon mode additionally reports the selected bus and runtime configuration. CAN channels report controller mode, nominal/data bitrate, and termination. LIN channels report role, bitrate, pull-up, supply direction, protocol version, and checksum model.

Machine outputs keep the legacy numeric cap/capability field and also expose the canonical numeric capability_mask plus readable capabilities such as CANFD,CAN,LIN. CSV appends capability_mask,capabilities. The mask is the BMAPI BM_*_CAP bitmask; readable names are derived from those same bits.

bmcli channel info                     # all devices
bmcli channel info --channel=0         # by legacy index
bmcli channel info --channel=10356/0   # by SN/port
bmcli channel info --channel=0 --format=json

Option	Description
--channel	Channel spec (SN/port, UID/port, or legacy index). Omit for all.

channel open

Open and activate one CAN or LIN channel in the persistent daemon. The default bus type is selected from the enumerated channel capability; --bus is not a public argument. Repeat the command to open additional channels.

bmcli channel open --channel=10356/0 --bitrate=500
bmcli channel open --channel=10356/0 --nbitrate=500k --dbitrate=2000k
bmcli channel open --channel=10356/1 --mode=loopback --termination=120

# LIN master and slave endpoints
bmcli channel open --channel=10356/4 --mode=master --bitrate=19200 --pullup=1k --power=on
bmcli channel open --channel=10357/4 --mode=slave --bitrate=19.2K --pullup=off --power=off

# Legacy index remains supported, but depends on the current enumeration order
bmcli channel open --channel=0 --nbitrate=500 --dbitrate=2000

Option	Default	Description
--channel	(required)	One channel spec: 0, 10356/0, UID/0, or an exact enumerated name
--mode	CAN normal; LIN listen-only	CAN controller mode or LIN master, slave, listen-only, internal-loopback
--nbitrate	500	CAN nominal bitrate. Bare kbps, bps, K/kbps, and M/mbps forms are accepted.
--dbitrate	2000	CAN data bitrate. Bare kbps, bps, K/kbps, and M/mbps forms are accepted.
--bitrate	CAN 500/2000; LIN 19200	CAN single-rate shorthand sets nominal=data; N/D remains an explicit pair. LIN uses bps, 1000..20000; auto is slave-only and requires supporting firmware.
--termination	120	CAN termination: 120 or off
--pullup	master 1k; other modes off	LIN pull-up: 1k or off
--power	master on; other modes off	Enable or disable this channel’s LIN 12 V output
--lin-version	2.2	LIN protocol version: 1.3, 2.0, 2.1, 2.2
--checksum	auto	LIN checksum: classic for IDs 0x3C/0x3D, enhanced otherwise

Current HPM firmware cannot safely accept a zero bitrate for slave auto-detect, so BMCLI rejects --bitrate=auto with a firmware-capability error instead of silently substituting a fixed value.

After a clean LIN close/reopen, current HPM firmware can briefly accept BM_OpenEx before voltage/protocol setup is ready. If and only if that setup returns BM_ERROR_ILLOPERATION and the compensating BM_Close succeeds, BMCLI waits 250 ms and retries the complete open/setup transaction, for at most four attempts. Other setup errors, open failures, and failed cleanup are returned immediately; the bounded readiness handling does not hide a lost or permanently unavailable device.

In daemon mode, channel open --format=json returns one object with the canonical physical identity in channel (UID/port, with SN/port fallback), the open-order-dependent daemon slot in channel_slot, bus type, and effective timing/mode. The same physical channel therefore keeps one identity across enumeration order and daemon restarts. Opening the same physical endpoint again reports state=already_open. If CAN --bitrate is combined with --nbitrate or --dbitrate, matching values are accepted and any conflict is rejected before daemon IPC or channel configuration. Use explicit nominal/data values for CAN FD with different arbitration and data rates.

channel close

Closing an unopened or invalid selector fails non-retryably. An actual BMAPI close failure remains a failure and retains the handle for recovery. An active ordinary CAN batch or host replay is asked to stop cooperatively; the handle is closed only after its user exits. Already submitted/transmitted frames are not rolled back. Cancellation can leave a small in-flight tail.

Close a previously opened channel.

bmcli channel close --channel=0

channel close --format=json returns one bounded success object with state=closed and the released daemon slot.

channel claim / release

Acquire an optional local control lock before a multi-step configuration or persistent workflow. CLI and REST share the same LOCAL principal. Ordinary one-shot message send and passive receive/monitoring remain available to other principals; protected operations such as channel configuration, close, TX Task, route, LIN schedule/response, replay, ISO-TP, and UDS return busy.

bmcli channel claim --channel=10356/0,10357/0 --timeout=300000 --format=json
# protected workflow: configure, install tasks/routes, run UDS, replay, etc.
bmcli channel release --channel=10356/0,10357/0 --format=json

--timeout is milliseconds (1000..86400000, default 300000). A repeated claim by LOCAL renews the lock. A multi-channel claim is all-or-nothing. Release has no force option and cannot override a remote owner. Use cleanup/finally logic in generated shell or Python automation.

Claim is optional for backward compatibility. When no claim exists, local and legacy remote configuration remains last-writer-wins; successful later writes may replace earlier settings without notifying the earlier caller.

channel status

Show CAN bus status (TEC, REC, busoff, TX/RX passive/warn). Public state flags are always 0 or 1; TEC/REC remain the BMAPI counters and buscode is the raw BMAPI status code returned by a successful query. If BMAPI cannot obtain controller state (for example after disconnect), the command returns the standard channel_status_failed error envelope instead of a zeroed healthy snapshot.

bmcli channel status --channel=0
bmcli channel status --channel=0 --format=json

JSON output:

{"status":"ok","channel":0,"busoff":0,"txbp":0,"rxbp":0,"txwarn":0,"rxwarn":0,"tec":0,"rec":0,"buscode":"0x0"}

channel power

Read or control channel power independently from LIN protocol configuration. Current hardware maps this command to the LIN 12 V output. off disables this device’s output but does not prove an externally powered bus is unpowered.

bmcli channel power status --channel=10356/4 --format=json
bmcli channel power on --channel=10356/4
bmcli channel power cycle --channel=10356/4 --off-duration=500

can config get/set

Read all CAN settings or idempotently apply supplied settings to an open daemon channel. The protocol prefix keeps CAN termination and bitrate terms out of LIN.

bmcli can config get --channel=10356/0 --format=json
bmcli can config set --channel=10356/0 --bitrate=500
bmcli can config set --channel=10356/0 --mode=normal \
  --nbitrate=500K --dbitrate=2M --termination=120

For CAN, a single --bitrate=N sets both nominal and data rates to N. Explicit --nbitrate/--dbitrate values remain available for different CAN FD rates. Combining the forms is accepted only when the normalized values match.

lin config get/set

Read all LIN role, timing, electrical, and protocol settings or apply supplied settings to an open daemon channel. A role change clears the active hardware TX task table before switching, preventing a master schedule or slave response from surviving into the opposite role.

bmcli lin config get --channel=10356/4 --format=json
bmcli lin config set --channel=10356/4 --mode=master --bitrate=19200 \
  --pullup=1k --power=on --lin-version=2.2 --checksum=enhanced

config is a noun and is always followed by get or set. Bare channel config and configure forms are not supported.

channel autoset

Detect the nominal/data bitrate and terminal resistor. AutoSet runs outside the daemon and requires exclusive access to its target physical analyzer. A running local daemon may remain active when it has no open channels or only owns other physical analyzers. AutoSet is rejected before probing when the daemon owns any port on the target analyzer, or when daemon occupancy cannot be determined reliably. Passive mode is the default and only listens; active mode transmits probe frames and must be explicitly selected on an isolated bench or authorized bus.

bmcli channel autoset --channel=10356/1 --timeout=10000
bmcli channel autoset --channel=10356/1 --timeout=10000 --format=json
bmcli channel autoset --channel=10356/1 --mode=active --timeout=10000 --format=json

Option	Default	Description
--channel	(required)	Stable SN/port, UID/port, or legacy index
--mode	passive	passive/listen observes existing traffic; active transmits probes and detects TX ACK evidence
--timeout	10000	Soft deadline, 1-60000 milliseconds. A candidate already showing plausible traffic is allowed to finish verification.
--confirmations	3	Required RX messages in passive mode or TX ACK confirmations in active mode, 3-255
--observation	BMAPI default	Passive mode: observation time per candidate in milliseconds
--probe-timeout	BMAPI default	Active mode: write timeout per probe in milliseconds
--probe-id	0x6A5	Active mode: standard or extended CAN probe ID
--probe-data	eight zero bytes	Active mode: 1-64 probe payload bytes

Passive success proves that the selected analyzer port observed valid traffic at the reported timing. Active success proves that another CAN node acknowledged repeated probes at the reported timing. Neither mode identifies a specific ECU. A silent bus can make passive mode fail even when an ECU is connected; active mode is faster in that case but can affect live network behavior. JSON output identifies mode and evidence_type, with either observed-message or acknowledged-probe counts.

Passive AutoSet treats expiry with no valid observed frame as a quiet-bus timeout. Text and structured output say No bus activity detected before timeout; structured output preserves reason=timeout and also reports the underlying bmapi_status/bmapi_status_name for diagnostics. The BMAPI status must not replace the user-visible timeout cause.

channel recover

Manually trigger fault recovery on a channel (BUSOFF, USB disconnect, etc.). The daemon also performs this automatically when auto-recover is on.

bmcli channel recover --channel=0

channel auto-recover

Enable or disable automatic fault recovery in daemon mode. Default: on.

bmcli channel auto-recover on
bmcli channel auto-recover off
bmcli channel auto-recover status

channel reset-defaults

Reset a channel’s runtime state to factory-neutral. This is the reliable way to clear device tables that a prior command may have populated:

• RX filters → accept-all (overwrite every device slot; LIN uses all 64 ID acceptance bits)
• TX tasks → none (overwrite every slot with BM_TXTASK_INVALID)
• message routes → none (overwrite every slot with type=0)
• online logging → off
• online replay → off
• CAN mode → NORMAL
• offline config storage → cleared (BM_ClearConfig)

bmcli channel reset-defaults --channel=10356/0
# ch0: rxfilters:ok(cap=0) txtasks:ok(cap=64) routes:ok(cap=64) logging:off replay:off mode:normal offlinecfg:cleared
# OK: 1 channel(s) reset to defaults

Omit --channel to reset every channel currently open in the daemon. In JSON mode the success response is one bounded document. target is the requested selector, or all when the option is omitted; reset_count equals the number of entries in targets. Each target reports its stable channel identity and slot, table capacities, and the actual result of every reset action:

{"status":"ok","operation":"channel.reset-defaults","target":"all","reset_count":2,"targets":[{"channel":"10356/0","channel_slot":0,"rxfilters":"ok","rxfilter_capacity":0,"txtasks":"ok","txtask_capacity":64,"routes":"ok","route_capacity":64,"logging":"off","replay":"off","mode":"normal","offline_config":"cleared"},{"channel":"10356/1","channel_slot":1,"rxfilters":"ok","rxfilter_capacity":0,"txtasks":"ok","txtask_capacity":64,"routes":"ok","route_capacity":64,"logging":"off","replay":"off","mode":"normal","offline_config":"cleared"}]}

If no requested channel is open, or the daemon is unavailable, JSON mode emits one standard status=error envelope and exits with code 1; it never mixes text lines into structured stdout. Text mode retains the existing per-channel lines and final summary shown above.

Why capacity-based overwrite? Passing NULL/0 to BM_SetMsgRoutes / BM_SetTxTasks / BM_SetRxFilters is a no-op — the BMAPI write loop runs for (i = 0; i < n; i++), so n=0 writes nothing and leaves the device table untouched. The only reliable clear is to overwrite every slot the device actually exposes. BMCLI queries the device’s real slot count via BM_Control(BM_GET_STAT, BM_STAT_MAX_*) and writes that many invalid/accept-all entries. The (cap=N) in the response is that queried count:

• cap>0 — the device reported its real slot count; that many slots were overwritten (a true clear).
• cap=0 — the stat item is unsupported on this firmware; BMCLI fell back to a hardware-specific default (see below).

Fallback defaults when the stat query is unsupported (cap=0). These are the real slot counts of the hardware — writing more than this is an out-of-bounds write that can corrupt the table, so the defaults MUST match the hardware, not the (larger) BMAPI internal array sizes:

Table	Fallback default	Notes
RX filters	2	Our hardware exposes 2 rxfilter slots.
TX tasks	gen3 = 64, gen2 = 1	Generation detected from the firmware version major byte (version[0]==3 → gen3, ==2 → gen2). TX-task stat is normally supported on gen3.
Message routes	4	Our hardware exposes 4 route slots.

To inspect the live device runtime state (the same fields reset-defaults clears — RX filters, TX tasks, routes, logging/replay config, CAN status), use bmcli doctor --channel=<spec>, which now dumps all of them. Note: BM_Get* returns stale slot memory (the device does not zero unused slots), so the active=N counts are an upper bound, not ground truth — a slot that held an entry earlier in this power cycle may still read back as active after a logical clear. reset-defaults is the reliable clear.

With --channel, channel reset-defaults resets only the matching open channel or comma-separated channels. Without it, the command resets all open channels. Routes and TX tasks are device-global tables; each selected open channel is nevertheless reported independently.

---

---

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