Help with CAN OPEN protocol

I need to pull in CANOpen data into a PLC to use in another process. I have used 2 different devices to sniff the CAN bus for the data. The message is identified as 187 hex. One program just shows it as 187 the other shows it as s187n. After this identification there are 8 bytes of data that I need. With these 2 devices I can see the data.

I purchased a Gateway-300 CAN protocol converter from Renuelectronics (GWY-300). This device will send the data into an integer register in a format that I can use. The data I need is located in node 8 TxPDO1 index 2100. The problem is that nothing in the setup software relates to 187 in any way. The other 2 devices just pass through everything that is on the bus. This device appears to map the data and send it to my PLC. The dealer that I bought this device from does not have a lot of CANOpen experience.

Does anyone have CANOpen experience or a better idea? Nathan Boerger???

P.S. I am not looking for a quick easy answer. I knew this project was coming for a while and I have been studying CAN, CANOpen & J1939 for weeks. I thought this would be a piece of cake. Not the case. I have done research but am striking out.

Well, 187 hex should be the COB id for the first Transmit PDO from node 7. I have no experience with the hardware you mention but you said you have it set up for node 8 and 187 is for node 7 so that could be it right there...

Hi Norm,

Thank you very much for your reply. What else does the 187 signify if anything else? Where can I find more details about this?

From your description, 187 is the COB id or (Communication OBject id). Every message that gets thrown out on the can bus has a COBid to identify it. DS301 (Draft Standard 301) defines what these mean as well as everything else concerning generic CANopen. The fact that it is called a Draft standard does not mean that it is preliminary. It's a German thing where they can't call it a "Standard" unless it is part of German law which would be silly for CANopen.

A book I have found helpful is described here:
http://www.canopenbook.com/
Don't let the word Embedded in the title fool you. I is not a book about designing chips.

You can "order" copies of the specifications here:
http://www.can-cia.org/

If you can see the data you want with your CAN sniffer, then the device is obviously set up to send the information properly. You have to then look for the parts of the system that are looking at this data and trying to get them into your PLC.

Index 2100 in the data dictionary is not a CANopen defined area. 2000 - 5fff are for manufacturer specific data so I can't help you there.

I'm no expert mind you but I've read a fair deal on the subject.

Hi Norm,

Believe it or not I own a copy of that book. The info you refer to is on page 75 (I feel like an idiot). I am going out to the machine now to try out the settings for node 7 instead of 8.

If you can see the data you want with your CAN sniffer, then the device is obviously set up to send the information properly. You have to then look for the parts of the system that are looking at this data and trying to get them into your PLC.

Click to expand...

The 2 devices that I can see the data with are different than the one I am setting up now to actually do the transfer.

I'll let you you if I am successful. Thanks again for your help.

Simply changing the node number did not work. The setup software has a buffer labelled 2100. This matches the PDO index of 2100 but it may just be a coincidence. This TxPDO is 64 bits long but the input buffer 2100 is 16 bits long.

I've attached some screenshots that may cause a light to go off for someone. There are 2 pics of the 187 identifier and the data. Most of the other shots are of the setup software.

Not sure what you mean by the PDO index of 2100. There is a data type signified by 21 hex that is a PDO mapping parameter. Is this what you are thinking about.

Another question, The pictures show that the sniffer is still seeing cob id 187. This means that device 7 is still sending it's 1st PDO out on the can network.

What does your network layout look like? Looks like there are transmissions from Node 6, Node 7 and maybe Node 10....

Looks like 2100 is the index address into the data dictionary on the gateway device. Not sure how the data gets from the can into the gateway or how it gets from teh gateway to the PLC?

Network description. 5 Intercontrol Digsy Compact controllers. 1 CGC Graphic display. 2 Moba grade controllers. All of these communicate with each other on the CAN bus. I have no access to the network other than to sniff the bus. This is on a highway milling machine. I need to know the desired and actual depth the machine is milling on the right and left side. This information is the data in the 187 message and I can see it with the bus sniffers.

I have some information about the Intercontrol system from the machine OEM. This documentation says that controller 4 has a TxPDO1 index 2100 that has all the information that I am looking for. This document says controller 4 is address 8. I have to assume that node 7 putting out the 187 message has to be the Moba grade controller and possibly controller 4 is rebroadcasting it?

The device that I purchased claims to map PDO's and send them to an Allen Bradley MicroLogix1200 and many other PLC's. These are the GWY screenshots. I am having difficulty understanding how this device needs to be configured. They just added the CANOpen protocol recently to the J1939 for this device so the company selling it in the states is not much help nor is the literature.

I can e-mail this document tomorrow but it looks like this:

CONTROLLER 4 (address 8)

TxPDO1 2100 actleft desiredleft actright desiredright

Each of the above 4 parameters are 16 bits.

Can you see on the CGC what those values are so you can check vs. what you see w/ the CAN sniffer?

For instance, if the data is in fact in COB-ID 187 then the following would be the values based on PCAN View.bmp:

actleft FFFC (-4 Decimal)
desiredleft 0000
actright FEB6 (-330 Decimal)
desiredright 0000

Still not sure what the 2100 is?

Sounds like the devices are doing a bunch of peer to peer communications...

Are you sure the system is CANOpen and not J1949?

Yes the data is displayed on CGC. It is scaled some how. 2 hex values are the resolution i.e. behind the decimal point and the other 2 are the depth in inches. You cannot just convert from HEX to decimal, it does not come out right. BTW how did you arrive at your numbers? They may be close in mm.

The 187 does not appear on the bus until I operate the grade sensor. The numbers then scroll in proportion to the grade sensor movement. The other numbers scroll in relation to the actual value entered into the Moba controller. The grade sensor connects to the Moba controller also.

The data is definitely CANOpen not J1939.

Kyle Grathwol said:

Yes the data is displayed on CGC. It is scaled some how. 2 hex values are the resolution i.e. behind the decimal point and the other 2 are the depth in inches. You cannot just convert from HEX to decimal, it does not come out right. BTW how did you arrive at your numbers? They may be close in mm.

Click to expand...

If you look at your PCANView.bmp the sets of numbers after 187 are the data attached to that message. However, the byte orders are flipped. The data shown is:
FC FF 00 00 B6 FE 00 00
You said the data was four 16 bit values so those 4 values are:
FFFC 0000 FEB6 and 0000

Then I assumed each value was a signed 16 bit integer. Converting the hex values to decimal gives:
Negative 4, 0, Negative 330 and 0

You saved me some time figuring that out. Thanks. How did you know the bits needed to be flipped? I could see they needed flipped when viewing the live data and actuating the sensor but how did you know to do this without the live data?

I attached the screenshots that I e-mailed the device vendor. They may make more sense to you now. Let me know what you think.

My biggest problem appears to be mapping the PDO into the GWY-300 device correctly.

Kyle Grathwol said:

You saved me some time figuring that out. Thanks. How did you know the bits needed to be flipped?

Click to expand...

Page 93 and 94 of the Embedded Networking book. Also experience with disecting raw can messages before.

I think the source should be set to 7 as you suggested in the word document. If the data you want is in teh 187 message then I don't think you have to worry about the 2100 index. As I said before it is a manufacturer specific index and so you won't find out what it really means from anyone other than the company that made the device.

You just need to look at the 1st TPDO from node 7 and get that to where you want it.

Here's an observation for consideration / comment:

I've been twiddling around with Visual Basic lately, and learning a bit about object-oriented programming. Just prior to this, I was digging quite a bit into CanOpen.

The more I see, I get the impression that CAN, and it's red-headed step-child Devicenet, are physical implementations of object-oriented programming principles.

Thoughts?

TM

You just need to look at the 1st TPDO from node 7 and get that to where you want it.

Click to expand...

I totally agree and that is what I am working on now.
Based on the GWY screenshots, what would be your best guess as how to map this into the software?