Closed ksdexory closed 1 year ago
Which version do you use? Please use the latest release or the bugfix branch. Can you provide the xdd file, please.
I came across that in the latest binary version v4.0-104-g6f50f73. I found a workaround, when I give transmit/receive access to PDO under the object dictionary tab -> object settings (instead of transmit only as per video tutorial), the problem goes away. I was wondering if there is a bug on that field and the logic is the other way around (t gives access to receive and r gives access to transmit).
@CANopenNode : Janez, we had a discussion about the PDO access types and whether they are consistent across all import/export options. I have a halfway overview of the V1.x (legacy mode) stuff with rww and so on, but with the new definitions (tr, etc) I lack the deeper insight. Do you have a feeling for whether everything is OK? If not, I will try to dive deeper, but it may take some time.
Hi,
Clarifying Access PDO:
Then there are rww and similar, which is combination of SDO and PDO access. In V1options are unchanged. In V4 I tried to make SDO and PDO access more clear and independent from each other, so I just removed confusing options. I think, the latest CANopen standards use the same approach.
Then I must say, I usually configure PDOs dinamically, directly on the running CANopen devices and then store parameters, not using OD editor at all.
The problem here is independent from legacy or V4 mode. There is problem inside "(T)X PDO mapping" tab. After I do a configuration and press the Save button, it generates all TPDO communication and mapping parameters, but: it generates only as much subindexes in mapping parameters as there are mapped variables. This is wrong. It must always generate 8 subindexes or at least leave number of subindexes unchanged. "Number of mapped objects" is correct. Unused mapping slots are necessary for dynamic PDO configuration.
I clarified myself about "rww" and "rwr". This is from the standard:
The “rwr” indicates that the related object is read or is written using SDO, but is only mapped to TPDO. The “rww” indicates that the related object is read and is written using SDO, but is only mapped to a RPDO.
I think, it is now correct in CANopenEditor.
This should be fixed now.
Following the CANOpen Node STM32 example I am getting the following error: TPDO 0x1A00,0x01: not mappable OD entry 0x6000,0x00 https://www.youtube.com/watch?v=R-r5qIOTjOo (creating a TPDO section at 1:26)