Merging modern software development with electrons and metal
Random header image... Refresh for more!

Category — CANOpen Adventures

CANOpen Monitoring and Power Board


I created the CO-RJ45-PWR so that I can easily monitor my RJ45 CANOpen network and, if needed, provide power to CAN_V+.

My Trac site has the details, and this post has the background information.

Since all of my other adapters provide CAN_V+ connections, I doubt I’ll use that capability often.  I’ve already used the board several times to investigate CAN buses.

I used this board to try out Phoenix Contact’s PST/PT series of removable terminal blocks.  The main reason I used them is the pin-strip header makes a great connecting post for grabber-type oscilloscope probes – but if you want to use discrete wires, just plug in the screw terminal socket.

The PT terminal block sockets are  very affordable, and some models, including the one I choose, can be mounted in three different positions.

On the down side, the polarized pin-strip isn’t readily available (so be careful when plugging the socket into the header) and the socket is only available with screw terminals (I prefer spring clamp).

March 29, 2012   No Comments

CANOpen Terminal Block to 2xRJ45 Adapter Board



The CO-TB-RJ45 connects a terminal block to 2 RJ45 jacks, with optional, flexible connection to CAN_V+.

My Trac site has the details, and this post has the background information.

I created this board so I could connect anything to my RJ45 CANOpen network.  Since I’ve always liked the flexibility of removable terminal blocks, I used them for both the CAN and V+ terminals.


March 27, 2012   No Comments

CANOpen M12 To 2xRJ45 Adapter Board

CO-M12-RJ45 connected to a Festo CPV10-GE-CO-8

CO-M12-RJ45 connected to a Festo CPV10-GE-CO-8

The CO-M12-RJ45 converts a standard CANOpen M12 device connector to 2 RJ45 jacks, with an optional, flexible connection to CAN_V+.

My Trac site has the details, and this post has the background information.

I created this board to make it easy to connect my Festo CPV10-GE-CO-8 and my Norgren VM10  pneumatic manifolds to my RJ45 CANOpen network.  These manifolds use a 5-pin M12 circular plug connector with type-A polarization for the CANOpen connection.  They do not require power on CAN_V+, but I included connections to CAN_V+ in my design in case I need it in the future.

So far I’ve discovered one big issue with the board: the connector is a bulkhead connector.  It needs a panel with the proper sized cut-out to mount the socket’s threaded nut which fits on to M12 plug’s threads.  The picture above shows the missing locking nut on the board while the power cable’s locking nut is clearly visible on the right.

As far as I can tell, all the right angle PCB M12 socket connectors have the same issue.  Right now I’m just letting the M12 socket rest in the M12 plug, but that’s not very secure.  If I need a secure setup, I’ll try to rig up some kind of a hack to hold the nut to the board.

March 22, 2012   No Comments

CANOpen Terminal Block Header to 2xRJ45 Adapter Board

CO-HDR-RJ45 Mounted On A Wago 750-337

CO-HDR-RJ45 Mounted On A Wago 750-337

The CO-HDR-RJ45 converts a standard CANOpen 5.08mm terminal block header to 2 RJ45 jacks, with optional, flexible connection to CAN_V+.

My Trac site has the details, and this post has the background information.

I created this board to make it easy to connect my Wago 750-337 and Beckhoff BK5150  CANOpen  K-bus interfaces to my RJ45 CANOpen network.  These interfaces use a 5-pin 5.08 mm terminal block header for the CANOpen connection.  They do not require power on CAN_V+, but I included connections to CAN_V+ in my design in case I need it in the future.

So far I’ve discovered one minor issue with the board: the Phoenix Contact inverted header I used does not perfectly fit the Wago header used by the 750-337.  I had to break off one tab; if you look at the picture above, you can see that the top Phoenix tab does not line up with the cut-out for the top tab.

I typically use Phoenix Contact terminal blocks over Wago because they are much more readily available from my favorite catalog distributors, Mouser and Digikey.

I also have a Wago 750-338 interface which uses a DB9M connector, but based on my eBay monitoring, I’d say the terminal block models, such as the 750-337, are substantially more popular.  If I were buying new, I would use the 750-338 instead of the 750-337 (since I prefer cables over terminal blocks), or more likely the 750-838 (PLC version of the 750-338) since I’ve found that programmable logic + distributed I/O is a great combination.


March 20, 2012   No Comments

CANOpen DB9M to 2xRJ45 Adapter

CO-DB9-RJ45-2 Adapter connected to AMC DX15C Drive

CO-DB9-RJ45-2 Adapter connected to an AMC DX15C08 Drive

The CO-DB9-RJ45-2 converts a standard CANOpen DB9M connector to 2 RJ45 jacks, with optional, flexible connection to CAN_V+.

My Trac site has the details, and this post has the background information.

The AMC drive pictured is the reason why this board exists: I have a bunch of DX15C08s and a couple DX60C08’s and wanted to get them running, but they require 9->13VDC on the CAN_V+ line.  So I created this adapter to solve that problem with its CAN_V+ connection, and added the RJ45’s because it’s so much easier than trying to daisy-chain DB9s.  (I did think about staying withDB9s).

The design is called the -2, because I have a CO-DB9-RJ45-1 mostly designed, which uses ultra low profile RJ45 jacks in a DB9/DB25 gender changer backshell with 2.5mm terminal blocks.  The board shape is complicated, and I haven’t had the PCB made yet.

This board shows how it’s hard to get everything right the first time: I put the TB1 terminal block header on the wrong side for the DX15C08 servo drives.  Look at the picture and you can see the HD44 cable is right next to the terminal block.

My solution was to replace the pluggable terminal block with a compatible fixed terminal block that doesn’t extend past the PCB board.  That works, but it’s still a tight squeeze.

The board is shown with my RJ45 terminator, which is pretty slick and affordable (~$2).  I’ll try to document the terminator sometime soon.

March 15, 2012   No Comments

My CANOpen Adapters

CANOpen Adapters

CANOpen Adapters

I’ve finally create Trac pages for my CANOpen adapters.  I will be highlighting each adapter in a blog post, starting with the CO-DB9-RJ45-2.

I created these adapters for two reasons:

  1. I’ve standardized on RJ45 cables for my CANOpen networks, because daisy-chained RJ45 cables are cheap, simple, and work well.  However, many of my CANOpen devices do not use RJ45’s, so I created adapter boards from their connectors to dual RJ45 jacks that are perfect for daisy chaining.
  2. Some devices require power on CAN_V+ to power their CAN line drivers.  Unfortunately, most CAN interfaces do not provide any power, or any way to get power, to the CAN_V+ wire.  Also, I need to provide incompatible voltages to different devices.  So I added flexible connections for CAN_V+ to my boards.

After using the boards, I’ve found a couple things that could be improved; the details will be covered in the board’s blog post.

Most of the boards use a similar setup for CAN_V+:

  • CAN_V+ from the power terminal block (TB1) is always connected to the device’s connector.
  • CAN_V+ from TB1 can be connected to the right and/or left RJ45 jack using jumpers.

This setup gives a lot of flexibility: you can power each device that needs CAN_V+ individually, you can power part of the network (left or right), you can power the whole network (left and right), or you can have separate power domains (by not connecting one or both of the jumpers).

If you start doing fancy stuff (such as different CAN_V+ voltages on different network segments), be careful.  For example, if you have an AMC DX15 segment (+12V) and a Baldor e100 segment (+24V), and accidentally move the AMC to the Baldor segment, you will fry the AMC’s CAN line drivers.

The CO_RJ45_PWR board is a little different, since it’s in-line.  Basically, CAN_V+ from the incoming RJ45 jack (J1) is always connected to the 8-position terminal block (P1), and CAN_V+ from the power terminal block (TB1) can be connected to J1 or J2 (outgoing RJ45 jack) using jumpers.

I had the PCBs made at Gold Phoenix, which is a good choice if you need several boards each of different types.  There are many other good PCB fabs.  I am not providing my Gerber files, since different PCB manufacturers may require different formats (units, resolution etc); there are plenty of resources on how to create Gerbers from Eagle on the internet.  If you can’t figure it out, you can always use a PCB fab house that takes Eagle PCB files directly.

Update 3/31/2012: Here are links to the different boards.

  • The CO-DB9-RJ45-2 converts a DB9M CANOpen connector to dual RJ45 jacks.
  • The CO-HDR-RJ45 converts a 5-pin, 5.08mm CANOpen terminal block header to dual RJ45 jacks.
  • The CO-M12-RJ45 converts a M12 CANOpen connector to dual RJ45 jacks.
  • The CO-TB-RJ45 converts a 5-pin terminal block to dual RJ45 jacks.
  • The CO-RJ45-PWR provides inline monitoring and access to CAN_V+ for RJ45 networks.

March 13, 2012   2 Comments

Programming CANOpen Motion

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.

January 21, 2012   5 Comments

Why I Like Copley Accelnet Servo 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.

October 9, 2011   No Comments

A Bunch of Boards

First Batch of PCBs (assembled)

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.

November 5, 2009   3 Comments

Book Review: A Comprehensive Guide to Controller Area Network

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.

May 6, 2009   2 Comments