That's correct, set the length to zero, change the mappings then set the length to the number of mappings.
Let's hope between us you can get running soon. The drive side is where my experince is but I'll do what I can to help.
OK, finally had a chance to spend some time on this again today, but I've not made any progress. I seem to be getting several conflicting sources of information. The CANOpen Solutions document that Dirk linked states that when the SDO Upload request is sent the first byte (command specifier) of the data has to be 0x40. That's fine, that's what the working code that I have does. But, the document then says that the server (in my case the drive) should respond with a first byte of 0x60. This is not what happens, I see the first byte having a value of 0x41.
Now, I can see (and keep in mind that this is the CANopencRIOSDODemo.vi I'm running) that the code is looking for the size of the response data in order to either perform an expedited transfer or a segmented transfer. In my case it's a segemented transfer. Once this is begun, the code alternates writing data with 0x60 and 0x70 as the first byte. Given the documentation that I have, this makes no sense to me at all. But, this is code that successfully reads SDOs like the manufacturer device name (SM-CANopen, index 0x1008), hardware version (UT77, index 0x1009), and the software version (Ver. 03.02.05, index 0x100A).
I tried changing my TxPDO mapping code to use a first byte of 0x23 instead of the 0x40 I'd been using, it still doesn't seem to be working.
I have lots of specs, lots of manuals, and they all say mostly the same things, but they differ on a few key points. Still stuck, rapidly losing hope.
So I spent half my Easter Sunday in the shop working on this gremlin-riddled thing, and I managed to make some fairly significant progress. What I found is that my problem is indeed (as Dirk said) the command specifier byte. The problem is that using 0x23 for SDO writes in mapping does not work. I after reading through some of the documentation, I went with a value of 0x29 for the mapping SDO Writes. I don't think this is entirely correct since writing a zero to 0x1802sub00 to enable mapping clearly has fewer data bytes than writing 0x200A2810 to 0x1802sub01 to map the Status Word to TxPDO 3's first mapped word.
So that's my big problem, how to correctly calculate the command specifier byte value for a given SDO Write.
Also, trying to read TxPDO 3 by sending a remote transmission request (remote frame) isn't working. I have not changed the transmission type, it still reads 0xFF, which is transmit on change of value. This may not be a real problem, since while I'm attempting to read the values I've mapped, they're static.
Big stride made, but still need some help!
No not correct if you do an upload (read) with 0x40 as the first byte your answer should have 0x43 as the first byte for an expedited transfer. The 0x41 is correct if it is just a normal transfer.
See the attached documentation for SDO to get an idea about how to calculate the first byte.
Dirk, I am indeed seeing a 0x43 as the first byte of the response for expedited transfers. The fact that the document said it should be a 0x60 is part of why I was so confused. I'll take a look at the file you just linked. Thanks.
OK, so issues with calculating the command specifier byte aside for the moment, I'm having another issue trying to map the RxPDOs. I'm getting an Abort SDO Transfer response and the error code translates to a data type mismatch. The parameter I'm trying to map is an signed 32-bit integer, but using standard CAN frames (recall I've got an NI 9853 module) all I can use is an array of U32. Am I dead in the water here?
Found an application note on the web that had a great explanation of the CS byte values. Problem with mapping the RxPDO is solved, now on to the next issue.
Well, hopefully this problem will be easy for someone to help me solve. I can map Tx and Rx PDOs, change their COB-IDs, and change their transmission type. The number of mapped objects will still read zero for any PDO that I map, but performing an SDO read of the mapped parameters will show that they're there and saved to the module EEPROM.
Yesterday I restored the module defaults, then mapped the status word and analog input 1 to TxPDO 1. I set the tranmission type to 0xFD (253d) which is RTR only. In my test VI, I have code to read SDOs, read or write PDOs, start and stop the node, and map Tx and Rx PDOs. I start it up and do an SDO read of 0x1008, which returns SM-CANopen. If I then attempt to read TxPDO 1, I get the last frame of the SDO read every time I try the read.
I've attached a screenshot of the block diagram of the Map TxPDO function. I don't have access to the system right now, so I can't capture any of the returned data.
I really hope someone can help, this problem is really exasperating!
Using sync messages (not sure if the controller supports this) is the quickest way and set the TXPDO data to 0x01, this will force the drive to send the TXPDO every sync message.
This will give you an idea if the mappings are good.
You can also try transmitting the data off a parameter change (I don't recall the tx type, but it's in the user guide).
If you are still reading back 0 for the number of mappings it implies there is an issue with the data or you have not written the number of mappings to the si 0 of the mapping you are configuring.