I have a question about Canopen hope someone has an answer! Lets frist start with the facts so that we can confirm them as we go. We have 4 TPDOs and 4 RPDOs in each canopen node. Each TPDO/RPDO is mapped to some data in the object dictionary. Now since I have only 8 byte size packets I can only map 32 bytes of object dictionary data to all the available Tpdos/Rpdos at one time??? Is this correct? If so isn't this a serious limitation? How do we get around this? Thanx in advance
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Guest hat geschrieben:
I have a question about Canopen hope someone has an answer! Lets frist start with the facts so that we can confirm them as we go. We have 4 TPDOs and 4 RPDOs in each canopen node. Each TPDO/RPDO is mapped to some data in the object dictionary. Now since I have only 8 byte size packets I can only map 32 bytes of object dictionary data to all the available Tpdos/Rpdos at one time??? Is this correct? If so isn't this a serious limitation? How do we get around this? Thanx in advance
The 4 TPDO and 4 RPDO per node is the setup for a CanOPEN implementation. But, being open, you can really have anything you want so long as the hardware supports it. Also, you can always use SDO's to request/receive information. It is just that PDO's are more efficient. The default addressing scheme (every CAN message needs a unique COBid) saves addresses for 127 nodes to each have 4 TPDO's and 4 RPDO's. If you are never using all the nodes, then you can set up those COB id's for the nodes you do have.
From my personal very limited experience with CanOpen it seems that it would not be the first choice for something very data or character intensive like an HMI unless the hardware on both ends was very customized to accomplish this. For remote I/O drops where there is a lot of bit data and maybe an analog or two it seems ideal.
I'm sure there are more people here with much more experience. If you are just diving into CANopen you should definately get yourself a book on the subject. The best book out there that is well worth the $40 is "Embedded Networking with CAN and CANOpen" by Pfeiffer, Ayre, and Keydel.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-01-09
Originally created by: Gast
Norm,
Thanx for the reply. Yes our network is quite simple however we have to be 100% canopen complaint. So, even though we really don’t need 127 nodes i would suspect that using the other COBids would not be possible for us. Is it? We are almost certainly going to need SDOs for some of the stuff that we have in the OD and the network traffic is such that the overhead should not be an issue. But, it would be sure nice to use pdos for most of the rest of the stuff......
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are using 3S solution on your system, then they also support Network variables. Network variable implimentation by 3S very interesting and can handle communication on producer-consumer concept. There are provisions for configuring various factors like transmit on change of state, cyclic, event based etc (almost similar to CANopen PDOs).
Try it. It might solve your problem. But.... it is again outside CANopen frmework and beautiful part of this is it co-exists with CANopen communication.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
4 PDO's for Tx are only reserved PDO's. You can have as many as you want. Although PDOs other than the first 4 are generally mappable through SDO messages.
The CAN Open spec leaves some undefined areas (I belive these include CAN ID in Decimal 1 --> 127, 256 ->383, 2027 -> 2047, 1664->1791) in their CAN mapping. (Quite Suitable for a Mapped PDO) (I believe Codesys Net Var's Occupy 1 --> 127, maybe more???).
Generally for large data packet transfer (i.e. text strings), people use SDO messages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Originally created by: Guest
I have a question about Canopen hope someone has an answer! Lets frist start with the facts so that we can confirm them as we go. We have 4 TPDOs and 4 RPDOs in each canopen node. Each TPDO/RPDO is mapped to some data in the object dictionary. Now since I have only 8 byte size packets I can only map 32 bytes of object dictionary data to all the available Tpdos/Rpdos at one time??? Is this correct? If so isn't this a serious limitation? How do we get around this? Thanx in advance
The 4 TPDO and 4 RPDO per node is the setup for a CanOPEN implementation. But, being open, you can really have anything you want so long as the hardware supports it. Also, you can always use SDO's to request/receive information. It is just that PDO's are more efficient. The default addressing scheme (every CAN message needs a unique COBid) saves addresses for 127 nodes to each have 4 TPDO's and 4 RPDO's. If you are never using all the nodes, then you can set up those COB id's for the nodes you do have.
From my personal very limited experience with CanOpen it seems that it would not be the first choice for something very data or character intensive like an HMI unless the hardware on both ends was very customized to accomplish this. For remote I/O drops where there is a lot of bit data and maybe an analog or two it seems ideal.
I'm sure there are more people here with much more experience. If you are just diving into CANopen you should definately get yourself a book on the subject. The best book out there that is well worth the $40 is "Embedded Networking with CAN and CANOpen" by Pfeiffer, Ayre, and Keydel.
Originally created by: Gast
Norm,
Thanx for the reply. Yes our network is quite simple however we have to be 100% canopen complaint. So, even though we really don’t need 127 nodes i would suspect that using the other COBids would not be possible for us. Is it? We are almost certainly going to need SDOs for some of the stuff that we have in the OD and the network traffic is such that the overhead should not be an issue. But, it would be sure nice to use pdos for most of the rest of the stuff......
Have you considered multiplexing your PDO Messages?
If you are using 3S solution on your system, then they also support Network variables. Network variable implimentation by 3S very interesting and can handle communication on producer-consumer concept. There are provisions for configuring various factors like transmit on change of state, cyclic, event based etc (almost similar to CANopen PDOs).
Try it. It might solve your problem. But.... it is again outside CANopen frmework and beautiful part of this is it co-exists with CANopen communication.
4 PDO's for Tx are only reserved PDO's. You can have as many as you want. Although PDOs other than the first 4 are generally mappable through SDO messages.
The CAN Open spec leaves some undefined areas (I belive these include CAN ID in Decimal 1 --> 127, 256 ->383, 2027 -> 2047, 1664->1791) in their CAN mapping. (Quite Suitable for a Mapped PDO) (I believe Codesys Net Var's Occupy 1 --> 127, maybe more???).
Generally for large data packet transfer (i.e. text strings), people use SDO messages.