v0.4.0

Date: 2026-11-06
Previous release: v0.3.1

Added

• OT Fabric's own stack: own/go-canopen/ puts go-canopen behind the container contract, and the manual workflow "Own stack (go-canopen)" builds it from the latest go-canopen release, tests it on a vcan interface against the references of the latest release (CANopenNode, Lely, python canopen) on amd64 and arm64, and publishes it from main as ghcr.io/otfabric/canopen-interop-otfabric:<go-canopen version> and :latest. Not an independent implementation, not a reference, and not part of this or any release (otfabric/engineering ADR-0012).
• Container contract 1.2: the capability document may carry upstream (name, version, revision, independentEngine); without it an image is independent, and results.json takes independent from it. The three reference images are unchanged.
• scripts/interop.sh <adapters…> (make interop): the self-test between exactly those adapters. scripts/lib.sh: ADAPTER_IMAGE_<adapter> names the image of an adapter, for scripts/smoke.sh and scripts/selftest.py too.
• REQUIREMENTS.md (R1: nothing outside own/ names a library under test, checked in CI).

Changed

• CI runs the self-test through make interop; make selftest stays as its alias.

Images

Image	Digest
ghcr.io/otfabric/canopen-interop-canopennode:v0.4.0	sha256:e1f2f96b644b64f60e8a22af2b3499aa5417fcc134be68b7edc3df5240f4ecff
ghcr.io/otfabric/canopen-interop-lely:v0.4.0	sha256:915e23e86f0bcdf58a634992cfa2ea416577a6e3cb8f8c3ddb9c67989486fd06
ghcr.io/otfabric/canopen-interop-pythoncanopen:v0.4.0	sha256:f3c4828d2de0fa31c7ae262ab00344f229446e83b9f55d98759ef3589aea1907

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.

v0.3.1

Date: 2026-11-01
Previous release: v0.3.0

Changed

• The Release workflow can be run by hand from the Actions tab with a patch, minor or major bump. The adapters, the container contract and the fixtures do not change.

Images

Image	Digest
ghcr.io/otfabric/canopen-interop-canopennode:v0.3.1	sha256:1430fc9a54af9fc501cdb53fef9fd8cfc971fdc1470511e73dd49cd17ee6d67d
ghcr.io/otfabric/canopen-interop-lely:v0.3.1	sha256:fc0b80cff1d09cf667ab88df09720a15bacb12074cf3462172f7b33c426383d8
ghcr.io/otfabric/canopen-interop-pythoncanopen:v0.3.1	sha256:ea530a624645c215b4416f33870e17aff04ad10f933521c900de94ce92e943aa

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.

v0.3.0

Date: 2026-10-31
Previous release: v0.2.0

Added

• Adds results.json in the interop-result-v1 format.
• Policy 1.2: build output in bin/ and release/, and shared CI at v3.3.0.

Images

Image	Digest
ghcr.io/otfabric/canopen-interop-canopennode:v0.3.0	sha256:ed8a4a4563b85f50f40bbd94fd3e9872e96c5f922fc901ad00ad5bacc783f4fc
ghcr.io/otfabric/canopen-interop-lely:v0.3.0	sha256:e9929db374e3af757f861e6b7ab2362e5a7fe4e77a803b9257184d17c0b0d547
ghcr.io/otfabric/canopen-interop-pythoncanopen:v0.3.0	sha256:a2f465e812a578513ff3c23df60b1f18e1ab042c28f739b6ef654dc9972f7bed

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.

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.

v0.1.0

Date: 2026-10-29
Previous release: none (first release)

First release: CANopen reference implementations in containers behind one
contract, for interoperability testing of CANopen software such as
go-canopen.

• Container contract 1.0 (docs/CONTAINER_CONTRACT.md)
  and JSON Schemas: device, sdo-upload, sdo-download (expedited,
  segmented, --block), nmt, listen (boot-up, heartbeat state changes,
  EMCY), pdo-configure, pdo-receive, sync, eds-check, cia402;
  JSON Lines output, exit codes 0–5 with SDO abort codes.
• Images ghcr.io/otfabric/canopen-interop-<adapter> for linux/amd64 and
  linux/arm64:
  • canopennode: CANopenNode v4.1 with CANopenLinux canopend; the device's
    object dictionary is generated from the shared EDS by CANopenEditor
    v4.2.3; the master uses canopend's CiA 309-3 ASCII gateway.
  • lely: Lely CANopen lely-core v2.3.5 through a C++ helper on
    liblely-coapp (BasicSlave, AsyncMaster, Sdo) and liblely-co; Lely's
    dcf-tools for eds-check.
  • pythoncanopen: python canopen 2.4.1 on python-can 4.6.1 (LocalNode,
    RemoteNode, SYNC producer, BaseNode402, EDS importer).
• Fixtures: the shared test device fixtures/eds/interop-device.eds
  (CiA 301 communication objects, four RPDOs/TPDOs, test objects 0x2000–0x200A
  of every basic type, string, DOMAIN, read-only, write-only, range-limited)
  and EDS/DCF fixtures for CompactSubObj, ObjectLinks, DCF ParameterValue and
  an invalid file.
• Self-test on vcan, every master × every device: object dictionary,
  SDO (incl. block transfer and aborts) with the device's own view of the
  written values, NMT and heartbeat, EMCY, event-driven, configured and
  SYNC-driven TPDOs, EDS checkers. Stack differences found and documented in
  tests/known-differences.tsv, among them:
  lely's SDO server rejects a DOMAIN download without size indication (as
  CANopenNode's gateway sends long data), CANopenNode's SDO server cannot
  upload 0 bytes, python canopen's LocalNode ignores the sub-index of a VAR,
  and the checkers disagree on CompactSubObj and ObjectLinks.
• Not in v0.1.0 (LIMITATIONS.md): lely sync and
  pdo-configure, canopennode PDO/SYNC/EDS operations, a CiA 402 drive to
  verify cia402 against, RPDO senders.

Images

Image	Digest
ghcr.io/otfabric/canopen-interop-canopennode:v0.1.0	sha256:be2e965a11d9dbca0afd1344b1fec00efef396ac6e3eaf994a4b01555d7d0218
ghcr.io/otfabric/canopen-interop-lely:v0.1.0	sha256:9788a6c54bed94969371d73233e3b24a826874020a7b2e8698a47f3ad89a9e84
ghcr.io/otfabric/canopen-interop-pythoncanopen:v0.1.0	sha256:9e8309b16334396318dc0789dda2ee068a57e28130e0ba3c220f46cde1f180f4

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.