My Project Report

Introduction
INTRODUCTION
Automation today has penetrated in almost all types of industries and especially manufacturing industries. Not only the simple and mundane tasks, but also many complex tasks are now being achieved using automotive systems. A large bulk of responsibilities has now been shifted from humans to these automotive systems. Managers expect the systems to be reliable and precise with minimal human interference. Though the field of automation is not new, it has never been so sophisticated and developed. With the increasing demand from industries, automation sector is developing at an exponential rate. Any automation system however cannot function on its own. With the increasing number of tasks assigned to an automated system, the need for decentralization and distribution arises. Automotive systems, like humans distribute work among sub systems. And for any distributed system to work in proper harmony and order there should be a provision for effective communication. Just as humans need to communicate to work together, similarly machines also need to communicate to work in harmony. Communication within an industry can be classified in many levels. The lowest layer consists of sensors and actuators communicating with the controllers. Then comes the layer where controllers communicate among themselves. The data from controllers is also communicated to higher level human interfaces for display and control. This then properly presents and links the data as reports etc to the management. Thus there is a need of multiple communication channels within an industry. There are various ways in which this need of communication is met within an industry. Just a many different human languages are bound by different set of rules; there are different ways in which controllers can communicate guided by different set of rules. Before going into a detailed
discussion about these various rules and ways of communication, let us first have a look at the basics an automated system.
___________________________________________________________________________ __S. B. M. Polytechnic 1 VII Semester
Please purchase 'e-PDF Converter and Creator' on http://www.e-pdfconverter.com to remove this message.
Automated System Basics
AUTOMATED SYSTEM BASICS

Any automated system is basically must contain three components Input Processing part Output
A basic automated system is a one which takes an input of the factor needed to be controlled in the process. This input is then examined and processed by the processing part. According to the logic of the processing part, the output is then given. This forms the most basic form of automated system. Let us discuss each component in some more detail.
Inputs:
Any automated system operates according to the current condition of the factor it is monitoring. Suppose we take an example of a simple temperature control. Here the output of the temperature controller is always a function of the input i.e. the temperature. Hence the output mostly depends upon the state of the input(s) of the system. Hence these inputs need to be monitored. An automation system today means an electronic system with inputs and outputs and an electronic programmable processor (most probably a microprocessor or a microcontroller). These devices work on electrical signals, mostly digital. Hence the basic need of any input unit in an automated system would be to provide an interface between the real world events and these electronic components. Hence, as seen, inputs are more precisely devices which convert the mechanical events (real world events) into electrical signals. These devices are more specifically called transducers. They are specifically meant for converting the mechanical or other types of energy into electrical energy. These transducers, coupled with other additional components form a sensor. Sensors, as name suggest, are used in an automated system to sense the thing happening. It is by the sensor
_____________________________________________________________________________ S. B. M. Polytechnic 2 VII Semester
inputs that the processor knows what is going on in the system. Hence sensors form a very important input. Sensors are discussed more elaborately in later sections. Now, let us turn to the next component.
Processing part:
The processing part forms the main heart any automated system. It is the part which controls all the processes in the system by giving various signals which depend mostly on the inputs. The processing part essentially plays the same part as the CPU of a computer. It processes the data it continuously receives/fetches from the inputs according various programmed functions/logics and provides outputs accordingly. In most of the automated systems, the processing part is formed of a microprocessor/microcontroller unit. Easy programmability and simple and fast operation are the key reasons why they are opted more. However, systems requiring simple control logic also opt for some more economical options like Relay Logic, diode logic, etc. However c/p based systems still are preferred more at places where the control logic is complex and/or the processing time is critical. The simplest example of a p based control systems are PLC (Programmable Logic Circuit). PLCs are nothing but embedded systems of a processor, some memories, and some input/output interfaces. They are widely used because of the programming flexibility they offer, they can be easily programmed by the user for any logic which is to be implemented. But PLCs more aptly can be said as a complete automated system consisting of all three components rather than just a processing power. The processing part therefore forms the core part of any automated system where all decisions are made. Its performance is of major importance for success of any system.
Output:
Outputs, same as inputs, are for interfacing the real world with the electrical world. Outputs convert the various electrical signals given by the processing part (mostly digital) into the form of energy which can be implemented for control of other mechanical part. Output circuits generally are DAC (Digital to Analogue Converter) which convert the digital values given by the processing part into real world analogue values which further can be used to drive/control other devices. The output circuits can also contain other interfacing circuits for some higher level interface. Output circuits hence play a role of allowing the system to communicate with/control the outer world. To make output of one system
compatible with other system with different design, there are many protocols, a set of rules which enables each different unit control and communicate with other units with ease. That was basics of automated systems in brief. Now let us look at the basics of communication in industries.
Industrial Communication
INDUSTRIAL COMMUNICATION
A complex automated industrial system say a manufacturing assembly line usually needs an organized hierarchy of controller systems to function. In this hierarchy there is usually a Human Machine Interface (HMI) at the top, where an operator can monitor or operate the system. This is typically linked to a middle layer of programmable logic controllers (PLC) via a non time critical communications system (e.g. Ethernet). At the bottom of the control chain is the fieldbus which links the PLCs to the components which actually do the work such as sensors, actuators, electric motors, console lights, switches, valves and contactors.
Fieldbus is an industrial network system for real-time distributed control. It is a way to connect instruments in a manufacturing plant. Fieldbus works on a network structure which typically allows daisy-chain, star, ring, branch, and tree network topologies. Hence fieldbus is equivalent to a serial communication link which allows many controllers to be linked with each other with only minimum wiring. This makes the use of fieldbus easy and cost saving. Some advantages of fieldbus system are: Simple structure Facilitates effective communication De-centralization Easy Trouble-shooting & diagnostics More economical and cost savings
Fieldbus protocols: There are various protocols for communication using field bus. These protocols generally differ in the way in which they define data frames, bit timing, bit logic, arbitration logic etc. Some of the major fieldbus protocols defined are as follows Actuator Sensor Interface (ASI): ASI: Actuator Sensor Interface. Used to network sensors and actuators. ASi is a two wire interface; Power and Data. Based around ProfiSafe [developed from Profibus DP].ASI bus was developed by Siemens Automation. This is a Unshielded 2-wire [Yellow cable], Unterminated, Ungrounded Sensor Bus. The Topology may be Bus, Ring, Tree, or Star at up to 100 meters. Power is provided by a 24V floating DC supply, which can supply at least 8 A over the network. The AS-Interface is an open standard based on IEC 62026-2 and EN 50295. CAN Bus: The Controller Area Network (CAN) specification defines the Data Link Layer; ISO 11898 defines the Physical Layer. The CAN interface is an asynchronous transmission scheme controlled by start and stop bits at the beginning and end of each character. This interface is used, employing serial binary interchange. Information is passed from transmitters to receivers in a data frame. The data frame is composed of an Arbitration field, Control field, Data field, CRC field, ACK field. The frame begins with a 'Start of frame', and ends with an 'End of frame' space. The data field may be from 0 to 8 bits.
Industrial Ethernet: Industrial Ethernet and the "conventional" Ethernet both share the same physical and MAC levels but use different protocols. Profibus:
Process Field Bus: Based on EIA-485 and EN-50170, using a non-powered 2-wire bus. The connection is half-duplex over a shielded, twisted-pair cable. The bus will use either a 9 pin D (DIN 19245) or 12mm connector (EC50170). Data rates may be from 9600 to 12M baud, with message lengths of 244 bytes. At 12 Mbps the maximum distance is 100 meters. A maximum distance of 1200 meters may be achieved using a maximum data rate of 94kps. Up to 126 nodes may be connected in up two 5 segments, which are separated by repeaters. Each segment may contain up to 32 nodes which are laid out in a single node. Each node has one master and slave devices These are only the major protocols. There are many variants and higher level protocols inside these description of which is outside the scope of this report. Each protocol has its specific advantages and disadvantages. They also have specific levels of implementation. These are the levels for which these protocols were developed particularly. A level wise division of these protocols is as shown
ETHERNET-IP
Control level Production level Remote bus level
PROFIBUS
CAN
Process and Control level
AS-INTERFACE
Actuator and Sensor level
Hence it can be seen that ASI is generally suited for remote I/O level whereas Ethernet is suited for production and management level. This levels are decided on many factors like the amount of data transferred, time criticality of protocol etc. For example Ethernet can transfer large chunks of data but is not time critical as CAN. Hence Ethernet is suited for higher level communication where it does not matter if input data gets delayed by few milliseconds. However at sensor
and controller level, a delay of milliseconds in transferring process related data is not acceptable. Therefore protocols which can transmit small data packets but without wasting time are needed. CAN is one such protocol and hence it is used at control level. On this basis various protocols are divided in different levels of their application. However these levels are not fixed and can be changed if and when needed. All these protocols are not supposed to be vendor specific and must define a common global standard. Hence all these are developed such that they are compatible with the ISO-OSI model. A short description of the ISO-OSI standard is given in next chapter.
ISO-OSI Model
ISO-OSI MODEL
The Open Systems Interconnect basic reference model is an abstract description for layered communications and network protocol design. It was developed as part of the Open Systems Interconnection initiative. In its most basic form, it divides network architecture into seven layers. A layer is a collection of conceptually similar functions that provide services to the layer above it and receives service from the layer below it. The seven layers from top to Bottom are as follows:
Layer 1 Physical: Physical layer defines the cable or physical medium itself, e.g., thin net, thick net, unshielded twisted pairs (UTP). All media are functionally equivalent. The main difference is in convenience and cost of installation and maintenance. Converters from one media to another operate at this level.
Layer 2 - Data Link:

ISO-OSI Model
Data Link layer defines the format of data on the network. A network data frame, aka packet, includes checksum, source and destination address, and data. The largest packet that can be sent through a data link layer defines the Maximum Transmission Unit (MTU). The data link layer handles the physical and logical connections to the packet's destination, using a network interface. A host connected to an Ethernet would have an Ethernet interface to handle connections to the outside world, and a loop back interface to send packets to itself. Layer 3 Network: The network layer controls the operation of the subnet. A key design issue is determining how packets are routed from source to destination. Routes can be based on static tables that are wired in to the network and rarely changed. They can also be determined at the start of each conversation. Finally they can be highly dynamic, being determined a new for each packet, to reflect the current network load. If too many packets are present in the subnet at the same time, they will get in one anothers way, forming bottlenecks. The control of such congestion also belongs to the network layer. Layer 4 Transport: The basic function of the transport layer is to accept data from above, split it up in to smaller units if need be, pass these to network layer, and ensures that the pieces all arrive correctly at the other end. Furthermore, all this must be done efficiently and in a way that isolates the upper layers from the inevitable changes in the hardware technology. The transport layer also determines what type of service to provide to the session layer and ultimately to the users of network.
Layer 5 - Session: The session layer allows users on defferent machines to establish sessions between them. Session offers various services including dialog control token management and synchronization. Layer 6 - Presentation: Unlike lower layers, which are mostly concerned with moving bits around, the presentation layer is concerned with the syntax and semantics of the information transmitted. In order to make it possible for computers with different data representations to communicate, the data structures to be exchanged can be defined in an abstract way, along with a standard encoding to be used on the wire.
ISO-OSI Model
The presentation layer manages these abstract data structures and allows higher level data structures, to be defined and exchanged. Layer 7 Application: The application layer contains a variety of protocols that are commonly needed by the users. One widely used application protocol is HTTP (Hyper Text Transfer Protocol), which is the basis for the World Wide Web. When a browser wants a web page, it sends the name of the page it wants to the server-using HTTP. The server then sends the page back. Other application protocols are used for file transfer, electronic mail, and network news.
Controller Area Network
CONTROLLER AREA NETWORK

1.) INTRODUCTION
The Controller Area Network (CAN) is a serial communications protocol which efficiently supports distributed realtime control with a very high level of security. Its domain of application ranges from high speed networks to low cost multiplex wiring. In automotive electronics, engine control units, sensors, anti-skid systems, etc. are connected using CAN with bitrates up to 1 Mbit/s. At the same time it is cost effective to build into vehicle body electronics, e.g. lamp clusters, electric windows etc. to replace the wiring harness otherwise required. The intention of this specification is to achieve compatibility between any two CAN implementations. Compatibility, however, has different aspects regarding e.g. electrical features and the interpretation of data to be transferred. To achieve design transparency and implementation flexibility CAN has been subdivided into different layers. The (CAN-) object layer The (CAN-) transfer layer The Physical layer. The object layer and the transfer layer comprise all services and functions of the data link layer defined by the ISO/OSI model. The scope of the object layer includes Finding which messages are to be transmitted, Deciding which messages received by the transfer layer are actually to be used, Providing an interface to the application layer related hardware. There is much freedom in defining object handling. The scope of the transfer layer mainly is the transfer protocol, i.e. controlling the framing, performing arbitration, error checking, error signaling and fault confinement. Within the transfer layer it is decided whether the bus is free for starting a new transmission or whether a reception is just starting. Also some general features of the bit timing are regarded as part of the transfer layer. It is in the nature of the transfer layer that there is no freedom for modifications.
The scope of the physical layer is the actual transfer of the bits between the different nodes with respect to all electrical properties. Within one network the physical layer, of course has to be the same for all nodes. There may be, however, much freedom in selecting a physical layer.
2.) BASIC CONCEPTS

CAN has the following properties: Prioritization of messages Guarantee of latency times Configuration flexibility Multicast reception with time synchronization System wide data consistency Multimaster Error detection and error signaling 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.
The Physical Layer defines how signals are actually transmitted. Within this specification the physical layer is not defined so as to allow transmission medium and signal level implementations to be optimized for their application. The Transfer Layer represents the kernel of the CAN protocol. It presents messages received to the object layer and accepts messages to be transmitted from the object layer. The transfer layer is responsible for bit timing and synchronization, message framing, arbitration, acknowledgement, error detection and signaling, and fault confinement.
The Object Layer is concerned with message filtering as well as status and message handling. The scope of this specification is to define the transfer layer and the consequences of the CAN protocol on the surrounding layers. Messages Information on the bus is sent in fixed format messages of different but limited length. When the bus is free any connected unit may start to transmit a new message. Information Routing In CAN systems a CAN node does not make use of any information about the system configuration (e.g. station addresses). This has several important consequences. System Flexibility: Nodes can be added to the CAN network without requiring any change in the software or hardware of any node and application layer. Message Routing: The content of a message is named by an IDENTIFIER. The IDENTI- FIER does not indicate the destination of the message, but describes the meaning of the data, so that all nodes in the network are able to decide by MESSAGE FILTERING whether the data is to be acted upon by them or not. Multicast: As a consequence of the concept of MESSAGE FILTERING any number of nodes can receive and simultaneously act upon the same message. Data Consistency: Within a CAN network it is guaranteed that a message is simultaneously accepted either by all nodes or by no node. Thus data consistency of a system is achieved by the concepts of multicast and by error handling. Bit rate The speed of CAN may be different in different systems. However, in a given system the bit-rate is uniform and fixed.
Priorities The IDENTIFIER defines a static message priority during bus access. Remote Data Request By sending a REMOTE FRAME a node requiring data may request another node to send the corresponding DATA FRAME. The DATA FRAME and the corresponding REMOTE FRAME are named by the same IDENTIFIER. Multimaster When the bus is free any unit may start to transmit a message. The unit with the message of highest priority to be transmitted gains bus access. Arbitration Whenever the bus is free, any unit may start to transmit a message. If 2 or more units start transmitting messages at the same time, the bus access conflict is resolved by bitwise arbitration using the IDENTIFIER. The mechanism of arbitration guarantees that neither information nor time is lost. If a DATA FRAME and a REMOTE FRAME with the same IDENTIFIER are initiated at the same time, the DATA FRAME prevails over the REMOTE FRAME. During arbitration every transmitter compares the level of the bit transmitted with the level that is monitored on the bus. If these levels are equal the unit may continue to send. When a recessive level is sent and a dominant level is monitored (see Bus Values), the unit has lost arbitration and must withdraw without sending one more bit. Safety In order to achieve the utmost safety of data transfer, powerful measures for error detection, signaling and self-checking are implemented in every CAN node. Error Detection For detecting errors the following measures have been taken: - Monitoring (transmitters compare the bit levels to be transmitted with the bit levels detected on the bus) - Cyclic Redundancy Check - Bit Stuffing - Message Frame Check Performance of Error Detection The error detection mechanisms have the following properties: - All global errors are detected.
- All local errors at transmitters are detected. - Up to 5 randomly distributed errors in a message are detected. - Burst errors of length less than 15 in a message are detected. - Errors of any odd number in a message are detected. Total residual error probability for undetected corrupted messages: less than message error rate 4.7 X 10-17 Error Signaling and Recovery Time Corrupted messages are flagged by any node detecting an error. Such messages are aborted and will be retransmitted automatically. The recovery time from detecting an error until the start of the next message is at most 29 bit times, if there is no further error. Fault Confinement CAN nodes are able to distinguish short disturbances from permanent failures. Defective nodes are switched off. Connections The CAN serial communication link is a bus to which a number of units may be connected. This number has no theoretical limit. Practically the total number of units will be limited by delay times and/or electrical loads on the bus line. Single Channel The bus consists of a single bidirectional channel that carries bits. From this data resynchronization information can be derived. The way in which this channel is implemented is not fixed in this specification. E.g. single wire (plus ground), two differential wires, optical fibers, etc. Bus values The bus can have one of two complementary logical values: dominant or recessive. During simultaneous transmission of dominant and recessive bits, the resulting bus value will be dominant. For example, in case of a wired-AND implementation of the bus, the dominant level would be represented by a logical 0 and the recessive level by a logical 1. Physical states (e.g. electrical voltage, light) that represent the logical levels are not given in this specification. Acknowledgement
All receivers check the consistency of the message being received and will acknowledge a consistent message and flag an inconsistent message.
Sleep Mode / Wake-up To reduce the systems power consumption, a CAN-device may be set into sleep mode with-out any internal activity and with disconnected bus drivers. The sleep mode is finished with a wake-up by any bus activity or by internal conditions of the system. On wake-up, the internal activity is restarted, although the transfer layer will be waiting for the systems oscillator to stabilize and it will then wait until it has synchronized itself to the bus activity (by checking for eleven consecutive recessive bits), before the bus drivers are set to "onbus" again. In order to wake up other nodes of the system, which are in sleepmode, a special wake-up message with the dedicated, lowest possible IDENTIFIER (rrr rrrd rrrr; r = recessive, d = dominant) may be used.
3.) FRAME TYPES

Message transfer is manifested and controlled by four different frame types: A DATA FRAME carries data from a transmitter to the receivers. A REMOTE FRAME is transmitted by a bus unit to request the transmission of the DATA FRAME with the same IDENTIFIER. An ERROR FRAME is transmitted by any unit on detecting a bus error. An OVERLOAD FRAME is used to provide for an extra delay between the preceding and the succeeding DATA or REMOTE FRAMEs. DATA FRAMEs and REMOTE FRAMEs are separated from preceding frames by an INTERFRAME SPACE.
DATA FRAME A DATA FRAME is composed of seven different bit fields: START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD, CRC FIELD, ACK FIELD, END OF FRAME. The DATA FIELD can be of length zero.
START OF FRAME marks the beginning of DATA FRAMES and REMOTE FRAMES. It consists of a single dominant bit. A station is only allowed to start transmission when the bus is idle (see BUS IDLE). All stations have to synchronize to the leading edge caused by START OF FRAME (see HARD SYNCHRONIZATION) of the station starting transmission first. ARBITRATION FIELD The ARBITRATION FIELD consists of the IDENTIFIER and the RTRBIT.
IDENTIFIER The IDENTIFIERs length is 11 bits. These bits are transmitted in the order from ID-10 to ID-0. The least significant bit is ID-0. The 7 most significant bits (ID-10 - ID-4) must not be all recessive. RTR BIT Remote Transmission Request BIT. In DATA FRAMEs the RTR BIT has to be dominant. Within a REMOTE FRAME the RTR BIT has to be recessive. CONTROL FIELD The CONTROL FIELD consists of six bits. It includes the DATA LENGTH CODE and two bits reserved for future expansion. The reserved bits have to be sent dominant. Receivers accept dominant and recessive bits in all combinations. DATA LENGTH CODE The number of bytes in the DATA FIELD is indicated by the DATA LENGTH CODE. This DATA LENGTH CODE is 4 bits wide and is transmitted within the CONTROL FIELD.
Coding of the number of data bytes by the DATA LENGTH CODE
DATA FIELD The DATA FIELD consists of the data to be transferred within a DATA FRAME. It can contain from 0 to 8 bytes, which each contain 8 bits which are transferred MSB first. CRC FIELD contains the CRC SEQUENCE followed by a CRC DELIMITER.
CRC SEQUENCE The frame check sequence is derived from a cyclic redundancy code best suited for frames with bit counts less than 127 bits (BCH Code). In order to carry out the CRC calculation the polynomial to be divided is defined as the polynomial, the coefficients of which are given by the destuffed bit stream consisting of START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD (if present) and, for the 15 lowest coefficients, by 0. This polynomial is divided (the coefficients are calculated modulo-2) by the generator-polynomial: X 15 + X 14 + X 10 + X 8 + X 7 + X 4 + X 3 + 1. The remainder of this polynomial division is the CRC SEQUENCE transmitted over the bus. In order to implement this function, a 15 bit shift register CRC_RG(14:0) can be used. CRC DELIMITER The CRC SEQUENCE is followed by the CRC DELIMITER which consists of a single recessive bit. ACK FIELD The ACK FIELD is two bits long and contains the ACK SLOT and the ACK DELIMITER. In the ACK FIELD the transmitting station sends two recessive bits. A RECEIVER which has received a valid message correctly, reports this to the TRANSMITTER by sending a dominant bit during the ACK SLOT (it sends ACK).
ACK SLOT All stations having received the matching CRC SEQUENCE report this within the ACK SLOT by superscribing the recessive bit of the TRANSMITTER by a dominant bit. ACK DELIMITER The ACK DELIMITER is the second bit of the ACK FIELD and has to be a recessive bit. As a consequence, the ACK SLOT is surrounded by two recessive bits (CRC DELIMITER, ACK DELIMITER). END OF FRAME Each DATA FRAME and REMOTE FRAME is delimited by a flag sequence consisting of seven recessive bits.
REMOTE FRAME
A station acting as a RECEIVER for certain data can initiate the transmission of the respective data by its source node by sending a REMOTE FRAME. A REMOTE FRAME is composed of six different bit fields: START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, CRC FIELD, ACK FIELD, END OF FRAME. Contrary to DATA FRAMEs, the RTR bit of REMOTE FRAMEs is recessive. There is no DATA FIELD, independent of the values of the DATA LENGTH CODE which may be signed any value within the admissible range 0...8. The value is the DATA LENGTH CODE of the corresponding DATA FRAME.
The polarity of the RTR bit indicates whether a transmitted frame is a DATA FRAME (RTR bit dominant) or a REMOTE FRAME (RTR bit recessive).
ERROR FRAME
The ERROR FRAME consists of two different fields. The first field is given by the superposition of ERROR FLAGs contributed from different stations. The following second field is the ERROR DELIMITER.
In order to terminate an ERROR FRAME correctly, an error passive node may need the bus to be bus idle for at least 3 bit times (if there is a local
error at an error passive receiver). Therefore the bus should not be loaded to 100%. ERROR FLAG There are 2 forms of an ERROR FLAG: an ACTIVE ERROR FLAG and a PASSIVE ERROR FLAG. 1. The ACTIVE ERROR FLAG consists of six consecutive dominant bits. 2. The PASSIVE ERROR FLAG consists of six consecutive recessive bits unless it is overwritten by dominant bits from other nodes. An error active station detecting an error condition signals this by transmission of an ACTIVE ERROR FLAG. The ERROR FLAGs form violates the law of bit stuffing (see CODING) applied to all fields from START OF FRAME to CRC DELIMITER or destroys the fixed form ACK FIELD or END OF FRAME field. As a consequence, all other stations detect an error condition and on their part start transmission of an ERROR FLAG. So the sequence of dominant bits which actually can be monitored on the bus results from a superposition of different ERROR FLAGs transmitted by individual stations. The total length of this sequence varies between a minimum of six and a maximum of twelve bits. An error passive station detecting an error condition tries to signal this by transmission of a PASSIVE ERROR FLAG. The error passive station waits for six consecutive bits of equal polarity, beginning at the start of the PASSIVE ERROR FLAG. The PASSIVE ERROR FLAG is complete when these 6 equal bits have been detected. ERROR DELIMITER The ERROR DELIMITER consists of eight recessive bits. After transmission of an ERROR FLAG each station sends recessive bits and monitors the bus until it detects a recessive bit. Afterwards it starts transmitting seven more recessive bits. OVERLOAD FRAME The OVERLOAD FRAME contains the two bit fields OVERLOAD FLAG and OVERLOAD DELIMITER. There are two kinds of OVERLOAD conditions, which both lead to the transmission of an OVERLOAD FLAG: 1. The internal conditions of a receiver, which requires a delay of the next DATA FRAME or REMOTE FRAME.
2. Detection of a dominant bit during INTERMISSION. The start of an OVERLOAD FRAME due to OVERLOAD condition 1 is only allowed to be started at the first bit time of an expected INTERMISSION, whereas OVERLOAD FRAMEs due to OVERLOAD condition 2 start one bit after detecting the dominant bit.
At most two OVERLOAD FRAMEs may be generated to delay the next DATA or REMOTE FRAME. OVERLOAD FLAG consists of six dominant bits. The overall form corresponds to that of the ACTIVE ERROR FLAG. The OVERLOAD FLAGs form destroys the fixed form of the INTERMISSION field. As a consequence, all other stations also detect an OVERLOAD condition and on their part start transmission of an OVERLOAD FLAG. (In case that there is a dominant bit detected during the 3rd bit of INTERMISSION locally at some node, the other nodes will not interpret the OVERLOAD FLAG correctly, but interpret the first of these six dominant bits as START OF FRAME. The sixth dominant bit violates the rule of bit stuffing causing an error condition). OVERLOAD DELIMITER consists of eight recessive bits. The OVERLOAD DELIMITER is of the same form as the ERROR DELIMITER. After transmission of an OVERLOAD FLAG the station monitors the bus until it detects a transition from a dominant to a recessive bit. At this point of time every bus station has finished sending its OVERLOAD FLAG and all stations start transmission of seven more recessive bits in coincidence.
INTERFRAME SPACING DATA FRAMEs and REMOTE FRAMEs are separated from preceding frames whatever type they are (DATA FRAME, REMOTE FRAME, ERROR FRAME, OVERLOAD FRAME) by a bit field called INTERFRAME SPACE. In contrast, OVERLOAD FRAMEs and ERROR FRAMEs are not preceded by an INTERFRAME SPACE and multiple OVERLOAD FRAMEs are not separated by an INTERFRAME SPACE. INTERFRAME SPACE Contains the bit fields INTERMISSION and BUS IDLE and, for error passive stations, which have been TRANSMITTER of the previous message, SUSPEND TRANSMISSION. For stations which are not error passive or have been RECEIVER of the previous message:
For error passive stations which have been TRANSMITTER of the previous message:
INTERMISSION Consists of three recessive bits. During INTERMISSION no station is allowed to start transmission of a DATA FRAME or REMOTE FRAME. The only action to be taken is signaling an OVERLOAD condition.
BUS IDLE The period of BUS IDLE may be of arbitrary length. The bus is recognized to be free and any station having something to transmit can access the bus. A message, which is pending for transmission during the transmission of another message, is started in the first bit following INTERMISSION. The detection of a dominant bit on the bus is interpreted as a START OF FRAME. SUSPEND TRANSMISSION After an error passive station has transmitted a message, it sends eight recessive bits following INTERMISSION, before starting to transmit a further message or recognizing the bus to be idle. If meanwhile a transmission (caused by another station) starts, the station will become receiver of this message.
4.) CODING
BIT STREAM CODING The frame segments START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD and CRC SEQUENCE are coded by the method of bit stuffing. Whenever a transmitter detects five consecutive bits of identical value in the bit stream to be transmitted it automatically inserts a complementary bit in the actual transmitted bit stream. The remaining bit fields of the DATA FRAME or REMOTE FRAME (CRC DELIMITER, ACK FIELD, and END OF FRAME) are of fixed form and not stuffed. The ERROR FRAME and the OVERLOAD FRAME are of fixed form as well and not coded by the method of bit stuffing. The bit stream in a message is coded according to the Non-Return-to Zero (NRZ) method. This means that during the total bit time the generated bit level is either dominant or recessive.
5.) ERROR HANDLING

Error Detection There are 5 different error types (which are not mutually exclusive): BIT ERROR A unit that is sending a bit on the bus also monitors the bus. A BIT ERROR has to be detected at that bit time, when the bit value that is monitored is different from the bit value that is sent. An exception is the sending of a recessive bit during the stuffed bit stream of the ARBITRATION FIELD or during the ACK
SLOT. Then no BIT ERROR occurs when a dominant bit is monitored. A TRANSMITTER sending a PASSIVE ERROR FLAG and detecting a dominant bit does not interpret this as a BIT ERROR. STUFF ERROR A STUFF ERROR has to be detected at the bit time of the 6th consecutive equal bit level in a message field that should be coded by the method of bit stuffing. CRC ERROR The CRC sequence consists of the result of the CRC calculation by the transmitter. The receivers calculate the CRC in the same way as the transmitter. A CRC ERROR has to be detected, if the calculated result is not the same as that received in the CRC sequence. FORM ERROR A FORM ERROR has to be detected when a fixed-form bit field contains one or more illegal bits. ACKNOWLEDGMENT ERROR An ACKNOWLEDGMENT ERROR has to be detected by a transmitter whenever it does not monitor a dominant bit during the ACK SLOT.
Error Signaling A station detecting an error condition signals this by transmitting an ERROR FLAG. For an error active node it is an ACTIVE ERROR FLAG, for an error passive node it is a PASSIVE ERROR FLAG. Whenever a BIT ERROR, a STUFF ERROR, a FORM ERROR or an ACKNOWLEDGMENT ERROR is detected by any station, transmission of an ERROR FLAG is started at the respective station at the next bit. Whenever a CRC ERROR is detected, transmission of an ERROR FLAG starts at the bit following the ACK DELIMITER, unless an ERROR FLAG for another condition has already been started.
CANopen Protocol
CANopen PROTOCOL
CANopen is a communication protocol and device profile specification for embedded systems used in automation. In terms of the OSI model, CANopen implements the layers above and including the network layer. The CANopen standard consists of an addressing scheme, several small communication protocols and an application layer defined by a device profile. The communication protocols have support for network management, device monitoring and communication between nodes, including a simple transport layer for message segmentation/desegmentation. The lower level protocol implementing the data link and physical layers is usually Controller Area Network (CAN), although devices using some other means of communication (such as EtherCAT) can also implement the CANopen device profile. Every CANopen device has to implement certain standard features in its controlling software.

A Communication unit implements the protocols for messaging with the other nodes in the network Starting and resetting the device is controlled via a state machine. It must contain the states Initialization, Pre-operational, Operational and Stopped. The transitions between states are made by issuing a network management (NMT) communication object to the device. The object dictionary is an array of variables with a 16-bit index. Additionally, each variable can have an 8-bit subindex. The variables can be used to configure the device and reflect its environment, i.e. contain measurement data. The application part of the device actually performs the desired function of the device, after the state machine is set to the operational state. The application is configured by variables in the object directory and the data is sent and received through the communication layer.
CANopen Protocol
The protocol layer interactions describe the communication on the different layers. On the CANopen application layer the devices exchanges communication and application objects. All these objects are accessible via a 16bit index and 8-bit sub-index. These communication objects (COB) are mapped to one or more CAN frames with pre-defined or configured Identifiers. The CAN physical layer specifies the bit level including the bit-timing.
CANopen Protocol
A CANopen device can be divided into three parts: Communication interface and protocol software Object dictionary Process interface and application program The communication interface and protocol software provide services to transmit and to receive communication objects over the bus. The object dictionary describes all data types, communication objects and application objects used in this device. It is the interface to the application software. The application program provides the internal control functionality as well as the interface to the process hardware interfaces.
The CANopen object dictionary
The object dictionary is the heart of any CANopen device. The object dictionary is essentially a grouping of objects accessible via the network in an ordered pre defined fashion. Each object within the dictionary is addressed using a 16-bit index and an 8-bit subindex. The overall layout of the standard object dictionary conforms with other industrial fieldbus concepts.
CANopen Protocol
The object dictionary concept caters for optional device features, which means a manufacturer does not have to provide certain extended functionality on his devices but if he wishes to do so he must do it in a pre-defined fashion. By defining object dictionary entries for anticipated increased functionality in an optional category manufacturers wishing to implement enhanced functionality will all do so in the same way. The objects in the range 1000h to 1FFFh describe the communication behavior of the device. The objects in the index ranges 2000h to 5FFFh and 6000h to 9FFFh describe the application behavior either in a manufacturer specific way or in a standardized way by following a CANopen device or application profile. As the index range for standardized CANopen device and application profiles is divided into eight sections, it is possible to provide up to eight device/application profile implementations within one CANopen device. Network variables and system variables are arranged in the index range A000h to BFFFFh according to the related CiA interface specification.
A 16-bit index is used to address all entries within the object dictionary. In case of a simple variable this references the value of this variable directly. In case of records and arrays however, the index addresses the whole data structure.
CANopen Protocol
For complex object dictionary entries such as arrays or records with multiple data fields the sub-index references fields within a data structure pointed to by the main index. For example on a single channel RS-232 interface module there may exist a data-structure at index 6092h which defines the communication parameters for that module. This structure may contain fields for baud-rate, number of data bits, number of stop bits and parity type. The sub-index concept can be used to access these individual fields as shown above. To allow individual elements of structures of data to be accessed via the network a sub-index has been defined. The value for the sub-index is always zero.
Communication objects
CANbus, the physical layer of CANopen, can only transmit short packages consisting of an 11-bit id, remote transmission request (RTR) bit and a 0 to 8 bytes of data. The CANopen standard divides the 11-bit CAN frame id into a 4-bit function code and 7-bit CANopen node id. This limits the number of devices in a CANopen network to 127. An extension to the CANbus standard (CAN 2.0 B) allows extended frame ids of 29 bits, but in practice CANopen networks big enough to need the extended id range are rarely seen. In CANopen the 11-bit id of a CAN-frame is known as communication object identifier, or COB-ID. In case of a transmission collision, the bus arbitration used in the CANbus allows the frame with the smallest id to be transmitted first and without a delay. Since in CANopen frames the first 4 bits of the frame id are reserved to the function code, giving a low code number for time critical functions ensures the lowest possible delay. Contents of a standard CANopen frame: Function code Node ID RTR Data length Data 7 bits 1 bit 4 bits 0-8 bytes Length 4 bits The standard reserves certain COB-IDs to network management and SDO transfers. Some function codes and COB-IDs have to be mapped to standard functionality after device initialization, but can be configured for other uses later.
CANopen Protocol
Communication models
Different kinds of communication models are used in the messaging between CANopen nodes. PRODUCER/CONSUMER MODEL The Producer/Consumer model describes perfectly the CAN broadcast communication capability. Each station of the network can listen to the messages of the transmitting station. After receiving the message it is the task of every node to decide if the message has to be accepted or not. So Acceptance Filtering has to be implemented in a CAN node. The CAN broadcast communication is similar with a radio station transmitting information about traffic jam for vehicle drivers. Every driver has to decide if the messages are important for him depending on the direction he wants to go. The Producer/Consumer model allows to services: to transmit a messages (push model) or to request a message (pull model).
CANopen Protocol
CLIENT/SERVER MODEL In the classical Client/Server model the client transmits a messages, which will be responded by the server, so that the client get a confirmation. That is like to give an order, which must be confirmed, so that you know the order was understood.
CANopen Protocol
The Client/Server model is used to transfer data longer than 8 byte. Therefore the original data to be transmitted is segmented and sent segment for segment on the same identifier. Each or a group of segments or the total message will be confirmed by the receiver. So this is a peer-to-peer communication. The services on this client/server transmission may include up- and download as well as transfer abort. MASTER/SLAVE MODEL
The Master/Slave model allows only a communication initiated by the master, The slave has always to wait for the masters communication requests. This is like in the army: the soldier will get orders and he has only to speak after permission. In CAN-based networks master/slave communication can be implemented by an appropriate identifier allocation. Unconfirmed Master/slave communication allows also broadcasting.
COMMUNICATION PROTOCOLS
CANopen Protocol
CANopen communication objects transmitted via the CAN network are described by the services and protocols. They are classified as follows: The real-time data transfer is performed by the Process Data Objects (PDOs) protocol. With Service Data Objects (SDOs) protocols the read and write access to entries of a device object dictionary is provided. Special Function Object protocols provide application-specific network synchronization, time stamping and emergency message transmissions. The Network Management (NMT) protocols provide services for network initialization, error control and device status control.
Process Data Object (PDO) protocol
PDO communication can be described by the producer/consumer model. Process data can be transmitted from one device (producer) to one another device (consumer) or to many other devices (broadcasting). PDOs are transmitted in a non-confirmed mode. The producer sends a Transmit-PDO (T_PDO) with a specific identifier, which corresponds to the identifier of the Receive-PDO (R_PDO) of one or more consumers. There are two PDO services: to write a PDO and to read a PDO.
CANopen Protocol
The Write-PDO is mapped to a single CAN Data frame. The Read- PDO is mapped to CAN Remote Frame, which will be responded by the corresponding CAN Data Frame. Read-PDOs are optional and depending on the device capability. The complete data field of up to 8 byte may contain process data. Number and length of PDOs of a device are application-specific and have to be specified in the device profile. The PDOs correspond to entries in the Object Dictionary and provide the interface to application objects. Data type and mapping of application objects into a PDO is determined by a corresponding default PDO mapping structure within the Object Dictionary. This structure is defined in the entries 1600h for the 1st R_PDO and 1A00h for the first T_PDO. In one CANopen network there can be used up to 512 TPDOs and 512 RPDOs. The CANopen communication profile distinguishes three message triggering modes: 1. Message transmission is triggered by the occurrence of an object specific-event specified in the device profile. Periodically transmitting nodes are triggered additionally by elapsed timer even if no event has occurred. 2. The transmission of asynchronous PDOs may be initiated on receipt of a remote request initiated by another device. 3. Synchronous PDOs are triggered by the expiration of a specified transmission period synchronized by the reception of the SYNC object.
CANopen Protocol
The communication parameters describe the communication behavior of a PDO. The communication parameter set is defined by index 20h in the object dictionary.
The mapping parameter set described in 21h specifies, which application objects are mapped into a PDO. In maximum, there may be mapped up to 64 objects.
Service Data Object (SDO) Protocol

With Service Data Objects (SDO) the access to entries of a device object dictionary is provided. One SDO uses two CAN Data Frames with different identifiers, because the communication is confirmed. By means of a SDO a peer
CANopen Protocol
to-peer communication channel between two devices may be established. The owner of the accessed object dictionary is the server of the SDO. A device may support more than one SDO. One supported SDO is mandatory and the default case.
As the object directory values can be larger than the 8 byte limit of a CAN frame, the SDO protocol implements segmentation and desegmentation of longer messages. Actually, there are two of these protocols: SDO download/upload and SDO Block download/upload. The SDO block transfer is a newer addition to standard, which allows large amounts of data to be transferred with slightly less protocol overhead. The COB IDs of the respective SDO transfer messages from client to server and server to client can be set in the object directory. Up to 127 SDO servers can be set up in the object directory addresses 0x1200 - 0x127F. Similarly, the SDO client connections of the device can be configured with variables at 0x1280 0x12FF. However the pre-defined connection set defines an SDO channel which can be used even just after bootup (in the Pre-operational state) to configure the device. The COB IDs of this channel are 0x600 + node id for receiving and 0x580 + node id for transmitting. To initiate a download, the SDO client sends the following data in a CAN message with the 'receive' COB ID of the SDO channel: 3 bits 1 bit 2 bits 1 bit 1 bit 2 bytes 1 byte 4 bytes ccs=1 reserved(=0) n E s index subindex data
CANopen Protocol
ccs is the client command specifier of the SDO transfer, this is 0 for SDO segment download, 1 for initiating download, 2 for initiating upload, 3 for SDO segment upload and 4 for aborting an SDO transfer n is the number of bytes in the data part of the message which do not contain data, only valid if e and s are set e, if set, indicates an expedited transfer , i.e. all data exchanged are contained within the message. If this bit is cleared then the message is a segmented transfer where the data does not fit into one message and multiple messages are used. s, if set, indicates that the date set size is specified in n (if e is set) or in the data part of the message index is the object directory index of the data to be accessed subindex is the subindex of the object directory variable data contains the data to be uploaded in the case of an expedited transfer (e is set), or the size of the data to be uploaded (s is set, e is not set)
Synchronization Object (SYNC) protocol

The Sync-Producer provides the synchronization-signal for the SyncConsumer. When the Sync-Consumer receive the signal they start carrying out their synchronous tasks. In general the fixing of the transmission time of synchronous PDO messages coupled with the periodicity of transmission of the Sync Object guarantees that sensor devices may arrange to sample process variables and that actuator devices may apply their actuation in a coordinated fashion. The identifier of the Sync Object is available at index 1005h.
Time Stamp Object (TIME) protocol

Usually the Time-Stamp object represents an absolute time in ms after midnight and the number of days since January 1, 1984. This is a bit sequence of length 48 (6 byte). Some time critical applications especially in large networks with reduced transmission rates require very accurate synchronization; it may be necessary to synchronize the local clocks with an accuracy in the order of
CANopen Protocol
microseconds. This is achieved by using the optional high resolution synchronization protocol which employs a special form of time stamp message to adjust the inevitable drift of the local clocks. The high-resolution time-stamp is encoded as unsigned32 with a resolution of 1 microsecond which means that the time counter restarts every 72 minutes. It is configured by mapping the high resolution time-stamp (object 1013h) into a PDO.
Emergency Object (EMCY) protocol

Emergency messages are triggered by the occurrence of a device internal fatal error situation and are transmitted from the concerned application device to the other devices with high priority. This makes them suitable for interrupt type error alerts. An Emergency Telegram may be sent only once per error event, i.e. the emergency messages must not be repeated. As long as no new errors occur on a device no further emergency message must be sent. By means of CANopen Communication Profile defined emergency error codes, the error register and device specific additional information are specified in the device profiles.
The General Purpose Instrument
THE GENERAL PURPOSE INSTRUMENT

The instrument called General Purpose Instrument or General Purpose Controller is an embedded system built around the Atmels AVR architecture microcontroller (ATmega 32). It is a functionally equivalent to a PLC with other added features. The instrument has been elaborately described in the following parts: DRIVER CHIP: The outputs have to drive around 250mA per pin. So, it is necessary for us to connect a driver chip. ULN2003 is the chip selected for this function. It can drive up to 500mA per pin. INPUT CIRCUITRY: We would generally give a 12 / 24V DC as input to the circuit, so, it would be necessary for down conversion to 5Vand input filtering to be used properly by the microcontroller. This will also ensure protection of the circuit. Also the analog i/ps will have to be connected to similar circuitry. LCD: A 16 x 2 LCD with backlight is used for Display.
Block Diagram KEYBOARD: A keyboard is used for field setting of the system.
SERIAL COMMUNICATION: A RS-232 chip is used for interface of the c with the computer. CAN INTERFACE: The device has an interface to allow it to communicate on CAN network. It uses a can controller (mcp2510) and a transceiver(msp2551) to implement CAN 2.0A,ISO 11898 with CANopen device profile CIA DS-401 Working: As said, the device is functionally similar to a PLC. In simple words, it takes the inputs from various field devices, processes the gathered data as programmed by the user and switches the outputs accordingly. But its major advantage is its flexibility and user friendly interface. The instrument is preloaded with a program that can be used to define various variables and operating points and functions. Hence the user need not be an expert in programming, even a semi technical person can operate and set the different operating points. Currently, further developments are being done in the software and hardware structure of the instrument that will make it even more flexible and easy. Salient features: High Flexibility User friendly operating and programming structure Analog and digital both inputs can be connected 8 different input channels with independent Parameter settings Counter and display for encoders and pulse pick ups CAN interface RS 232 port for interfacing with computer Applications: It can be used in process automation where input from various sensors can be given to the instrument and the outputs can accordingly connected to either PLCs or main switching circuits. It can even take analog inputs without any need of external circuits. It can also be used as a display unit for encoders or pulse pick ups etc. other applications include its use in industrial communication via various
buses by configuring it as a bus controller like using it to communicate via CAN bus etc. Circuit Diagram:
As can be seen from the circuit diagram, the microcontroller ATmega 32 forms the heart of the circuitry. Various parts of the circuit can be explained as below Analog and Digital inputs: Inputs are given to the microcontrollers PORT A through signal processing circuits that convert the voltage levels to TTL logic levels. Hence up to 24V DC voltage can be supplied to as input to the instrument without causing any damage to the circuit. Each input pins has its own protection circuit. Also additional four inputs are also provided at PORT D (2-5) as digital inputs if PORT A is used for analog inputs. However digital input can also be given at PORT A but Analog inputs can only be given at PORT A.
Digital outputs: Outputs are given through the driver chip ULN 2003. It can provide currents up to 500mA. The driver IC is connected to PORT C (0 3) . Other 3 pins of driver IC is connected to PD6 ,PD7 and PB1. Hence the instrument has 7 digital NPN outputs with maximum sink current up to 500mA. Keyboard Inputs: Four keys are provided in the instrument for various parameters setting and selecting between various operations. These keys are connected to the microcontroller PORT C4 C7. Each key is at logic one when open (not pressed). When the key is pressed, the relative pin is grounded. Display output: A 16 X 2 LCD is used for display in the instrument. It is connected through connector no. 4 which is in turn connected to PORT B. the LCD is programmed to operate with 4 line interface and 2 line display. PORT B (4 7) forms as data interface lines and PB2 & PB 3 are used for as control lines. RS 232 interface: The serial data receive (Rx) and transmit (Tx) pins of the controller are connected to IC Max 232. The corresponding outputs of the IC are connected to the serial output port which can be used to interface the instrument with the computer or other devices with RS 232 interface. CAN interface: The CAN interface is provided using a CAN controller IC mcp2510. This IC implements the data link layer of the CAN protocol. It checks for bus access, does bus arbitration, assembles the out going data frame, disassembles incoming data frame, calculates CRC and other tasks specified by the CAN protocol. The transceiver implements the CAN physical layer in the form of a two wire differential bus. Vcc, Gnd and XTAL: All the ICs are provided with 5V DC supply from a supply circuit made of a step down transformer, a bridge rectifier, filter, Regulator IC LM7805. The controller is given a clock input of 8 Mhz through a crystal resonating circuit.
Hence as can be seen, the hardware part of the instrument is quite simple. All outputs and inputs are brought out to the housing of the instrument through various connectors. The microcontroller is programmed using software called IMAGECRAFT ICC AVR IDE. It allows programming of the controller in C language. It then acts as a cross compiler and translates that C programming into assembly language suitable for the microcontroller and programs it. Now let us have a detailed look into the application we have built to show the working and use of the instrument in a real industrial network.
Application
APPLICATION
The application built to show the functionality of the instrument is a model of a bottle filling plant. The plant mainly consists of to parts, one is the bottle filling part where the liquid is filled in the bottle, the bottle is then caped and counted. The other part is bottle packaging part where several bottles are packed in a box or cartoon to ship it to the destination. The actual application may vary according to the type of liquid filled in bottle, type of industry and many other factors, but the overall logic remains the same. Implementing CAN in bottle filling: As said earlier, a network is required for communication of two or more controllers working on related tasks. In our application, we have used a single controller for bottle filling and another controller for packaging. As both the tasks are closely related, both controllers are connected to each other through CAN. Also for easy human interface, a PC is used as a Human-Machine Interface (HMI) which is connected to other two controllers (nodes) through CAN. Hence the block diagram of the system looks as follows.
Here the PC provides various information of each node such as bottle count, box count, node status etc. It also provides options to control the node from
Application
here. The nodes also use there local display (LCD) to display information related to the conveyer they are controlling. All nodes exchange this information using CAN network. Application Logic: The basic logic of the application is simple. There are two conveyer belt; one for bottle filling controller by one controller called node 1 and another for packaging called node 2.Let us start with bottle conveyer. On the bottle conveyer, as shown in figure, there is as through beam photoelectric sensor to sense a bottle. Whenever the bottle cuts the path between the sensors, it gets sensed and sensor sends a signal to node 1. The node then stops the conveyer and starts the filling head to fill the bottle. The time for which the filling head should remain on is pre calculated depending upon the rate of liquid flow and volume of bottle. After that time, the node again starts the conveyer and waits for next bottle. Ahead on the conveyer is a diffuse photoelectric sensor mounted above. This sensor will sense the bottle and count the bottles. This is used to simulate the last stage in bottle filling process after the bottle is caped. Generally after filling there are many other intermediate processes. In this process sometime some bottles get damaged or fall off from the conveyer. To make the operator know of this fact, such logic is used. Two counts are maintained, one when bottle is filled and another at final stage. A difference in them suggests a bottle lost in between. On the box conveyer, the box is sensed by a through beam photoelectric sensor. When the box is sensed, node 2 stops the conveyer and allows the box to be filled by bottles. After the box is filled, a button is pressed by the operator. At this point the node checks the box with diffuse photoelectric sensor to see is box is completely filled or not. It may happen that the operator may sometimes forget to fill boxes to its full capacity. Forwarding such boxes may lead to errors and wastage. The node hence checks and notifies the operator if box is not filled completely. The logic discussed so far are local logic, they do not require any communication between nodes. But other precaution logic requires it. One such is the logic to prevent bottle conveyer to go on filing bottles even when they are not getting packed. It may happen that due to some faults or other reason, the box conveyer stops working. In such case the bottle conveyer should also stop or at least notify the operator. This is done by continuous communication between the nodes.
Application
Also the HMI maintains a display of current status and counts of node. This is done by continuously transmitting information on the CAN network. The technical details of each node are described in the following parts. CAN NODE 1: Input/Outputs: The I/Os connected to this node are two sensor inputs and three control outputs. The through beam sensor to sense the bottle is connected to the interrupt input of the node. Hence whenever a bottle is detected, the controller is interrupted. The diffuse photoelectric counter input is given to the counter pin of the node. On the output side the motor is connected to O/P4. The filling head requires two outputs for two different liquid types. Hence the filling head is connected to O/P2 and O/P3. The sensors are realized using an Infra red LED and a Photodiode. The circuit for the sensors is as follows.
Application
In the circuit, the left part forms the transmitter and the right part is the IR detector. Diode D1 is an IR LED. This IR light is detected using IR photodiode D2. The current in the diode is proportional to the amount of light falling on it. To convert this current change to voltage change, the resistor R1 is used. This voltage is then converted to TTL logic levels using transistor Q1. Hence when sufficient light falls on the receiver, the transistor is on and output is 0V. When light is blocked, the output is 5V. Hence as the output is compatible to TTL logics, the sensors can be directly connected to the controller ports. In the output side, the filling head is simulated using two different LEDs. The LEDs have a common anode and two different cathodes connected to the output of NODE1. When liquid type 1 is selected, the red led glows every time a bottle filling is to be shown. For liquid Type 2, yellow led glows. Software Details: The program for NODE1 is given as follows.
#include<iom32v.h> #include<macros.h> #define GET8FROM16(val) (val>>8) & 0xFF,val #define OBJ(index,sub_index,len,val1,val2) GET8FROM16(index),sub_index,len,GET8FROM16(val1),GET8FROM16(val2) #define CURRENT_VALUE (crntBtl*2)+crntLiq
Application
/****************** Declaring global variables *********************/ unsigned char crntLiq=1,crntBtl=0,errorReg,timrCnt,timer_OF_flag,tx_flag; /**** Declaring an array containing the object dictionary values ****/ unsigned char OD[]={OBJ(0x1000,0x00,4,0x0000,0x0191),\ OBJ(0x1001,0x00,1,0x0000,0x0000),\ OBJ(0x1018,0x00,1,0x0000,0x0000),\ OBJ(0x1018,0x01,4,0x0000,0x0001),\ OBJ(0x1018,0x02,4,0x0000,0x0001),\ OBJ(0x1018,0x03,4,0x0000,0x0000),\ OBJ(0x1018,0x04,4,0x0000,0x0001),\ OBJ(0x1400,0x00,1,0x0000,0x0002),\ OBJ(0x1400,0x01,4,0x0000,0x0201),\ OBJ(0x1400,0x02,1,0x0000,0x00FF),\ OBJ(0x1401,0x00,1,0x0000,0x0002),\ OBJ(0x1401,0x01,4,0x0000,0x0301),\ OBJ(0x1401,0x02,1,0x0000,0x00FF),\ OBJ(0x1600,0x00,1,0x0000,0x0002),\ OBJ(0x1600,0x01,4,0x6200,0x0110),\ OBJ(0x1600,0x02,4,0x6200,0x0210),\ OBJ(0x1601,0x00,1,0x0000,0x0002),\ OBJ(0x1601,0x01,4,0x6201,0x0110),\ OBJ(0x1601,0x02,4,0x6201,0x0210),\ OBJ(0x1800,0x00,1,0x0000,0x0002),\ OBJ(0x1800,0x01,4,0x0000,0x0181),\ OBJ(0x1800,0x02,1,0x0000,0x00FF),\ OBJ(0x1801,0x00,1,0x0000,0x0002),\ OBJ(0x1801,0x01,4,0x0000,0x0281),\ OBJ(0x1801,0x02,1,0x0000,0x00FF),\ OBJ(0x1A00,0x00,1,0x0000,0x0002),\ OBJ(0x1A00,0x01,4,0x6000,0x0110),\ OBJ(0x1A00,0x02,4,0x6000,0x0210),\ OBJ(0x1A01,0x00,1,0x0000,0x0002),\ OBJ(0x1A01,0x01,4,0x6004,0x0110),\ OBJ(0x1A01,0x02,4,0x6004,0x0210),\ OBJ(0xFFFF,0xFF,4,0xFFFF,0xFFFF)}; unsigned int process_data[16];
/******************************************************************** INTERRUPT HANDLER FOR INTERUPT 1 INTERRUPTED WHEN A BOTLE IS SENSED STOPS THE MOTOR,STARTS THE FILLING HEAD AND STARTS THE DELAY TIMER *********************************************************************/ #pragma interrupt_handler int1_handler:3 int1_handler() //This int occurs when bottle comes under filling head {
Application
unsigned char charTemp; unsigned char msg[8],temp; SREG&=0x7F; delay(200); PORTD&=0xDF; if(crntLiq==1) PORTC|=0x04; else PORTD|=0x10; //Disable interrupts
//Turn of the motor //Check which liquid is selected //Turn on the LED (liquid flow)
process_data[CURRENT_VALUE+3]++; SREG|=0X80; if(crntBtl==0) { delay(1500); } else { delay(900); } if(crntLiq==1) PORTC&=0xFB; else PORTD&=0xEF; PORTD|=0x20; }
//Increment bottle filled count
//Check which bottle type is selected //Wait for time accordingly
//Turn on the LED (liquid flow)
//Start Motor
/********************************************************************* TIMER 1 OVERFLOW INTERRUPT ROUTINE GENERATED WHENEVER BOTTLE SENSED BY DIFUSE SENSOR INCREMENTS BOTTLE COUNTER *********************************************************************/ #pragma interrupt_handler timer0_OF:12 timer0_OF() { tx('c'); TCNT0=0; timer_OF_flag=1; //Set timer overflow flag process_data[CURRENT_VALUE-1]++; //Increment total bottle counter process_data[15]++; } ********************************************************************** ********
Application
FUNCTION: MAIN INITIALIZES PORTS,DISPLAY,USART,CAN CONTROLLER,INTERRUPTS AND TIMERS. RETURNS: NONE ********************************************************************** ********/ void main() { unsigned char incr,key,charTemp,errCnt,buffer[8],i; port_init(); PORTC&=0xFB; PORTD&=0xEF; delay(100); lcd_init(); usart_init(); delay(20); clear(); command(0x85,'c'); dsplay("ACDM"); command(0xC3,'c'); dsplay("CAN NODE 1"); delay(900); //Initialize ports
//Initialize LCD display //Initialize USART
//Clear the display
SPCR=0x51; can_reset(); delay(10);
//Start SPI interface //Reset can controller
/********** Initialization of the CAN controller MCP2510 ***********/ /*(can_read and can_write are functions defined in the file "can_functions")*/ can_write(0xFF,0x80); can_write(0x60,0x64); can_write(0x70,0x60); can_write(0xFF,0x00); tx('\n');
//RXB0CNTRL, receive all msg with standard id //RXB1CNTRL, receive all msg with standard id //CANCNTRL, enter normal mode of operation
/****************************************************************/
for(charTemp=0;charTemp<8;charTemp++) buffer[charTemp]=0;
//Load a buffer for tx
charTemp=can_tx(0x0701,1,&(buffer[0])); //Tx CAN boot up msg
Application
if(charTemp) { clear(); command(0x83,'c'); dsplay(" Tx FAILED!"); command(0xC1,'c'); dsplay("CHECK CAN BUS"); goto end; } delay(5); clear(); dsplay(" PRE-OPERATIONAL"); command(0xC5,'c'); dsplay("STATE"); key=0; while(key==0) key=keybrd(); clear(); dsplay(" CAN NODE IS NOW"); command(0xC3,'c'); dsplay("OPERATIONAL"); delay(900); /*INITIALIZING INTERRUPT 1*/ SREG = 0x80; //Enabling Global interrupt bit MCUCR = 0x08; //Setting interrupt sense control for int1 //Enabling external interrupt 1 GICR = 0x80; /* INITIALIZING TIMER/COUNTERS*/ TCNT0=0xFE; TCCR0=0x06; TIMSK=0x01; //Enabling overflow ints for TC0,1 & 2 //Stopping TC2 TCCR2=0x00; TCNT2=0; //Initializing TC2 register with 0 crntLiq=1; crntBtl=0; for(i=0;i<16;i++) process_data[i]=0; PORTD|=0x20; asm("jmp _runMode"); end: charTemp=1; } /******************************************************************** //Wait for keypress //If returned val is 1,then tx failed
//Clear Process data array //Start Motor //Jump to Run mode
Application
FUNCTION:RUNMODE IT DISPLAYS THE BOTTLE COUNT,CHECKS FOR RECEIVED MESSSAGES,POLLS THE KEYBOARD AND IMPLEMENTS OTHER BASIC LOGIC RETURNS: NONE *********************************************************************/ runMode() { unsigned char key,a=1,b=0,i,charTemp; unsigned int temp,tempCount;
PORTC&=0xFB;
//Turn on the LED (liquid flow)
clear(); dsplay("Lqd= Bottle= "); command(0xC0,'c'); dsplay("Count="); nxt: command(0x84,'c'); command(0x30+a,'d'); command(0x8D,'c'); command(0x31+b,'d'); command(0xC7,'c'); if(timer_OF_flag) { timer_OF_flag=0; delay(200); TCNT0=0xFF; } //If timer overflow flag is set //Then reset it //delay for 200ms //Reload timer/counter 1 register
//Display liquid type //Display bottle type
tempCount=process_data[((b*2)+a)-1]; //Get the current bottle count temp=10000; for(temp=10000;temp>=1;temp/=10) { i=tempCount/temp; command(i+0x30,'d'); tempCount=tempCount%temp; } //Display count of 5 digits
charTemp=can_status_read();//Check if any msgs are recvd on CANBUS if((charTemp & 0x03)) checkRcvdMsg(); //If msga are received //Then check what type of msg is it
Application
tx_PDO1();
//Tx PDO1 data ie bottle counts on CANBUS //If 4 bottles has passed before //any msg from node 2 //Then stop the motor // and interrupts
if(process_data[15]>4) { PORTD&=0xDF; SREG&=0x7F; } else { PORTD|=0x20; SREG|=0x80; }
//Else restart motor //and interrupts
delay(200); key=0; key=keybrd(); if(key==2) { a++; if(a==3) { a=1; b++; b=b%2; } } else if(key==3) { a--; if(a==0) { a=2; b--; b=b%2; } } goto nxt; } /********************************************************************* FUNCTION: CHECKRCVDMSG IT GETS THE ID,LENGTH AND THE DATA OF THE RECEIVED MSG FROM CAN CONTROLLER AND CHECKS THE ID AND ACCORDINGLY CALLS VARIOUS OBJECT HANDLERS RETURNS: NONE *********************************************************************/ checkRcvdMsg() //Check for any keypress
Application
{ unsigned char charTemp,inr,i,msg_len,msg[8]; unsigned int msg_id; tx('\n'); tx('\r'); charTemp=can_status_read(); if((charTemp & 0x01)!=0)//If true than Msg has been received in RXB0 inr=0; else if((charTemp & 0x02) !=0) //If true than msg rcvd in RXB1 inr=0x10; else return; msg_id=can_read(0x61+inr); //Standard identifier High(SIDH10-SIDH03) msg_id=msg_id<<3; charTemp=can_read(0x62+inr); //Standard identifier Low(SIDH02-SIDH00) charTemp=charTemp>>5; msg_id|=charTemp; msg_len=can_read(0x65+inr); msg_len&=0x0F; hex2ascii(msg_len); //Message data length code //Only the lower 4 bits are useful
for(i=0;i<msg_len;i++) { msg[i]=can_read(0x66+i+inr); //Get data bytes in the array hex2ascii(msg[i]); } if(inr==0) can_bit_modify(0x2C,0x01,0); else can_bit_modify(0x2C,0x02,0);
//Clear receive buffer 0 flag //clear receive buffer 1 flag
if(msg_id==0x182) process_data[15]=0; if(msg_id==0x201) RPDO1_handler(&(msg[0])); else if(msg_id==0x301) RPDO2_handler(&(msg[0])); else if(msg_id==0x581 || msg_id==0x601) SDO_handler(msg_id,&(msg[0])); } /********************************************************************* FUNCTION: RPDO1_HANDLER IT GETS THE 4 BYTES OF POCESS DATA,STORES IT IN OBJECT DICTIONARY AND USES IT
Application
RETURNS: NONE *********************************************************************/ RPDO1_handler(unsigned char *p) { unsigned char node2Status,key,OD_index; if((*p)==0xFF) { SREG&=0x7F; PORTD&=0xDF; } else { SREG|=0x80; PORTD|=0x20; } //If 0xFF,then the NMT mstr has ordered node1 to stop //Turn off interrupt //Turn of the motor //Anything else means NMT mstr has nt ordered to stp //Start evrything again in case it was stopped //Turn on interrupt //Turn on motor
if(crntLiq!=*(p+1) || crntBtl!=*(p+2)) //If liquis or bottle type changed { crntLiq=*(p+1); //Get the new values for liquid and bottle type crntBtl=*(p+2); OD_index=search_OD(0x1A00,0x01); //Change the TPDO mapping accordingly OD[OD_index+5]=CURRENT_VALUE-1; OD[OD_index+8+5]=CURRENT_VALUE-1; } node2Status=*(p+3); if(node2Status==0xFF) { SREG&=0x7F; PORTD&=0xDF;
//0xFF means node 2 has stopped //Turn off interrupt
clear(); dsplay("NODE2 ERROR!PRESS"); dsplay("ANY KEY TO CONTINUE"); key=0; while(key==0) key=keybrd(); SREG|=0x80; PORTD|=0x20; errorReg|=0x02; rom_write(0x01,errorReg); } }
//wait for a keypress
//Turn on interrupt
Application
/********************************************************************* FUNCTION: RPDO2_HANDLER NOT USED CURRENTLY, IT JUST STORES THE RECEIVED VALUE IN OBJECT DICTIONARY RETURNS: NONE *********************************************************************/ RPDO2_handler(unsigned char *p) { process_data[0x0B]=*p | *(p+1) <<8; process_data[0x0C]=*(p+2) | *(p+3)<<8; return; }
/********************************************************************* FUNCTION: SDO_HANDLER IT GETS THE INDEX AND SUB-INDEX FROM SDO REQUEST, AND RETURNS THE OBJECT DICTIONARY VALUE.IF NOT PRESENT OR NO ACCESS TO OBJECT,SENDS ABORT MSG RETURNS: NONE *********************************************************************/ SDO_handler(unsigned int id,unsigned char *p) { unsigned int index; unsigned char len,temp,subIndex,temp2,msg[8],i,j; temp=*p; msg[1]=*(p+1); msg[2]=*(p+2); msg[3]=*(p+3); if(temp==0x40) { index=*(p+2); index=index<<8; index|=*(p+1); subIndex=*(p+3); if((index==0x6000) && (subIndex==0x01)) { msg[4]=process_data[0]; msg[5]=process_data[0]>>8; msg[6]=0; msg[7]=0; msg[0]=0x4B; temp=can_tx(id,8,&msg[0]); } else if((index==0x6000) && (subIndex==0x02)) { msg[4]=process_data[4];
Application
msg[5]=process_data[4]>>8; msg[6]=0; msg[7]=0; msg[0]=0x4B; temp=can_tx(id,8,&msg[0]); } else if((index==0x6001) && (subIndex==0x01)) { msg[4]=process_data[1]; msg[5]=process_data[1]>>8; msg[6]=0; msg[7]=0; msg[0]=0x4B; temp=can_tx(id,8,&msg[0]); } else if((index==0x6001) && (subIndex==0x02)) { msg[4]=process_data[5]; msg[5]=process_data[5]>>8; msg[6]=0; msg[7]=0; msg[0]=0x4B; temp=can_tx(id,8,&msg[0]); } else if((index==0x6002) && (subIndex==0x01)) { msg[4]=process_data[2]; msg[5]=process_data[2]>>8; msg[6]=0; msg[7]=0; msg[0]=0x4B; temp=can_tx(id,8,&msg[0]); } else if((index==0x6002) && (subIndex==0x02)) { msg[4]=process_data[6]; msg[5]=process_data[6]>>8; msg[6]=0; msg[7]=0; msg[0]=0x4B; temp=can_tx(id,8,&msg[0]); } else if((index==0x6003) && (subIndex==0x01)) { msg[4]=process_data[3]; msg[5]=process_data[3]>>8; msg[6]=0; msg[7]=0; msg[0]=0x4B; temp=can_tx(id,8,&msg[0]); }
Application
else if((index==0x6003) && (subIndex==0x02)) { msg[4]=process_data[7]; msg[5]=process_data[7]>>8; msg[6]=0; msg[7]=0; msg[0]=0x4B; temp=can_tx(id,8,&msg[0]); } else { temp2=search_OD(index,subIndex); if(temp2==255) { msg[0]=0x80; msg[4]=0x00; msg[5]=0x00; msg[6]=0x02; msg[7]=0x06; can_tx(id,8,&msg[0]); return; } len=OD[temp2+3]; msg[0]=0x43 | ((4-len)<<2); for(i=4,j=7;i<=7;i++,j--) msg[i]=OD[temp2+j]; temp2=can_tx(id,8,&msg[0]); } } else { msg[0]=0x80; msg[4]=0x00; msg[5]=0x00; msg[6]=0x01; msg[7]=0x06; can_tx(id,8,&msg[0]); } return; } /********************************************************************* FUNCTION: SEARCH_OD IT GETS THE INDEX AND SUB INDEX AND SEARCHES FOR THAT ENTRY IN THE OD RETURNS: POSITION IN OD IF FOUND, ELSE 255 *********************************************************************/ search_OD(unsigned int index,unsigned char subIndex) { unsigned char i,indexH,indexL;
Application
indexH=index>>8; indexL=index; for(i=0;1;i+=8) { if((indexH==OD[i]) && (indexL==OD[i+1]) && (subIndex==OD[i+2])) return i; else if((OD[i]==0xFF) && (OD[i+1]==0xFF) && (OD[i+2]==0xFF)) return 255; } }
/********************************************************************* FUNCTION: TX_PDO1 IT GETS THE VALUE ACCORDING TO TPDO1 MAPPING AND TX IT RETURNS: NONE *********************************************************************/ tx_PDO1() { unsigned char msg[8],temp; msg[0]=process_data[CURRENT_VALUE-1]; msg[1]=process_data[CURRENT_VALUE-1]>>8; msg[2]=process_data[CURRENT_VALUE+3]; msg[3]=process_data[CURRENT_VALUE+3]>>8; temp=can_tx(0x181,4,&msg[0]); }
In the program, for CAN interface various functions are used such as can_read, can_write, can_status_check etc. These functions are defined and written in a different module called can functions. The details of that and other modules such as LCD module and keyboard module are given later in the report. Apart from that the main part of the program is the run_mode. The program starts execution form main. Before that all the global variables including the object dictionary entries are initialized in the internal SRAM. Then main initializes all ports, lcd, USART and CAN controller. It then sends a boot up message to the network master (here NODE 3) as specified in the CANopen protocol. If the message tx is successful, the NODE enters into preoperational state and now waits for the user to press any key and start he conveyer. On coming out of preoperational state, main initializes all the interrupts and timer/counters needed for the application. It then passes control to run_mode.
Application
Run_mode now displays the current bottle type and liquid type selected and also displays the current bottle count. It also checks the CAN controller for any new messages in its buffer. It loops into this sequence continuously until next reset or power off. On detecting a bottle, the program vectors to the ISR of interrupt, int1_handler in this case. Here the code is written is to stop the motor, start the filling head and start a timer for delay. After the delay, the motor is started and filling stopped. Run_mode on detecting a new message in receive buffer of Can controller calls checkRcvdMsg to check what kind of message is received (RPDO, TPDO or SDO Request). Accordingly it calls other functions to handle the incoming message.
CAN NODE 2: Inputs/Outputs: Node 2 consists of three sensor inputs, one switch input and motor output. One sensor input is the through beam sensor for detecting the box. The other two sensors are diffuse mounted above the belt to check for empty positions in the box. These sensors are given to analog inputs of the node. The switch is for user to signal that the box is filled. Software Details:
#include<iom8535v.h> #include<macros.h> #define GET8FROM16(val) (val>>8) & 0xFF,val #define OBJ(index,sub_index,len,val1,val2) GET8FROM16(index),sub_index,len,GET8FROM16(val1),GET8FROM16(val2) #define CURRENT_VALUE (crntBtl*2)+crntLiq /****************** Declaring global variables *********************/ unsigned int boxCnt,errorReg; unsigned char timer_flag,flg; /** Declaring an array containing the object dictionary values ******/ unsigned char OD[]={OBJ(0x1000,0x00,4,0x0000,0x0191),\ OBJ(0x1001,0x00,1,0x0000,0x0000),\ OBJ(0x1018,0x00,1,0x0000,0x0004),\ OBJ(0x1018,0x01,4,0x0000,0x0001),\ OBJ(0x1018,0x02,4,0x0000,0x0001),\
Application
OBJ(0x1018,0x03,4,0x0000,0x0000),\ OBJ(0x1018,0x04,4,0x0000,0x0001),\ OBJ(0x1400,0x00,1,0x0000,0x0002),\ OBJ(0x1400,0x01,4,0x0000,0x0202),\ OBJ(0x1400,0x02,1,0x0000,0x00FF),\ OBJ(0x1401,0x00,1,0x0000,0x0002),\ OBJ(0x1401,0x01,4,0x0000,0x0302),\ OBJ(0x1401,0x02,1,0x0000,0x00FF),\ OBJ(0x1600,0x00,1,0x0000,0x0002),\ OBJ(0x1600,0x01,4,0x6200,0x0110),\ OBJ(0x1600,0x02,4,0x6200,0x0210),\ OBJ(0x1601,0x00,1,0x0000,0x0002),\ OBJ(0x1601,0x01,4,0x6201,0x0110),\ OBJ(0x1601,0x02,4,0x6201,0x0210),\ OBJ(0x1800,0x00,1,0x0000,0x0002),\ OBJ(0x1800,0x01,4,0x0000,0x0182),\ OBJ(0x1800,0x02,1,0x0000,0x00FF),\ OBJ(0x1801,0x00,1,0x0000,0x0002),\ OBJ(0x1801,0x01,4,0x0000,0x0282),\ OBJ(0x1801,0x02,1,0x0000,0x00FF),\ OBJ(0x1A00,0x00,1,0x0000,0x0002),\ OBJ(0x1A00,0x01,4,0x6000,0x0110),\ OBJ(0x1A00,0x02,4,0x6000,0x0210),\ OBJ(0x1A01,0x00,1,0x0000,0x0002),\ OBJ(0x1A01,0x01,4,0x6001,0x0110),\ OBJ(0x1A01,0x02,4,0x6001,0x0210),\ OBJ(0xFFFF,0xFF,4,0xFFFF,0xFFFF)}; /********************************************************************* INTERRUPT HANDLER FOR INTERUPT 1 INTERRUPTED WHEN A BOX IS SENSED STOPS THE MOTOR,INCREMENTS BOX COUNT AND SETS A FLAG ********************************************************************/ #pragma interrupt_handler int1_routine:3 int1_routine() //This is occurs when box comes at position { unsigned char Temp; SREG&=0x7F; PORTC&=0xF3; flg=1; boxCnt++; delay(500); SREG|=0x80; } /********************************************************************* FUNCTION: MAIN INITIALIZES PORTS,DISPLAY,USART,CAN CONTROLLER,INTERRUPTS AND TIMERS. //Turn off the motor
//Increment the box count
Application
RETURNS: NONE *********************************************************************/ void main() { unsigned char charTemp,errCnt,key,charTemp1,buffer[8]; port_init(); lcd_init(); usart_init(); delay(20); clear(); command(0x85,'c'); dsplay("ACDM"); command(0xC3,'c'); dsplay("CAN NODE 2"); delay(900); SPCR=0x51; can_reset(); delay(10); //Start SPI interface //Reset can controller
/********* Initialization of the CAN controller /*(can_read and can_write are functions defined "can_functions")*/ can_write(0xFF,0x80); can_write(0x60,0x64); //RXB0CNTRL, receive all can_write(0x70,0x60); //RXB1CNTRL, receive all can_write(0xFF,0x00);
MCP2510 ***********/ in the file
msg with standard id msg with standard id
//CANCNTRL, enter normal mode of operation
/****************************************************************/
for(charTemp=0;charTemp<8;charTemp++) buffer[charTemp]=0;
//Load a buffer for tx
charTemp=can_tx(0x702,1,&(buffer[0])); //Tx CAN boot up msg if(charTemp) //If returned val is 1,then tx failed { clear(); command(0x83,'c'); dsplay("Tx FAILED!"); command(0xC1,'c'); dsplay("CHECK CAN BUS"); goto end; } SREG = 0x80; TIMSK=0x45; //Enabling Global interrupt bit
Application
clear(); dsplay(" PRE-OPERATIONAL"); command(0xC5,'c'); dsplay("STATE"); key=0; while(key==0) key=keybrd(); clear(); dsplay(" CAN NODE IS NOW"); command(0xC3,'c'); dsplay("OPERATIONAL"); PORTC|=0x0C; delay(900); //Start Motor
/*INITIALIZING INTERRUPT 1*/ MCUCR = 0x0C; GICR = 0x80; /*Initialize ADC*/ ADCSRA=0x82; SFIOR=0x00; ADMUX=0xE1; //Setting interrupt sense control for int1 //Enabling external interrupt 1
//Enable the ADC with clk of Fosc/4 //Select an internal ref of 2.56V and //left adjust the result
flg=0; boxCnt=0; asm(jmp _run_mode);
//Enter normal mode of operation
end: charTemp=1; } /********************************************************************* FUNCTION:RUN_MODE IT DISPLAYS THE BOX COUNT,CHECKS FOR RECEIVED MESSSAGES,POLLS THE KEYBOARD AND IMPLEMENTS OTHER BASIC LOGIC RETURNS: NONE *********************************************************************/ run_mode() { unsigned char i,charTemp,lineStatus,secondTimeFlag=0,temp1,charTemp1,adc_h,adc_l,j; unsigned int adc,temp,tempCount,intTemp; unsigned char cmpValues[4]={0x33,0x23,0x33,0x21},key;
Application
clear(); dsplay("Boxes="); agn: command(0x87,'c'); tempCount=boxCnt; hex2ascii(tempCount); tx(' '); for(temp=10000;temp>=1;temp/=10) { i=tempCount/temp; command(i+0x30,'d'); tempCount=tempCount%temp; } charTemp1=can_status_read(); if((charTemp1 & 0x03)) checkRcvdMsg(); hex2ascii(flg); if(flg) { SREG&=0x7F; delay(10); charTemp=PINB & 0x02; if(charTemp==0) { //Display box count of 5 digits //Clear the display //and display "Boxes"
//Check if any msgs r recvd on CANBUS
//Check if box sensed (flg=1 if sensed) //If sensed,disable all interrupts
//Check button status (0 if pressed) //If button pressed
flg=0; //Reset Flag if(secondTimeFlag) //If the flag is set,it means the box was sensed before { tx('s'); PORTC|=0x0C; //Start the motor and IR sensor temp1=can_tx(0x182,2,&(boxCnt)); //transmit Box cnt data on canbus if(temp1) { tx('f'); } secondTimeFlag=0; //Reset the flag command(0xC0,'c'); for(i=0;i<16;i++) command(' ','d'); SREG|=0x80; goto agn; //Take cursor to second row //Clear whole second row
//Enable interupts //wait for next box
Application
} chckAgn: lineStatus=0x0F; //Initilize line status to ll detected //(zero in a bit position means that pos is empty) secondTimeFlag=0; //Reset secondTimeFlag charTemp=0x01; for(i=0;i<4;i++) { if(i==2) { PORTC|=0x08; delay(300); PORTC&=0xF7; delay(1100); } intTemp=0; adc_l=0; for(j=0;j<2;j++) //Take { ADMUX=0xE1+(i % 2); ADCSRA|=0x40; while(ADCSRA & 0x40); ADCSRA|=0x10; adc_l=ADCL; adc_h=ADCH; hex2ascii(adc_h); intTemp=adc_h+intTemp; } intTemp=intTemp/2; adc_h=intTemp; hex2ascii(adc_h); tx(' '); //If sensor val less thn set point if(adc_h<cmpValues[i]) { lineStatus&=(~charTemp); //Then bottle absent,make that bit 0 secondTimeFlag=1; //Set second time flag } charTemp=charTemp<<1; } tx(' '); hex2ascii(lineStatus); tx_s("\n\r"); two readings of same positon for avg //Select channel in ADC //Start conversion //Poll for conversion complete //Reset ADC interrupt flag
//If checked 2 front positions //then bring back pos under sensor //by starting the motor //For predefined amount of time //Wait for belt to stablize
//Add current reading with previous
//Take avg of 2 reading
Application
if(lineStatus==0x0F) {
//If all bottles detected
PORTC|=0x0C; //Start the motor delay(10); SREG|=0x80; //Enable the interuupts temp1=can_tx(0x182,2,&(boxCnt)); //transmit box cnt data on canbus if(temp1) { tx('f'); } } else { secondTimeFlag=1; flg=1; command(0xC0,'c'); dsplay("Box Not Full!"); } } } goto agn; } /********************************************************************* FUNCTION: CHECKRCVDMSG IT GETS THE ID,LENGTH AND THE DATA OF THE RECEIVED MSG FROM CAN CONTROLLER AND CHECKS THE ID AND ACCORDINGLY CALLS VARIOUS OBJECT HANDLERS RETURNS: NONE *********************************************************************/ checkRcvdMsg() { unsigned char charTemp,inr,i,msg_len,msg[8]; unsigned int msg_id; charTemp=can_status_read(); if((charTemp & 0x01)!=0)//If true than Msg has been received in RXB0 inr=0; else if((charTemp & 0x02) !=0) //If true than msg rcvd in RXB1 inr=0x10; else return; msg_id=can_read(0x61+inr); //Standard identifier High(SIDH10-SIDH03) hex2ascii(msg_id);
Application
msg_id=msg_id<<3; charTemp=can_read(0x62+inr); //Standard identifier Low(SIDH02-SIDH00) hex2ascii(charTemp); charTemp=charTemp>>5; msg_id|=charTemp; msg_len=can_read(0x65+inr); msg_len&=0x0F; hex2ascii(msg_len); //Message data length code //Only the lower 4 bits are useful
for(i=0;i<msg_len;i++) { msg[i]=can_read(0x66+i+inr); //Get data bytes in the array hex2ascii(msg[i]); } if(inr==0) can_bit_modify(0x2C,0x01,0); else can_bit_modify(0x2C,0x02,0);
//Clear receive buffer 0 flag //clear receive buffer 1 flag
if(msg_id==0x181) TPDO1_handler(&(msg[0])); if(msg_id==0x202) RPDO1_handler(&(msg[0])); else if(msg_id==0x302) RPDO2_handler(&(msg[0])); else if(msg_id==0x582 || msg_id==0x602) SDO_handler(msg_id,&(msg[0])); }
The NODE 2 program has almost similar initialization and CAN message processing routines. Hence the routines for TPDO, RPDO and SDO handling are not included in the above code. The main difference is in the run_mode where real application logic is implemented. Here initially the system waits for an interrupt to signify that a box has been detected. Once the interrupt comes, it sets a global flag byte. This byte is sensed by the run_mode and it now waits for the user to press the switch to signify that the box has been filled. Once key is pressed, the program checks for empty spaces in the box. It does this by first taking in the sensor ADC converted values of the first two positions of the box. It actually takes two readings and takes an average of that for greater accuracy. It then compares these values with internally stored reference values, if the values are less than reference; the controller
Application
interprets this as no box. It then gives a pulse of 300ms to the motor to bring the back portion below the sensors, and repeats the above process. If the box is filled completely, the conveyer is started and the node waits for next box. If box was not full, it displays a message to the operator and stops the conveyer. It then waits for the operator o press the switch again. On second time pressing, the controller assumes that the operator has taken the corrective measures; it does not check the box again and waits for next box.
CAN NODE 3: Hardware details: CAN NODE 3 is the PC which acts as a HMI. The PC directly does not connect to any Inputs or Outputs. It is only connected to the two NODES through CANBUS. To allow PC to communicate to communicate on the CANBUS, an additional hardware consisting of CAN controller and transceiver is required. The CAN controller requires SPI interface, to realize this from the PC, its Parallel port (LPT1) is used. The circuit diagram for the interface is as follows. The circuit use three data pins of the parallel port data output and a Ack pin for data input. Proper clock is generated on the SCK pin by the PC.
Software Details: The software for the PC is written in Visual Basic. The main user screen for the HMI is as follows
Application
As can be seen, the screen is divided mainly in thee frames. Short description of each frame is as follows. Frame: Process Data Text Box: No of bottle(s) Filled This box displays the bottle count as counted by the first sensor in NODE 1. Text box: Total Bottle(s) This box displays the total bottle count counted by the final diffuse sensor on NODE 1. Text Box: Box Count This box displays the total boxes as counted by NODE 2.
Application
Selection Box: Liquid Type This combo box is used to select two different types of liquid types for selection on NODE 1. Selection Box: Bottle Type This combo box is used to select two different types of bottle volumes viz. 500ml & 300ml.
Frame: CAN NODE 1 Text Box: Node Status This box displays the current status of NODE 1 such as NOT DETECTED, STARTED and STOPPED. Input Box: Index This box is used to enter the index of the device OD entry to be read. Input Box: Sub-Index This box is used to enter the sub-index of the device OD entry. Text Box: Data This box displays the returned device OD entry data. Command Button: READ DEVICE OD Pressing this button will send an SDO read request for the specified index and sub index to NODE 1. Command Button: START This button is used to start and stop NODE 1 remotely. Frame: CAN NODE 2 All the buttons and boxes in this frame are functionally similar to that of node one except for the difference that they all are now applicable to NODE 2 The VB program code for the user interface is as follows.
Option Explicit Public node1_detect_flag As Boolean Public node2_detect_flag As Boolean Private Sub Combo1_Change() End Sub
Application
Private Sub Combo1_Click() Call tx_node1_PDO(0, 0) End Sub Private Sub Combo2_Click() Call tx_node1_PDO(0, 0) End Sub Private Sub Combo3_Click() Dim i As Byte i = Combo3.ListIndex Combo3.Text = Combo3.List(i) If (Combo3.ListIndex = 0) Then port_add = &H378 ElseIf (Combo3.ListIndex = 1) Then port_add = &H278 End If End Sub Private Sub Command1_Click() Dim msg(0 To 7) As Byte, main_index As Integer, sub_index As Byte, temp As Byte If (Text5.Text = "") Then MsgBox "Please Enter the Index of OD to be read", vbOKOnly, "No Index Specified" Exit Sub End If If (Text6.Text = "") Then MsgBox "No sub index entered.0000H will be taken by defualt", vbInformation, "Default Subindex" Timer1.Enabled = False msg(0) = &H40 main_index = Val("&H" + Text5.Text) sub_index = Val("&H" + Text6.Text) Form1.MousePointer = 11 msg(1) = get8from16(main_index, 0) msg(2) = get8from16(main_index, 1) msg(3) = sub_index msg(4) = 0 msg(5) = 0 msg(6) = 0 msg(7) = 0 temp = can_tx(&H581, 8, msg) If (temp = 1) Then MsgBox "Msg not transmitted.Check CANBUS", vbCritical, "CANBUS Error!" Else Label19.Visible = True Text7.Text = "Waiting for reply" End If Timer1.Enabled = True
Application
Form1.MousePointer = 0 End Sub
Private Sub Command11_Click() Dim add As Byte, sdata As Byte If (Text12.Text = "" Or Text13.Text = "") Then MsgBox "Address or Data field empty", vbInformation, "Error" Exit Sub End If Form1.MousePointer = 11 add = Val("&H" & Text12.Text) sdata = Val("&H" & Text13.Text) Call can_write(add, sdata) Form1.MousePointer = 0 End Sub Private Sub Command12_Click() Dim add As Byte, sdata As Byte If (Text12.Text = "") Then MsgBox "Address field empty", vbInformation, "Error" Exit Sub End If Form1.MousePointer = 11 add = Val("&H" & Text12.Text) sdata = can_read(add) Text13.Text = Hex(sdata) Form1.MousePointer = 0 End Sub Private Sub Command10_Click() Dim msg(0 To 7) As Byte, a As Byte For a = 0 To 7 Step 1 msg(a) = a Next a a = 0 a = can_tx(&H201, 8, msg()) MsgBox a End Sub Private Sub Command14_Click() Dim a As Byte a = can_status_read() MsgBox a End Sub Private Sub Command2_Click() If (node1_detect_flag = False) Then
Application
MsgBox "Node 1 not detected.Cannot be started", vbCritical, "Undetected node" Exit Sub End If If (Command2.Caption = "START NODE 1") Then Call tx_node1_PDO(0, 0) Else Call tx_node1_PDO(&HFF, 0) End If End Sub Private Sub Command3_Click() If (node2_detect_flag = False) Then MsgBox "Node 2 not detected.Cannot be started", vbCritical, "Undetected node" Exit Sub End If If (Command3.Caption = "START NODE 2") Then Call tx_node2_PDO(0, 0) Else Call tx_node2_PDO(&HFF, 0) End If End Sub Private Sub Command4_Click() Dim msg(0 To 7) As Byte, main_index As Integer, sub_index As Byte, temp As Byte If (Text9.Text = "") Then MsgBox "Please Enter the Index of OD to be read", vbOKOnly, "No Index Specified" Exit Sub End If If (Text10.Text = "") Then MsgBox "No sub index entered.0000H will be taken by defualt", vbInformation, "Default Subindex" Timer1.Enabled = False Sleep (10) msg(0) = &H40 main_index = Val("&H" + Text9.Text) sub_index = Val("&H" + Text10.Text) Form1.MousePointer = 11 msg(1) msg(2) msg(3) msg(4) msg(5) msg(6) msg(7) = = = = = = = get8from16(main_index, 0) get8from16(main_index, 1) sub_index 0 0 0 0
temp = can_tx(&H582, 8, msg)
Application
If (temp = 1) Then MsgBox "Msg not transmitted.Check CANBUS", vbCritical, "CANBUS Error!" Else Label19.Visible = True Text11.Text = "Waiting for reply" End If Timer1.Enabled = True Form1.MousePointer = 0 End Sub Private Sub Command5_Click() Dim i As Byte Dim a As Byte Call can_write(&H32, 0) Call can_write(&H35, 8) For i = 0 To 7 Step 1 Call can_write(&H36 + i, i) Next i Call can_write(&H30, &HA) MsgBox "Tx" End Sub Private Sub Command6_Click() Dim i As Byte, a As Byte i = can_status_read() MsgBox i i = can_read(&H65) MsgBox i
Call can_bit_modify(&H2C, &H2, 0) Call can_bit_modify(&H2C, &H1, 0) End Sub Private Sub Command7_Click() Dim add As Byte, sdata As Byte If (Text12.Text = "" Or Text13.Text = "") Then MsgBox "Address or Data field empty", vbInformation, "Error" Exit Sub End If Form1.MousePointer = 11 add = Val("&H" & Text12.Text) sdata = Val("&H" & Text13.Text)
Application
Call can_write(add, sdata) Form1.MousePointer = 0 End Sub Private Sub Command8_Click() Dim add As Byte, sdata As Byte If (Text12.Text = "") Then MsgBox "Address field empty", vbInformation, "Error" Exit Sub End If Form1.MousePointer = 11 add = Val("&H" & Text12.Text) sdata = can_read(add) Text13.Text = Hex(sdata) Form1.MousePointer = 0 End Sub Private Sub Command9_Click() Form1.MousePointer = 11 Call can_reset Form1.MousePointer = 0 End Sub Private Sub Form_Load() Text1.Text = "" Text2.Text = "" Text3.Text = "" Text4.Text = "" Text5.Text = "" Text6.Text = "" Text7.Text = "" Text8.Text = "" Text9.Text = "" Text10.Text = "" Text11.Text = "" Text12.Text = "" Text13.Text = "" Text1.Locked = True Text2.Locked = True Text3.Locked = True Text4.Locked = True Text7.Locked = True Text8.Locked = True Text11.Locked = True Text1.Font.Size Text2.Font.Size Text3.Font.Size Text4.Font.Size Text5.Font.Size Text6.Font.Size = = = = = = 10 10 10 10 10 10
Application
Text7.Font.Size = 10 Text8.Font.Size = 10 Text9.Font.Size = 10 Text10.Font.Size = 10 Text11.Font.Size = 10 Command6.Visible = False Label19.Visible = False Combo1.List(0) = Combo1.List(1) = Combo2.List(0) = Combo2.List(1) = Combo3.List(0) = Combo3.List(1) = port_add = &H378 "Red" "Yellow" "500ml" "300ml" "LPT1" "LPT2"
Combo1.ListIndex = 0 Combo2.ListIndex = 0 Combo3.ListIndex = 0 Command2.Caption = "START" Command3.Caption = "START" Text4.Text = "NOT DETECTED" Text8.Text = "NOT DETECTED" Command1.Enabled = False Command4.Enabled = False Timer1.Interval = 14 Timer1.Enabled = False Timer2.Interval = 1500 Timer2.Enabled = False Call Out32(port_add, &H80) Call can_init node1_detect_flag = False node2_detect_flag = False Timer1.Enabled = True End Sub
Public Sub can_init() Call Out32(port_add, &H80) Sleep (1) Call can_reset can_write Sleep (1) can_write Sleep (1) can_write Sleep (1) can_write Sleep (1) &HFF, &H80 &H60, &H64 &H70, &H60 &HFF, &H0
Application
End Sub
Public Sub check_bus() Dim can_status As Byte can_status = can_status_read() can_status = bit_and(can_status, &H3) If (can_status <> 0) Then Timer1.Enabled = False If (can_status = 1) Then check_rcvd_msg (0) ElseIf (can_status = 2) Then check_rcvd_msg (&H10) ElseIf (can_status = 3) Then check_rcvd_msg (0) check_rcvd_msg (&H10) End If End If End Sub
Private Sub Timer1_Timer() Call check_bus End Sub
Public Sub check_rcvd_msg(ByVal bufferNo As Byte) Dim msg_id_high As Byte Dim msg_id_low As Byte Dim msg_id As Integer Dim temp As Integer Dim msg_len As Byte, i As Byte Dim msg(0 To 7) As Byte, limit As Byte msg_id_high = can_read(&H61 + bufferNo) msg_id_low = can_read(&H62 + bufferNo) msg_id = CInt(msg_id_high) msg_id = int_shift(msg_id, 0, 3) msg_id_low = byte_shift(msg_id_low, 1, 5) temp = CInt(msg_id_low) msg_id = int_or(msg_id, temp)
msg_len = bit_and(can_read(&H65 + bufferNo), &HF) If (msg_len > 8) Then Exit Sub If (msg_len = 0) Then limit = 0 Else
Application
limit = msg_len - 1 End If For i = 0 To limit Step 1 msg(i) = can_read(&H66 + bufferNo + i) Next i If bufferNo = 0 Then Call can_bit_modify(&H2C, 1, 0) Else Call can_bit_modify(&H2C, 2, 0) End If If msg_id = &H181 Then Call rx_node1_PDO(msg) ElseIf msg_id = &H182 Then Call rx_node2_PDO(msg) ElseIf msg_id = &H202 Then Timer2.Enabled = False Timer2.Interval = 2000 Timer2.Enabled = True ElseIf msg_id = &H581 Then Call node1_SDO(msg) ElseIf msg_id = &H582 Then Call node2_SDO(msg) ElseIf msg_id = &H701 Then node1_detect_flag = True Call tx_node1_PDO(0, 0) ElseIf msg_id = &H702 Then node2_detect_flag = True Call tx_node2_PDO(0, 0) End If Timer1.Enabled = True End Sub
Public Sub rx_node1_PDO(ByRef msg() As Byte) Dim bottle_filled As Integer Dim temp As Integer Dim total_bottle As Integer bottle_filled = msg(1) bottle_filled = int_shift(bottle_filled, 0, 8) temp = CInt(msg(0)) bottle_filled = int_or(bottle_filled, temp) Text1.Text = Str(bottle_filled) total_bottle = msg(3) total_bottle = int_shift(total_bottle, 0, 8) temp = CInt(msg(2)) total_bottle = int_or(total_bottle, temp) Text2.Text = total_bottle End Sub Public Sub rx_node2_PDO(ByRef msg() As Byte)
Application
Dim temp As Byte Dim total_box As Integer total_box = msg(1) total_box = int_shift(total_box, 0, 8) temp = CInt(msg(0)) total_box = int_or(total_box, temp) Text3.Text = total_box End Sub Public Sub tx_node1_PDO(ByVal strt_stp As Byte, ByVal node2_status As Byte) Dim can_msg(0 To 7) As Byte, ret_val As Byte
can_msg(0) = strt_stp If (Combo1.ListIndex > -1) Then can_msg(1) = Combo1.ListIndex + 1 Else Exit Sub End If If (Combo2.ListIndex > -1) Then can_msg(2) = Combo2.ListIndex Else Exit Sub End If can_msg(3) = node2_status If (node1_detect_flag = False) Then MsgBox "CAN node1 not detected on network", vbCritical, "Undetected Node" Exit Sub End If ret_val = can_tx(&H201, 4, can_msg) If (ret_val = 1) Then MsgBox "Message not transmitted. Please check can bus.", vbCritical, "CANBUS ERROR!" Text4.Text = "NOT DETECTED" Command2.Caption = "START NODE 1" Command1.Enabled = False Else If (strt_stp = 0) Then Text4.Text = "STARTED" Command2.Caption = "STOP NODE 1" Command1.Enabled = True Else Text4.Text = "STOPPED" Command2.Caption = "START NODE 1" Command1.Enabled = False End If End If End Sub
Application
Public Sub tx_node2_PDO(ByVal strt_stp As Byte, ByVal node1_status As Byte) Dim can_msg(0 To 1) As Byte, ret_val As Byte If (node2_detect_flag = False) Then MsgBox "CAN node2 not detected on network", vbCritical, "Undetected Node" Exit Sub End If can_msg(0) = strt_stp can_msg(1) = node1_status ret_val = can_tx(&H202, 2, can_msg) If (ret_val = 1) Then MsgBox "Message not transmitted. Please check can bus.", vbCritical, "CANBUS ERROR!" Text8.Text = "NOT DETECTED" Command2.Caption = "START NODE 1" Command4.Enabled = False Timer2.Enabled = False Else If (strt_stp = 0) Then Text8.Text = "" Text8.Text = "STARTED" Command3.Caption = "STOP NODE 2" Command4.Enabled = True Timer2.Enabled = True Else Text8.Text = "" Text8.Text = "STOPPED" Command3.Caption = "START NODE 2" Command4.Enabled = False Timer2.Enabled = False End If End If End Sub
Public Sub node1_SDO(ByRef msg() As Byte) If (msg(0) = &H80 Or msg(0) = &HFF) Then MsgBox "The specified Index/Sub-Index does not exist", vbOKOnly, "SDO Aborted" Text7.Text = "" Exit Sub End If Text7.Text = "" Text7.Text = Str(msg(7)) + Str(msg(6)) + Str(msg(5)) + Str(msg(4)) End Sub
Application
Public Sub node2_SDO(ByRef msg() As Byte) If (msg(0) = &H80 Or msg(0) = &HFF) Then MsgBox "The specified Index/Sub-Index does not exist", vbOKOnly, "SDO Aborted" Text11.Text = "" Exit Sub End If Text11.Text = "" Text11.Text = Str(msg(7)) + Str(msg(6)) + Str(msg(5)) + Str(msg(4)) End Sub
Private Sub Timer2_Timer() node2_detect_flag = False Command3.Caption = "START" Command4.Enabled = False Text8.Text = "" Text8.Text = "NOT DETECTED" Text9.Text = "" Text10.Text = "" Text11.Text = "" Timer2.Enabled = False MsgBox "CAN node 2 disconnected from network", vbCritical, "Node Disconnected" End Sub
In the program, as in NODE programs, the CAN interface and SPI interface functions are in as separate module. For access to the parallel port through VB, the program uses a Dynamic Link Library called InpOut32.dll. This DLL file is developed using Visual C++ compiler. Also we have added other bit level and lower levels functions not available in VB in this file such as bit_and, bit_or, bit_shift etc. That covers almost all the major aspects of the application developed to show the working of CAN and CANopen protocol in actual industrial environment. Details of various components can be obtained from their respective datasheets easily available on the internet. Also these datasheets and other literature about Industrial Automation, Sensors, Industrial Networking, CAN, CANopen and other details are available on the websites listed in Bibliography.
Conclusion
CONCLUSION
The only source of knowledge is experience Albert Einstein A very apt quote whose correctness we understand now after making a working model of a project that few months ago was just our aspiration. This project helped us observe and understand the phenomenon which we until now just imagined and understood on paper. It helped us bridge the gap between the theoretical world and the practical world. We now have ample experience and knowledge about working of various sensors, different type of industrial automation units and parts and basic knowledge of various industrial communication protocols. Also we know in depth the working of CAN and CANopen protocols and various peripherals available for them. Also we have gained wide experience in microcontroller programming and interfacing it other peripherals and implementing application software on it. Similarly we know Visual Basic programming and some parts of Visual C++. Apart from this we have learned numerous minute details about working of various electronic components and their common problems and solutions The experience which we have gained from this project will be with us for the rest of our life and it will surely help us in many ways. And the experienced does not only relate to technical and practical aspects from this project, but it covers a wide spectrum even outside technical details like working in a group, managing time and resources, delegation of work and many other things which will surely help us enrich our career and life.
Bibliography
BIBLIOGRAPHY Industrial Automation & sensors: www.ifm-electronic.com www.wikipedia.com www.omega.com Industrial Networking: www.fieldbus.com www.odva.org www.as-interface.com www.profibus.com www.wikipedia.com CAN and CANopen: CAN Specification 2.0A, 1991, Robert Bosch GmbH, Stuttgart, Germany www.can-cia.de www.esacademy.com www.canopensolutions.com www.emicros.com

My Project Report

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

My Project Report

Hochgeladen von

Copyright:

Verfügbare Formate

Introduction

___________________________________________________________________________ __S. B. M. Polytechnic 1 VII Semester

Automated System Basics

AUTOMATED SYSTEM BASICS

Automated System Basics

Automated System Basics

_____________________________________________________________________________ S. B. M. Polytechnic 4 VII Semester

_____________________________________________________________________________ S. B. M. Polytechnic 6 VII Semester

Control level Production level Remote bus level

Actuator and Sensor level

_____________________________________________________________________________ S. B. M. Polytechnic 8 VII Semester

Layer 2 - Data Link:

_____________________________________________________________________________ S. B. M. Polytechnic 11 VII Semester

Controller Area Network

CONTROLLER AREA NETWORK

Controller Area Network

2.) BASIC CONCEPTS

_____________________________________________________________________________ S. B. M. Polytechnic 13 VII Semester

Controller Area Network

_____________________________________________________________________________ S. B. M. Polytechnic 14 VII Semester

Controller Area Network

Controller Area Network

Controller Area Network

Controller Area Network

3.) FRAME TYPES

_____________________________________________________________________________ S. B. M. Polytechnic 18 VII Semester

Controller Area Network

_____________________________________________________________________________ S. B. M. Polytechnic 19 VII Semester

Controller Area Network

_____________________________________________________________________________ S. B. M. Polytechnic 20 VII Semester

Controller Area Network

Coding of the number of data bytes by the DATA LENGTH CODE

Controller Area Network

Controller Area Network

_____________________________________________________________________________ S. B. M. Polytechnic 23 VII Semester

Controller Area Network

Controller Area Network

Controller Area Network

Controller Area Network

Controller Area Network

5.) ERROR HANDLING

Controller Area Network

_____________________________________________________________________________ S. B. M. Polytechnic 29 VII Semester

_____________________________________________________________________________ S. B. M. Polytechnic 30 VII Semester

_____________________________________________________________________________ S. B. M. Polytechnic 31 VII Semester

The CANopen object dictionary

_____________________________________________________________________________ S. B. M. Polytechnic 34 VII Semester

_____________________________________________________________________________ S. B. M. Polytechnic 35 VII Semester

_____________________________________________________________________________ S. B. M. Polytechnic 36 VII Semester

Process Data Object (PDO) protocol

_____________________________________________________________________________ S. B. M. Polytechnic 39 VII Semester

Service Data Object (SDO) Protocol

_____________________________________________________________________________ S. B. M. Polytechnic 41 VII Semester

Synchronization Object (SYNC) protocol

Time Stamp Object (TIME) protocol

Emergency Object (EMCY) protocol

_____________________________________________________________________________ S. B. M. Polytechnic 43 VII Semester

The General Purpose Instrument

THE GENERAL PURPOSE INSTRUMENT

The General Purpose Instrument

The General Purpose Instrument

The General Purpose Instrument

The General Purpose Instrument

_________________________________________________________________________ S. B. M. Polytechnic 1 VII Semester