The CANopen 节点 do not send the Heartbeats automatically.
You can programm the heartbeat with the function COP_WriteSDO.
e.g.: COP_WriteSDO( ... idx = 1017, subidx = 00 ... )

The Heartbeat interval for the CANopen node, that is programmed in this way, should be smaller than the guard time GuardHeartbeatTime in the COP_AddNode().
You will get the COP_k_NMT_HEARTBEATERR event,
when no Heartbeat message arrived during the setted guard time,
or when the state of the node is not correct.

PDO Management is implemented as a static array in the firmware. For each node there is space reserved for 10+10 PDOs, regardless of their actual usage. The limitations are thus set by the available RAM on the respective board type.

To cope with this limitations, it is recommended to register only PDOs actually active at the CANopen Master API by calling function COP_CreatePDO().  On the 其他 hand, for reasons of clarity it is good practice to use the numbers of the PDOs in the order they are present at the device, i.e. CANopen Master API PDO#1 = device’s 1400/1800 etc.

Contrary to the statement given in the user manual in the description of this particular function (chapter 5.3.1) it is possible to call this function more than once for the same PDO in order to 改变 former settings. This offers some dynamics for the PDO management. Usually, reconfiguring resp. overwriting an already declared CANopen Master API PDO should be done only if the corresponding actual device PDO communication parameters 改变, in particular, the COB-ID.

If you still need more PDOs for a particular node, you can use the 10+10 PDOs of a not existing node. For this, call COP_AddNode() for an unused NodeID with "passive" settings (i.e. no node monitoring) and use all this 节点´ PDOs as you wish.

With CANopen Master API 6 these limits are pushed up to a maximum of 16+16 depending on the CAN board utilised, while the standard PDO count is increased from 10 to 12 for all boards.

When programming CANopen Master API, we adapt to the existing physical CANopen slave devices’ PDOs.  This means, we create corresponding/matching CANopen Master API PDOs to the slave’s PDOs.  By this “creation”, internal records and 连接ions of the CANopen Master API are being set up, but no 改变 to the slave’s PDO configuration takes place.  If you want to do the latter, you have to use the SDO-related function set of CANopen Master API and write to the slave’s PDO communication and mapping parameters Object Dictionary entries.  Afterwards, you still had to “create” a matching CANopen Master API PDO that mirrors the slave alterations.

Apart of that, CANopen Master API up to V5 is not aware of this so called “Predefined Connection Set” COB-ID allocation rule.

 

For CANopen Master API 5:

• There are no SDO data length restrictions anymore.
• Additional functions for asynchronous SDO handling (COP_PutSDO, COP_GetSDO, COP_CancelSDO)
• SDO blockmode support
• USB boardtypes support
• Bootup message supported according to CANopen Specification DS-301 V4
• COP_InitBoard function: Simplified parameters, board identification based on VCI V2 hardware selection mechanism(XatxxReg.dll)
• COP_CreatePDO function: Priority and inhibittime parameters removed.
• COP_CreateSDO function: Priority parameter removed.
• Unified timer resolution of 1ms and unified timer value ranges for all boards
• Support of Heartbeat to CANopen Specification DS-301 V4
• DLC of the RTR messages is not 0 any more.

• Support of the iPC-I XC16/PCI, tinCAN161 and USB-to-CAN II interface
• Microsoft .Net based example programs

• Support of two CAN controllers per CAN interface board (for iPC-I XC16, tinCAN 161 and USB-to-CAN II only)
• full LSS master functionality (according to CiA 305)
• Flying Master mechanism (as specified in CiA 302)

• Support of VCI V3
• Support of single and dual channel for CAN interface boards with 16bit microcontroller
• Support of the iPC-I XC16/PCIe board

1. Which version of the CANopen Master API is used?
   (see „Start | Control panel | Software | IXXAT CANopen Master API version“ orthe version number of the XatCOP50.dll, cop40un6.dll, cop22un6.dll, cop21un6.dllfrom the Windows System32 directory)
    
2. Is it possible to reproduce the problem with the programming example from the CANopen Master API installation directory?
3.  
4. Please use the debug version of the XatCop50.dll, cop40un6.dll from the CANopen Master API installation directory
   (e.g.: C:| Programms| IXXAT| CANopen Master API 5.1| bin| debug| log| XatCOP50.dll) and send us the created protocol file XatCOP50.log, COPMST32.log.
   Please note:
   There is also a copy of XatCOP50.dll (release build) in the Windows „system32“ folder which might be used by the application. Please rename this instance for creation of the log file.
5. Which VCI version is installed?
   (see „Start | Control panel | Software | IXXAT VCI version“ or the version number of the vcinpl.dll or vci11un6.dll from the Windows System32 directory)
6. Which CAN interface board is used?
   (Please send us a screenshot of the device manager.)
    
7. Does the CAN interface board run correctly with the Minimon?

1. CANopen Master API V4.1.2.28 (or higher)
2. CANopen Master API V5.0
3. CANopen Master API V5.1
4. CANopen Master API V5.2

• Support of VCI V3 for CAN@netII/VCI hardware. Requires VCI 3.2.2.2098 (or higher).
• Support of 64bit Windows host systems.

• New CANopen functionality (enhanced SYNC mechanism specified in CiA 301 v4.2, LSS fastscan specified in CiA 305 v2.2)
• LabVIEW examples
• Support for passive IXXAT CAN interface boards using VCI 3.5.x
  (CAN-IB100/PCIe, CAN-IB120/PCIe Mini, PC-I 04/PCI)