We noticed that CoDeSys has a strange behavior :
After having started a CANopen slave node, CoDeSys decides - on its own - to transmit enabled RPDOs to the slave. This happens automatically without any specific action in our application.
This is a problem since these PDOs are transmitted with invalid (uninitialized) command words inside. So they are rejected by the slave.
How can we control this behavior ?
We would like the RPDOs not to be transmitted automatically after startup.
Thanks for your answers.
Is this V3 or V23?
CoDeSys does not automatically send RPDO data. Typically RDPO on the CoDeSys side is on COS (Change of State). You can control RPDO data in multiple ways but differently based on which version of CoDeSys you are using.
Are you using Sync object?
How is the RPDO setup in the Node configuration? Sync, Async, EventTimer, Inhibit timer?
I bet as a test you take your data and set it to zero like this
IF (xtransmit_data = FALSE) THEN
myRPDO_data := 0;
myRPDO_data := process_data;
If sync is not enabled you should see that no RPDO data is sent until xtransmit_data = TRUE AND the myRPDO_data changes.
This is CoDeSys v3. As the forum section suggests.
We do not use sync objects.
Our RPDOs are configured as asynchronous. We tried both "manufacturer specific" and "device profile specific" settings.
Since we use asynchronous mode, EventTimer and InhibitTimer are set by default to 0 but they are normally unused. Right?
Indeed, our test is as follows:
- The RPDO fields are mapped to global variables.
- At the beginning of the test, we do NOT write nor read these global variables.
- After a while, the global variables are written to a valid value (different from 0).
The problem is that RPDOs transmission occurs before these global variables are assigned a value.
As you said, we were expecting our RPDOs to be transmitted on Change of State.
If it may help :
- RPDOs are transmitted even if their content is not mapped to a variable
- RPDOs are transmitted even if the mapped dictionary object are initialized with SDOs messages
- The only way we found to avoid RPDOs transmission at startup is to disable them
Could CoDeSys send the RPDOs to synchronize its local cache (process data) ?
Any other idea is welcome.
The default setting is that at startup the PDO mapping is done and the CAN nodes are automatically put into operational mode.
I think you should enable the expert settings of your CAN node and check the option "No initialisation". This way the mapping is not done to the node, but the CoDeSys runtime knows which PDO data is exchanged.
The other thing I think you should do is go to the CANopen_Manager and uncheck the option Start slaves.'
This way your nodes will stay in pre-operational state and you will have to put them in operational mode once your application is running.
For this you can use the Function Block "CIA405.NMT" (never tested myself with V3 yet).
Good advice from Tim but one point when you check "No Initialization" you get no SDO configuration data either! When I get back to office I'll check on this. In V23 no RPDO's are sent until the data is changing. How invalid can the data be? Sending 0 is invalid?
Indeed, when the "No initialization" option is checked, the RPDOs are not transmitted but the SDOs (for configuration) neither.
The other problem you might encounter when "No initialization" is unchecked is that you do not know when all SDO have been transmitted and your application might start its execution prior SDO transmission completion. In extreme conditions, the application might try to start the node before it is reseted.
The "Start slaves" option was already disabled and the slave nodes are started by our application thanks to CIA405.NMT messages. It works properly.
Is there a way to trigger SDO transmission by code ? I mean in an automated way for configuration. I know we can write them one by one with SDO_Write.
Or maybe the way to do it is by iterating of the SDOs table. Do you know a way to do this ?
Please we should all complain to 3S about the lack of access to the CANopen stack in V3. They made great improvements but cut the developers out of access. Let me know if you know how to trigger all SDO in V3.
Log in to post a comment.