You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been working with Eduard from canmatrix to introduce support for CANopen Electronic Data Sheet (EDS) conversion to DBC files. EDS files are roughly equivalent to DBC files, but are the standard within the CANopen protocol (commonly used in industrial/medical/automotive applications). You can read about the file in our CANopen intro.
In the branch eds_bugfixing, I believe the support for EDS files is now sufficiently mature that it could make sense to integrate the file format as a supported format in the Bus Logging CAN tab of asammdf. Specifically, the idea would be to allow users to load DBC files as normal - but that they could alternatively load EDS files as well (i.e. this would be an option).
If I understand the dynamics of how asammdf uses canmatrix under-the-hood, I think this might be almost a plug-and-play addition. I recognize, however, that this requires introducing both the support for LDF files (for LIN) and EDS files (for CANopen) into the canmatrix master branch, as these are currently stuck on two separate non-master branches. But it might be possible to do a test of whether this works as intended.
I have multiple CANopen log files and related EDS files for testing this and can share some as well.
Optional: Enable Node ID selection
In the base version of this feature, it could be made possible to just load EDS files with no further EDS-specific functionality.
However, while a DBC file will contain the exact CAN IDs used on the CAN bus it's related to, this is not necessarily the case in the EDS file. For example, the EDS may define the properties of a specific device, e.g. Temperature2CANDevice. A CANopen bus may have e.g. 5 of these connected to the CAN bus, each assigned a unique Node ID in the range 1 to 127. Each of these nodes will communicate their temperature measurements on a message defined in the EDS (a Transmit PDO) onto the CAN bus. The TPDO is defined in the EDS as having a 'base CAN ID' of 0x180. However, each of the 5 nodes will then use a unique CAN ID by adding their node ID to this base ID. Node 1 thus uses 0x181, node 2 uses 0x182 etc.
In canmatrix, this is currently handled by allowing an optional argument to be passed in the EDS to DBC conversion, --edsNode - e.g. --edsNode 2. This allows for 'customizing' the EDS to a specific CANopen node, in order to match the CAN IDs of that node.
A way this could be implemented in asammdf could be to allow for an extra dropdown field next to the CAN bus channel dropdown for each database. This field would allow the user to select Node 1, Node 2, ... , Node 127 for example. The field would be greyed out when a DBC is loaded, but could be modified when an EDS is loaded. This way I think it would cause minimum confusion for regular DBC users, but it would provide a powerful way for CANopen users to specify the node IDs in a dynamic way (these may easily change across different deployments, for example).
Happy to provide further context on this as needed, of course.
The text was updated successfully, but these errors were encountered:
Hi Daniel,
I have been working with Eduard from canmatrix to introduce support for CANopen Electronic Data Sheet (EDS) conversion to DBC files. EDS files are roughly equivalent to DBC files, but are the standard within the CANopen protocol (commonly used in industrial/medical/automotive applications). You can read about the file in our CANopen intro.
In the branch
eds_bugfixing
, I believe the support for EDS files is now sufficiently mature that it could make sense to integrate the file format as a supported format in the Bus Logging CAN tab of asammdf. Specifically, the idea would be to allow users to load DBC files as normal - but that they could alternatively load EDS files as well (i.e. this would be an option).If I understand the dynamics of how asammdf uses canmatrix under-the-hood, I think this might be almost a plug-and-play addition. I recognize, however, that this requires introducing both the support for LDF files (for LIN) and EDS files (for CANopen) into the canmatrix master branch, as these are currently stuck on two separate non-master branches. But it might be possible to do a test of whether this works as intended.
I have multiple CANopen log files and related EDS files for testing this and can share some as well.
Optional: Enable Node ID selection
In the base version of this feature, it could be made possible to just load EDS files with no further EDS-specific functionality.
However, while a DBC file will contain the exact CAN IDs used on the CAN bus it's related to, this is not necessarily the case in the EDS file. For example, the EDS may define the properties of a specific device, e.g.
Temperature2CANDevice
. A CANopen bus may have e.g. 5 of these connected to the CAN bus, each assigned a unique Node ID in the range 1 to 127. Each of these nodes will communicate their temperature measurements on a message defined in the EDS (a Transmit PDO) onto the CAN bus. The TPDO is defined in the EDS as having a 'base CAN ID' of0x180
. However, each of the 5 nodes will then use a unique CAN ID by adding their node ID to this base ID. Node 1 thus uses0x181
, node 2 uses0x182
etc.In canmatrix, this is currently handled by allowing an optional argument to be passed in the EDS to DBC conversion,
--edsNode
- e.g.--edsNode 2
. This allows for 'customizing' the EDS to a specific CANopen node, in order to match the CAN IDs of that node.A way this could be implemented in asammdf could be to allow for an extra dropdown field next to the CAN bus channel dropdown for each database. This field would allow the user to select
Node 1
,Node 2
, ... ,Node 127
for example. The field would be greyed out when a DBC is loaded, but could be modified when an EDS is loaded. This way I think it would cause minimum confusion for regular DBC users, but it would provide a powerful way for CANopen users to specify the node IDs in a dynamic way (these may easily change across different deployments, for example).Happy to provide further context on this as needed, of course.
The text was updated successfully, but these errors were encountered: