There are CAN (Controller Area Network) high speed and can low speed transceivers that have different bus levels.

Logical 1 or recessive is quite different. On high speed transceivers 2.5V toward ground for both data lines. Low speed transceiver have CAN_L 5V and CAN_H 0V.

Logical 0 or dominant is CAN_H 3.5V and CAN_L 1.4V for high speed and it is similar for low speed CAN_H 3.6V and CAN_L 1.4V

The transceiver hardware has therefore a well defined behavior when a collision occurs, dominant level 0 bits overwrite recessive level 1 bits.

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 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.

For a self made CAN interface description: http://cryptomys.de/horo/CAN200/ and its driver http://canbus4linux.sourceforge.net/.

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.

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 is a CANopen framework http://www.canfestival.org/ that focuses on a CANopen stack that can run on different platforms.

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.