BMCLI channel
Reference version: BMCLI 1.6.5. Command names, parameters and machine-readable fields retain their source spelling.
channel enumerate
Section titled “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 enumeratebmcli channel enumerate --format=jsonbmcli channel enumerate --format=csvchannel info
Section titled “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 devicesbmcli channel info --channel=0 # by legacy indexbmcli channel info --channel=10356/0 # by SN/portbmcli channel info --channel=0 --format=json| Option | Description |
|---|---|
--channel |
Channel spec (SN/port, UID/port, or legacy index). Omit for all. |
channel open
Section titled “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=500bmcli channel open --channel=10356/0 --nbitrate=500k --dbitrate=2000kbmcli channel open --channel=10356/1 --mode=loopback --termination=120
# LIN master and slave endpointsbmcli channel open --channel=10356/4 --mode=master --bitrate=19200 --pullup=1k --power=onbmcli channel open --channel=10357/4 --mode=slave --bitrate=19.2K --pullup=off --power=off
# Legacy index remains supported, but depends on the current enumeration orderbmcli 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
Section titled “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=0channel close --format=json returns one bounded success object with
state=closed and the released daemon slot.
channel claim / release
Section titled “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
Section titled “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=0bmcli channel status --channel=0 --format=jsonJSON output:
{"status":"ok","channel":0,"busoff":0,"txbp":0,"rxbp":0,"txwarn":0,"rxwarn":0,"tec":0,"rec":0,"buscode":"0x0"}channel power
Section titled “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=jsonbmcli channel power on --channel=10356/4bmcli channel power cycle --channel=10356/4 --off-duration=500can config get/set
Section titled “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=jsonbmcli can config set --channel=10356/0 --bitrate=500bmcli can config set --channel=10356/0 --mode=normal \ --nbitrate=500K --dbitrate=2M --termination=120For 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
Section titled “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=jsonbmcli lin config set --channel=10356/4 --mode=master --bitrate=19200 \ --pullup=1k --power=on --lin-version=2.2 --checksum=enhancedconfig is a noun and is always followed by get or set. Bare
channel config and configure forms are not supported.
channel autoset
Section titled “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=10000bmcli channel autoset --channel=10356/1 --timeout=10000 --format=jsonbmcli 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
Section titled “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=0channel auto-recover
Section titled “channel auto-recover”Enable or disable automatic fault recovery in daemon mode. Default: on.
bmcli channel auto-recover onbmcli channel auto-recover offbmcli channel auto-recover statuschannel reset-defaults
Section titled “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 defaultsOmit --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-defaultsclears — RX filters, TX tasks, routes, logging/replay config, CAN status), usebmcli doctor --channel=<spec>, which now dumps all of them. Note:BM_Get*returns stale slot memory (the device does not zero unused slots), so theactive=Ncounts 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-defaultsis the reliable clear.
With
--channel,channel reset-defaultsresets 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.