1. Home
  2. Embedded Programming
  3. CAN/CANopen under Linux

CAN/CANopen under Linux

Hi,

my company is developing a complex planar motion system at the moment which is controlled by an embedded Linux. One part of this system is a servo motor. This motor is a CANopen device connected to the whole system using a compact-PCI CAN card with two SJA1000s.

The whole system is controlled with a realtime kernel module which is intended to send, at some point, 'move' commands to the motor.

So far, I wrote a driver to have access to the can controller from kernel space.

Unfortunately, we have little or no experience in CAN/CANopen. My 'plan' was to do the CANopen encoding myself because we only need a very limited set of functions for the motor. It's more or less a pretending of a CANopen stack.

I've read through tons of specifications 'til now but was not able to communicate with the CANopen device in any way.

The only thing I see from the device is a message with id 0x701 ( NMT message + node id) and a single, empty data byte right after bootup. I guess, it's indicating the presence of the device which is in the state 'pre-operational'. But switching to 'operational' using the appropriate message always failed.

So, the questions are:

- is it some kind of master/slave problem, maybe? One slave but no 'physical' master present?

- is it in general possible to communicate with CANopen devices without a real CANopen stack or network using a simple application (in this case a kernel module) as 'master'?

Best regards Mark Braczek

Reply to
Mark Braczek
Loading thread data ...

So far, so good. If you have actually received a proper NMT bootup message, you have come a long way. The communications channel is established, no wires are crossed, and the nodes agree on the bit rate.

Time for a sanity check. Which message, exactly, did you send? Was it perhaps:

  • Identifier = zero
  • Byte 0 = 1 (Start remote node command)
  • Byte 1 = 0 (=all nodes) or 1 (=your node's ID, if you received 0x701 from it.)

If it was, then what did you do next? How did you make sure the node was dead? What messages did you try to send and/or receive? A servo controller can be a reasonably complicated device, requiring setup of many parameters while in the pre-operational state, before switching it to Operational. At worst, if not properly initialized, it might well stay both dumb and mute. If you could provide a link to the controller's manual, it might be easier to provide intelligible answers.

The CanOpen master here is your SW, through the CAN I/F board.

Sure, anything is possible. There is no magic in a CANopen stack; all it does is send the right messages at the right time. If you can send the proper subset you need to send in your SW, then to your purposes you are a CANopen stack. Whether it is worth the effort is another matter; maybe it is, if you only have one slave that you need to access in a simple manner.

Reply to
Hans Odeberg

Yes and no. The wires are ok, the motor itself is functionable. I know that because my colleague actually got it working. However, using a terminal under Windows, not under Linux.

I'm not so sure concerning the bit rate. I played around with different bit rates. The controller always got the bootup message, even with a totally different bit rate than the motor (which has a default rate of 125 kbit/s - I didn't changed that).

Yes, indeed. I also tried the 'set to pre-op' command (0x80), just to make sure. Didn't change anything, too (at least that's something I understand).

Nothing. Well, actually the very first thing I tried was to send one of my 'faked' CANopen massages. A SDO to gain access to the OD, simply to read out some general info (like the software version). After that failed, I took a closer look at the manual and the CANopen 'box'. The box has a LED which is permanently 'on'. The manual states that this means the device is awaiting the start command. The LED is supposed to be 'off' in operational mode. So, I thought I would have to send the start command in order to gain access to the OD. Oh btw, the CANopen device is a mcIO-C4-dsa-CANopen by miControl

formatting link
which is actually the amplifier for the motor itself, I guess. Their download section has some German manuals (mcDSA*.pdf). But I don't know if it's worth taking a look at. It's mainly the description of the OD. It doesn't even tell about the (0x70x) bootup message. I have that information from some other manual.

That's what I figured. And yes, we plan to use the motor in a very simple way. It wil be used to move a vertical axis up and down, that's it.

This morning, we used an oscilloscope to check the CAN bus. It seems to be ok but we noticed a permanent activity on the bus, along with some other 'strange' behaviour of the controller. I read that the controller tries over and over again to send a message, as long as it doesn't see an ACK. But the LED on the cPCI-card (a CCAN-40 by SMA) indicating activity is not flashing at all. Next thing: the controller's status register permanently claims to receive a message but when I check the rx message counter, the counter is zero.

So, the reason for the mess could also be a defective CAN-I/F board, or (more likely) my lousy driver. Unfortunately, I was not able to use the driver delivered by SMA ( a modified can4linux ) due to the kernel versions (2.4 2.6). I tried to configure the chip the same way they did but I'm so sure that I got everything right.

Best regards Mark Braczek

Reply to
Mark Braczek

can4linux works under kernel 2.6. Download version 3.3.3 from

formatting link
and compare it with your changes. (I hope the board is equipped with SJA1000 CAN controller?)

I have only two additional remarks to your overall problem.

- look for a commercial CANopen package and support

- Get at least some tools which you can trust, lets say at minimum a CAN analyzer (with CANopen option) and better an CANopen Configuration tools which acts as network master.

Regards Heinz

Reply to
Heinz-Jürgen Oertel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.