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
