BMCLI txtask

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

Device-firmware transmit tasks. CAN tasks are hardware-timed periodic or pattern generators. A LIN task on a slave channel is a fixed, header-triggered response, not a periodic transmission. Persistent LIN response tasks require daemon mode.

txtask add

# Fixed payload, 100ms cycle
bmcli txtask add --channel=0 --message=0x100 --cycle=100 --data="AA BB"

# Explicit Classic CAN length/DLC; the three payload bytes are padded with zeroes
bmcli txtask add --channel=10356/0 --message=0x101 --cycle=100 \
    --data="AA BB CC" --length=8 --dlc=8 --format=json

# Nine bytes select CAN FD DLC 9 and are padded to the 12-byte wire length
bmcli txtask add --channel=10356/0 --message=0x102 --cycle=100 \
    --data="00 01 02 03 04 05 06 07 08" --format=json

# Increment data: counter at startbit=0, 32-bit, step=1, range 0-255
bmcli txtask add --channel=0 --message=0x100 --cycle=100 --type=incdata \
    --inc-startbit=0 --inc-nbits=32 --inc-step=1 --inc-min=0 --inc-max=255

# Increment CAN ID: from 0x100 to 0x1FF, step=1
bmcli txtask add --channel=0 --message=0x100 --cycle=50 --type=incid \
    --inc-min=0x100 --inc-max=0x1FF --inc-step=1

# Random data at startbit=16
bmcli txtask add --channel=0 --message=0x100 --cycle=50 --type=random \
    --inc-startbit=16 --inc-nbits=32 --inc-min=0 --inc-max=65535

# With delay offset and finite rounds
bmcli txtask add --channel=0 --message=0x100 --cycle=50 --delay=10 --rounds=1000

# LIN slave response: first open the channel as slave in the daemon
bmcli txtask add --channel=10357/4 --id=0x20 --data="01 02 03 04" --cycle=0 --checksum=enhanced

Option	Default	Description
--channel	(required)	Channel (SN/port, UID/port, legacy index, or name)
--message / --id	(required)	CAN ID or LIN response ID 0x00..0x3F
--cycle	CAN required; LIN 0	CAN interval in ms; LIN responses are header-triggered
--delay	0	Delay offset within cycle in ms
--data	8 zero bytes	Payload hex bytes; explicit --data= selects an empty CAN payload
--length	derived; 8 when all three payload options are omitted	CAN wire payload length: 0..8,12,16,20,24,32,48,64
--dlc	derived from length	Decimal CAN DLC 0..15; must agree with --length when both are present
--type	fixed	CAN patterns; LIN requires fixed
--flags	none	CAN frame flags
--checksum	auto	LIN response checksum model
--rounds	infinite	Decimal or hexadecimal 0..65535; 0xFFFF or omit = infinite. CAN 0 sends no rounds; LIN requires at least 1.
--inc-startbit	0	Byte-aligned start bit for incdata/random; the complete 32-bit field must fit in the final payload
--inc-nbits	32	Hardware data patterns accept only 32 bits
--inc-step	1	Increment step
--inc-min	0	Minimum value
--inc-max	max	Maximum value

The daemon and standalone CLI apply the same pattern parameters. randomdata is an alias of random; randomid generates IDs in the specified range. Data patterns use Motorola (big-endian) byte order and preserve bytes outside the 32-bit field. The BMAPI hardware pattern API does not support arbitrary DBC bit fields: use simulation with the DBC/E2E configuration for a 4-bit Counter. Unsupported widths, unaligned starts and fields beyond the payload are rejected before changing the hardware task table. On the tested generation-3 firmware, increment patterns start at min and clamp at max; they are not modulo counters. Use the simulation E2E Counter when the protocol requires wraparound.

CAN uses this complete DLC-to-wire-length mapping:

DLC	Final length (bytes)
0..8	0..8 (same numeric value)
9	12
10	16
11	20
12	24
13	32
14	48
15	64

For CAN, a payload without --length or --dlc selects the smallest legal wire length. Non-linear CAN FD sizes are zero padded, length above 8 sets FDF, and BRS is enabled only when requested in --flags. A payload longer than the selected length, a payload above 64 bytes, an invalid length/DLC, or conflicting --length and --dlc fails before the task is applied. Successful JSON adds report length, dlc, payload_length, padding_bytes, and padded.

Open every master and slave endpoint before installing a finite-round LIN response task. Reconfiguring another channel on the same analyzer can consume or reset a task that was armed too early.

txtask remove

bmcli txtask remove --channel=0 --taskid=0
bmcli txtask remove --channel=10356/0 --slot-index=0

# Daemon mode: preferred for AI/automation because stale handles are rejected
bmcli txtask remove --handle="txtask:sn=10356:port=0:slot-index=0:token=0123456789ABCDEF"

taskid, the compatibility alias index, and slot_index all identify the same physical hardware slot. They are not an offset into the filtered list of active tasks, so deleting a task leaves a hole and does not renumber later tasks. A subsequent add reuses the lowest free physical slot. count is the number of active tasks; device capacity is a separate limit.

In daemon mode, a missing task, stale/conflicting identity, or control denial is rejected before cancelling active work. A valid removal cooperatively drains affected operations before changing the hardware task table.

Standalone JSON returns the common physical identity fields only:

{"taskid":0,"index":0,"slot_index":0,"slot_ref":"txtask:sn=10356:port=0:slot-index=0"}

Daemon add/list JSON additionally returns handle_scope: "daemon_instance" and a handle ending in a 16-digit random token. The token distinguishes a current task from an older task that occupied the same slot. It is kept only in daemon memory: slot reuse, daemon restart, or channel-state reinitialization invalidates the old handle. It is not persistent, globally unique across computers, or an authentication credential. Standalone deliberately does not return a tokenless weak handle; use its slot_ref plus the existing channel and slot arguments instead. BMCLI does not currently provide txtask update; Signal/Message/E2E atomic update work belongs to CAN-222.

txtask list

bmcli txtask list --channel=0
bmcli txtask list --channel=0 --format=json

---

---

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