Application Parameter
This section describes the specification of a parameter groups. The parameter structures are highly application specific and shall be defined within the application header files.
Example:
This example defines multiple parameter groups:
These structure type definitions are recommended to force the linker to place the corresponding parameter variables in a consecutive memory block. Any other technique to get this result is reasonable, too.
Within the object directory configuration, the parameter group information structures shall be allocated and filled with the corresponding parameter group information settings.
Example:
The following descriptions explains the details of the table members:
Reset Type | Description |
---|---|
CO_RESET_COM |
parameter group shall be set to the stored values on communication reset |
CO_RESET_NODE |
parameter group shall be set to the stored values on node reset |
Parameter Feature | Description |
---|---|
CO_PARA____ |
parameter group is disabled |
CO_PARA___E |
parameter group is enabled and will be stored on command |
CO_PARA__A_ |
parameter group is enabled and will be stored autonomously |
CO_PARA__AE |
parameter group is enabled and will be stored on command and autonomously |
Note: "autonomously" means without CANopen network interaction; e.g. the application is responsible for the storage of these parameter groups.
The object entries, handling the saving and restoring of parameters, shall be set for the example to the following values:
The single parameters are most likely used within the object directory. The example definition of a object entry is shown for one parameter:
{ CO_KEY(0x1017, 0, CO_UNSIGNED16|CO_OBJ____RW), 0, (CPU_INT32U)&Para.App.DemoWord },
End of topic