There is a lot of uncertainties about the ground
connection between the CAN nodes. If the nodes are not
galvanic isolated, then a shielded cable can produce the
opposite effect as intended, since the shield can serve as
power wire carrying noisy currents. In case of the galvanic
isolated nodes, every transceiver has its isolated Gnd. Again
uncertainties what to do with all those isolated transceiver
grounds exist. Some application show that they are all
connected to a common isolated ground wire. This is not
necessary and might even have negative effects regarding EMC.
The CAN bus is designed in a way that all CAN transceiver
ground pins have nearly the same potential even when not
directly connected. For a high speed recessive or idle CAN
bus all Gnd pins are 2.5V lower than the signal lines and VCC
is 2.5V higher than the signal lines.

Having the can bus completely be floating might give the
effect that it could be statically charged up to a level
where sparks could damage something. Putting high resistors
towards ground, ground it in a single point or create well
defined spark gaps are therefore recommended solutions.

CAN frames

Can messages have an identifier (11bit or 29bit) that
basically identifies the message content and it is not a
source destination node address (however some proprietary
upper layer protocols might use it for this). Those
identifiers must be unique in the network. In idle condition
the bus is recessive. More than one CAN node might try to
send out messages and a collision could occur. The message
starts with the dominant SOF (Start Of Frame) bit followed by
the unique identifiers. When more than on node send out a
frame the dominant bits will overwrite the recessive ones
collisions can be detected by a node sending a recessive bit
that gets overwritten by a dominant bit and this will make
this node to stop transmitting. This mechanism gives priority
to the CAN identifiers. After the RTR bit the arbitrary phase
is over and since CAN ID must be unique no collision will
occur, one node sends out all others receive.

When sequentially 5 bits (including stuffing bits) with
the same level are transmitted, bit stuffing takes place and
inserts a bit with the opposite level. This helps
synchronizing bit timing of sender and receiver.

The data frame is used to send up to 8 bytes of data. The
remote frame is used to request data. The requested data will
then be sent via a responding data frame. CAN controller with
object storage do this quasi in hardware. More simple CAN
controllers require the application SW to do it.

The receiver are not just passive and read the frame they
are also interactive and have to overwrite the recessive
ACK-slot bit with a dominant 0 in case the have received a
frame with correct check sum. In case they see something
wrong with the frame they can over write the recessive
ACK-delimiter bit. A single CAN node can not communicate
trouble free onto a cable since a receiver that acknowledges
its frame is missing.

At the end of a positively received frame a recessive idle
period is required. The 6 bit EOF (End Of Frame) and the 3
bit ITM form this.

In case a node detects and error it immediately sends out
an error frame (The error frame is not really a frame, since
it never exists on its own and has no CAN ID). It is a
sequence that overwrites an running frame. The receiver or
sender that initiates the error frame sends 6 dominant bits
the error flag and therefore violets the stuffing bit role
and dominates the signal on the bus. All other nodes detect
the stuffing error and send again a 6 dominant bit error
flag. After that the nodes send 8 recessive bits the error
delimiter. After that ITM (Intermission) follows and then new
attempt to transmit can start.

Since every node can send out error frame it could happen
that a not important broken node could mark correct frames
(not even used for itself) as faulty and therefore block the
complete CAN bus. To avoid this a error counter mechanism is
introduced. When error occur it is incremented when CAN
frames are transmitted error free it is decremented. If those
error counters are low, then the nodes is in Error Active
status and sends out error flags. It the counter gets too
high then the go in Error Passive status and do no more send
error flags with dominant bits. When the error counter even
goes extremely high then they go in Bus Off status and get
removed from the bus where counter decrement is blocked. Just
hardware reset or application SW intervention to the CAN
controller will change the state.

The enhancement CAN FD will support up to 64Byte data. A
CAN FD frame will no more have a constant baudrate. The
baudrate of the transmission phase (DLC, data, CRC) can be
increased up to 15Mbaud.

The kernel needs a device driver this can either be
selected in the kernel sources under Networking Support ->
Can bus networking support or when not available in the
kernel source via http://www.can-wiki.info/can4linux/man/index.html.
There is also a virtual driver in case the PC does not have a
CAN hardware.

There is also the SLCAN protocol http://www.can232.com/docs/can232_v2.pdf that can
be used over a serial connection. There is support for it in
the kernel sources. This way a USB to serial converter can be
connected to the PC and on the other side a microcontroller
that converts it to CAN. The driver is called slcan and must be connected
to a tty port using slcan_attach

Socket CAN is an abstraction layer (coming from
Volkswagen) that allows to communicated to a CAN network. It
is well supported by Linux https://www.kernel.org/doc/Documentation/networking/can.txt
or in your sources /usr/src/linux/Documentation/networking/can.txt.
It is supported in python3 under the socket family name
AF_CAN. See https://docs.python.org/3/library/socket.html?highlight=can.
Since it is a socket interface commands similar that the ones
for Ethernet apply as ifconfig
can0 up to bring it up or ip link set can0 up type can bitrate
125000 to change the bitrate to 125k. It has
some command line tools as candump can0 to receive
cansend can0
500#1E.10.10 to send 3 hex Byres using
identifier 500 and cansend can0
500#R request data.

CANopen

When the network gets bigger, the CAN development task can
be split in node design and networking design. Often a
network designer does not want to bother about node details,
he likes to just take existing nodes and integrate them into
the network. The big task of the network design is selecting
the identifiers an data to be exchanged. In proprietary CAN
this might be fix, but it often grows and then some hacks
need to be done so the new things fit.

It is therefore desirable to have something that allows
assigning identifiers and selecting data flexible. CANopen
exactly allows this. CANopen specifies a set of identifiers
to be used to configure the network. When the network is
configured the remaining identifiers are used to exchange the
data among the nodes without a user could identify them as
CANopen messages (except that he would see that some reserved
identifiers are not used and some typical CANopen messages
might appear, as the boot-up messages and the sync
messages).

Unfortunately the CANopen specifications use a bit strange
vocabulary, is heavily abstract and theoretical and often the
vocabulary is not consistent. As examples too many things in
CANopen are called Object, except Objects are called
Profiles. Draft Standards are not draft standards as known
form CEN, ISO they are the published standards. So many
designers get highly confused and give up and start designing
their own proprietary CAN implementation.

To send out messages used for the applications PDO
(Process Data Objects) are used. Those PDO's produce CAN
messages that look like raw CAN messages, there is an
Identifier that identifies the message and nothing else and
in the data there is data that can be of any kind as a bit
field or a complete data-structure as long as it fits into
the 8Byte limitation of CAN.

When designing a network it has to be decided what data
goes from a source node to a destination node (or nodes).

The first thing is deciding of a CAN identifier that does
not conflict with other used CAN identifiers. In CANopen this
can be any number so a number that reflects the desired
priority on the CAN bus can be selected (low numbers have
high priority). Once chosen, the CAN identifier (plus
communication parameters) will be stored as PDO Communication
parameters on both nodes the receiver and transmitter.

The second thing is looking what data has to be
transmitted. The data available can be found in the Object
Directory (OD) that is something as the CANopen node internal
database. Data in the OD can be addressed by an index and a
subindex. The PDO Mapping parameters will hold the sequence
of data that is packed into the CAN message. It holds
therefore index subindex information of all the data to be
transmitted. This has to be done on the transmitting node and
all the receiving nodes. The PDO Mapping parameters will be
different on receiving and transmitting nodes, since the
transmitting node will probably send its status of its
physical attached inputs and the receiving node will probably
map this to its physically attached outputs.

Complex CANopen nodes contain many PDOs and full
flexibility. Simple CAN nodes may have just a single PDO.

There are different ways to send out the CAN messages as
asynchronous or triggers by a dedicated syc CAN message. This
is configured via PDO Communication parameters and its
details can be found in the CANopen spec.

Again all the data including PDO Communication and Mapping
parameters can be found in the Object Directory (OD). To
configure the network read and write access over the CAN bus
to the nodes OD is required. This is done via Service Data
Objects (SDO). SDO's allow via request response mechanism to
read and write to the OD. Since they need to transmit what to
do the occupy some of the 8 Bytes in the CAN message. In a
simple SDO access to the OD just 4 Bytes can be transmitted.
Since often more Bytes needs to be transmitted (it is
possible do download a nodes firmware via CANopen) SDO use
segmentation to transmit the desired data into little chunks
and produce therefore many CAN messages until the data is
transmitted.

If a CANopen network gets powered it can not be assured
that it is ready to go. Many CANopen nodes might start with
the PDO's using the predefined configuration set. This set
makes use of a node ID that might come from a 7bit DIP switch
allowing to give the nodes unique ID's between 1 and 127 (0
is reserved for broadcast). The node ID is used in the
identifiers and to have no conflict plus to not cause any
accidental connection between a transmitting and receiving
node.

Some PDO configuration might be required to have the nodes
exchanging data among each others (slave to slave
communication). Therefore CANopen nodes go after sending a
boot message to a Pre-Operational state. A CANopen
network-manager has then the chance to do the missing
configuration and then change them in operational state.

Some networks might have a quite dominant master (e.g. a
PC or PLC) and do not want slave to slave communication.
Those networks might work directly with the CAN ids defined
by the predefined configuration set. So no configurations of
the nodes might be required and the network manager could put
them directly into operational state.

The CANopen device internal SW will have a CANopen stack
contains a driver to the CAN controller, the Object Directory
and SW routines as for SDO, PDO and network management.

There is obviously also an application SW running on the
CAN open device the reacts to the arriving PDO data and
produces PDO data when some events in the node occur (as
signal change on a physical input).

It is a demand to standardize behavior of such
applications, so as example an CANopen IO converter can be
selected from different manufacturers or a 24Vdc IO device
behaves as a 230Vac IO device.

CANopen has therefore created profiles. A profile defines
where the application variables reside in the Object
Directory and assigned them index and subindex. Additionally
it defines the behavior of them. It should be noted that can
open allows to have just one profile in the CANopen node.
First there is just one entry in the OD for that, secondly
the profiles have overlapping index subindex assignments. To
resolve that can uses application profiles. Still just on
application profile is possible per CANopen device, but the
application profiles have virtual devices. As example the
CiA417 lift application profile can contain 1 to 8 virtual
lifts (for US readers, lift means elevator). To communicate
with an PLC or PC there is the Interface Profile CiA405 that
introduce new concepts as network variables (see also
CiA302). This way data can be exchanged in a standard way
without really knowing their content. Gateway functionality
to other buses (as Modbus over TCP/IP) is also specified (see
CiA309).

The Object Directory has a index section reserved for
manufacturers proprietary objects to not put limits to
CANopen node developers.

CANopen node developers should be register at https://www.can-cia.org/index.php?id=canopen. A
hobbyist probably does not want to become a CANopen member
and pay the yearly fee or the Vendor ID registration fee and
will therefore not having a vendor ID. An non conflicting
Vendor ID as 0 should be used .

CAN
Festival

Under doc the source to created the documentation can be
found. The manual could be created by cd doc/manual and type
make or simply
use the already created pdf under /objdictedit/doc. To get
the code documentation cd
doc/doxygen and then run doxygen.

After installing dev-python/gnosis-utils-1.2.2 the command
./objdictedit.py brings up
the object directory editor. The object directory editor
creates a xml file with the od file extension, but to use it
in the application a c and h file can be created. Also an
export to the commonly used EDS form is possible.

The c and h file of the object dictionary needs to be
compiled with the application. The application makes use of
the canfestival lib. The canfestival lib communicates trough
a target interface layer with the operating system. the
operating system needs a device driver to access the physical
can controller (or a virtual). Since most CANopen nodes are
not PC's Canfestival supports also embedded devices. The is
the configure script in the can festivals top directory holds
the default definitions, see help how to pass other values
./configure
--help. It allows to turn your Linux computer
into a CanOpen node. If no can hardware is available then the
serial driver ./configure
--can=serial can be used to connect two PC
running canfestival. Or ./configure --can=virtual
or, for kernel space: ./configure
--can=kernel_virtual to simulate a virtual
can controller that produces echoes. modprobe vcan loads the
virtual can kernel driver vcan.

There are different example programs that run on a PC.

The HCS12 is well supported: There is also a sample
applications for an Atmel AVR slave and an Atmel AT91 master.
Finally there are some hints how to port it to other
devices.