FACULTY OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF INSTRUMENTATION AND CONTROL ENGINEERING

COURSE FILE

ACADEMIC YEAR OF JUNE 2013 – DEC 2013

SUBJECT CODE: IC0401

SUBJECT TITLE:VIRTUAL INSTRUMENTATION

PREPARED BY

S.SENTHILMURUGAN M.E,

101235. ASSISTANT PROFESSOR/ICE.

SRM UNIVERSITY. KATTANKULATHUR.

CHENNAI-603203. TAMILNADU. INDIA.

MOB: +91 – (0) 98942 96319, 98426 35912

MAIL ID: senthilmurugan.s@ktr.srmuniv.ac.in

VISION & MISSION

Vision

To emerge as a World - Class University in creating and

disseminating knowledge, and providing students a unique

learning experience in science, technology, medicine,

management and other areas of scholarship that will best serve

the world and betterment of mankind.

Mission

MOVE UP through international alliances and collaborative

initiatives to achieve global excellence.

ACCOMPLISH A PROCESS to advance knowledge in a rigorous

academic and research environment.

ATTRACT AND BUILD PEOPLE in a rewarding and inspiring

environment by fostering freedom, empowerment, creativity and

innovation.

CONTENTS

1. VISION & MISSION

2. SYLLABUS

3. LESSON PLAN

4. MATERIALS

5. CYCLE TEST I

6. CYCLE TEST II

7. MODEL EXAMINATION

8. ANSWER SCRIPTS

9. UNIVERSITY QUESTION PAPER

10. RESULT ANALYSIS

FACULTY OF ENGINEERING AND TECHNOLOGYFACULTY OF ENGINEERING AND TECHNOLOGYFACULTY OF ENGINEERING AND TECHNOLOGYFACULTY OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF INSTRUMENTATION AND CONTROL ENGINEERINGDEPARTMENT OF INSTRUMENTATION AND CONTROL ENGINEERINGDEPARTMENT OF INSTRUMENTATION AND CONTROL ENGINEERINGDEPARTMENT OF INSTRUMENTATION AND CONTROL ENGINEERING

Course CodeCourse CodeCourse CodeCourse Code : : : : IC0401 IC0401 IC0401 IC0401

Course TitleCourse TitleCourse TitleCourse Title : : : : VIRTUAL INSTRUMENTATIONVIRTUAL INSTRUMENTATIONVIRTUAL INSTRUMENTATIONVIRTUAL INSTRUMENTATION

Year& Semester Year& Semester Year& Semester Year& Semester :::: IV year,IV year,IV year,IV year, VII sVII sVII sVII semesteremesteremesteremester

Course DurCourse DurCourse DurCourse Durationationationation :::: Odd Semester (Odd Semester (Odd Semester (Odd Semester (JuneJuneJuneJune----Dec201Dec201Dec201Dec2013333))))

LocationLocationLocationLocation :::: Tech Park Tech Park Tech Park Tech Park

Faculty Details:Faculty Details:Faculty Details:Faculty Details:

Name of the staff Section Office Office Hours Mail ID

Mr.S.Senthilmurugan B.Tech ICE A

Tech Park

8.45 AM-4.00 PM Senthilmurugan.s@ktr.srmuniv.ac.in

Mrs.P.Anithasaraswathi B.Tech ICE B

Tech Park

8.45 AM-4.00 PM Anitha.p@@ktr.srmuniv.ac.in

Required Text Books:Required Text Books:Required Text Books:Required Text Books:

• LabVIEW based Advance Instrumentation, P.Surekha, S.Sumathi. • Virtual Instrumentation Using LabVIEW, Jovitha Jero me • Gary Johnson, 'Lab view graphical programming', II Ed., McGraw Hill,

1997 • Lisa K Wells & Jeffrey Travels, 'Lab view for everyone', Prentice Hall, 1997 • Sokoloff, 'Basic Concepts of lab view 4', Prentice Hall, 1998 • S. Gupta, J.P. Gupta, 'PC interfacing for Data Acquisition & Process

Control', 2nd Ed., Instrument Society of America, 1994

Web Resource:

• www.ni.com

Prerequisite: Concepts of Data Acquisition Systems and Basics of LabVIEW Programming

ObjectiveObjectiveObjectiveObjective: : : :

1) Understand the importance and applications of virtual instrumenta1) Understand the importance and applications of virtual instrumenta1) Understand the importance and applications of virtual instrumenta1) Understand the importance and applications of virtual instrumentation tion tion tion

2) Learn the basic programming concepts in LabVIEW 2) Learn the basic programming concepts in LabVIEW 2) Learn the basic programming concepts in LabVIEW 2) Learn the basic programming concepts in LabVIEW

3) Learn different Data Acquisition System concepts. 3) Learn different Data Acquisition System concepts. 3) Learn different Data Acquisition System concepts. 3) Learn different Data Acquisition System concepts.

4) Develop real time applications using LabVIEW 4) Develop real time applications using LabVIEW 4) Develop real time applications using LabVIEW 4) Develop real time applications using LabVIEW

Tentative test details and portions:Tentative test details and portions:Tentative test details and portions:Tentative test details and portions:

Cycle Test Cycle Test Cycle Test Cycle Test ---- I: I: I: I: Unit I &IIUnit I &IIUnit I &IIUnit I &II

CycCycCycCycle Test le Test le Test le Test ––––IIIIIIII:::: Unit III & IVUnit III & IVUnit III & IVUnit III & IV

Model Exam:Model Exam:Model Exam:Model Exam: All five unitsAll five unitsAll five unitsAll five units

Assessment detailsAssessment detailsAssessment detailsAssessment details

Cycle test-I 10 Cycle test –II 10 Model Examination 20 Surprise test 5 Attendance 5 Total 50

Outcomes

Students who have successfully completed thiStudents who have successfully completed thiStudents who have successfully completed thiStudents who have successfully completed this course s course s course s course

Course outcome Program outcome

Familiarize the basics and interfacing of VI

Write programs for different applications

To understand basics, programming techniques, data acquisition To understand basics, programming techniques, data acquisition To understand basics, programming techniques, data acquisition To understand basics, programming techniques, data acquisition and interfacing techniques of virtual instrumentation and interfacing techniques of virtual instrumentation and interfacing techniques of virtual instrumentation and interfacing techniques of virtual instrumentation

To use To use To use To use VI for different applications VI for different applications VI for different applications VI for different applications

Detailed Session PlanDetailed Session PlanDetailed Session PlanDetailed Session Plan

Day Name of the topics Reference

DAY 1 UNIT1: Historical perspective Jovitha Jerome DAY 2 Need of VI, Advantages of VI, Define VI Jovitha Jerome DAY 3 Block diagram & architecture of VI Jovitha Jerome DAY 4 Data flow techniques Jovitha Jerome DAY 5 Graphical programming in data flow Jovitha Jerome DAY 6 Comparison with conventional programming Jovitha Jerome

DAY 7 Surprise test DAY 8 Unit II: VIS and sub-VIS Jovitha Jerome DAY 9 Loops & charts, arrays, clusters, graphs Jovitha Jerome DAY 10 Case & sequence structures Jovitha Jerome DAY 11 Formula modes, local and global variable Jovitha Jerome DAY 12 String & file input and output Jovitha Jerome DAY 13 Graphical programming in data flow Jovitha Jerome DAY 14 Surprise II DAY 15 Unit III: ADC, DAC P.Surekha,

S.Sumathi DAY 16 DIO techniques P.Surekha,

S.Sumathi

DAY 17 PC Hardware structure P.Surekha, S.Sumathi

DAY 18 DMA P.Surekha, S.Sumathi

DAY 19 GPIB/IEEE 488 concepts P.Surekha, S.Sumathi

DAY 20 Embedded system buses - PCI, CPCI P.Surekha, S.Sumathi

DAY 21 USB & VXI. A P.Surekha, S.Sumathi

DAY 22 Timing, interrupts P.Surekha, S.Sumathi

DAY 23 Software and Hardware Installation P.Surekha, S.Sumathi

DAY 24 Counters & timers P.Surekha, S.Sumathi

DAY 25 EISA programming P.Surekha, S.Sumathi

DAY 26 Surprise test III DAY 27 Unit IV: Current loop P.Surekha,

S.Sumathi DAY 28 RS 232C/RS 485RS 232C/RS 485RS 232C/RS 485RS 232C/RS 485 P.Surekha,

S.Sumathi DAY 29 System basics, interface basics: USB, PCMCIA P.Surekha,

S.Sumathi DAY 30 VXI, SCXI, PXI P.Surekha,

S.Sumathi DAY 31 Networking basics for office & industrial application P.Surekha,

S.Sumathi DAY 32 VISA & IVI P.Surekha,

S.Sumathi DAY 33 Image acquisition & processing P.Surekha,

S.Sumathi DAY 34 Motion Control P.Surekha,

S.Sumathi DAY 35 DMM, waveform generator P.Surekha,

S.Sumathi DAY 36 Unit V: General applications of VI P.Surekha,

S.Sumathi DAY 37 Fourier transforms, Power spectrum P.Surekha,

S.Sumathi

DAY 38 windowing & flittering P.Surekha, S.Sumathi

DAY 39 Application in Process Control projects P.Surekha, S.Sumathi

DAY 40 Major equipments- Oscilloscope, Digital Multimeter P.Surekha, S.Sumathi

DAY 41 Pentium Computers P.Surekha, S.Sumathi

DAY 42 Temperature data acquisition system P.Surekha, S.Sumathi

DAY 43 Motion control employing stepper motor P.Surekha, S.Sumathi

DAY 44 Revision DAY 45 Revision

1.1. What is Labview?

LabVIEW is a graphical programming language that uses icons instead of lines of

texts to create applications. In contrast to text-based programming languages, where

instructions determine program execution, LabVIEW uses dataflow programming, where

the flow or data determines execution.

In LabVIEW, you build a user interface by using a set of tools and objects. The user

interface is known as the front panel. You then add code using graphical representations

of functions to control the front panel objects. The block diagram contains this code. In

some ways, a block diagram resembles flow chart

LabVIEW programs are called virtual instruments, or VIs, because their appearance and

operation imitate physical instruments, such as oscilloscopes and multimeters. LabVIEW

contains a comprehensive set of VIs and functions for acquiring, analyzing, displaying,

and storing data, as well as tools to help you troubleshoot your code.

1.2. Parts of a VI

LabVIEW VIs contain three main components:

1. The front panel,

2. The block diagram

3. The icon/connector pane

Getting started screen will be shown when you run LabVIEW. It can be seen in fig. 1

below.

Fig 1. Getting started screen of LabVIEW

For now, as a beginner, you should get acquainted to LabVIEW environment. Try to

click "Blank VI" under the "New" Section on the left (See Fig. 1). You will see two

windows are appearing. One is the grey one which is called “Front panel” and the other

is white which is called “Block diagram”.

1.2.1. Front Panel

Front panel is the graphical user interface (GUI) of your LabVIEW program where

you will interact with it while it is running. See Figure 2 to observe the blank front panel.

Note that the background of front panel is grey.

Fig. 2. Blank front panel of LabVIEW program

1.2.2. Block Diagram

Different from front panel, the block diagram has white background. In fact, this

window is where the program will actually be written. When you develop the block

diagram, you are actually writing the program that makes the front panel operate as you

desire. It is here that you will make the computer perform calculations, write files,

communicate with hardware, etc. This view of the VI is what most programmers would

call a "Program" or "Source code". A blank block diagram is shown in figure 3.

Front Panel has grey background

Fig. 3. Blank block diagram of LabVIEW program

1.2.3. Icon / Connector Pane

Icon / connector pane is used to make subVI. A subVI is a VI used inside another VI.

SubVIs are an important introductory concept in LabView. A VI is a "Virtual Instrument"

which is just the basic labview program, contained in a .VI file, which is represented by a

front panel and block diagram. However, every VI can also be a SubVI. The third

component of a VI consists of its icon and connector pane. These two pieces make every

VI capable of becoming a SubVI.

So, what exactly is a SubVI? It is a VI that is placed on the block digram of a higher

level VI. It allows you to write modules of code that you can wire into your diagrams

later. The icon is what the SubVI will look like on another VIs block diagram. The

connector pane allows you to assign terminals on the icon to front panel controls and

indicators for the purpose of wiring values into and out of a SubVI.

1.3. Controls Palette, Functions Palette, and Tools Palette

These three palettes are the most widely used feature to make a program in

LabVIEW. You must be familiar with these palettes. Controls palette and functions

Block diagram has white background

palette are associated with front panel and block diagram respectively, whereas tools

palette is associated with both, front panel and block diagram window.

1.3.1. Controls Palette

In order to show the controls palette, in front panel, go to View>>controls palette (See

fig. 4). Controls palette contains the ‘controls’ and ‘indicators’ you use to create the

front panel. Controls and indicators can be accessed from View>>controls

palette>>Numeric (there is another way to access these controls and indicators through

‘Express’ menu in controls palette, but it is left for you to explore later).

� ‘Controls’ allow you to input something into your program. That means you can

change the value and affect the program while it is running.

� ‘Indicators’ allow you to see results from the program. You cannot change their

value. They are your way of seeing what has happened.

Fig. 4. Controls Palette

1.3.2. Functions Palette

The functions palette contains the VIs, functions, and constants you use to create the program in the block diagram. You access the functions palette from the block diagram by selecting View>>Functions Palette. The functions palette is presented in fig. 5.

Fig. 5. Functions Palette

1.3.3. Tools Palette

Tools palette contains tools to construct the graphical user interface (GUI) on the front panel and the program on the block diagram. It can be accessed through View>>Tools Palette (see Fig.6.).

Fig. 6. Tools Palette

2nd TUTORIAL ACQUIRING, ANALYZING, AND PRESENTING DATA

Now, through example, you will try to make a simple program used to acquire, analyze, and present data. Since you are not doing actual experiment, you will utilize a simulate signal function as an acquired signal.

You will make a VI shown in the figure below (Front panel and block diagaram respectively). Follow the steps in the figures and the instructions

1. Access ‘View>>Controls Palette>>Express>>Graph Indicators>>Waveform Chart

(Chart)’.

Put the chart on the front panel (see picture below)

2. Go to ‘View>>Tools Palette>>Edit Text’ and change the label ‘Waveform Chart’ to

Graph of experimental data as shown below

3. Access ‘View>>Controls Palette>>Express>>Numeric Indicators>>Numeric Indicators’.

4. And then change the label ‘Numeric’ to ‘Measured Amplitude’ and enlarge the

indicator by drag the right side of the indicator to the right.

5. Put two more ‘numeric indictors’ by using the same method (or you can use another

way, i.e, on the first numeric indicator press ‘Ctrl + hold the left mouse botton’ then

drag).

6. Change the label to ‘Measured Frequency’ and ‘Standard Deviation’ (see figure below)

7. You can see in ‘block diagram’ the terminals of the indicators is automatically coming.

8. Next, we will go to block diagram to make the program. View>>Functions Palette

9. Click ‘Express>>Signal Analysis>>Tone Measurements’ and put it on the block diagram.

10. The properties window of ‘Tone measurement’ will appear automatically. Check

‘Amplitude and Frequency’ options then click OK.

11. Afterwards, go to ‘View>>Functions Palette>>Express>>Input>>Simulate Signal’.

12. The properties window will appear automatically and make the setting shown in the

picture then press OK.

13. Now, your block diagram is as shown in the figure below

14. Next, go to ‘View>>Functions Palette>>Express>>Signal Analysis>>Statistics’ put it

on the block diagram. The Properties window will appear. Check the ‘Standard Deviation Option’ then click OK (see figures below)

Properties window of the statistic function can be seen below.

15. Connect the wire from ‘View>>Tools Palette>>Connect wire’.

16. Next, do right click (another way to access functions palette) and go to

‘Express>>Execution Controls>>While Loop’.

17. Enclose the whole program with the ‘While Loop’.

This is while loop

18. Go to front panel and arrange the front panel so that it looks like the figure below.

Then run the program

3rd TUTORIAL

CREATING SUBVI

In this lecture, we are about to learn how to make subVI. What exactly is a SubVI? It

is a VI that is placed on the block digram of a higher level VI. It allows you to write

modules of code that you can wire into your diagrams later. The icon is what the SubVI

will look like on another VIs block diagram. The connector pane allows you to assign

terminals on the icon to front panel’s controls and indicators for the purpose of wiring

values into and out of a SubVI.

The SubVI interface (icon and connector pane) is not as immediately obvious as the

front panel and block diagram when a VI is opened. It is accessible from the upper right

hand corner of the front panel window (This expalantion and example is taken from

www.learnlabview.blogspot.com):

By default the icon is displayed. By right clicking on the icon you will see a pop-up

menu. You can see there are options for setting properties of the current VI, Editing the

Icon, and Showing the connector pane. In this menu you should select Show Connector:

Upon doing so, the icon image will change to a layout of the connector pane:

By clicking on the regions in the connector pane with the wiring tool, and then

clicking on front panel objects, the VI becomes a usable SubVI. There are no

requirements on how many or how few of the front panel objects should be wired. It is up

to you if the value is needed for the program to function properly. If a front panel object

is not connected to the connector pane, then the default value will likely be used when the

VI is called from another VI as a SubVI. Now let's create a SubVI to make this clear.

First, create a VI. In this case, a simple VI that gives increment of one on a value will

suffice.

Next you will need the connector pane visible and the wiring tool selected. The wiring

tool is always selected when you use the right click menu on the icon to choose "Show

Connector". Therefore, if the connector pane is visible but the wiring tool is not selected,

go back to the Icon, then back to the Connector again. (i.e. right click -> "Show Icon" ->

right click -> "Show Connector") This is a trick to get to the wiring tool with the

connector pane quickly. Left click with the wiring tool on the upper left terminal of the

connector pane and it will turn black:

Then left click on the input control on the front panel GUI:

Note that the terminal turns an orange/grey highlighted color, indicating that the link

is established between that terminal and the "Number Input" control. When you click off

of the Number Input control, the terminal is shown as being linked but not selected:

Now, follow the same steps to connect the indicator terminal and it should look like this:

Now that the connector pane is wired for this VI, it is a usable SubVI. However, to

make it easily identifiable in the block diagrams of VIs that call it, you should give it a

custom icon. This is not necessary, but a brief summary of the steps follow:

Use the right click menu on the Icon or Connector Pane to select "Edit Icon". The

following utility appears:

This program operates more or less like a rudimentary paint program. I drew the

following simple icon for this example:

Hit OK, and the VI now uses the new icon. Note that the icon appears at the upper right

of the VI windows:

Now, before LabView can use this Untitled VI as a SubVI, it needs to be saved. It

should be given a reasonable name. Select File->Save As, then navigate to a folder where

you would like to save this VI. I named it "Increment". The .VI extension is

automatically added by LabView.

Now are about to see this newly saved SubVI in action. Start a new blank VI and

open the Block Diagram menu:

Hit "Select a VI" then select the SubVI from the location where you saved it.

Immediately you will be holding something that looks like the Icon of the SubVI to be

placed on the block diagram of this new VI:

Once it is placed, you will find that by hovering over the terminals that were attached on

the connector pane, you will find wiring locations that correspond to the front panel

objects of the original VI. For example, hovering over the upper left terminal shows that

there is a wiring site for "Number Input".

Whatever you wire into that terminal on this block diagram will essentially run the

original VIs block diagram with that value. This is all represented just by this icon you

have placed. That is the power of the SubVI. For programmers, you will recognize this is

the same as a function, module, subroutine, etc. SubVI is the LabView name for this.

Below is an example of what it might look like once the SubVI is wired into this new VI:

Note that this new VI has the default Icon and if you go to its connector pane, it is empty. You could set this VI up as another SubVI.

4th TUTORIAL STRUCTURES

(Taken from www.learnlabview.blogspot.com)

Now, we are going to do get acquainted to one of labVIEW important features, i.e.,

structures. Without structures, LabView would be just a mesh of wires with no way to

control the order and timing of the things that occur. However, structures make LabView

a true programming language. For those with experience programming in languages such

as C, LabView structures are essentially identical to flow control or conditional

statements. The most common structures can be seen below:

While Loop

Case Structures

For Loop

Sequence Structures

All LabView structures are placed on the block diagram by dragging a box. You left

click at one corner, drag the mouse, and release at the opposite corner. The area in the

box is now partitioned from the area outside of the box. In a sense there are multiple

block diagrams (at least from a dataflow standpoint) in the one piece of code. The menu

to access LabView structures is shown below:

In block diagram click ‘view>>functions palette>>programming>>structures’.

In this lecture, we are focused only on while loop. Now, let's just start with an

example:

while loop

This code program shows a block diagram which has one input and one output. In

between is a while loop structure. This structure contains just the grey rectangle, the "i"

and conditional terminals. In this example, the portion of the block diagram inside the

while loop will run until TRUE is sent to the stop terminal. It will simply start over

within the confines of that rectangle, if FALSE is sent to the stop terminal. The 'i'

terminal always puts out how many times the while loop has repeated starting with 0. If

FALSE is received on the first iteration of the while loop, then 'i' will send out 1 as its

value for the second iteration. On the third iteration, if it is reached, the 'i' terminal will

send 2.

The squares on the periphery of the while loop where values come in and leave the

structure are called "tunnels". The leftmost tunnel happens to be an input tunnel and the

rightmost tunnel happens to be an output tunnel. The value coming into the while loop on

an input tunnel will stay the same for every iteration of the while loop. The value going

out of the while loop on the output tunnel will only be sent once after the last iteration

(when TRUE is received by the condition terminal and the condition is set to be ‘stop if

true’). Actually, a programmer can change the condition of this terminal to be either ‘stop

if TRUE’ or ‘continue if TRUE’, depends on what they need.

So what does this code program do? It iterates multiple times in the while loop, until

the value from the index 'i' terminal is greater than the value on the front panel control

wired to the input tunnel. The last value of 'i' on the final iteration is sent out of the while

loop structure to the indicator on the front panel.

With structures, the tunnels are a key entry and exit point. All dataflow is conducted

into and out of structures looking at the tunnels as nodes that tie the structures to the rest

Conditional terminal ‘i’ terminal

or iteration terminal

of the block diagram. Once all the input nodes have their values, the structure will begin

to execute the portion of the block diagram within the structure to completion. Once it

completes, any output tunnels will contain the results of the processing within the

structure.

LABVIEW FINAL EXAM, 1 ST SEMESTER 1429-1430

This exam is a take-home exam. The students will be given evaluation version of LabVIEW 8.2 program to be installed on their computers. This exam must be submitted to the tutor no longer than 2 weeks after the distribution of the question sheets. The problems set are presented below. Q.1. Here, you are going to make a LabVIEW program which uses while loop and will

answer some questions after you complete the program. While loop is one of structures that will control the running of a program. Any program which is inside while loop will keep running until it meets the chosen condition. The program can be seen below.

In this program, you will give a certain value in the ‘numeric control’ labeled ‘target of number of iteration’. When you run the program, the ‘numeric indicator’ labeled ‘actual number of iteration’will count the number of iteration that has been done. The program will stop running when the ‘actual number or iteration’ matches the ‘ target number of iteration’. The steps that you should do to make the program are as follows. 1. Find ‘while loop’ from functions pallete>>programming>>structures>>while

loop. Put the while loop on the block diagram by left-clicking (keep holding the botton) and draging the mouse from top-left-corner to the bottom-right-corner direction.

This is (i) terminal. (i) terminal provides the current loop iteration count which is zero for the first iteration

This is the loop condition terminal which will receive a Boolean (true or false) value.

2. Create numeric indicator on the (i) terminal by right-clicking on the terminal then choose create>> indicator. Numeric indicator with blue color and I32 notation will appear. This means the numeric indicator can only show 32-bit integer values. Change the label to ‘Actual number of iteration ’ (to show or hide the label: right-click on the terminal>>visible items>>label).

3. Take the ‘great or equal?’ function from functions palette>>programming>>comparison>> great or equal?. This function will compare between two values whether the ‘x’ (top-left side terminal) value is greater or equal than the ‘y’ (bottom-left side terminal) value. The output (right side terminal) value of this function is ‘true (boolean/logic)’ if x>y or x=y and is ‘false (boolean/logic)’ if x<y.

4. Create numeric control on the ‘y’ terminal of ‘great or equal’ function by right-

clicking on the terminal then choose create>>control. Numeric control with blue color and I32 notation will appear. This means the numeric control can only be filled with 32-bit integer values. If the color of control appears is orange with DBL notation, you can change it by right-clicking on the terminal>>representation>>I32. Change the label to ‘ target of number of iteration’ (to show or hide the label: right-click on the terminal>>visible items>>label).

5. Put ‘And’ function on the block diagram. It can be found in functions palette>>programming>>boolean>>and. ‘And’ function is one of boolean/logic functions. It only processes logical values (true and false) input and gives a logical value output.

6. Create control on the ‘y’ terminal of ‘and’ function by right-clicking on the terminal then choose create>>control. Push button, which is one of ‘Boolean controls’, will appear. The control is automatically chosen as ‘boolean control’ because ‘and’ function can only deal with boolean values. To show or hide the label: right-click on the terminal>>visible items>>label. Change label to ‘push button’. ‘ Push button’ will give true value when it is ‘on’ and give false value when it is ‘off’ .

7. Connect wires and arrange the functions and terminals as shown in the figure below

8. Now arrange the front panel so that it looks like the figure below

9. Finally, you need to add ‘time delay express VI’ inside the while loop as shown

below. The ‘time delay express VI’ can be found in functions palette>>programming>>timing>>time delay. Set the time delay to 1 second.

10. Now, your program is complete.

11. Please do the following instructions and answer the questions below

a. Change the value of the ‘target of number of iteration’ (numeric control) to 10 and then turn on the push button. Run the program. Explain what you observe!

b. Turn off the push button and then run the program (keep the value 10). What happens? Explain why!

c. Now, go to block diagram, put the cursor on the ‘loop condition’ terminal and then right click>>continue if true. Next, go back to front panel, turn on the push button and run the program with the same value in the numeric control (10). What do you observe?

d. Now, change the value inside the numeric control to 0 and run the program. What happens? Explain why does the program runs like that in ‘c’ and ‘d’ after you change the condition loop!

e. Summarize what the function of ‘while loop’ is, based on your experiments above (a, b, c, d)!

f. What happens if you change the value of ‘time delay’? Describe what the function of ‘time delay’ is, based on what you observe.

Note: 1. Try also to use help menu provided by the program.

2. You can use search menu to find anything you need to make the program. It can be accessed from functions and controls palette>>search (on the top right corner of the palette).

Q.2. Now you are going to make another program. Make the following program on

your own and explain the steps like that of question no.1 (the previous program)!

This program is used to convert celcius degree into farenheit and Kelvin degree. You can see the front panel and the block diagram of the complete program below.

Note: You can use search menu to find anything you need to make the program. It can be accessed from functions and controls palette>>search (on the top right corner of the palette) and then type the name of the thing that you need.

Q.3. Explain briefly what 1. Front panel, 2. block diagram, and 3. connector pane

are. Note: Connector pane is related to subVI.

Universal Serial Bus (USB)

Universal Serial Bus (USB) provides a serial bus standard for connecting devices, usually to computers such as PCs and the Apple Macintosh, but is also becoming commonplace on video game consoles such as Sony's PlayStation 2, Microsoft's Xbox 360, Nintendo's Revolution, and PDAs, and even devices like televisions and home stereo equipment.

Contents

� 1 Overview � 1.1 Standardization

� 2 Technical details � 2.1 Device classes � 2.2 USB signaling

� 2.2.1 Standard USB signaling � 2.2.1.1 Transfer speed

� 2.2.2 Mini USB signaling � 2.3 USB connectors � 2.4 Power supply

� 3 USB compared to other standards � 3.1 Storage � 3.2 Human-interface devices (HIDs) � 3.3 FireWire

� 3.3.1 Technical differences � 3.4 USB 2.0 Hi-Speed vs FireWire

� 4 Version history � 4.1 USB � 4.2 USB On-The-Go Supplement � 4.3 Wireless USB

� 5 Extensions to USB � 6 Communication with USB devices

� 6.1 Communication from the Linux OS � 6.2 Communication from the Mac OS � 6.3 Communication from the Windows OS � 6.4 Other communication options

� 7 See also � 8 External links

Overview

A USB system has an asymmetric design, consisting of a host controller and multiple daisy-chained devices. Additional USB hubs may be included in the chain, allowing branching into a tree structure, subject to a limit of 5 levels of branching per controller. Not more than 127 devices, including the bus devices, may be connected to a single host controller. Modern computers often have several host controllers, allowing a very large number of USB devices to be connected. USB cables do not need to be terminated.

USB was designed to allow peripherals to be connected without the need to plug expansion cards into the computer's ISA, EISA, or PCI bus, and to improve plug-and-play capabilities by allowing devices to be hot-swapped (connected or disconnected without powering down or rebooting the computer). When a device is first connected, the host enumerates and recognises it, and loads the device driver it needs.

A USB hub

USB can connect peripherals such as mice, keyboards, gamepads and joysticks, scanners, digital cameras, printers, external storage, networking components, etc. For many devices such as scanners and digital cameras, USB has become the standard connection method. USB is also used extensively to connect non-networked printers, replacing the parallel ports which were widely used; USB simplifies connecting several printers to one computer. As of 2004 there were about 1 billion USB devices in the world. As of 2005, the only large classes of peripherals that cannot use USB are displays and monitors, and high-quality digital video components, because they need a higher data rate than USB can provide.

Standardization

The design of USB is standardized by the USB Implementers Forum (USB-IF), an industry standards body incorporating leading companies from the computer and electronics industries. Notable members have included Apple Computer, Hewlett-Packard, NEC, Microsoft, Intel, and Agere.

The USB specification is at version 2.0 (with revisions) as of February 2006. Hewlett-Packard, Intel, Lucent, Microsoft, NEC, and Philips jointly led the initiative to develop a higher data transfer rate than the 1.1 specification. The USB 2.0 specification was released in April 2000 and was standardized by the USB-IF at the end of 2001. Previous notable releases of the specification were 0.9, 1.0, and 1.1. Equipment conforming with any version of the standard will also work with devices designed to any of the previous specifications (backwards compatibility).

Smaller USB plugs and receptacles, called Mini-A and Mini-B, are also available, as specified by the On-The-Go Supplement to the USB 2.0 Specification. The specification is at revision 1.0a (Jan 2006).

Technical details

USB connects several devices to a host controller through a chain of hubs. In USB terminology devices are referred to as functions, because in theory what we know as a device may actually host several functions, such as a router that is a Secure Digital Card reader at the same time. The hubs are special purpose devices that are not officially considered functions. There always exists one hub known as the root hub, which is attached directly to the host controller.

These devices/functions (and hubs) have associated pipes (logical channels) which are connections from the host controller to a logical entity on the device named an endpoint. The pipes are synonymous to byte streams such as in the pipelines of Unix, however in USB lingo the term endpoint is (sloppily) used as a synonym for the entire pipe, even in the standard documentation.

These endpoints (and their respective pipes) are numbered 0-15 in each direction, so a device/function can have up to 32 active pipes, 16 inward and 16 outward. (The OUT direction shall be interpreted out of the host controller and the IN direction is into the host controller.) Endpoint 0 is however reserved for the bus management in both directions and thus takes up two of the 32 endpoints. In these pipes, data is transferred in packets of varying length. Each pipe has a maximum packet length, typically 2n bytes, so a USB packet will often contain something on the order of 8, 16, 32, 64, 128, 256, 512 or 1024 bytes.

Each endpoint can transfer data in one direction only, either into or out of the device/function, so each pipe is uni-directional. All USB devices have at least two such pipes/endpoints: namely endpoint 0 which is used to control the device on the bus. There is always an inward and an outward pipe numbered 0 on each device. The pipes are also divided into four different categories by way of their transfer type:

� control transfers - typically used for short, simple commands to the device, and a status response, used e.g. by the bus control pipe number 0

� isochronous transfers - at some guaranteed speed (often but not necessarily as fast as possible) but with possible data loss, e.g. realtime audio or video

� interrupt transfers - devices that need guaranteed quick responses (bounded latency), e.g. pointing devices and keyboards

� bulk transfers - large sporadic transfers using all remaining available bandwidth (but with no guarantees on bandwidth or latency), e.g. file transfers

When a device (function) or hub is attached to the host controller through any hub on the bus, it is given a unique 7 bit address on the bus by the host controller.

The host controller then polls the bus for traffic, usually in a round-robin fashion, so no device can transfer any data on the bus without explicit request from the host controller. The interrupt transfers on corresponding endpoints does not actually interrupt any traffic on the bus, they are just scheduled to be queried more often and in between any other large transfers, thus "interrupt traffic" on a USB bus is really only high-priority traffic.

USB device descriptors are hierarchical and quite complex. This UML diagram tries to give a entity relation between the different descriptors: the lower left device descriptor is highest in the hierarchy, this has configuration descriptors, which have interface descriptors, which have interface settings which in turn hold the actual endpoints.

To access an endpoint, a hierarchical configuration must be obtained. The device connected to the bus has one (and only one) device descriptor which in turn has one or more configuration descriptors. These configurations often correspond to states, e.g. active vs. low power mode. Each configuration descriptor in turn has one or more interface descriptors, which describe certain aspects of the device, so that it may be used for different purposes: for example, a camera may have both audio and video interfaces. These interface descriptors in turn have one default interface setting and possibly more alternate interface settings which in turn have endpoint descriptors, as outlined above. An endpoint may however be reused among several interfaces and alternate interface settings.

The hardware that contains the host controller and the root hub has an interface toward the programmer which is called Host Controller Device (HCD) and is defined by the hardware implementer. In practice, these are hardware registers (ports) in the computer.

At version 1.0 and 1.1 there were two competing HCD implementations. Compaq's Open Host Controller Interface (OHCI) was adopted as the standard by the USB-IF. However, Intel subsequently created a specification they called the Universal Host Controller Interface (UHCI) and insisted other implementers pay to license and implement UHCI. VIA Technologies licensed the UHCI standard from Intel; all other chipset implementers use OHCI. The main difference between OHCI and UHCI is the fact that UHCI is more software-driven than OHCI is, making UHCI slightly more processor-intensive but cheaper to implement (excluding the license fees). The dueling implementations forced operating system vendors and hardware vendors to develop and test on both implementations which increased cost. During the design phase of USB 2.0 the USB-IF insisted on only one implementation. The USB 2.0 HCD implementation is called the Extended Host Controller Interface (EHCI). Only EHCI can support high-speed transfers. Each EHCI controller contains four virtual HCD implementations to support Full Speed and Low Speed devices. The virtual HCD on Intel and Via EHCI controllers are UHCI. All other vendors use virtual OHCI controllers.

On Microsoft Windows platforms, one can tell whether a USB controller is version 2.0 by opening the Device Manager and checking for the word "Enhanced" in its description; only USB 2.0 drivers will contain the word "Enhanced." On Linux systems, the lspci -v command will list all PCI devices, and controllers will be named OHCI, UHCI or EHCI respectively, which is also the case in the Mac OS X system profiler. Most Linux systems also provide the lsusb command which provides USB-specific details about ports and controllers. On BSD systems, dmesg will show the detailed information hierarchy.

Device classes

Devices that attach to the bus can be full-custom devices requiring a full-custom device driver to be used, or may belong to a device class. These classes define an expected behavior in terms of device and interface descriptors so that the same device driver may be used for any device that claims to be a member of a certain class. An operating system is supposed to implement all device classes so as to provide generic drivers for any USB device.

Device classes are decided upon by the Device Working Group of the USB Implementers Forum. If the class is to be set for the entire device, the number is assigned to the bDeviceClass field of the device descriptor, and if it is to be set for a single interface on a device, it is assigned to the bInterfaceClass field of the interface descriptor. Both of these are a single byte each, so a maximum of 253 different device classes are possible (values 0x00 and 0xFF are reserved). If bDeviceClass is set to 0x00, the operating system will look at bInterfaceClass of each interface to determine the device class.

Each class also optionally supports a SubClass and Protocol subdefinition. These can be used as the main device classes are continuously revised.

The most used device classes (grouped by assigned class ID) are:

0x00 Reserved value - used in the device descriptor to signify that the interface descriptor holds the device class identifier for each interface.

0x01 USB audio device class, sound card-like devices.

0x03 USB human interface device class ("HID"), keyboards, mice, etc.

0x06 Still image capture device class, identical to the Picture Transfer Protocol as used across USB

0x07 USB printer device class, printer-like devices.

0x08 USB mass storage device class used for flash drives, portable hard drives, memory card readers, digital cameras, digital audio players etc. This device class presents the device as a block device (almost always used to store a file system).

0x09 USB hubs.

0x0A USB communications device class used for modems, network cards, ISDN connections, Fax.

0x0E USB video device class, webcam-like devices, motion image capture devices.

0xE0 Wireless controllers, for example Bluetooth dongles.

0xFF Custom device class - used to establish that a device or interface does not support any standard device class and requires custom drivers.

USB signals are transmitted on a twisted pair of data cables, labelled D+ and D−. These collectively use half-duplex differential signaling to combat the effects of electromagnetic noise on longer lines. D+ and D− operate together; they are not separate simplex connections.

Transfer speed

USB supports three data rates.

� A Low Speed rate of 1.5 Mbit/s (183 KiB/s) that is mostly used for Human Interface Devices (HID) such as keyboards, mice and joysticks.

� A Full Speed rate of 12 Mbit/s (1.4 MiB/s). Full Speed was the fastest rate before the USB 2.0 specification and many devices fall back to Full Speed. Full Speed devices divide the USB bandwidth between them in a first-come first-served basis and it is not uncommon to run out of bandwidth with several isochronous devices. All USB Hubs support Full Speed.

� A Hi-Speed rate of 480 Mbit/s (57 MiB/s).

Though Hi-Speed devices are commonly referred to as "USB 2.0", not all USB 2.0 devices are Hi-Speed. A USB device should specify the speed it will use by correct labeling on the box it came in or sometimes on the device itself. The USB-IF certifies devices and provides licenses to use special marketing logos for either "Basic-Speed" (low and full) or High-Speed after passing a compliancy test and paying a licensing fee. All devices are tested according to the latest spec, so recently-compliant Low Speed devices are also 2.0.

Hi-Speed devices should fall back to the slower data rate of Full Speed when plugged into a Full Speed hub. Hi-Speed hubs have a special function called the Transaction Translator that segregates Full Speed and Low Speed bus traffic from Hi-Speed traffic. The Transaction Translator in a Hi-Speed hub (or possibly each port depending on the electrical design) will function as a completely separate Full Speed bus to Full Speed and Low Speed devices attached to it. This segregation is for bandwidth only; bus rules about power and hub depth still apply.

Most of the pins of a mini USB connector are the same as a standard USB connector, except pin 4. Pin 4 is called ID and is connected to pin 5 for a mini-A. This indicates if a device supporting usb on the go (with a mini AB socket) should initially act as host, in the mini B this is open circuit. The Mini A also has an additional piece of plastic inside to prevent insertion into slave only device.

USB connectors

The connectors which the USB committee specified were designed to support a number of USB's underlying goals, and to reflect lessons learned from the varied menagerie of connectors then in service. In particular:

� The connectors are designed to be robust. Many previous connector designs were fragile, with pins or other delicate components prone to bending or breaking, even with the application of only very modest force. The electrical contacts in a USB connector are protected by an adjacent plastic tongue, and the entire connecting assembly is further protected by an enclosing metal sheath. As a result USB connectors can safely be handled, inserted, and removed, even by a small child. The encasing sheath and the tough moulded plug body mean that a connector can be dropped, stepped upon, even crushed or struck, all without damage; a considerable degree of force is needed to significantly damage a USB connector.

� It is difficult to incorrectly attach a USB connector. Connectors cannot be plugged-in upside down, and it is clear from the appearance and kinesthetic sensation of making a connection when the plug and socket are correctly mated. However, it is not obvious at a glance to the inexperienced user which way round a connector goes, so it is often necessary to try both ways. The simplest way to distinguish the "top" side of a USB connector is to check for the USB logo marked on the top.

� The connectors are particularly cheap to manufacture. � The connectors enforce the directed topology of a USB network. USB does not support

cyclical networks, so the connectors from incompatible USB devices are themselves incompatible. Unlike other communications systems (e.g. RJ-45 cabling) gender-changers are never used, making it difficult to create a cyclic USB network.

� A moderate insertion/removal force is specified. USB cables and small USB devices are held in place by the gripping force from the receptacle (without the need for the screws, clips, or thumbturns other connectors require). The force needed to make or break a connection is modest, allowing connections to be made in awkward circumstances or by those with motor disabilities.

� The connector construction always ensures that the external sheath on the plug contacts with its counterpart in the receptacle before the four connectors within are connected. This sheath is typically connected to the system ground, allowing otherwise damaging static charges to be safely discharged by this route (rather than via delicate electronic components). This type of enclosure also means that there is a (moderate) degree of protection from electromagnetic interference afforded to the USB signal while it travels through the mated connector pair (this is the only location when the otherwise twisted data pair must travel a distance in parallel).

� The USB standard specifies relatively low tolerances for compliant USB connectors, intending to minimize incompatibilities in connectors produced by different vendors (a goal that has been very successfully achieved). Unlike most other connector standards, the USB spec also defines limits to the size of a connecting device in the area around its plug. This was done to avoid circumstances where a device complied with the connector

specification but its large size blocked adjacent ports. Compliant devices must either fit within the size restrictions or support a compliant extension cable which does.

The USB 1.0, 1.1 and 2.0 specifications define two types of connectors for the attachment of devices to the bus: A, and B. The USB 2.0 specification also introduces the mini-B connector, for smaller devices such as PDAs, mobile phones or digital cameras. All connectors are mechanically incompatible, with an A connector always used on the upstream (host) end, and a B connector always used on the downstream (device) end. Hosts and devices include connectors (female) while cables contain plugs (male). Thus all compliant USB cables have an A plug on one end, and either a B or Mini-B on the other end. The A-plug is approximately 4x12 mm, the B-plug is approximately 7x8 mm, and the B-mini plug is approximately 3x7 mm.

However, the mechanical layer has changed in some examples. For example, the IBM UltraPort is a proprietary USB connector located on the top of IBM's laptop LCDs. It uses a different mechanical connector while preserving the USB signaling and protocol. Other manufacturers of small items also developed their own small form factor connector, and a wide variety of these have appeared. For specification purposes, these devices were treated as having a captive cable.

An extension to USB called USB On-The-Go allows a single port to act as either a host or a device - chosen by which end of the cable plugs into the socket on the unit. Even after the cable is hooked up and the units are talking, the two units may "swap" ends under program control. This facility targets units such as PDAs where the USB link might connect to a PC's host port as a device in one instance, yet connect as a host itself to a keyboard and mouse device in another instance. USB On-The-Go has therefore defined two small form factor connectors, the mini-A and mini-B, and a hermaphroditic socket (mini-AB), which should stop the proliferation of proprietary designs.

Wireless USB is a standard being developed to extend the USB standard while maintaining backwards compatibility with USB 1.1 and USB 2.0 on the protocol level.

The maximum length of a USB cable is 5 meters; greater lengths require hubs [1].

Power supply

The USB connector provides a single nominally 5 volt wire from which connected USB devices may power themselves. In practice, delivered voltage can drop well below 5 V, to only slightly above 4 V. The compliance spec requires no more than 5.25 V anywhere and no less than 4.375 V at the worst case; a low-power function after a bus-powered hub. In typical situations the voltage is close to 5 V.

A given segment of the bus is specified to deliver up to 500 mA. This is often enough to power several devices, although this budget must be shared among all devices downstream of an unpowered hub. A bus-powered device may use as much of that power as allowed by the port it is plugged into.

Bus-powered hubs can continue to distribute the bus provided power to connected devices but the USB specification only allows for a single level of bus-powered devices from a bus-powered hub. This disallows connection of a bus-powered hub to another bus-powered hub. Many hubs include external power supplies which will power devices connected through them without taking power from the bus. Devices that need more than 500 mA must provide their own power.

When USB devices (including hubs) are first connected they are interrogated by the host controller, which inquires of each their maximum power requirements. The host operating system typically keeps track of the power requirements of the USB network and may warn the computer's operator when a given segment requires more power than is available (and will generally shut down devices or hubs in order to keep power consumption within the available resource).

A number of devices use this power supply without participating in a proper USB network. The typical example is a USB-powered reading light, but fans, battery chargers (particularly for mobile telephones) and even miniature vacuum cleaners are available. In most cases, these items contain no electronic circuitry, and thus are not proper USB devices at all. This can cause problems with some computers—the USB specification requires that devices connect in a low-power mode (100 mA maximum) and state how much current they need, before switching, with the host's permission, into high-power mode.

Some USB devices draw more power than is permitted by the specification for a single port. This is a common requirement of external hard and optical disc drives and other devices with motors or lamps. Such devices can be used with an external power supply of adequate rating; some external hubs may, in practice, supply sufficient power. For portable devices where external power is not available, but not more than 1 A is required at 5 V, devices may have connectors to allow the use of two USB cables, doubling available power but reducing the number of USB ports available to other devices. Amongst others, a number of peripherals for IBM laptops (now made by Lenovo) are designed to use dual USB connections.

USB-powered devices attempting to draw large currents without requesting the power will not work with certain USB controllers, and will either disrupt other devices on the bus or fail to work themselves (or both). Those problems with the abuse of the USB power supply have inspired a number of April Fool hoaxes, like the introduction of a USB-powered George Foreman iGrill [2] and a desktop USB Fondue Set [3].

USB compared to other standards

Storage

USB implements connections to storage devices using a set of standards called the USB mass-storage device class. This was initially intended for traditional magnetic and optical drives, but has been extended to support a wide variety of devices. USB is not intended to be a primary bus for a computer's internal storage: buses such as ATA (IDE) and SCSI fulfill that role.

However, USB has one important advantage in making it possible to install and remove devices without opening the computer case, making it useful for external drives. Today, a number of manufacturers offer external, portable USB hard drives, or empty enclosures for drives, that offer performance comparable to internal drives. These external drives usually contain a translating device that interfaces a drive of conventional technology (IDE, ATA, SATA, ATAPI, or even SCSI) to a USB port. Functionally, the drive appears to the user just like another internal drive..

FireWire technology is also commonly used with portable hard drives; some have both USB and FireWire ports. FireWire tends to perform better in speed benchmark tests than even Hi-Speed USB 2.0, although the latter supports a numerically higher bit-rate. The main reason for this is that the tests are conducted point to point (only one device) which means the USB system is

always waiting for the drive. Additionally, some operating systems transfer blocks limited to the USB 1.1 size of 64 bytes, without taking advantage of the larger block sizes allowed by USB 2.0. An operating system designed to handle Hi-Speed USB 2.0 optimally is capable of data rates higher than Firewire, but the most commonly found [early 2006] operating systems and drivers are not. However, USB ports are more usual than Firewire on consumer-level computers, which enhances the compatibility of a USB drive. Additionally, when multiple devices are connected, USB has significant advantages over FireWire,

Human-interface devices (HIDs)

As of 2006, most PCs and motherboards have at least one USB port, but still retain PS/2 keyboard and mouse connectors. AT keyboard connectors are less frequently found. Motherboards for non-portable PCs usually have a number of USB 2.0 high-speed ports, some available at the back of the computer case, others requiring USB sockets on the front or rear of the computer to be connected via a cable to a header on the motherboard. Joysticks, keypads, tablets and other human-interface devices are also progressively migrating from MIDI , PC game port, and PS/2 connectors to USB. Mice and keyboards are frequently fitted with USB connectors, but supplied with a small USB-to-PS/2 adaptor so that they can be used with either USB or PS/2 ports.

Apple computers have used USB mice and keyboards exclusively since January 1999.

FireWire

USB was originally seen as a complement to FireWire, which was designed as a high-speed serial bus which could efficiently interconnect peripherals such as hard disks, audio interfaces, and video equipment. USB originally operated at a far lower data rate and used much simpler hardware, and was suitable for small peripherals such as keyboards and mice.

However, because FireWire ports were more costly to implement than USB ports, primarily due to their per-port licence fee, they were rarely provided as standard equipment on computers, and peripheral manufacturers offered many more USB devices. The introduction of USB 2.0 Hi-Speed, with its widely advertised 480 Mbit/s signaling rate, convinced many consumers that FireWire was outdated (although this was not necessarily the case; see "USB 2.0 Hi-Speed vs FireWire" below).

Today, USB Hi-Speed is rapidly replacing FireWire in consumer products. FireWire retains its popularity in many professional settings, where it is used for audio and video transfer, and data storage.

Technical differences

The most significant technical differences between FireWire and USB include the following:

� USB networks use a tiered-star topology, while FireWire networks use a repeater-based topology.

� USB uses a "speak-when-spoken-to" protocol; peripherals cannot communicate with the host unless the host specifically requests communication. A FireWire device can communicate with any other node at any time, subject to network conditions.

� A USB network relies on a single host at the top of the tree to control the network. In a FireWire network, any capable node can control the network.

These and other differences reflect the differing design goals of the two busses: USB was designed for simplicity and low cost, while FireWire was designed for high performance, particularly in time-sensitive applications such as audio and video.

USB 2.0 Hi-Speed vs FireWire

The signalling rate of USB 2.0 Hi-Speed mode is 480 megabits per second, while the signalling rate of FireWire 400 (IEEE 1394a) is 393 Mbit/s [4]. USB can require more host resources than FireWire due to the need for the host to provide the arbitration and scheduling of transactions. USB transfer rates are generally higher than FireWire due to the need for FireWire devices to arbitrate for bus access. A single FireWire device may achieve a transfer rate for FireWire 400 as high as 41 MB/s, while for USB 2.0 the rate can be a higher 55 MB/s (for a single device). In a multi device environment FireWire rapidly loses ground to USB; FireWire's mixed speed networks and long connection chains dramatically affect its performance.

The peer to peer nature of FireWire requires devices to arbitrate, which means a FireWire bus must wait until a given signal has propagated to all devices on the bus. The more devices on the bus the lower the peak performance. Conversely, for USB the maximum timing model is fixed and is limited only by the host-device branch (not the entire network). Furthermore, the host-centric nature of USB allows the host to allocate more bandwidth to high priority devices instead of forcing them to compete for bandwidth as in FireWire.

Why then can some USB devices only sustain 34 MB/s not 55 MB/s? The main reason is usually that the devices themselves are slow and spend most of the time NAK'ing the host to indicate they are not ready - this is particularly true of memory sticks. So the sustained transfer rate is a limitation of the individual device technology, not the infrastructure. It is a testament to the flexibilty of the USB bus that it can handle wide variances in device performances. In addition to this some operating systems take a conservative approach to scheduling transactions and limit the number of transfers per frame. Reducing the maximum transfers from, say, the theoretical 13 per frame to 10 or 9. Therefore if high speed transfer is what you need you should match this with a good host controller and operating system.

In 2003, FireWire was updated with the IEEE 1394b specification. This provides a new mode called S800, which operates at 786.432 Mbit/s. S800 requires a new physical layer, but S800 nodes can be connected to existing FireWire 1394a ports, just as USB Hi-Speed nodes will operate with older full-speed hosts. However, unlike USB Hi-Speed systems that can change the speeds on each branch, a 1394a device on a 1394b system requires all devices to fall to 1394a speeds. IEEE 1394b also provides rates up to approximately 3.2 Gbit/s; however, the higher rates use special physical layers which are incompatible with 1394a devices.

Version history

USB

� USB 1.0 FDR: Released in November 1995, the same year that Apple adopted the IEEE 1394 standard known as FireWire.

� USB 1.0: Released in January 1996.

� USB 1.1: Released in September 1998.

� USB 2.0: Released in April 2000. The major feature of this standard was the addition of high-speed mode. This is the current revision.

� USB 2.0: Revised in December 2002. Added three-speed distinction to this standard, allowing all devices to be USB 2.0 compliant even if they were previously considered only 1.1 or 1.0 compliant. This makes the backwards compatibility explicit, but it becomes more difficult to determine a device's throughput without seeing the symbol. As an example, a computer's port could be incapable of USB 2.0's hi-speed fast transfer rates, but still claim USB 2.0 compliance (since it supports some of USB 2.0).

USB On-The-Go Supplement

� USB On-The-Go Supplement 1.0: Released in December 2001.

� USB On-The-Go Supplement 1.0a: Released in June 2003. This is the current revision.

Wireless USB

Released in May 12, 2005. Wireless USB uses UWB (Ultra Wide Band) as the radio technology.

Extensions to USB

The PictBridge standard allows for interconnecting consumer imaging devices. It typically uses USB as the underlying communication layer.

Sony's PlayStation 2 was the first console to feature USB support. Noteable attachments that can connect are Logitech's headset, the EyeToy, and a keyboard and mouse for online gaming.

Microsoft's Xbox game console uses standard USB 1.1 signalling in its controllers, but features a proprietary connector rather than the standard USB connector. The newer Xbox 360 uses standard USB 2.0 in both signalling and connectors. The IBM UltraPort uses standard USB signalling, but uses a proprietary connection format. A complementary protocol, Powered USB, uses standard USB signalling with the addition of extra power lines for point of sale terminals.

The USB Implementers Forum is working on a wireless networking standard based on the USB protocol. Wireless USB is intended as a cable-replacement technology, and will use Ultra wideband wireless technology for data rates of up to 480 Mbit/s. Wireless USB is well suited to wireless connection of PC centric devices, just as Bluetooth is now widely used for mobile phone centric personal networks (at much lower data rates). See http://www.usb.org/developers/wusb/ for more details.