v0.2.0

Date: 2026-10-29
Previous release: v0.1.0

Container contract 1.1: additions only, so that CANopen software such as
go-canopen can be cross-checked on LSS, multiplexed PDOs, the CiA 302
boot-up with concise DCFs and the SYNC window. Every 1.0 command, flag and
document is unchanged; documents still carry "schemaVersion": "1.0".

• LSS (CiA 305): lss --step ... runs LSS master steps in one run
  (switch global/selective, configure node-ID, configure and activate bit
  timing, store, inquire identity and node-ID, fastscan, assign-all) with
  the masters of all three stacks: CANopenNode's CiA 309-3 gateway
  (lss_switch_glob, lss_switch_sel, lss_set_node, lss_conf_bitrate,
  lss_activate_bitrate, lss_store, lss_inquire_addr, lss_get_node,
  _lss_fastscan, lss_allnodes), lely's coapp LssMaster (in the CiA 302
  boot-up) and python canopen's network.lss. device --node-id 255 --serial N starts an unconfigured LSS slave (CANopenNode, lely) that
  reports the node-ID it takes (node-id events, nodeId in the result)
  and the bit rate it is asked to activate (bit-rate).
• RPDO sender and SYNC window: rpdo-send (python canopen) packs and
  sends a device's RPDO, optionally between two SYNCs; devices declare
  syncWindowRpdo (lely discards a synchronous RPDO received after the
  window 0x1007, CANopenNode does not; CiA 301 allows both).
• MPDO: mpdo-send / mpdo-receive (lely): DAM- and SAM-MPDO
  producer and consumer, with the object scanner (0x1FA0) and dispatching
  (0x1FD0) lists.
• CiA 302 boot-up: boot (lely) boots a network from the slaves' DCFs
  with a concise DCF per slave (0x1F22, written by Lely's dcfgen) and
  reports each 'boot slave' result with the CiA 302-2 error status.
• Concise DCF: cdcf writes lely's concise DCF of a DCF, from dcfgen
  (configuration entries) or co_dev_write_dcf (every sub-object of a
  range), for byte-for-byte comparisons.
• Fixtures (schema 1.1): 0x1007 and LSS_Supported=1 in the shared
  device, mpdo-device.eds, interop-device-other-product.eds.
• Self-test: suites rpdo, lss (every LSS master × every LSS slave), mpdo,
  boot (a network of all three devices), cdcf: 54 pass, 6 known, 14 skip of
  the new suites; 389 pass, 15 known, 32 skip in all, no failure (Linux 7.0,
  arm64; CI on amd64 and arm64). New known
  differences: lely's LSS slave activates a configured node-ID only at NMT
  reset communication and answers fastscan whatever its node-ID, so
  CANopenNode's lss_allnodes keeps assigning node-IDs to the first lely
  slave.
• Images: CANopenNode v4.1 with the upstream fix for
  lss_activate_bitrate (commit cf85a4c, not in a release yet); lely with
  dcfgen (PyYAML, empy); the python canopen device processes NMT resets
  before the next NMT command (a master's start right after its reset was
  undone before). Upstream pins unchanged: v4.1, v2.3.5 and 2.4.1 are the
  latest releases.
• Not covered: CANopen FD (CiA 1301, USDO) — none of the pinned stacks,
  nor their development branches, implements it
  (LIMITATIONS.md).

Images

Image	Digest
ghcr.io/otfabric/canopen-interop-canopennode:v0.2.0	sha256:a6bcc486bf4a752c526cbaae13a9c12709acca73411aeea9c0153862839b5cae
ghcr.io/otfabric/canopen-interop-lely:v0.2.0	sha256:52455c38167d3e149bd3b3fc96953921a0639652c79f33661b200ca69e698cc9
ghcr.io/otfabric/canopen-interop-pythoncanopen:v0.2.0	sha256:e1243943f62942adae74a939379b185f1bb3f69b208756bbe6d37b0c07062024

manifest.json lists the images by digest for pinning. The images contain MIT, Apache-2.0 and LGPL-3.0 software and are for interoperability testing; see THIRD_PARTY_NOTICES.md.