This project presents a method of real time measurement and transmission of Rpm of motor and Temperature. In this system three PIC controllers built in CAN module are used as three different nodes, first and second node measures the physical parameters, then transmits digital packets on CANBUS and another node receives. Sensors actually measures Rpm as well as Temperature in the form of analog signal and PIC controller built-in ADC converts the analog data from sensor into digital . This is processed and encoded by the same controller and sent the digital code to another PIC controller through a cable. The receiving controller can be used for analysis, display and or control purpose. Transmission and reception of data is performed by CAN transceivers.PIC controller supports CAN transceiver. The data transmission remains reliable due to CAN BUS even in the presence of noise.
Table of contents
Multipoint Communication Of CANBUS i
Get your grade
or your money back
using our Essay Writing Service!
This work, entitled "Multipoint Communication Of CANBUS" has been approved for the award of i
Table of contents vi
List of Figure vii
1 Introduction 1
2 Literature Review 3
3 Requirements Specification 16
4 Project Design 18
5 Implementation 27
Appendix A:C Source Code 33
Appendix B: Hardware Schematics 40
Appendix C: List of Components 45
Appendix D: Project Timeline 47
List of Figure
CAN is a serial bus protocol to connect individual systems and sensors as a substitute to conventional multi-wire looms. Our purpose was to communicate two different modules on a single bus that's why we have used CANBUS as it allows different modules to communicate on a single or dual-wire networked data bus up to 1Mbps.
CAN is an industry standard protocol used in automotive electronics and many new embedded environments where discrete components need sharing of information.CAN was initially developed for use in cars, to provide a cost-effective communications bus for in-car electronics and as substitute to expensive, unreliable wiring looms and connectors
CAN additionally feature:
Small message frame sizes (maximum of 8 data bytes) that guarantee access to the
Network in short time periods.
Multi-master transmissions and collision avoidance determined through priority.
The physical layer requires one or two twisted pairs and is opposing to electrical
Network speeds up to 1Mbit that can be easily deployed in 8-bit microcontrollers.
The CAN BUS was developed by Bosch in 1986 as a multi-master message broadcast system that specifies a highest signaling rate of 1 megabit per second. Unlike traditional networks such as USB or Ethernet, CAN does not send large blocks of data from point-A to point-B under the supervision of a central master. In a CAN network, many short messages like temperature or speed are broadcast over the entire network. The short message format provides data consistency among all the nodes on the network.
In 1992, CiA (CAN in Automation) organized several chipmakers to standardize CAN, and one year later, the first CAN standard, ISO 11519, commonly referred to as low speed CAN, emerged with an 11-bit identifier and is used in applications up to 125 kbps. The second version, ISO 11898, was released in 1993, used an 11-bit identifier and offered data rates up to 1 Mbps. It is sometimes called CAN 2.0-A. An amendment was made in 1995 extending the 11-bit identifier to 29 bits known as CAN 2.0-B. Since 1992, CiA has worked with numerous industry groups to create Higher Layer Protocols (HLPs) that provide CAN network solutions apposite to industry requirements.
This project describes CAN as a multipoint communications system that connects different systems without the need of a master and a broadcast messaging system that guarantees fast data transmission and integrity by virtue of a sophisticated bit arbitration system, error detection and the retransmission of faulty messages.
Chapter 2 covers the background material and literature reviewed to understand the CAN BUS communication
Chapter 3 then specifies the lists of extracted requirements for the project development. These requirements are categorized into several groups on the basis of their functionality. Requirements are also prioritized to explain their importance and enable the user to sift them according to his needs.
Always on Time
Marked to Standard
Chapter 4 describes the design formulated for the successful execution of the suggested techniques. The design explains the architecture of CAN BUS. In the end, this chapter gives detailed information for each module, explaining their critical methods and properties required for successful execution.
Chapter 5 explains the implementation of project.
In February of 1986, Robert Bosch GmbH introduced the serial bus system Controller Area Network (CAN) at the Society of Automotive Engineers (SAE) congress for use in cars, to provide a cost-effective communications bus for in-car electronics and as alternative to expensive, cumbersome and unreliable wiring looms and connectors.
The goal was to make automobiles more reliable, safe and fuel efficient while decreasing wiring harness weight and complexity.
History of CAN
1983: Start of the Bosch internal project to develop an in-vehicle network
1986: Official introduction of CAN protocol
1987: First CAN controller chips from Intel and Philips Semiconductors
1991: Bosch's CAN specification 2.0 published
1991: CAN Kingdom CAN-based higher-layer protocol introduced by Kvaser
1992: CAN in Automation (CiA) international users and manufacturers group established
1992: CAN Application Layer (CAL) protocol published by CiA
1992: First cars from Mercedes-Benz used CAN network
1993: ISO 11898 standard published
1994: 1st international CAN Conference (iCC) organized by CiA
1994: DeviceNet protocol introduction by Allen-Bradley
1995: ISO 11898 amendment (extended frame format) published
1995: CANopen protocol published by CIA 
Introduction to CAN
CAN is a serial bus protocol to connect individual systems and sensors as a substitute to conventional multi-wire looms. It allows automotive components to communicate on a single or dual-wire networked data bus up to 1Mbps. 
CAN protocols types:
There are basically two types of CAN protocols: 2.0A and 2.0B`.
CAN 2.0A is the earlier standard with 11 bits of identifier, while CAN 2.0B is the new extended standard with 29 bits of identifier. 2.0B controllers are completely backward-compatible with 2.0A controllers and can receive and transmit messages in either format.
There are two types of 2.0A controllers. The first is capable of sending and receiving 2.0A messages only and reception of a 2.0B message will flag an error. The second type of 2.0A controller (known as 2.0B passive) sends and receives 2.0A messages but will also acknowledge receipt of 2.0B messages and then ignore them.
CAN Basic Features
CAN has the following properties
Based on a bus topology
Prioritization of messages
Carrier-Sense Multiple-Access (CSMA) protocol
Error detection and signalling
Multicast reception with time synchronization
Automatic retransmission of corrupted messages as soon as the bus is idle again
Distinction between temporary errors and permanent failures of nodes and autonomous switching off of defect nodes
CAN bus offers remote transmit request (RTR) 
How CAN works
CAN bus is not addresses based but each message contains a unique identifier ,so data messages transmitted from any node on a CAN bus do not contain addresses of either the transmitting node, or of any desired receiving node.
All nodes on the network receive the message and each performs an acceptance test on the identifier to check if the message is relevant to that particular node or not. If the message is relevant, it will be accepted and processed; otherwise it is rejected. The unique identifier also determines the priority of the message. The lower the numerical value of the identifier, the higher the priority. When two or more nodes attempt to transmit at the same time, a non-destructive arbitration technique guarantees that messages are sent in order of priority and that no messages are lost.
Depending on the operational speed devices are connected to the bus, as in a typical vehicle application usually more than one CAN bus and their operational speed is different. Slower devices, such as door control, climate control, and driver information modules, can be connected to a slow speed bus. Devices that require faster response, such as the ABS antilock braking system, the transmission control module, and the electronic throttle module, are connected to a faster CAN bus.
Figure 2.1 How CAN Works 
CAN logic states
This Essay is
a Student's Work
This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.Examples of our work
The data on CAN bus is differential and can be in two states: dominant and recessive. Figure 1.4 shows the state of voltages on the bus. The bus defines a logic bit 0 as a dominant bit and a logic bit 1 as a recessive bit. When there is arbitration on the bus, a dominant bit state always wins out over a recessive bit state.
Figure 2.2 CAN logic states 
In the recessive state, the differential voltage CANH and CANL is less than the minimum threshold (i.e., less than0.5V receiver input and less than 1.5V transmitter output). In the dominant state, the differential voltage CANH and CANL is greater than the minimum threshold.
The 1st version of the CAN standards, ISO 11519 (Low-Speed CAN) is for applications up to 125 kbps with a standard 11-bit identifier. The 2nd version, ISO 11898 (1993), also with 11-bit identifier offers signalling rates from 125 kbps to 1 Mbps and the more recent ISO 11898 amendment (1995) introduces the extended 29-bit identifier.
Table 1: CAN versions 
The ISO 11898 11-bit versions is referred to as Standard CAN Version 2.0A and the ISO 11898 amendment is referred to as Extended CAN Version 2.0B. Also Standard CAN Version 2.0A is occasionally referred to as Basic CAN, and Extended CAN Version 2.0B is occasionally referred to as Full CAN.
The Standard CAN 11-bit identifier field in Figure 2 provides for 2^11 or 2048 different message identifiers, while the Extended CAN 29-bit identifier in Figure 3 provides for 2^29, or 537 million identifiers.
The Bit Fields of Standard CAN and Extended CAN:
Figs 2.3a Standard CAN 
The meaning of the bit fields of Figure 2.3a are:
SOF-the single dominant start of frame (SOF) bit marks the start of a message, and is used to synchronize the nodes on a bus after being idle.
Identifier-The Standard CAN 11-bit identifier sets the priority of the message.
RTR-the single remote transmission request (RTR) bit is dominant when information is required from another node. All nodes receive the request, but the identifier determines the desired node. The responding data is also received by all nodes and used by any nod interested. In this way all data being used in a system is uniform.
IDE-a dominant single identifier extension (IDE) bit means that a standard CAN identifier with no extension is being transmitted.
r0-Reserved bit (for possible use by future standard amendment).
DLC-The 4-bit data length code (DLC) contains the number of bytes of data being transmitted. Data-Up to 64 bits of application data may be transmitted.
CRC-The 16-bit cyclic redundancy check (CRC) contains the `checksum (number of bits transmitted) of the preceding application data for error detection.
ACK-every node receiving an accurate message overwrites this recessive bit in the original message with a dominate bit, indicating an error-free message has been sent. Receiving node detects an error and leaves this bit recessive, it discards the message and the sending node repeats the message after re-arbitration.
EOF-this end-of-frame (EOF) 7-bit field marks the end of a CAN frame (message) and disables bit-stuffing, indicating a stuffing error when dominant. When 5 bits of the same logic level occur in succession during normal operation, a bit of the opposite logic level is stuffed into the data.
IFS-This 7-bit inter-frame space (IFS) contains the amount of time required by the controller to move a correctly received frame to its proper position in a message buffer area.
Fig2.3b Extended CAN 
As shown in Figure 2.3b, the Extended CAN message is the same as the Standard message with the addition of:
SRR-the substitute remote request (SRR) bit replaces the RTR bit in the standard message location as a placeholder in the extended format.
IDE-a recessive bit in the identifier extension (IDE) indicates that there are more identifier bits to follow. The 18-bit extension follows IDE.
r1-Following the RTR and r0 bits, an additional reserve bit has been included ahead of the
There are four different message types, or frames (Figures 2.3a and 2.3b) that can be transmitted on a CAN BUS:
the data frame
the remote frame
the error frame
the overload frame
A message is considered to be error free when the last bit of the ending EOF field of a message is received in the error-free recessive state. A dominant bit in the EOF field causes the transmitter to repeat a transmission.
The Data Frame
The data frame is made up by the arbitration field, the CRC field, the acknowledgement field and the data field. The arbitration field tells the priority of a message when two or more nodes are struggling for the bus. The arbitration field consists of an 11-bit identifier for CAN 2.0A in Figure 2.3a and the RTR bit, which is dominant for data frames. For CAN 2.0B in Figure 2.3b it consist the 29-bit identifier and the RTR bit. The data field contains zero to eight bytes of data and the CRC field contains the 16-bit checksum used for error detection. At the end there is the acknowledgement field. Any CAN controller which is able to receive a message correctly sends a dominant ACK bit that overwrites the transmitted recessive bit at the end of correct message transmission. The transmitter checks for the dominant ACK bit and retransmits the message if no acknowledge is detected.
The Remote Frame
The desired purpose of the remote frame is to obtain the transmission of data from another node. The remote frame is same as the data frame but with two important differences. First, this type of message is explicitly marked as a remote frame by a recessive RTR bit in the arbitration field. Secondly there is no data.
The Error Frame
This frame is a special message that breaks the formatting rules of a CAN message. It is transmitted when a node finds an error in a message, and causes all other nodes in the network to send an error frame as well. The original transmitter then automatically retransmits the message. There is a careful system of error counters in the CAN controller which ensures that a node cannot tie up a bus by repeatedly transmitting error frames.
The Overload Frame
The frame is similar to the error frame with regard to the format, and it is transmitted by a node that becomes too busy. It is basically used to provide for an extra delay between messages. 
Error Checking and Fault Confinement
The CAN protocol implements five methods of error checking: three at the message level and two at the bit level.
The CRC and the ACK slots are at the message level as displayed in Figures 2.3a and 2.3b.The CRC which is 16-bit contains the checksum of the preceding application data for error detection with a 15-bit checksum and 1-bit delimiter. The 2-bit ACK field consists of the acknowledge bit and an acknowledge delimiter bit. The form check is also at the message level. It looks for fields in the message which must always be recessive bits. If a dominant bit is detected, an error is generated. The SOF, EOF, ACK delimiter, and the CRC delimiter are the checked bits.
At the bit level the transmitter of the message is monitoring each transmitted bit. If a data bit (not arbitration bit) is written onto the bus and its opposite is read, an error is generated. The message identifier field which is used for arbitration, and the acknowledge slot which requires a recessive bit to be overwritten by a dominant bit are the only exceptions to this. The bit stuffing rule is the final method of error detection where after five consecutive bits of the same logic level if the next bit is not a compliment then an error is generated. It ensures rising edges available for on-going synchronization of the network, and that streams of recessive bits are not mistaken for an error frame, or the seven-bit interface space that signifies the end of a message. Stuffed bits are removed by a receiving node's controller before the data is forwarded to the application. 
With any one of these error detection methods if a message fails then it is not accepted and an error frame is generated from the receiving nodes causing the transmitting node to resend the message until it is received correctly. But if a faulty node hangs up a bus by continuously repeating an error, its transmit capability is removed by its controller after an error limit is reached. 
Three Types of BUS
FLEX RAY BUS
Bus-type, Star-type, or Coexisting
Over Rode Frame
Type of errors
All errors except a clock synchronization
Synchronized only by sync_seg
Rate correction and offset correction are available.
40m at 1Mbps
(between nodes, between Active-Star and node, and between Active-Star and Active-Star.)
Connected nodes (max)
Depending on the delay time of the bus
Bus-type: 22 nodes Star-type: 22 nodes or 64 nodes during active Coexisting: 64 nodesComparison of CAN BUS FlexRay BUS
Table 2: Comparison of CAN BUS FlexRay BUS [ 10]
Comparison of CAN BUS with LIN BUS]
Maximum baud rate
1Mbaud - High Speed CAN
Enhanced ISO-9141 (ISO-K)
Network Access Method
Master initiates transmission, therefore no
Number of nodes
Usually limited by physical layer or
higher layer protocol to 128 or 64
16 nodes (1 Master, 15 Slave)
Number of wires
Table 3: Comparison of CAN BUS with LIN BUS 
MikroC Functions Overview
There are number of compilers but we have used the Mikroc.
The following are the mikroC functions which we have use in our project:
The Prototype of the function is
Void CANSetOperationMode (unsigned short mode, unsigned short wait_flag);
It sets CAN to requested operation mode, i.e. copies mode to CANSTAT. The parameter wait_ flag is either 0 or 0 x FF. If it is set to 0 xFF this is a blocking call and will not return until the requested mode is set. If it is set to 0, the function returns as a no blocking call. The mode can be one of the following:
CAN_MODE_NORMAL Normal mode of operation
CAN_MODE_SLEEP Sleep mode of operation
CAN_MODE_LOOP Loop-back mode of operation
CAN_MODE_LISTEN Listen-only mode of operation
CAN_MODE_CONFIG Configuration mode of operation
The prototype of the function is
Void CANInitialize(unsigned short SJW, unsigned short BRP, unsigned short PHSEG1, unsigned short PHSEG2, unsigned short PROPSEG, unsigned short CAN_CONFIG_FLAGS);
Where parameters are
SJW is the synchronization jump width
BRP is the baud rate prescaler
PHSEG1 is the Phase_Seg1 timing parameter
PHSEG2 is the Phase_Seg2 timing parameter
PROPSEG is the Prop_Seg
We have us used the following configurations:
The prototype of the function is
void CANSetMask(unsigned short CAN_MASK, long value, unsigned short CAN_CONFIG_FLAGS);
It sets mask for advanced filtering of messages. CAN_MASK can be one of the following:
CAN_MASK_B1 Receive buffer 1 mask value
CAN_MASK_B2 Receive buffer 2 mask value
value is the mask register value. CAN_CONFIG_FLAGS can be either
CAN_CONFIG_XTD (extended message),or
CAN_CONFIG_STD (standard message).
The prototype of the function is
Void CANSetFilter (unsigned short CAN_FILTER, long value, unsigned short CAN_CONFIG_FLAGS);
It sets message filter.
We have used the following modes
CAN_FILTER_B2_F3 Filter 3 for buffer 2
CAN_FILTER_B1_F1 Filter 1 for buffer 1
CAN must be in Config mode; otherwise the function will be ignored.
The prototype of the function is
Unsigned short CANRead (long *id, unsigned short *data, unsigned short *datalen, unsigned short *CAN_RX_MSG_FLAGS);
It reads message from receive buffer. If at least one full receive buffer is found, it is extracted and returned. If none found, function returns zero.
The Parameters are:
id is message identifier
data is an array of bytes up to 8 bytes in length
Datalen is data length, from 1-8.
CAN_RX_MSG_FLAGS is value formed from constants
The prototype of the function is
Unsigned short CANWrite(long id, unsigned short *data, unsigned short data len, unsigned short CAN_TX_MSG_FLAGS);
If at least one empty transmit buffer is found, function sends message on queue for transmission. If buffer is full, function returns 0 and CAN must be in Normal mode. 
Platform: window operating system
Machine: personal computer or Laptop
Delivery: The system development process and deliverable documents shall conform to the process and deliverables defined in the document "project proposal report" and " project progress report"
Standard: The standard of the final product shall be of undergraduate level
Security: This is a degree project having no strict security requirements.
Ethical: The application will not use any type of un-ethical electronic material while project development and execution.
Legislative: The application shall not use any private or confidential data, or network information that may infringe copyrights and/or confidentiality of any personnel not directly involved in this product.
We are providing the functional requirements which are as following
The hardware of the "multipoint communication of can bus "is intended to provide communication using CAN protocol. And this hardware is based on three main parts:
22.214.171.124 Temperature Node
We develop the temperature node on which it has a temperature program that runs on PIC 18F4580.it interface with Display node and gives temperature value to display node.
126.96.36.199 Speed Node
We develop the rpm node on which it has a rpm program that runs on PIC 18F4580.it interface with Display node and gives rpm value to display node.
188.8.131.52 Display Node
Display node shows the value of other two nodes (temperature &speed) which are interface with it. This node has a PIC18F4580 and 16*2 LCD.
The software of the "multipoint communication of can bus "is intended to generate the successful programs which are burn on microcontroller.
184.108.40.206 Mikro c
We choose mikroC language because mikroC provides a library (driver) for working with CAN module.
There are many control modules like Anti-lock Braking, Speed Sensor, Temperature Sensor, Engine Management, Traction Control, Air Conditioning Control, Central door locking, and Powered seat and Mirror controls in vehicles .But we are working on two modules Temperature sensor and measure the speed of dc motor for the sake of increase efficiency and reduce complexity using CAN BUS.
Figure 4.1 Block diagram of CAN BUS 
The Architecture diagram for hardware module is shown in fig 4.2.
Figure 4.2 Architecture Overview Diagram 
Following are the modules constituting the Multi point communication of CAN BUS to be developed. Please note that we are documenting only the salient properties and methods of each module to keep the description simple and more readable.
PIC Microcontroller CAN Interface
Any type of PIC microcontroller can be used in CAN bus-based projects, but some PIC microcontrollers (e.g., PIC18F458) have built-in CAN modules, which can simplify the design of CAN bus-based systems. Microcontrollers with no built-in CAN modules can also be used in CAN bus applications, but additional hardware and software are required, making the design costly and also more complex.
Fig4.3.1a Can node with any pic microntroller
Fig 4.3.1b Can node with integrated can module 
Figure 4.3.2 PIC18F4580 
Three other microcontrollers are related to this family
P I C18F448
These devices are available in 28-pin, 40-pin and 44-pin packages. They are differentiated from PIC18f458 in four ways:
PIC18F4580 devices have twice the Flash program memory and data RAM of PIC18F448 devices (32 Kbytes and 1536 bytes vs.16 Kbytes and 768 bytes, respectively).
PIC18F258 & PIC18F248 devices implement 5 A/D channels, as opposed to 8 for PIC18F4580 devices.
PIC18F258 & PIC18F248 devices implement 3 I/O ports, while PIC18F4580 devices implement 5 I/O ports.
Only PIC18F4580 & PIC18F448 devices implement the Enhanced CCP (Capture/Compare/PWM) module, analogy comparators and the Parallel Slave Port.
Data Memory (RAM)
Table 4: PIC 18F4580 Specifications 
MCP2551 (Transreceiver) Overview
MCP2551 Transreceiver is a high speed CAN, fault-tolerant device which is serves as the interface between a CAN protocol controller and the physical bus.MCP2551 transreceiver provides differential transmit and receive capability for the CAN protocol controller and is fully companionable with ISO-11898 standard, with 24V requirements. MCP2551 transreceiver operate at speeds of up to 1 Mb/s. normally each node in a CAN system must have a device to change the digital signals generated by a CAN controller to signals suitable for transmission over the bus cabling (differential output). MCP2551 also provide a buffer between the CAN controller and the high-voltage spikes that can be generated on the CAN bus by outer source. 
Figure 4.3.3 MCP2551
Supports 1 Mb/s process
It Implement ISO 11898 model physical layer requirements
fit for 12 V and 24 V systems
It controlled outward slope for reduced RFI emissions
Detection of ground error (permanent dominant) on TXD input
Power-on reset & voltage brown-out protection
An unpowered node or brown-out incident will not disturb the CAN bus
Low current supply operation
Protection against damage because of short circuit conditions (positive or negative battery voltage)
Protection against high power transients
Its best function Automatic thermal shutdown protection
It support Up to 112 nodes
High noise exception due to differential bus implementation
Temperature ranges of MCP2551
Industrial (I): -40Â°C to +85Â°C
Extended (E): -40Â°C to +125Â°C 
There are a lot of sensors to measure the temperature. various sensors such as the thermocouples, RTDs, and thermistors are the older standard sensors and they are used extensively due to their huge advantages.
-270 to +2600
-200 to +600
-50 to +200
-40 to +125
Low Table 5:Temperature Sensors 
The new invention of sensors for example the integrated circuit sensors and radiation thermometry devices are popular only for narrow applications The selection of a sensor depends on the accuracy, the temperature range, speed of Response, thermal coupling, the environment (chemical, electrical, or physical), And the price.
Thermocouples are best matched to very low and very high temperature measurements. The typical measuring range is -270oC to +2600oC. Thermocouples are low price and very robust. They are able to use in most chemical and physical environments. External power is not required to drive them and the typical accuracy is + 10C.
RTDs are used in medium range temperatures, ranging from -200oC to +600oC they offer high accuracy, typically 0.2oC. RTDs can typically be used in most chemical and physical environments, but they are not as robust as the thermocouples. The operation of RTDs requires external power.
Thermistor are used in low to medium temperature applications, ranging from -50oC to +200oC They are not as robust as the thermocouples or the RTDs and they cannot easily be used in chemical environments. Thermistors are low price and their accuracy is around +0.2oC
We have used Thermistor in our project due to its big advantages
Advantages of Thermistor
The big advantages of thermistors compared with thermocouples and RTDs is their comparatively large change in resistance with temperature, typically -5%per oC
Thermistors is available in very small sizes and this makes for a very rapid response to temperature changes. features of thermistor is very important in temperature feedback control systems where a fast response is required.
One of the advantages of thermistor is, it can handle mechanical and thermal shock and vibration better than other types of temperature sensors.
Thermistors is used to sense the temperature of remote locations by long cables because the resistance of a long cable is unimportant compared to the relatively high resistance of a thermistor.
Thermistors price less than most of the other types of temperature sensors.
We have designed techno motor to measure the dc motor rpm.for this purpose we have selected two dc motors and joined both motor shafts, 1st motor is connected with a 9v battery while 2nd motor is connected with microcontroller.When dc motor which is connected with 9v battery ON its shaft helps the 2nd dc motor shaft to keep in motion. When shaft of 2nd dc motor revolve it generate variable voltages. Microcontroller pick these voltages apply A2D function on it and send this digital data on display node through CAN BUS.
CAN BUS Termination
CAN BUS is terminated to reduce signal reflections on the bus. ISO-11898 requires that the bus has a typical impedance of 120 ohms. The bus is able to terminate by one of the following methods
Biased split termination
In our project we have terminated CAN BUS by using standard termination method shown in figure a.
(a) Standard Termination (b) Split Termination
(c) Biased Termination 
Figure 4.3.6 Bus termination method
We have implemented our project in three stages.
Stage 1 Interfacing Temperature sensor Node with Display Node.
Stage 2 Interfacing Techno Motor with Pic Display Node.
Stage 3 Combine both Temperature sensor Node and Techno Motor with Display Node.
Interfacing Temperature sensor Node with Display Node.
First of all we have tried to communicate Temperature sensor (Node 1) with DISPLAY Node through Pic 18f4580 controller using CAN BUS. For that purpose we have to select a temperature sensor with gives continuous values without error, so we selected Termistor 103 which is easy to use .This hardware consist of two CAN nodes One node (called DISPLAY node) which requests the temperature every second from Node 1 and displays it on an LCD.Node 1 reads the temperature from thermistor and sends it to DISPLAY Node via CANBUS. This process is repeated continuously. These two nodes are connected via CAN cable which is less than half meter in length and cable is terminated with 120 ohms resistor so that sended message doesn't reflects back.
At display node side firstly we attach LCD with Pic18f4580 controller at Port D to see temperature values. Microcontroller is operated at 4Mhz frequency, so oscillator of 4 MHz is connected at ports(13 and 14) of microcontroller. Port 1 is MCLR input which is connected with 5V through 4.7Kohms resistor.CAN output ports (RB2/CANTX and RB3/CANRX) are connected with Mcp2551 ports (1 and 4) respectively and CANH and CANL outputs of Mcp2551 are connected directly to a CAN cable.
COLLECTOR node consists of a PIC18F4580 microcontroller with a built-in CAN module and is connected with MCP2551 transceiver through CAN output ports (RB2/CANTX and RB3/CANRX). The CANH and CANL outputs of Mcp2551 are connected directly to a cable. Crystal oscillator of 4Mhz is connected at port (13 and 14). The MCLR input is connected to port 1 of microcontroller through 4.7K ohms resistor.Thermistor is connected at AN0 of microcontroller .The sensor can measure temperature in the range of (-50 to +200)and generates an analog voltage which is equal to measured temperature approximately and sends the value to DISPLAY node.
Figure 5.1.2Hardware of Interfacing of Node1 with Display node
Interfacing Techno motor with Display Node.
After successful communication of temperature sensor with PIC 18f4580 now we have tried to communicate techno motor with Pic18f4580 controller via CANBUS.This hardware also consist of two CAN nodes One node (called DISPLAY node) requests the revolution per minute of motor every second and displays it on an LCD. This process is repeated continuously. Node 2 detects the speed of techno motor and send it DISPLAY node via CANBUS. AS we told you earlier these two nodes are connected via CAN cable which is less than half meter in length and cable is terminated with 120 ohms resistor.
As we tell you earlier in case of temperature sensor, that LCD is attached with Pic 18f4580 controller at Port D of DISPLAY node to show temperature values but now it shows RPM of techno motor in this process. Crystal oscillator of 4Mhz is connected at ports(13 and 14)of microcontroller. Port 1 is MCLR input which is connected with 5V through 4.7Kohms resistor.CAN output ports (RB2/CANTX and RB3/CANRX) are connected with Mcp2551 ports (1 and 4) respectively and mcp2551 ports (6/ CANH and 7/ CANL) are connected to CAN cable.
COLLECTOR node consists of a PIC18F4580 microcontroller with a built-in CAN module and is connected with MCP2551 transceiver through CAN output ports (RB2/CANTX and RB3/CANRX). The MCLR input is connected to port 1 of microcontroller through 4.7K ohms resistor.Technomotor is connected at AN0 of microcontroller.
Figure 5.2.2 Hardware of Interfacing of Node2 with Display node
Combine both Temperature sensor Node and Techno Motor with Display Node.
Now at stage 3 we have to connect both temperatures sensor and techno motor via CAN cable to Display node to show our respective values on LCD which comes from Node1 and Node 2 via CANBUS. But in this case there is little bit difficulty to get data from node 1 and node 2 simultaneously for that we have to give priority to that node which gives its value on lcd when updated. Due to this we give priority to Temperature node 1 because CAN protocol is massage based not address based every node send its data continuously on CAN cable and lcd shows that data which updated continuously. As we all know RPM vary continuously it always shows on lcd for that purpose we give priority to Temperature Node 1 when its message comes Rpm message stops or discard and temperature values shows on lcd. In this way we also avoid collision and takes data of both nodes on Lcd without error. We already made hardware during stage 1 and 2,in this stage we only connect them in such a ways that CANH of both Nodes (1 and 2) are connected and CANL of both Nodes(1 and 2) are connected respectively on CAN cable. After connection we run our project to obtain values of temperature and motor on lcd .After start up both nodes (1 and 2) follow CAN protocol of message based and start sending messages. Display Nodes request the Nodes to send him data and the node which accept that message send its data to display node. This process repeats continuously and we see our result on Lcd by changing the Techno Motor speed using variable resistance as well as Temperature values by heating temperature sensor .
Figure 5.3 Combine both Temperature sensor Node and Techno Motor with Display Node.