CanOpen

[Volker]

Hello,

I need to add an Can open absolute encoder to a MC012 Controller. Do anyone know how I can get the position of this encoder?

I have integrated the Encoder in my hardware but I can't find it in the service tool. Normally the encoder sends cyclic his position but with the Can King from Sauer-Danfoss I see no communication. Do I need other Protocol file's?

Best regards

Volker

[Neil]

Hi.

Have you tried with a 125kb setting?

Neil

[Volker]

Hi Neil,

i had the correct settings for the encoder and the controller. The encoder have 125K Baudrate and the Node ID 6. Stefan from the Helpdesk said that i have to send a Message with ID 0 and 1 in the first byte to start the encoder.
It doesn't work with a message generated in Plus+1 but with a message out of can King it worked perfectly.

Thanks to all for the help.

Best regards

Volker

[Niska]

Hi Volker.

I have a working system that you can look at. I am using a Kübler encoder type F3688.

[Rafal_Typiak]

I have a question concerning CANOpen. I'm fresh with this. I was only using a simple CAN communication till now but I also have to integrate a CANOpen encoder into my system and was wondering if someone could help me out with the principles of CANOpen. I've read that I need to send a CAN message with '1' in byte0 and send it to device with 0 ID (I’m guessing the ID 0 is a factory setting). Is there a command that makes the encoder continuously send data about its position?

Rafa?

[Neil]

Hello Rafa.

the CAN message you refer to is a global start message, or you can start individual nodes, such as 10,11,12,13 shown below.
change byte 0 to 2 and you can stop the nodes. After the receipt of a start command you may see a heartbeat message from the nodes if they are set up to transmit a heartbeat. CANopen is structured with indexes and sub indexes. There is usually a EDS sheet that accompanies the CANopen device see attached.

You have to poll the devices for information

// Start All Nodes

 0    00000000         2  01  10                            8798.156380 T
 0    00000000         2  01  11                            8832.252510 T
 0    00000000         2  01  12                            8848.661020 T
 0    00000000         2  01  13                            8875.416860 T

If you look at the message below, I'm asking a PVE-CX for its serial number
Node 6(10)
byte 0 = 40 request
the index is 1018 (so LSB first ) byte 1 =18 byte 2 =10
sub index 4 byte 3 = 4

// PVE_CX Serial Numbers

0    00000610         8  40  18  10  04  00  00  00  00    9908.597470 T
> Response from node 10 is
 0    00000590         8  43  18  10  04  6B  AC  32  45     287.544860 R
The first four bytes confirm which index and sub index the info has come from. The next four bytes is the info I'm interested in
ie 4532AC6B

I hope that helps a little.

regards Neil

[Rafal_Typiak]

@Neil,
Thanks a lot for that info. It helped to answer a few questions. But is there a way to force encoders to send data at set intervals without the need to poll data? This question refers to the CANOpen standard, not a specific device, as I'm aware that some manufacturers may implement that on their own accord.
Another question I have is, is there a universal command to poll data from the device?

Rafa?

[Rafal_Typiak]

Hello,
If I could take moment of your time again I'd be grateful.

Here's the thing. When I send the 'wake up' command [Id:0, Bytes=2, B0=1, B1=0]

0           0         2   1   0                            7170.537180 T

I get the following response from my absolute encoder:

0         447         4 236 149   2   0                    7170.537700 R
0         959         2   0   0                            7170.538020 R

The IDs 447 and 959 in CANOpen standard refer to not only the device's ID but also the type of data transmission - whether it's a PDO or an SDO.
I've converted the ID to binary and got:

447 = 0001 1011 1111
959 = 0011 1011 1111

than I've divided the binary into ID and transmission type
ID=63
Type = PDO1tx and PDO3tx (this I believe is still CANOpen standard compliant)

If everything till now is correct, here are my questions.

PDO1 should have data regarding encoder's position data [Byte 0-3] and flags [Byte 4]
while
PDO3 should have just position data [Byte 0-3] (still CANOpen compliant?)

if so, than how do I get this data out? How should I read it to get my position? Is this the place where the indexes and sub-indexes come into play? If so, than I have this table in my datasheet:

Communication parameter

Index   Name                                           Standard val

1800h   TPDO1 Communication Parameter   
01h           COB-ID                                      180h+Node number
02h           Transmission type                      255 (asynch)
03h           Inhibit timer                              0 [steps in 100?s]
05h           Event timer                              0 [steps in ms]

1801h   TPDO2 Communication Parameter   
01h           COB-ID                                      280h+Node number
02h           Transmission type                      01 (synch)
03h           Inhibit timer                              0 [steps in 100?s]
05h            Event timer                              0 [steps in ms]

1802h   TPDO3 Communication Parameter   
01h           COB-ID                                      380h+Node number
02h           Transmission type                      255 (asynch)
03h           Inhibit timer                              0 [steps in 100?s]
05h           Event timer                              0 [steps in ms]

Now what are those indexes and sub indexes?
Do 01h 02h 03h 05h refer to bytes?
 
Data from the ID 447(dec) was
236 149   2   0
this data is in decimal values. In no way does it fit with the presented table. I've tried subtracting ID=63 from Byte 0 [236] to get the 180 or 280 or 380 but to no avail. Maybe this is not the PDO1 data at all?

If anyone will have the time to look into my predicament, I'd be really grateful for help.

Rafal

[FluidPowerTom]

Rafa,

I'll preface this that I've only used CANOpen on one project, but it was with encoders and was fairly involved.

Getting the data out will likely not require any concern with sub-indices per se.  Identify the address that your process data is getting transmitted with, and use that with the CAN Receive function block.  The data, which is spread out in multiple bytes, can be combined using the 'Combine' function block in the 'Data Conversion' section.

Sub-indices are entered into your CAN message structure as part of one of the data bytes.  Somewhere in the encoder documentation it probably shows message structure something like this image:


Also in your encoder documentation should be a list of Commands, Indexes, and Sub-indexes

Using that structure you just fill in the ID and the data bytes as shown.  The COB-ID is going to be maybe 180h+node# or 280h+ or 380h+ depending on if you're interested in PDO1, PDO2, or PDO3.  The Command will depend on if you're sending data to the encoder or telling the encoder to send you data, and it may also vary depending on the length of the data.  Index is basically the parameter that you're interested in, and the sub-index identifies what aspect of that parameter you're interested in.  For example, sub-index 2h for PDO1 (Index 1800h) may control whether or not PDO1 sends data synchronously or asynchronously while sub-index 3h of that same 1800h Index may control an inhibit time on the PDO1 data transfer.  As shown in the above message structure, the Index and Sub-index go into what you might typically use as your data bytes.  Finally, at the end of that structure is the Service Data which for in something like commanding inhibit time on PDO1 you would put in those bytes the desired inhibit time.

Look through your encoder CANOpen manual to correlate this stuff.  Log into your CAN sniffer and see what works.  Doing stuff like commanding an inhibit time or synchronous data transfer requires a sequence of commands to put the encoder into a certain state and then save and reset the encoder when you're done.

Thanks,