BMCLI CANopen CC

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

CANopen is an upper-layer protocol view on the CAN Host Runtime. It does not own a second BMAPI receive thread, physical channel, or private ingress queue. Daemon mode reuses RxBroker; standalone mode uses the same bounded Host Transport. CANopen, raw receive/logging, UDS, XCP, Web, and Gateway can share the same open channel.

Runtime JSON Help is authoritative for parameters. Typical resources and commands follow:

bmcli database load --file=device.eds --name=axis --format=json
bmcli canopen object list --database=axis --format=json
bmcli canopen enable --channel=10356/0 --database=axis --format=json
bmcli canopen receive --channel=10356/0 --duration=5 --format=json
bmcli canopen receive --channel=10356/0 --follow --format=jsonl
bmcli canopen node discover --channel=10356/0 --duration=5 --format=json
bmcli canopen heartbeat status --channel=10356/0 --format=json
bmcli canopen sdo read --channel=10356/0 --node-id=1 --index=0x1018 --sub-index=1 --format=json
bmcli canopen pdo list --database=axis --format=json
bmcli canopen emcy list --channel=10356/0 --format=json
bmcli canopen nmt pre-operational --channel=10356/0 --node-id=1 --format=json
bmcli canopen sync send --channel=10356/0 --format=json
bmcli canopen time send --channel=10356/0 --time=now --format=json

database load is a read-only EDS/DCF importer. Unknown fields that do not affect supported semantics are skipped with diagnostics retained; no editor is provided. Like DBC/LDF/A2L, EDS/DCF resources use the common database unload --name=<resource> command. Conflicting Node-ID, bitrate, or communication parameters across explicit arguments, the bench, and DCF cause failure; BMCLI does not guess Node-ID or COB-ID.

canopen enable enables purely passive analysis and bounded in-memory history, transmitting nothing on the bus. disable destroys the current observation epoch without closing the CAN channel. Repeated enable is idempotent only when the full binding, database hash, Heartbeat configuration, and capacities match. Daemon restart, a channel generation change, or re-enabling creates a new epoch. History cursors are server-issued co1:<32-hex-epoch>:<sequence> values. An old epoch, expired sequence, or invalid format returns its respective stable error; callers must not construct cursors themselves.

node discover, receive, history, and local clear are passive; node identify, sdo read, and pdo verify are active_read; sdo write is active_write; NMT, RPDO, SYNC, and TIME are active_control. NMT Node-ID 0 means explicitly requested broadcast only. --confirm=tx proves only that a frame was accepted for transmission; --confirm=heartbeat waits for target Heartbeat/Boot-up evidence. Broadcast cannot use Heartbeat confirmation.

SDO CLI read/write correspond to CiA upload/download. Auto download uses segmented transfer for 0 bytes, expedited for 1..4 bytes, and segmented for longer data; upload mode is determined by the server’s initiate response. An explicit transfer option constrains acceptance only. If an expedited-only upload receives a segmented response, BMCLI first sends client abort 0x05040001 to clean up peer state, then returns sdo_unexpected_transfer_mode. Transactions are not automatically retried; a connection loss near the write ACK explicitly reports write_may_have_completed.

PDO list/show is strictly offline with zero TX. EDS/DCF mappings initially have unverified quality and require an explicit active-read pdo verify for an online comparison. --apply is valid only for a matching enabled daemon binding, database, and source hash. After successful verification, mapping SDO writes, incomplete or ambiguous transactions, relevant receive gaps, or changes to the database hash, host generation, or epoch degrade quality to stale/unverified/mismatch. When not verified, events retain raw payload, quality, reason, and evidence, but do not present typed engineering values as established values.

Web API provides typed analyzer, node/history, SDO/PDO/NMT, and SYNC/TIME endpoints under /api/v1/canopen. It does not accept shell argv. Bearer auth protects the API; state-changing operations require Idempotency-Key. Each SSE /api/v1/canopen/events/stream record corresponds to one CANopen event DTO. id uses the same opaque cursor, and clients resume through Last-Event-ID.

For EDS/DCF object lookup, a simple VAR declared directly at an index has an implicit sub-index 0. Typed SDO read/write and typed RPDO --set therefore resolve it exactly as --sub-index=0, while an explicit sub-object 0 takes precedence when present. RECORD/ARRAY child lookup, access, mapping, length, range, and local preflight rules are unchanged; raw SDO operation remains available.

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