#include <def.h>
Go to the source code of this file.
In this file you'll find some definitions, variables, ... which are needed to create/accessing the object dictionary. For creating your own CANopen SlaveLib, you have to adapt several variables and defines here.
|
this are static defined datatypes taken fCODE the canopen standard. They are located at index 0x0001 to 0x001B. As described in the standard, they are in the object dictionary for definition purpose only. a device does not to support all of this datatypes. |
|
defines the last available entry of the communication profile area. Adjust this var, if you have additional enties. |
|
The count of digital inputs for which memory has been allocated |
|
The count of digital outputs for which memory has been allocated |
|
In order to perform lifeguarding of devices, there are two different systems: a device sends itself Heratbeat packages in predefined time-spaces (e.g. every 10 seconds) or the other possibility is, that a node (e.g. the master) "asks" each client about the state of the node (this is called node guarding). Of course also a client can be a heartbeat-consumer (this means it consumes the heartbeats of a device (e.g. it checks, wheter the master is still alive or not). The definition below tells the object dictionary how many heartbeats this node does consumes |
|
adjust this value, if you need more or less PDO mapping entries. (up to 64 are possible) |
|
This macro helps creating the object dictionary entries. by calling this macro it creates an entry in form of: 7 of entries, pointer to the entry. This macro was sponsered by Edouard Tisserant: thanks! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
real used datatypes for different object dictionary things. I know, some of this definitions are done in def.h, but i thought it would be useful if the datatype names (e.g. UNSIGNED8) has the same names as mentioned in the CANopen standard. so instead of using BYTE, you can use UNSIGNED8, although both are 'unsigned char'... maybe this should be changed... |
|
Each pdo can map up to 64 vars (8 vars per 8bit, and 8 * 1Byte = 64 possibilities "normally" i think you need a maximum of 8 time 1 Byte, so 8 mapping entries should be sufficient. note: for each PDO a PDO-mapping is mandatory! |
|
autogenerated value: indicates the count of defined PDOs |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is the last defined entry for pdo-paramters (rx). This means: this is the last entry for which memory has been allocated. Adjust this value if you need more or less entries. |
|
This is the last PDO-Mapping parameter (rx) for which memory has been allocated |
|
|
|
|
|
|
|
|
|
|
|
This is the last defined entry for pdo-paramters (tx). This means: this is the last entry for which memory has been allocated. Adjust this value if you need more or less entries. |
|
This is the last PDO-Mapping parameter (tx) for which memory has been allocated |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Struct for creating entries in the communictaion profile |
|
Struct needed for the idendity of a CANopen device. Defined by the CANopen standard |
|
This is the datatype for the communication parameter of PDOs defined by the CANopen standard |
|
Struct needed for setting up PDO mapping parameter. Defined by the CANopen standard |
|
Struct needed for SDO parameter. Defined by the CANopen standard |
|
This are some structs which are neccessary for creating the entries of the object dictionary. |
|
Each entry of the object dictionary can be READONLY (RO), READ/WRITE (RW), WRITE-ONLY (WO), OR CONSTANT (CONST) At the moment SDO-Transfer is not implemented, and therefore the functions which accesses the object dictionary do not care about this acces-types. Of course this is topic to change! |
|
Each entry of the object dictionary can be a different object. this objects are defined by the CANopen standard. see standard for more information. At the moment the object dictionary does not really care about this different types. this is topic to change! |
|
now the communication profile entries are grouped together, so they can be accessed in a standardised manner. This could be memory-optimized if the empty entries wouldn't be added, but then the communictaionprofile area must be accessed different (see objacces.c file) |
|
This variable indexes all entries which are responsible for digital inputs. (input means: a value which is captured by this node and sent to another node e.g. the state of a port is sent to the server ) |
|
This variable indexes all entries which are responsible for digital outputs. |
|
Create the Receive PDO Parameter area. |
|
This variable indexes all entries neccessary for pdo-mapping for receiving PDOs |
|
Create the Transmitting PDO Parameter area. |
|
This variable indexes all entries neccessary for pdo-mapping for transmitting PDOs |