CAN Bus Specifications and Troubleshooting

The CAN bus is a robust field bus that is used in IDCP for communication between the IOC and motor control devices, power supplies and temperature sensors.

Cabling

We use a shielded twisted pair cable with 9 pin D-Sub plugs.

This is the pin-allocation as we use it here:

Pin	Signal	Description
2	CAN_L	CAN bus signal (dominant low)
3	CAN_GND	CAN ground
7	CAN_H	CAN bus signal (dominant high)

Topology

All participants on the CAN bus must be connected in bus topology. You must not have branches on your network.

Termination

With our standard cable the CAN bis must be terminated with 120 Ohm at both ends.

VME-CAN4 Interface card

For VME bus IOCs we use mostly the VME-CAN4 interface card for CAN Bus communication.

Manual

The hardware manual can be found here:

VME-CAN4 hardware manual.

VME-CAN4 diagnostic LEDs

There are three rows with 4 LEDs each:

Column A	Column B	Column C	Column D
LED1:A red SYSFAIL	LED1:B yellow BUS	LED1:C red IRQ	LED1:D green, always off
LED2:A green Status CPU 1	LED2:B green Status CPU 2	LED2:C green Status CPU 3	LED2:D green Status CPU 4
LED3:A red Error CAN 1	LED3:B red Error CAN 2	LED3:C red Error CAN 3	LED3:D red Error CAN 4

LED states:

LED	LED off	LED on
LED 1:A red SYSFAIL	SYSFAIL not active.	SYSFAIL active The signal is active if at least one CPU is not initialized. The SYSFAIL signal is guided to the VMEbus.
LED 1:B yellow BUS	No VMEbus access to the VME-CAN4.	Access from VMEbus to the VME-CAN4.
LED 1:C red IRQ	No VMEbus interrupt of the VME-CAN4 is active.	The VMEbus-interrupt signal of the VME-CAN4 is active.
LED 1:D green User	From PCB version >= BAxxxx on, this LED is no longer in use. The LED is always off.
LED2:A…D green Status CPU1…4	The respective CPU is not initialized.	The initialization of the CPU has been successfully completed.
LED 3:A…D red Error CAN 1…4	The error flag of the respective CAN controller is inactive.	The error flag of the respective CAN controller is active.

CAN Cable lengths

With the CAN bus, the baud rate limits the maximum cable length.

Bit rate [Kbit/s]	Typical values of reachable wire length with esd interface lmax [m]	CiA recommendations (07/95) for reachable wire lengths lmin [m]
1000	37	25
800	59	50
666.6	80
500	130	100
333.3	180
250	270	250
166	420
125	570	500
100	710	650
66.6	1000
50	1400	1000
33.3	2000
20	3600	2500
12.5	5400
10	7300	5000

Troubleshooting

If you don’t have a connection check the following.

Termination

The CAN bus must have termination of 120 Ohm at both ends. Without termination it only works for very short cable lengths in the region of 1m.

A common problem is that the termination resistor is missing at one or both ends.

The VME-CAN4 card sometimes has a termination resistor directly on the card.

In newer installations we use D-Sub connections with a built-in resistor that can be switched on and off.

If the termination resistors are in the connector you can unplug all CAN devices and measure the resistance between PIN 2 and 7. With correct termination at both ends you should measure 60 Ohm.

Connectors

Open connectors and check that PINs 2, 3 and 7 are connected to the correct wires. Make sure that CAN_H and CAN_L are not swapped.

Ports

The VME-CAN4 card has 4 CAN Bus ports. Make sure that the cable is plugged to the right port.

This is the current CAN Port use with IDCP, note that we start counting with zero here:

CAN Port	Usage	Baud rate
0	Connection to monochromator	500 kBit
1	Connection to Collectior IOC	66 kBit
2	Connection to motor controllers (UniDrive)	1 MBit
3	Connection to power supplies and temperature modules	1 MBit

Connecting the cable to the wrong port disrupts communication between all other participants if the Baud rate doesn’t match.

Diagnose with a Linux Notebook

Any Linux notebook with a CAN-USB interface that is supported by the Linux kernel can be used to diagnose problems further.

First you have to initialize the CAN interface with the correct baud rate before you connect it to your CAN bus line. The baud must be an integer between 10000 and 1000000, the transfer speed in Bit/sec.

Enter:

sudo ip link set can0 type can bitrate BAUDRATE
sudo ip link set can0 txqueuelen 1000
sudo ip link set up can0

You can see your can interface with:

ip link show type can

You must have the program ‘candump’ installed. Usually this is part of a package named “can-utils”.

You start a simple diagnose with:

candump -t A can0

candump has many options, see also candump -h.

CAN line to the monochromator

Diagnose with LED

As described at VME-CAN4 LEDs in the third row of LEDs there is an LED for each CAN port.

If the first LED in the third row is red, there is a CAN communication problem with the monochromator detected by the CAN bus card. The CAN bus card can detect if there isn’t any receiver on the CAN bus line. If the VME CAN interface card on the monochromator is set up with the correct baud rate and connected to the undulator and the CAN cable termination is correct, you shouldn’t see a red LED.

Diagnose with channel access

For an undulator with name DEVICENAME enter:

watch -n 1 caget -a DEVICENAME:BaseStatIStat

If you see TIMEOUT or TIMEOUT invalid the undulator didn’t get a response from the monochromator.

Diagnose with Linux notebook

When you use a Linux notebook as described at Linux notebook.

Ensure that the baud rate of the CAN bus interface of the linux notebook is correct. Baud rates are shown here Baud rates. Usually the baud rate here is 500 kBit.

Caution

A wrong baud rate on the Linux notebook will disrupt all CAN communication.

You should see, among others, the CAN objects shown below. The undulator IOC sends the outgoing CAN objects at least every 5 seconds:

Variable	outgoing CAN object	incoming CAN object from monochromator	length (bytes)	remarks
Gap status [1]	724	660	5	stop: 1 run: 3
Watchdog [1] [2]	980	916	5	increasing counter

[1] (1,2)

For each outgoing CAN object you should see a reply by the monochromator IOC on the incoming CAN object.

[2]

The watchdog object will be implemented on the monochromator IOC in the future. Currently (as of 2025-06-17) you will not see a reply here.

Now you can do the following to locate the problem:

Check if the Undulator IOC has a problem

Connect the Undulator IOC directly to the Linux notebook, remove the CAN cable to the monochromator. Ensure that the CAN termination is still correct. If you see that the Undulator IOC sends CAN objects, this shows than the CAN bus card in the Undulator IOC works and the Undulator software works. If not, the problem is with the Undulator IOC hardware or software.

Check if the cable prevents the sending of CAN objects

Keep the Linux notebook connected but attach the CAN bus cable to the monochromator, too. Ensure that the termination is still correct. This shows if the problem comes from the cable or something at the monochromator IOCs. Look if the Undulator gets replies from the monochromator.

Check if one of the monochromator IOCs causes the problem

Unplug all monochromators from the cable. If you see that the Undulator IOC now sends CAN objects, it shows that the cable and it’s termination are okay.

Connect each of the monochromators separately, this shows which monochromator causes the problem.