2.2.7 production

2.2.7 latest - production

minor debugging output improvements
some cleanup done as always
update CI for documentation image ubuntu24.04.doc
largely validated for performance and stability, see validation reports
no CAN extended ID, no CAN flexible datarate
debugging traces TRC/DBG in reception handlers w22 suppressed
last release from Michael before code handover to Luis

2.2.4

small bug fixes

• suppressed the interactive message box in CanLibLoaderWin.ccp:61 https://its.cern.ch/jira/browse/ENS-27467
• made m_updateInitialError () ; public again and renamed it to updateInitialError() accordingly, OPCUA-2602.
  also initialize it to 0 at init.
• fixed a silly bug in the build chain for socketcan: some sources were missing.
• code around reconnection behavior based on superclass methods everywhere now. Hope this works for windows
• validation reports for versioning and stability ongoing across OS and vendors

2.2.3

• very minor cleanup, just released for tidyness
• same as 2.2.2

2.2.2 ready for production

tag 2.2.2 ready for production

• some trailing fixes and cleanups since 2.2.1
• remains stable also with 1e6 frames per port sent, with all 16ports of an anagateFZ connected on the same bus
• conveniently tested to high confidence
• wrap up of validation reports stability, performance and versions still in progress
• alma9.3 for sock, otherwise (almost) any linux and alma9 for anagate, windows2022, windows2019

v2.2devel

• intermediate tag for new anagate bridge with added functionality.
• builds for cc7, alma9, w2019s, w2022s
• needs testing and docker-windows integration
• NON PRODUCTION

2.1.1 for CanOpenNG

release good for production, issues for CanopenNG solved
lots of updates and changes
documentation update is in progress
validated cc7, alma9, w2029 and w2022 with systec, peak, anagate, see

• EDMS https://edms.cern.ch/document/2848748/1 (all signals validation)
• EDMS https://edms.cern.ch/document/2827478/1 (anagate fwd and rev compatibility)

using anagate beta.v6 everywhere since it is backwards compatible without new functionality
using latest vendor APIs elsewhere, but can choose versions in the build chain easily if needed
there are now signals for:

• data transmit
• port specific errors
• global errors
• port status changes

2.0.24intermediate

intermediate release 2.0.24, with lots of changes inside already

• this release is validated for anagate bridges new and old, forward and backwards compatible with API beta.v6, for cc7, cs9, cal9 and w2016s. See https://edms.cern.ch/document/2827478/1 for the detailed validation report on this. No new functionality is yet used or tested, just very basic stuff
• new functionality required for integration with CanOpenNG is implemented already, see the issues underneath in progress https://its.cern.ch/jira/browse/OPCUA-2928 . I am now going to test all this firstly, and have a new branch "devel2.0.25" for that if there are changes
• the third step is the new diagnostic functionality from the anagate API beta.v6 ("ideal CAN bridge"). This should be based on the previous steps and be a branch "devel2.0.26". When all this is properly tested and validated then we are good.

USER FEEDBACK for CanOpenNG

from now on this is again a good moment to collect and integrate any feedback you might have.
Here is what happened so far:

2.0.24 [ 30.jan.2023 ]

• socketcan: reworks for CanOpenNG server integration, keeping compatibility with other implementations

  • send remote requests also with stats, error signals and reconnection thread
  • using wrappers for send, socket
  • using signals for
    • can message error detection and publish
      detect error flags in the can message frame and decode them into text. For socketcan, this should be
      identical to can_get_state. For other implementations this would be the only way.
    • port status changes (not always errors) (NEW)
      extends the can_get_state (socketcan) with
      • CANMODULE_NOSTATE, // could not get state
      • CANMODULE_WARNING, // degradation but might recover
      • CANMODULE_ERROR, // error likely stemming from SW/HW/firmware
      • CANMODULE_TIMEOUT_OK, // bus is fine, no traffic
      • CANMODULE_OK // bus is fine
        so that this covers other vendors as well, at least approximatively, and sends that through a signal
    • receiving can frames
      send the received CAN frames down the according port signal as usual
  • sendRemoteRequest: copied clarification from Piotr using the wrapper
  • trigger reconnection thread when nb bytes read <0 , drop m_recoverPort() method for that
  • moved code out from header files to implementation

• getPortStatus() (unified) remains untouched. This method can be invoked by the user. This goes out to the hardware for any
  vendor, acquires the port state and returns the bit-pattern plus implementation encoding "sugar" in the highest nibble. This is
  always a straight-down-to-the-hardware method. If you invoke it too often you might slow sown / mess up the hw actually.

• anagate: reworks for CanOpenNG server integration, keeping compatibility with other implementations

  • error messages signalling much more extensive
  • port status change signals (NEW) as common defined standard
  • had to hack an anagate API header for windows. annoying but no big deal.

• peak:

  • do proper versioning of the windows vendor libs, 17.nov2017 and 16.july.2022, see CanInterfaceImplementations/peak/CMakeLists.txt,
    as defaults. Use toolchain of course
  • fix (trivial) inconsistencies between API versions so that we have one code only
  • translate the wonderful error-bitpatterns from peak into new enum, and add the peak specific text to the error message which is LogIt'ed
  • for each status change, send a signal to the err handler, but suppress bitpattern details at this stage

• cal9 build with new beta.v6 anagate API lib, for a try

• fix logit pull-in

2.0.23 build chain updated

build chain updated

• changed project name to avoid lib name collision
• link option corrected
• standalone, static/shared build
• uatrace dep from LogIt

2.0.22 ready to be validated by CanOpenNG

2.0.22 is ready to be validated by CanOpenNG

• chrono and std:: cleanup, nanosleep etc are suppressed in favour of chrono. Some code streamlining.
• drop messages with extended IDs or data (do not truncate and send nevertheless)
• checked all thrown exceptions: they are indeed runtime_error and NOT logical_error
• getPortStatus(): UNIFIED PORT STATUS. when invoked by a client, it actually talks to the specific hardware for each vendor using the vendor API. It returns a unified port status as documented: first nibble=implementation, all other bits: whatever the vendor returns per implementation. No "abstraction" to an i.e. "CAN_PORT_ERROR_ACTIVE is possible. A port status change occurs (1) there is an error (2) a controlling action by the client has occurred. Errors are reported by LogIt or by thrown exceptions. So there is no need to report port-status changes through signals.
• depending on the vendor API CAN status is not available through the API! That is why getPosrtStatus() exists. IF we have a CAN error frame we send it per signal.

mainly documentation

• version corrected
• found and suppressed another few nanosleeps, replace with chrono
• OPCUA-2584: rx/tx counting in the handler, for now, to improve err reporting already, and port status:
  • CanMessageError: send a boost signal with an error message to a subscibing error handler
  • anagate: used in sendMessage() and sendRemoteMessage()
  • peak: sendErrorCode() sends an error code (not a message) at sendMessage(), triggerReconnectionThread() and sendRemoteRequest()
  • systec: sendErrorCode() sends an error code (not a message) at message reception with USB error AND the return code of sendMessage (also if it is OK)
  • sock: no wrapper method (defined but not used), error messages are sent when: socket recovers, error reading from socket, a CAN error
    was flagged from the socket (plus message and socket timestamp if possible), when opening a CAN port produces an error
• no functional changes