> You are right they can't in CAN but maybe in CAN-FD but only for values sent > to drives and not feedback.
CAN-FD is still in it's infancy. The support is growing but it's not compatible with BASIC/FULL CAN on the bus at the same time so it's all or nothing. > > > The problem with relative is it turns again into the equivalent of a toggle > > message. Miss one and your position is wrong. So I would > never do that. > > Agree, almost. It is in most cases possible to use a 16 bit value and keep > track of the overflows provided it does not move to many > counts in between each time. It is not uncommon Micro controller have 16 bit > encoder counter so software need to keep track of > overflows, not many rows of code but it must be there and work perfect. I disagree. What happens in the processor with encoder and motion output is deterministic and you can use smaller counters and overflow interrupts etc. It's tightly coupled. A CAN message sent and ACK'd by _a_ node on the bus will _not_ be retransmitted. So the target motor that missed it will not know that it missed it nor will the sender. This is a fundamental issue with the CAN protocol which is why toggle messages are a bad idea. So PDO messages in CANopen are useful for information but not for commands unless the commands are absolute. For example a PDO that contains a SWITCH ON message that is missed and then a short time later contains SWITCH OFF doesn't change the target node. Just the ON/OFF pulse was missed. And that's a different problem. One could send relative distances to a motor and then also use PDOs to report position/velocity but what does the sender do if the position isn't yet what it expected? Could be any number or reasons why it's not there yet. Mechanical load, periodic messages that are more often than the rate of change of the motor. CAN as a medium is great for positioning or even detecting reported position and when found told to decelerate. John Dammeyer > > > Nicklas Karlsson > > > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
