Revision history [back]

Dear Mathias and Cyril

I guess that there might be some confusion about the meaning and usage of *.eds and *.dcf files present. Please let me explain the usage of these files in practice.

• The .eds is a so-called "Electronic Data Sheet" and holds an overview of all CANopen objects present by a CANopen slave device. This file is typically requested by CANopen master's system manager tools (or by the ROS_CANopen library tools) to get an overview of all present objects by a slave. The .eds file does not(!) hold any "ParameterValue" because it is seen as a kind of data sheet without application specific data. Based on Mathias' comments that just in case of a "ParameterValue" present it will be written, I expect that the *.eds file does not run into the problem about writing any parameters value at all. Therefore I recommend (and expect that this has actually been the intention by the ROS_CANopen library developers) to use the *.eds file instead of the *.dcf file. The *.eds file can be easily exported by the maxon's EPOS4 like described by the linked maxon Support Center document: -> "EPOS: Export of the *.eds resp. *.esi file (Electronic Data Sheet)". It is important that the *.eds file is exported by the EPOS4 actually in use because the object dictionary depends on the concrete EPOS4 product type and installed firmware version.

• The *.dcf file is quite similar to the *.eds file but holds parameter values too. *.dcf files are typically shared for debugging purposes to get a comprehensive overview about all parameter (resp. object) configurations in case of support issues or by setting up different EPOS4 the same way.

General remark about duplicating Parameter values:

Even in case of duplicating the settings of an EPOS4 it makes no(!) sense to write down any object's content. It is a point of fact that the content of objects with the "AccessType=ro" (-> "Read Only"!!!) or "AccessType=const" (-> "Constant"!!!) cannot be written by any CANopen master. These objects are just internally updated or set by the CANopen slave itself but cannot be written by an external device or master. The term "Read Only" of "AccessType=ro" resp. "Constant" of "AccessType=const" should clearly state this. Therefore the ROS_CANopen library or tools should not(!) write "AccessType=ro" or "AccessType=const" objects' content independent if the *.dcf holds a "ParameterValue" which has been read during data export.

Recommendation:

Please fix the functionality of the "ROS_CANopen library" taking the AccessType into account before an object's content is written. Thanks.

Another topic of concern is that the order of how the "AccessType=rw" or "AccessType=rww" objects are written can also have some impact because the value range of different objects might depend on each other, e.g. in case of different velocity with depend on each other. It also makes less sense to duplicate configuration values like the CAN "Node-ID" or CANopen PDO COB-IDs for example. Therefore it is not recommended to simple write down any object's content like this seems currently be a fact in case of the ROS_CANopen library. Typically the device manufacturer (e.g. of maxon in case of the EPOS4) provide tools to export and import parameter configuration files (*.dcf) to duplicate the relevant object contents on multiple EPOS4s in a proper way. In practice the application code normally takes care that the proper and required configuration settings (e.g. motor data, current limits, speed limits, control parameters) are checked and updated at start-up depending on the operating modes in use later on or specific requirements of the application or system environment.