This document briefly describes the changes between the different releases of Powerlink Controlled Node V3 over time. For each new release the major differences compared to the previous release are documented. The intended audience is external software developers, testers and users. The range of topics is not limited, all user-observable changes any be described here, though this mostly should be around the packet API.

Migration from 3.4.0.x to V3.5.0.x

Synchronous application

The stack feature flag MSK_EPLCN_IF_CFG_STACK_CFG_FLAGS_DISABLE_HOST_TRIGGERED_PREQ_XCHG is now obsolete and just ignored by the stack. The application has to use the generic Hilscher service HIL_SET_TRIGGER_TYPE_REQ in order to configure the synchronous operation. The following values are supported:

• usPdInHskTriggerType:
  • HIL_TRIGGER_TYPE_PDIN_NONE → free-run mode. PReq data are exchanged using an internal triple buffer. The Application gets the newest data received from the network
  • HIL_TRIGGER_TYPE_PDIN_RX_DATA_RECEIVED → handshake coupled to PReq data receive. If the handshake still locked by the application when receiving the PReq frame, the data are just ignored and the internal synchronous error counter is incremented
  • HIL_TRIGGER_TYPE_PDIN_TIMED_ACTIVATION → not supported
• usPdOutHskTriggerType:
  • HIL_TRIGGER_TYPE_PDOUT_NONE → free-run mode. The application writes the PRes data in DPM in own cycle. The stack will always copy the newest data into the HAL buffer and return the handshake directly.
  • HIL_TRIGGER_TYPE_PDOUT_READY_FOR_TX_DATA → handshake coupled to PReq data receive. The application writes the PRes data in DPM, the stack copy the data into the HAL but does not return the handshake until the next PReq frame was received.
  • HIL_TRIGGER_TYPE_PDOUT_TIMED_LATCH → not supported
• usSyncHskTriggerType:
  • HIL_TRIGGER_TYPE_SYNC_NONE → no sync signal
  • HIL_TRIGGER_TYPE_SYNC_TIMED_ACTIVATION → sync handshake coupled to SoC (Start of Cylce) frame. This mode can only be enabled if usPdInHskTriggerType and usPdOutHskTriggerType are set to HIL_TRIGGER_TYPE_PDXXX_NONE.

  • Others → not supported

IO data status in DPM

The stack feature flag MSK_EPLCN_IF_CFG_STACK_CFG_FLAGS_USE_APP_READY_FOR_PRES_RD_FLAG is now obsolete and just ignored by the stack. The IO data status are handled in 2 different ways depending on the new stack feature flag MSK_EPLCN_IF_CFG_STACK_CFG_FLAGS_ENABLE_PDO_STATUS.

• Flag is not set (default mode): In this case the following rules apply:
  • If the received PReq data are invalid, the stack just zero them previous copying to DPM
  • The PRes data are permanently marked valid after the first DPM IO exchange
• Flag is set: In this case, an additional byte is placed at the end of the IO data in DPM for the data status. Following rules apply:
  • The flag enables the IO data status byte for both directions Tx and Rx. It is not possible to enable them separately.
  • The IO data status byte is defined as follows:
    • Bit0: Status:
      • 0 → invalid
      • 1 → valid
    • Bit1-7: reserved for future purposes
  • In case of an application with the CrossTraffic feature enabled, the IO data status of each Rx PDO channel is placed at the end of the corresponding data.

Cross Traffic

The stack supports now the Cross Traffic feature. Refer to the protocol API manual for detailed information.

Device Data Provider

The stack implements the new Hilscher DDP behavior. In the PLS stack, this affects the way how an application may configure its own MAC address. Following rules apply:

• The DDP may be in state "active" or "passive".
• The protocol stack delays its startup until the DPP is set to "active" and a valid MAC address was configured.
• The default initial state of the DDP in the firmware is "active". A new Tag List entry allows changing this initial state to "passive".
• While the DDP is "passive", an application may configure its own MAC address using the HIL_DDP_SERVICE_SET_REQ service.
  
  • DO NOT USE HIL_SET_MAC_ADDR_REQ anymore. Even if the service still accepted by the OS in the FW, the data are ignored by the protocol stack.
• The application has to change the DDP state to "active" to continue with protocol stack startup.
• Refer to the official DDP documentation for more details