21

We have a robot project where the motor controllers use CANopen for communication. I need to communicate with these motor controllers using a master microcontroller. The problem is that I need to develop a CANopen layer in this microcontroller, but I only know how to send and receive at the low level (CAN).

I don't know much about the CANopen (PDO, SDO, Heartbeat, object dictionary, etc.). I tried to read the CiA specifications, but it was very complicated. I would appreciate it if someone could point me in the right direction or give me a good tutorial to program a simple CANopen layer.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
  • Have you seem the other questions about canopen, http://stackoverflow.com/questions/tagged/canopen (nothing obviously helpful, but who knows...) – Johan Aug 05 '09 at 11:35

7 Answers7

13

Since this seems to be a topic of general interest - I agree that understanding the full original specs can be a somewhat painful experience. So here is a suggestion for "get your drive going", as opposed to "implementing the whole thing":

  • Check if your CANopen drives can be operated via the CiA 402 standard objects and for performance reasons it would be perfectly fine to NOT configure and use PDOs, and you don't really need heartbeat, a.s.o. It's usually switching the drive's state machine (object 6040h, control word), setting operation mode (object 6060h), and setting additional parameters like "profile position velocity".

  • Then implement expedited SDO transfers only. (See http://en.wikipedia.org/wiki/CANopen.) SDO download is for writing/changing an object in your drive. SDO upload is for reading an object.

  • I suggest to take a PC software that can read and write SDOs and has a CAN Bus Monitor. (Our Kickdrive Zero freeware can do that, but really, any other PC tool for CANopen should work.) Do some example reads and writes for the data types and objects you need. Look how this translates into frames on a CAN level. For basic integer data types, it's always just one frame for the request, one for the answer.

  • Now build a simplistic protocol stack on your microcontroller that can send the SDO download/upload requests and process the answers.

Disclaimer - the above is not even close to "implementing CANopen", or "supporting CANopen", or even "CANopen compliant". It's about "make your drive move ASAP and without third-party code". Which is sometimes the right thing to do.

Oliver Heggelbacher
  • 732
  • 5
  • 10
  • I found to be fundamental also the implementation of TxPDO to avoid polluting the bus with periodic SDO requests. At the end the mapping is a fistful of SDO write and you can just parse the TxPDO packets you expect. – ntd May 09 '17 at 23:09
  • I see your point, but I believe it depends on the application. The original question was about "isn't there a simpler way?". I don't count PDO mapping and its configuration via SDO to the simpler aspects of CANopen. It all depends on your amount of nodes and the cycle times you really need. – Oliver Heggelbacher May 16 '17 at 12:02
  • Well, the PDO mapping itself is quite easy (4 or 5 SDO writes). IMO the handling of the response is much work but (again IMO) comparable if not less than an SDO polling loop (after all you definitely want to get inputs). And this is exactly [what I did](https://sourceforge.net/projects/lv-canopen/) in a CANopen library for LabVIEW. – ntd May 16 '17 at 14:38
  • 1
    Wow, ntd, thanks for the link to your CANopen LabVIEW library! This looks very interesting! – Oliver Heggelbacher May 24 '17 at 10:49
4

We have implemented our CANopen layer from scratch for both embedded ARM and Windows PC devices. It's not impossible, unlike previous answers might make you think. If you need only basic functionality of CANopen and can quickly learn the concepts of the protocol, you can get things up and running rather quickly.

You will have to read CiA specification, there is no way to avoid it, but at first it might turn out to be somewhat overwhelming. I recommend that you start by reading "Embedded Networking with CAN and CANopen" by Pfeiffer, Ayre and Keydel. It explains the basic concepts nicely, which in turn helps understanding the specification better.

tshepang
  • 12,111
  • 21
  • 91
  • 136
Alex
  • 1,574
  • 17
  • 36
  • 1
    Yes you can implement most things "quickly" yourself. But as some people have already pointed out if you want a standard compliant implementation, that can interact with other standard compliant CANopen nodes, then it will cost you less to buy a commercial stack than to write it yourself. – Simon Byholm Mar 10 '14 at 08:57
  • 1
    If you are working on an open-source, educational or non-profit project there is also two open source CANopens tacks that are completely free to use. Search for CANFestival and CANopenNode on Google. – Simon Byholm Mar 10 '14 at 09:07
  • @SimonByholm CANfestival is [LGPL](http://dev.automforge.net/CanFestival-3/file/tip/COPYING) and CanOpenNode is under [GPL with linking exception](https://github.com/CANopenNode/CANopenNode#gpl-linking-exception), so both can be used in commercial projects. – ntd May 26 '17 at 08:23
  • @ntd LGPL is problematic on many compact embedded systems as everything is statically linked. – Simon Byholm Jun 27 '17 at 14:02
3

Try using the CanFestival stack - it's free, and it ports easily from OSes like Linux down to bare machines that just have a tick timer.

4-6 months seems a bit of a stretch - you may only need a master or a slave, and we did a master-only implementation in C++ in 3-4 weeks.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Larry_C
  • 316
  • 1
  • 9
1

Unfortunately, there is no simple CANopen layer. To support CANopen, you have to implement the whole thing.

I suggest you buy a CANopen library from a third-party vendor. Usually they're not cheap, but considering the time you would need to implement this yourself it's cheaper than your salary for that time.

We've been using PORT GmbH's ANSI-C CANopen Library library, which is moderately priced and has very few bugs, compared to other libraries we tried.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Stefan
  • 43,293
  • 10
  • 75
  • 117
1

We're using the MicroCANopen stack with the Manager add-on, from here: http://www.canopenstore.com/pip/microcanopen.html

It's relatively cheap compared to other stacks, although we're using it on all nodes in our network so I can't offer a testimonial as to how it operates with other CANOpen-compliant devices.

Jason Machacek
  • 994
  • 1
  • 8
  • 18
0

If this is something commercial I would not consider implementing CANopen. This is going to take you (even for a subset) somewhere between four and six months (if you actually want it to work). I don't know what your salary per hour is and what your time to market requirements are. You need to do the maths yourself.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
robert.berger
  • 13,211
  • 1
  • 16
  • 6
0

Another commercial solution I worked with is IXXAT's CANopen software. They offer ports for many different platforms.

As already said before: you don't get it for free nor is it cheap. But what are a few thousand USDs compared to several months of development time?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
chrmue
  • 1,552
  • 2
  • 18
  • 35