CANOpen Library - Limited number of PDOs ?

[Balaboum]

Hello,
 
 
Here's my story :
 
        I have a CAN network grouping 13 CANOpen nodes ( motors, I/Os, pneumatic valves ) and a NI pcmcia adapter in my PC. I use LV 7.1 and the CANOpen library to build a nice application to automate all this.
        For each of 10 of this nodes, I declared ( and I need ) 2 RXPDOs and 3 TXPDOs.
 
        Actually, I am facing an error message ( PDO create from CANOpen library ) saying that I've reached the software/firmware memory limit ( of the pcmcia board I suppose ) and that I should reduce the size of the PDO queues or reduce the number of CANOpen objects... For each PDO, I set the buffer size at 2 frames which is not a lot in my point of view. I cannot reduce the number of CANOpen objects because I need them...
        What is the exact limit with my hardware ?
        Can my configuration handle 4 TPDOs and 4 RPDOs for each node ( in case I'd like to ) ?
 
Another question :
         In my LV code, I created a cluster for each node storing a SDO handle ( CANOpen object ), 4 RPDO handles and 4 TPDO handles. I initialize them calling "create SDO" and "create PDO" at start up if I need them otherwise I let them to a default value (0). What do you think about this ? Can this be the source of the error message ?
 
 
Thanks in advance for your answer
 
 

[DirkW]

Hi,
 
The CANopen Library is based on the NI CAN driver. Because of the tight timing needs for SDO communication and the need to send periodic frames some library functions are using objects for communication. Objects are able run directly on the hardware, thus they can meet these strict timing issues. The bad thing is, they are limited in number to 50 per NI CAN device. That includes one per Port configuration, thus for a 2 port board , if you configure both ports there are 48 objects left for both ports together.
 
The second limitation applies to the shared memory between board and driver. The driver can configure approx. 300 messages for queues for the board, shared between 2 ports if available.
Now if you know this you can calculate the number of SDOs and PDOs you can configure until the mentioned error occurs.
Ok , you are right, we need to know how many messages the particular functions configure for queues.
Thats something we find from the NI SPY. The Tool gets installed with NI CAN and allows you to log all API Calls to certain drivers including NI CAN.
The configuration api call tells us from the buffer page the size for Read and Write Queue configured with property 80000013 and 80000014. If you switch to AttrPtr. you can see the qeuesizes in hex at the same location.
Now you can see that the CANopen Interface Create allocates 100 frames for the read Queue and 10 Frames for the Write Queue. This numbers are used to read all incoming frames and write all nonperiodic frames which are not configured with objects, like the NMT commands or RX PDOs.
The SDO create takes internally 10 frames for the Read Queue only, because it needs to buffer the answers only.
The TX PDO is created as an object but does per default not use any queue internally . But as you mentioned, you can configure a buffer size, which is the same queue.
 
That means it is highly recommended to use one port devices or one port only for a 2 port device only, because you need 110 messages for the port configuration already.
For SDOs i would recommend to close the handle if you have used the SDO and do not need it anymore. That frees the memory (10 messages ) for other operations.
For PDOs i would recommend to use buffer size 0. That means you allways read the most recent value. I never needed a queue for my applications, but thats somewhat your decision. Within the configuration cluster you find the rx or tx PDO List control. This List triggers internally the COB ID you are using for the PDO. We configured four in each direction because it is likely that you canopen node uses these IDs which often are mapped by default.
But if you need more then 4 PDOs you can use tx PDO 1 for example more then once, but you have to enter a valid COB ID by your own. That overwrites the default COB ID.
See the attached example for LabVIEW, for details.
 
But back to your problem: Lets calculate, which limit you reached first. 10 nodes with  3 Tx PDOs and 1 SDO. Here are the numbers: 60 messages and 30 Objects for the PDOs 100 messages and 10 objects for the SDOs and the Port configuration with 110 messages and 1 object.
Thus you have 270 messages queue size and 41 objects.
Thats not really the limity but it is near the limit and likely to cause the error with the next configuration step.
I would  recommend the following:
1. use one port only.
2. close SDO handles after using them.
3. use PDO buffer 0.
 
Or use multiple boards . ;-)
 
Hope that helps
 
DirkW
 
 


Write and Read PDO Network Mapping71.llb:
http://forums.ni.com/attachments/ni/30/2357/1/Write and Read PDO Network Mapping71.llb

[Balaboum]

       I didn't expect the ressources to be so limited but that's life...
 
So, if I followed you correctly :
 
For SDOs, instead of having one SDO object for each node, I can have a common one which will be reconfigured ( opening with different COB-ID and closing after use ) each time I want to send SDO frames to a particular node.
So, I'll use only 1 object and 10 messages instead of 13 objects and 130 messages... Yes, sounds logical...
 
The Sync, hertbeat or emergency objects also consumes messages. Is there a manual or withepaper resuming the object/message consumption for each function ? ( This may make your answer a little shorter... ;) )
In my case, I use the sync message to get a TPDO regularly. But now, I can imagine to use the event timer feature instead to get same information.
 
If I am correct, CANOpen devices allows to concatenate several mappable dictonary objects in one PDO. This may also be a solution to reduce objects and messages consumption.
 
Now, I have a more clear view of what is happening and how things work. I will correct my code accordingly.
 

As we are speaking about the SDOs, some devices ( like axis ) offer the feature of group node ID. This ID is virtual and is used to send several nodes same CANOpen frame. However, CANOpen write SDO function expects to get an answer from a node otherwise it times out and can abort a SDO transmission longer than 4 bytes... With this virtual ID, the function gets answer from each node inside the group but no answer with the corresponding COB-ID. Is thera a way to tell thefunction to not care about answers and just to put frames on the line ? In my case, I configured the SDO object with a calculated COB-ID using the highest node-ID within the group of axis.
 
Thanks for your time and input.

[DirkW]

Hi,
You can easily find the queue sizes if you use the NI SPY to log the api calls, as described above in my first reply. It is likely that all these sync and heartbeat functions have a queue assigned because they are timecritical.
And yes you could change to an event triggered mode for your Tx PDOs.
The VI i attached to the last post shows how to use this mapping feature with WAGO modules.
This WAGO CANopen  module is grouping multiple DIO and AI and AO modules together as you mentioned and has only one node ID. But it acts as one instance and replies only ones to an SDO request. I have never seen such a grouped device you are talking about. I doubt that this is CANopen CiA conform?
DirkW

[Balaboum]

       Hello,
 
 
       The object I am speaking about is named "Coordinate system group ID" at index 0x2040. It is defined in the Cia DS301 in manufacturer-specific object section. In my case, it is implemented in a brushless motor driver. That may explain also why you have not seen it in the devices you used. I have to check if this kind of object exists in motor driver from other manufacturers. As it is manufacturer specific, I have no doubt about compliance with Cia.
       Of course, when you use this "virtual ID", each node in the group will answer with its own ID. I have noticed that if the send SDO function do not get the corresponding answer, it aborts the transmission in case of data length higher than 4 bytes.
        But the CANOpen library function allows to enter another COB-ID for reception than the default. So, I always enter a COB-ID calculated using the highest node-ID of my group plus 0x580... It works fine...
        Thanks for the info about NI-Spy. I will consider using this tool more often than before. However, I think that the limitations of the NI-CAN should appear more clearly in the documentation. When you design system architecture with several nodes, it is a key point for your entire project.
 
 
                                                                                                                                          Regards.
        

[can we generate frequency using counters . if so then what is the range and resolution.]

Hello
 
I apologize for posting in between. I was not able to start the new thread.
 
I am new to the CANopen PDO. I have read a lot of documents on PDO but still the concept is not clear. Kindly tell me how to start and stop the PDO communication using Labview 8.
 
Regards
R