Category — CANOpen Adventures

How do you make a CANOpen motion control system move?  Your program creates the desired motions by sending the appropriate commands over the CAN bus using the vendor independent CiA 402 profile.

A CANOpen profile is a standard set of objects to interface to a particular device type, such as inputs, outputs, encoders, or motor drives.  A profile that is still being evaluated is called a Draft Standard; eventually it will become a CiA (CAN-in-Automation) standard.  So CiA 402 was originally called DS402, and is still often called DS 402.

Most CiA standards are available from the CAN in Automation web site for free by requesting the desired standards.  However, CiA 402 is not available.  I suspect the reason is that CiA 402 is now part of the IEC 61800-7-201 and IEC 61800-7-301 standards, and thus are only available from the IEC.

I was able to locate and download a copy of the older DS402 standard; there might be a few changes, but it should be good enough for my uses, and I also have the various manufacturers’ guides on how they implemented CiA 402.

Ease of use is one weakness of CANOpen.  I’ve been looking through DS 402 and although it may be well designed, it’s not easy to learn.  I think more vendors should do what Copley Controls does: provide a much easier to use interface that makes it much faster to get started with their drives.

Another approach is to have a motion controller that controls the CANOpen axes, such as the Schneider LMC (Lexium Motion Controller) series, the Elmo Maestro, and (for Ethernet PowerLink) the Balder NextMove E100.  In this case, your program interacts directly with the motion controller instead of the CANOpen drives.

A couple years ago I was looking for a distributed servo drive, and selected the Coley Accelnet Panel.  There are a lot of other good servo drives out there, but  I like a lot of little details on the Accelnet Panel ADP drives, such as:

• The ADP uses a standard fieldbus, CANOpen, so I’m not tied to a proprietary network.
• Copley’s free CMO software makes it easy to get started with CANOpen, assuming you can use COM objects.  Raw CANOpen has a substantial learning curve.
• The ADP uses HD (high density sub-D) connectors, so I can buy affordable, molded cables.  The HD connector is also robust; the MDR (Micro-D Ribbon) cables on the previous model (ACJ) are a nice idea, but I can’t get affordable cables for them, and they do not have same level of mechanical robustness.
• The ADP uses RJ45 cables for CANOpen, with isolated DC/DC converters, so it’s easy to daisy chain units using affordable cables, without having to worry about providing the right voltage to the CAN line driver.
• There are no cables used for normal operation coming out the top of the bottom; this fit our mechanical footprint much better than having to deal with cables coming out three sides (front, top, bottom).  (The serial port is on the top, but not used during operation).
• The serial port, used for setup, has fixed settings (baud rate, etc) so it’s also easy to communicate (I don’t have to start guessing at baud rate, parity, etc on an unknown servo drive).
• The CANOpen address is set via a hex (0->F) rotary switch.  I like being able to see what a servo drive’s address is at a glance.  DIP switches are second best; I can decode them, but it’s not as easy.  The worst is having the address set only using a serial setup port.  (Note: the ADP switch is actually on offset, but we always keep the offset at 0.  You can also ignore the switch).
• The ADP buffered encoder output is great, since we need to provide the encoder output to a custom board on about half the axes.  We don’t need to provide an encoder splitter, unlike in our older systems.
• Finally, 100% of the Accelnets I’ve bought from eBay have worked (and I’ve bought 7 ACPs so far), and that hasn’t been true for some other brands.

First Batch of PCBs (assembled)

I’ve been slowly working on a bunch of PCBs, and the first batch is finally here.

In the coming weeks, I will discuss each board in more detail, fill in the trac pages, and add the Eagle PCB files to my subversion repository.  I will also cover any mistakes I find, and possible improvements.

The initial lineup consists of the:

• FP-SMC-1, which is finally here!  It’s a demo board designed to show how to design a custom PCB to replace typical control cabinet wiring.  It connects a Panasonic FP series PLC to a SMC pneumatic manifold.
• CO-DB9-RJ45-2, designed to convert a CANOpen DB9 connector to dual RJ45 connectors.
• CO-HDR-RJ45, designed to convert a CANOpen terminal block header to dual RJ45 connectors.
• CO-M12-RJ45, designed to convert a CANOpen M12 connector to dual RJ45 connectors.
• CO-TB-RJ45, designed to convert a CANOpen terminal block to dual RJ45 connectors.

A Comprehensive Guide to Controller Area Network by Wilfried Voss, Copperhill Media, 2008.

Summary: 8.0/10,  recommended reading if you are developing systems using CAN or higher level protocols such as CANOpen.

The Guide is an affordable (<$15) book on the low level details of the CAN protocol.  It covers in detail the different frame types (data, remote, error, and overload), network arbitration, error detection and recovery, and data transfer synchronization.

The Guide points out undefined or ambiguous areas in the official specifications (Bosch, ISO, CiA), including updates based on experience (such as the CiA’s recommendation not to use remote frames).   The book concentrates on the base CAN protocol; it does not cover higher level protocols (such as CANOpen) in any detail, nor does it describe the specifics of CAN controllers or transceivers.

The book is well written; I’m an automation software developer, not a low level embedded developer, but I was able to follow the explanations without any major problems — I’d say it was easier to read than many software development books.

If all you want to do is get a basic CANOpen control system running, then you can skip this book.  But if you to truly understand CAN and what it can do, then I highly recommend reading both this book and Embedded Networking with CAN and CANOpen. Here are some things I learned from the Guide:

• How fast CAN really is  (data throughput, error recovery time, etc), including protocol overhead, for both standard and extended addressing.  Serial network protocols have a substantial overhead.
• Termination resistors have be able to dissipate at least 220 mW.
• Terminators should be at the network ends, not inside the CAN device.
• The details of error counting and error frames.  I had been wondering what the Copley CMO library’s ErrorFrameCounter property really meant; now I know.
• The meaning of the bit time segments  and how bit resynchronization works.  The Grid Connect (aka Acacetus) CAN-USB Light manual refers to the bit segments (sync_seg, prop_seg, phase_seg1, phase_seg2, SJW, etc) but didn’t explain them.  Now I understand bit segments.

The Guide‘s network topology recommendation (straight line topology with minimal stub lines with terminators at the ends) match what I already do.  I was happy to see the correct recommendation for shielded cables (connect the shield at one end only).

I do have some small nitpicks and suggestions for improvement:

• The book is repetitive; the exact same explanations with the same diagrams appear multiple times, as do various notes and warnings.  I find this annoying when reading the book straight through; however, overall, it’s probably good — when using the book as a reference, I want relevant warnings in the section I’m using, not just in one place in the book.
• The diagrams could be better explained; there is no key to explain the dark black lines (high line only means that field is always recessive; low line only means the field is always dominant; both high and low lines means field can be either depending on the message — maybe that’s obvious to hardware guys).
• The diagrams could be clearer: a bit larger with more contrast.
• OK, the book isn’t a comprehensive guide to CAN transceivers.  But I would have appreciated some warnings about common physical layer gotchas.

I am working on a series of CANOpen cable adapters.  For example, here is a model of a DB9 to dual RJ45  adapter:

CANOpen DB9/dual RJ45 adapter

I made sure it will work well with AMC DX15C08 Digiflex drives to convert the DX15C’s DB9M to two RJ45s.  The Phoenix header (in green) is for supplying power to the DX15C’s isolators.  Since I will probably make some more changes (for one, I don’t think there is room to screw the adapter’s DB9F to a DB9M), I am not posting the design files yet.

I have trac page up on connecting CANOpen devices with DB9M connectors to a RJ45 network.

I have a page up on my trac site about connecting CANOpen devices with RJ45 connectors, including RJ45 terminators and breakouts.

As I’ve mentioned before, Copley’s CMO is a set of COM objects that provide a higher level interface (than the raw DS402 profile) to Copley’s CANOpen drives.  Right now, I am starting to use CMO since I need to get my Copley drives up and running quickly.

So I installed the latest Ixxat VCI drivers (V3) and then verified my Ixxat USB-to-CAN compact was working by sending and received CAN messages.  I installed CMO 2.5, fired up MS Visual Studio, ran the Copley example, and got this exception:  Access is denied.  (Exception from HRESULT: 0×80070005 (E_ACCESSDENIED).  Hmmm.  I started VB6, ran the VB6 example, and received this error: Permission denied, which looks like another way of saying E_ACCESSDENIED.

I contacted Copley.  The answer: CMO V2.5 only supports Ixxat using the older (VCI V2) drivers.  In the future, CMO will support VCI V3, but not yet.

So then I try installing VCI V2 – and had problems communicating with the Ixxat (error 0x1F hardware error).  I contacted Ixxat, and went through their recommended procedure:

1. Uninstall VCI V2 drivers, then reboot.
2. Uninstall VCI V3 drivers, then reboot.
3. Run Ixxat’s VCI Clean program to clean up any stuff left in the registry and on the computer, then reboot.
4. Re-install VCI V2 drivers.

Even after that procedure, I still couldn’t get the VCI 2 drivers to work.  I suspect it might be a problem with Windows and my particular USB controllers, but it’s not worth troubleshooting since the Ixxat is working fine with the VCI V2 drivers on a nearby computer.

In the future, I’ll install the VCI V2 drivers first, then VCI V3 (normally you can switch between them).

Ixxat, Acacetus, and Peak CAN Interfaces

I now have three CAN interfaces.  I plan on doing tests on all three to measure their performance.

The Acacetus (also sold by Grid Connect as the CAN USB Light) is the least expensive ($100).  It communicates via a virtual COM port.  So far I’ve used HyperTerm to communicate with it, which doesn’t work well (binary data isn’t intelligible, etc).  Using a serial library should work better.

The CAN and virtual COM port settings are accessed by resetting the device, and then going through a series of menus.  The CAN baud rate isn’t set directly; instead you set the various detailed parameters; fortunately, I found a handy table, but I much prefer Ixxat’s approach (pick the baud rate, and then tweak if you want).

So far, it works, but doesn’t seem in the same class as the Peak or Ixxat – it doesn’t feel as well built, and is more limited (e.g. can’t set baud rate remotely).  It only comes with driver software.

The Peak is a parallel port dongle; I much prefer a USB connection, but I didn’t pay for the Peak.  It has a keyboard pass-through connector to provide enough power.  It is sold in the US by Grid Connect and Phytec for $249.  The Peak USB to CAN is $279, but is worth the extra money.

The Peak interfaces come with PCAN Light driver, and PCANView which is a simple program to send and receive CAN messages.  The extra cost, advanced driver has some nice features, such as sharing a CAN interface among multiple applications.

Right now, the Peak is handy because I have PCANOpen Magic Lite for it (it was included with the CANOpenIA-XA kit I have), which provides some basic CANOpen functionality.  It has many restrictions; for example, it only supports CANOpen address 0×40 to 0x4F, so I had to remap my Copley drives to this address range.

The Ixxat USB-to-CAN compact is the most expensive ($335 from CAN Connection).  It comes with drivers and some helper programs, including one similar to PCANView, but does not include any CANOpen specific software.  I talked about it in my previous post.

Comment 8/24/2011: I now have a lot more CAN interfaces, including models from Kvaser (PCI and USB), esd electronics (PCI), and Applicom (PCI).  I really like both the Ixxat USB to CAN compact and Kvaser Leaf Light. 

Ixxat Box

I recently received an impressive blue ESD safe box.  Inside was the  Ixxat USB-to-CAN compact interface which I had ordered from the CAN Connection store.

So why spend the money on the Ixxat when I already have two CAN interfaces?  Software support.  I decided I needed a CAN interface which is supported by the manufacturer’s setup and tuning software.

I like USB to CAN interfaces – I do not having to open up my computer to plug cards in (although I do wish USB connectors could lock – it’s very easy for them to become disconnected if I have to move my computer around).  I’d like an Ethernet to CAN interface even better, but the only semi-affordable ones I know of are the Anagate CAN interfaces (about $300-$450), which are only supported by CANFestival (but not by AMC, Copley, Elmo, etc).

Only Kvaser and Ixxat CAN interfaces are supported by all of the CANOpen servo drives I own (AMC, Copley, Elmo), so I decided to buy either a Ixxat USB-to-CAN compact or a Kvaser Leaf Light.  I decided to buy the Ixxat because:

1. I like the Ixxat physical arrangement better (only the USB cable is permanently attached).
2. Kvaser currently does not have a CANFestival driver, which is very important since I plan on using CANFestival.
3. Faulhaber and Maxon support Ixxat but not Kvaser.

Ixxat USB to CAN compact

My Ixxat does have a quality feel to it, and unlike many CAN interfaces, does pack substantial processing power (a 24MHz Infineon C161 with 128K SRAM and 512K flash).  It is available with either a single RJ45 or single DB9M connector.  I choose the DB9M version since my other CAN interfaces use DB9M connectors.

Right now I am using the Ixxat with the Copley CMO COM library.  One quirk – Copley supports Ixxat in their CMO and CML libraries, but not in CME2 (Copley’s setup and tuning application).  Copley supports Kvaser in all three.

CME2 is needed to setup the drives.  The CAN baud rate has to be set from CME2, as well as the amplifier settings such as Hall sensor settings.  However, it’s easy to connect using the Copley’s serial port and a properly wired RJ12 to DB9F cable.