Skip to content

bench: move VCU_Command to 0x101 (land #6 on main) - #8

Merged
tkeairns merged 3 commits into
mainfrom
bench/vcu-command-0x101
Oct 4, 2026
Merged

tkeairns merged 3 commits into
mainfrom
bench/vcu-command-0x101

Conversation

@tkeairns

@tkeairns tkeairns commented Oct 4, 2026

Copy link
Copy Markdown
Contributor

Lands #6 on main. #6 merged into its stack base feat/canopen-hil after #5 had already merged, so its three commits never reached main. Same commits, unchanged:

  • bench: move VCU_Command to 0x101, off the CANopen TIME id
  • can-full: say why the VCU command is at 0x101
  • canopen: drop the notes on the TIME collision, gone with the VCU move

Reviewed and tested as #6: CI 14/14 (Renode benches incl. CANopen), and on hardware the example suites 26/26 with these images. The genset enters Drive on VCU_Command at 0x101 and sends its DM1.

zelos-can's test/hil/nodes/bench.dbc already expects 0x101 (zeloscloud/src#1628, merged), so main is out of step until this lands.

0x100 is the predefined COB-ID of the CANopen TIME object (CiA 301).
can-full puts the VCU on a bus with a CANopen node, so a node that
consumes TIME takes the VCU's command frames as TIME, and any CANopen
tool decodes them as TIME. CiA 301 forbids CANopen devices from
configuring 0x101-0x180, so a non-CANopen message there cannot collide
with a CANopen node, and 0x101 keeps the command's bus priority
essentially unchanged.

bench-health matches the message by name, so it reads both live data and
traces recorded before the move.
@tkeairns
tkeairns merged commit 8fe810e into main Oct 4, 2026
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant