Thanks for the input, I've fixed my SDO Reads so that I now get the correct values back (as I used to, and the same as the example SDO Read VI does). I had left a Write CAN 0 Boolean in the wrong place, this was a holdover from a different version of the FPGA VI I tried. At any rate, at least the most basic stuff is working.
Right now I'm attempting to configure TxPDO 3 to map to a couple different parameters. I'm not quite sure that I'm building the Data Array correctly, and I can't figure out why in the example VIs Byte 0 is set to 0x40 by default. Now, this seems to work, I just don't understand why.
So I am setting Index 0x1A02 (my drive's TxPDO 3 which is the second TxPDO) Sub-Index 0 to 0x00 to enable PDO mapping. I am doing this using the WriteSDO VI from the example project, wiring 0x1A02 to the Index terminal and 0x00 to the Sub-Index terminal. The next part is where I'm getting confused. I think that I need to write to 0x1A02sub0x01 and the Data Array should be the parameter I want to map. In this case that should be 0x200Asub0x28. So, do I need to include that default Byte 0 0x40? Do I break 0x200A2800 into eight U8s for bytes 0 - 7? Do I use 0x200A0028?
I feel like I'm very close to cracking this, but I'm not quote there.
To set up the PDO mapping, subindex 0 of the index 0x1A02 need to be set to the number of parameters you are mapping. Subindexes 1 and onwards of index 0x1A02 will contain the information about which parameters you want to map. So, if you are trying to map index 0x200A, subindex 0x28, you would write 200A28xx as the data field to object dictionary item [1A02h, 01h], where xx is the length of the field. This would map the entry at index 200Ah, subindex 28h, of length xx to the first xx bits of the 1A02 PDO.
I would recommend that you take a look at this resource on PDO mapping - go to the PDO Mapping section, about three quarters of the way down the page. In this section, there is a great diagram of an object dictionary with PDO Mapping implemented. It shows the PDO Map (at index 1A00h) and the items being mapping (indexes 6000h and 6401h).
Thanks for the quick reply! I changed my code to write 0x200A2816 to use a 16-bit length. I set the other parameter length to 16 bits, also. I had not been storing the parameters I was mapping, but by writing to 0x1010sub01 with a 0x65766173 data array value, I believe I should be storing the mapped values.
But, when I execute a PDO Read of TxPDO 3, I only get zeroes back. There are a few places in the code where that default 0x40 for byte 0 (in the data array) is still used. Do you have any idea what the significance of that 0x40 is? I don't know if what I'm doing by setting that Byte 0 to 0x40 (or 0x0) is correct or not.
I've attached a partial screenshot of my code, it's a wide block diagram since I haven't created subVIs yet. It shows the bulk of what I'm doing.
The h40 is just the command byte 0 of a master reading from a slave. The exact calculation is somewhat complicated and available from the canopen spec. The command byte for writing from a slave is h23.
So I guess you did a read instead of a write?
More information can be found here: http://www.canopensolutions.com/english/about_cano
So the default 0x40 is correct for SDO Writes? In other words, in my code (see screenshot) I should always have that set to 0x40? I'm not sure I understand what you mean by "writing from a slave", but then again, I'm not sure I need to.
I'm going to change my code to use the Write SDO VIs instead of the way you see it now. I'll create the data arrays as shown, but now that I know how to do that (assuming the Endianism is correct), I can use the subVIs. I'll let you know what happens.
Still no luck. Mapped TxPDO 1 to allow me to write the Encoder Lines/Revolution parameter, and while the mapping code gave me no errors, a subsequent PDO Write to change the parameter to 2048 (default is 1024) yielded no results.
I have to be missing something very simple here, but I've no idea what it might be.
just to clarify when configuring the PDO you need to set the length to zero in SI 0, this allows you to write the other objects, once setup write the length (number of mappings) to si 0. Think of it as a sort or write enable system.
This should allow you to change the mappings to what is needed.
eg. 0x2mmmppss gives a mapping of the menu in mmm (hex) parameter pp (hex) and size ss (eg x20=32 bit x10=16 bit)
For example 0x20141520 maps to parameter 20.21 which is a 32 bit parameter.
ARGH! I was setting the length in decimal, not hex! Thank you!
I have been setting the sub-index to 0 prior to the mapping writes, then writing the number of mappings to sub-index zero after the writes. Are you seeing something in my screenshot that is showing you that I'm doing something incorrectly in this regard?
Well I think there is a little bit of a misunderstanding here. Your Write SDO function probably is the same request from the Master for either a write or read request. You would then have another Read SDO function that would read either the requested information from the read request or the status for the write request. But the first byte of your write SDO request has to be 0x40 for read requests and 0x23 for write requests. So again it seems you are using the wrong command byte.
You can find all this information by reading the CANopen spec. ;-)