CAN Open PDO transmission type settings - Page 1
Forum section: electronics / projects

author: Simon
author_rank: Unknown
timestamp: September 06, 2025, 08:50:57 am
content: I think I have this right but as what I have read so far on the matter is vague I just want to see that I have it right and see if people have experience of devices that don't quite follow the standard.When configuring the PDO transmissions (RPDO & TPDO) there is an object for each PDO called PDO transmission type. 0 will have the PDO transmitted or the received data processed on every sync message and for N = 1 to 240 will do this every well this is where it gets confusing. The wording seems to imply every time this sync number is received in the sync message but looking at DS301 it talks about system using the minimum common multiple of the different "N's" which implies not on this sync number but every multiple of this sync number. This would make more sense as it allows one to actually setup fast and slower updating devices but with the updates still at regular intervals.The other thing that I am considering is the sync rate. Does it need to be regular? I don't think it does as it simply triggers TPDO's to be sent and RPDO's to be acted upon. You see this gives me a dilemma. Assuming every PDO is transmitted or actioned on every sync message, when my master sends a sync message commands previously sent with RPDO's will be actioned but I will also be getting data back from TPDO's. But the data received back is the effect of the command sent before the previous sync message and this one just activated a command sent based on the data from the command before that.OK, so I set it so that on odd sync counts the TPDO's are sent by the slaves, I process the data and send the RPDO's and then on the even sync count the commands are processed. But the time it takes to receive the TPDO's process the data and send RPDO commands back may be much less than the interval between sync messages. If the interval is fixed it does need to be enough to do the receiving, processing and command transmitting worse case before the next sync. This could leave a big gap between current data and a command response that will leave thing for the system to drift further making the later response also already out of date.So how about I send a sync message. The slaves will reply with the data. I wait enough time for these responses (worse case), process the data and send RPDO's with commands and then send the sync message. The sync message that gets data would be sent on a regular basis, the sync message that provides commands in response to the data is send as soon as.Reasonable? or will I break the CAN Open universe?

author: BennoG
author_rank: Frequent Contributor
timestamp: September 06, 2025, 02:41:33 pm
content: you know you don't have to use sync transmission. We use CAN only in event based transmissions (with rate limiting if needed).This way you can have fast response times.If you need to switch all the outputs on different nodes at exactly the same time you need sync messages.Benno

author: Simon
author_rank: Unknown
timestamp: September 06, 2025, 05:26:09 pm
content: Well I have worked on a project with two motors connected together (with some "elasticity" in that link) where I would want them to react together. I see in the options for the motor driver I am working with to have the TPDO's sent only if there is a change or every 1-0xFFFF ms.

author: BennoG
author_rank: Frequent Contributor
timestamp: September 06, 2025, 05:44:29 pm
content: That is the mode we use only wint 10 - 30 motors per CAN bus.We use 600 ms interval on no change and 1 or 25 ms back-off on change depending wat we want from the motor.

author: Simon
author_rank: Unknown
timestamp: September 06, 2025, 05:52:54 pm
content: Well from what the manual says the options are "on change" (0) or every so many ms (1- 65535). It does make the "on change" option rather useless as I have no idea how fast it will transmit for something that could vary quite fast... maybe the filtering settings for each value effectively controls that.

author: BennoG
author_rank: Frequent Contributor
timestamp: September 06, 2025, 05:55:49 pm
content: 0xFE is on most devices on change and interval.Benno

author: Simon
author_rank: Unknown
timestamp: September 06, 2025, 06:06:08 pm
content: Yes there is the option but on change has no way to limit the bandwidth

author: BennoG
author_rank: Frequent Contributor
timestamp: September 07, 2025, 07:06:25 am
content: That is a default part of the DS301 specification.See image- inhibit-time: n*100 μs, n >> 0So if you set it to 100 it will be a minimum of 10 ms time between PDO messages, and 1000 will be minimum 100 ms between PDO messages.

author: Simon
author_rank: Unknown
timestamp: September 08, 2025, 07:37:52 am
content: Ah, I see, the motor driver I am working with does not feature all of these.

author: BennoG
author_rank: Frequent Contributor
timestamp: September 08, 2025, 07:53:11 am
content: Most devices have them but are not documented you can try writing and see what happens (UINT16)

author: Simon
author_rank: Unknown
timestamp: September 08, 2025, 09:39:08 am
content: I see, to be honest I like the way I am proposing as it means everything is predictable. I just don't know if it will upset things

author: Simon
author_rank: Unknown
timestamp: September 09, 2025, 07:52:48 am
content: Which version of the CiA301 document do you have? The current version 4.2.0 also has a sub index 0x06 that has the starting sync count from which the count intervals will be counted. This makes sense as it means that if you have say 10 different devices and you only want 1 to report at a time, setting the transmission type to 10 will simply have all 10 report every 10 sync counts.But again my device (Delta-line Leo driver) does not list this object so I don't know if it is there.