E122 Spring 2015

LabVIEW Experiment 2
Motor Speed Control using USB and Arduino DAQs

Experiment Objectives

Experience LabVIEW capabilities through self learning exercises by designing and

implementing a Virtual Instrument (VI) to meet specified requirements.
Understand how to use and program the USB-6009 DAQ using support software
(DAQmx and Measurement and Automation Explorer) provided by LabVIEW.
Introduce feedback control systems and understand basic concepts and problems for
their implementation.
Design and conduct your own experiments to gather and analyze data required to
optimize the performance of our feedback control system according to specified
criteria.
Develop your abilities to function in teams, act cooperatively and honor individual
commitments.
Develop your ability to generate good technical reports.

Experiment Overview
In this experiment you will simultaneously use capabilities of both the Arduino and USB
DAQs to monitor, display and control (set) the speed of a DC motor as measured in
revolutions per minute (RPM). Both the Arduino and USB DAQs will connect to your laptop
via separate USB serial communications cables. LabVIEW will run both devices. The DC
motor will be powered by the Arduino DAQ, which can pulse width modulate (PWM) the
power signal to change its speed. (Same as we did in Design I with the motors function.)
The motor will be operated at a maximum speed of 9000 RPM and a minimum speed of
3000 RPM. A sensor on the motor will connect to the USB DAQ and provide LabVIEW a
feedback signal proportional to motor speed. You will design a LabVIEW front panel and
block diagram to meet specified motor speed regulation control requirements. No
programming of the Arduino DAQ will be required. It will be preloaded with the necessary
control and communication firmware.

The sensor that provides the motor speed feedback signal is a HOA0963-T51 Optical
Interrupter switch. (The device specification is available on Canvas.) It consists of an
infrared emitting diode coupled with a photo transistor detector mounted in a plastic housing.
The photo transistor acts like a switch. When infrared energy from the emitter hits the photo
transistor, the transistor turns on. That is, it conducts electricity. When the infrared energy
is blocked from reaching the photo transistor, the transistor turns off. The orientation of the
emitting diode and photo transistor is such that a inch air gap separates the two. Any
solid, opaque object passing through the gap will stop the flow of infrared energy. The motor
has attached to its rotating shaft a 3 inch diameter, 1/16 inch thick plastic disk. Sixty (60)
1/16 inch slots have been cut through the plastic on the perimeter of the disk. The
geometric design of the disk is such that the solid plastic remaining between the slots is also
approximately 1/16 inch. In the experimental setup, the slots in the disk are positioned in the
path of the sensor's infrared beam. As the motor rotates, the slots/solid portions in the disk
alternately enable/interrupt the beam from reaching the photo transistor detector, causing it
to turn on and off. As the motor rotates faster, the slots and solid portions of the disk move
through the optical interrupter switch faster, shortening both the on and off time of the photo
transistor. This is a digital sensor that provides an output frequency proportional to
RPM. Figure 1 depicts a typical output relationship.

Photo Transistor ON
Slower RPM
(Lower Frequency) Photo Transistor OFF

Photo Transistor ON
Faster RPM
(Higher Frequency) Photo Transistor OFF

Figure 1. Output of RPM Sensor

We could now connect the sensor output to a device that measures frequency and relate the
frequency directly to RPM. However, neither of our Arduino or USB DAQs has the capability
to directly measure frequency. The USB DAQ does have the capability to count pulses.
Since there are 60 slots on the perimeter of the sensor disk, every revolution of the motor
will generate sixty pulses. We could count the pulses over a period of time and relate this
count to RPM. If we counted pulses over one minute of time, divided by 60 pulses per
revolution we could get RPM directly. However, for most applications requiring speed
control waiting one minute to get the information is much too long. Imagine setting the
cruise control on your car and waiting one minute to see how its doing. We could shorten the
time and count pulses over any duration we want realizing, however, that as this sample
time becomes smaller and smaller, the error on estimating RPM becomes larger and larger.
In general RPM for our particular motor apparatus can be determined from:

RPM = (Rotations) / (Minute)

RPM = (# of pulse counts / 60) / (sample time in seconds / 60)

Simplifying:

RPM = # of pulse counts / sample time in seconds

This simple relationship exists because we designed the sensor disk with 60 slots, AND
there are 60 seconds in a minute.

The motor speed set point, Desired RPM, will be entered on your front panel. Based on
information gathered from counting pulses over time, an Actual RPM will be calculated. In
LabVIEW you will compare Actual RPM to Desired RPM and direct the Arduino DAQ via
its serial communication cable to either increase or decrease motor speed according to a
simple motor control algorithm that you will design and implement. A graph of RPM vs.
Time will also be displayed in LabVIEW to monitor the operation of the motor control
algorithm. Figure 2 presents a top level functional block diagram of the system under test.

RPM error
Motor PWM Power
RPM set Control Motor
Algorithm

Feedback
Sensor
RPM sensor

Figure 2 - Feedback Control Loop to Regulate Motor Speed

Design requirements for the motor control algorithm will be provided. Guidance suggesting
which LabView functions could be used to satisfy those requirements will also be provided,
however, a step by step programming procedure will not be provided. You must develop
your own Virtual Instruments (VI). Requirements for analyzing the performance and
tuning the feedback control system will be provided, however, you will have to design
your own experimental approach, step-by-step data collection procedure, and data
analysis to come up with the best performing system. A written lab report (team effort)
documenting all of the above will be due on the date specified by your instructor.

Implementing Motor Speed Control using the Arduino Communication SubVI

During Experiment 1, LabVIEW used the Arduino_Communication_SubVI to request analog

data from the Arduino DAQ. This was done by sending a specific ASCII string to the SubVI.
That string implemented the protocol (language) understood by both LabVIEW and the
Arduino DAQ. For example, data on analog channel 0 could be received by sending the
string A0 to the SubVI; A0 meaning Analog channel 0. To implement motor speed
control, you will need to learn additional parts of the protocol, i.e. new strings to send to the
Arduino_Communication_SubVI.

Recall from last semester how the motors on your robot (which were connected to the
Arduino's board serial motor controller board) were operated by the C program you wrote.
For review, refer to the Arduino Hardware/Software Interface Definition document under
the E121 Robot Project Resources icon on Canvas. The robot motors were operated
using the "motors" function and telling it which of the two (or both) motors to address, what
direction you wanted it to spin (or turn it off), and at what speed. The motor control ASCII
string to send to the Arduino_Communication_SubVI will mimic the same input parameters
used during Design I. It has the following format:

M{Motor}{Status}{Speed}

Where:
M stands for Motor
{Motor} will specify which motor to control. Valid ASCII characters for Motor
include:
'1' - Control Motor 1 which is connected to the M1+ and M1- screws
'2' - Control Motor 2 which is connected to the M2+ and M2- screws
'B' or 'b' - Simultaneously control both motors
{Status} will specify the direction of motor spin or whether to turn it off. Valid
ASCII characters for Status include:
'A' or 'a' - Spin (in a direction determined by your motor wiring)
'B' or 'b' - Spin the other way
'O' or 'o' - (letter O), turn the specified motor off
'X' or 'x' - Do not modify Status of the motor (i.e., we may want to just
change speed)
{Speed} will control the PWM duty cycle of power being sent to the motor(s) and
must be one to three ASCII characters representing numbers in the range of 0-
255.
1-255 shall specify power duty cycle. At the extremes, 1 means that motor
power will be on for only 1/255 of the time during a duty cycle. 255 means
the motor will be on 255/255 of the time (i.e., always on/full power) during
a duty cycle..
0 is a special case and shall indicate to not modify the last speed
command sent. It has no effect on motor speed.

Here are some important points to note for Experiment 2:

You will only be controlling one motor. Decide which motor terminals on the
Arduino board you want to use, then your Motor string will always just
command that motor, either '1' or '2'.

Your motor will always spin in only one direction, and it doesn't matter which
direction you choose, either 'a' or 'b'. Once selected you must never change
direction of the motor. Doing so while the motor is spinning will immediately
damage it!!

So once your motor starts spinning, your LabVIEW program will exclusively
manipulate only the Speed parameter of the Motor string.

Also note, that the Speed command MUST always remain between 0-255 otherwise the
Arduino_Communication_SubVI will return a Data Input Error, and commands out of range
will not be sent to the Arduino DAQ. Your LabVIEW block diagram must contain checks to
make sure the motor speed parameter is limited to the range between 0 and 255, inclusive.
Experimental Hardware Setup

Since the pulse counting capability is unique to the USB DAQ, and motor speed control is
unique to the Arduino DAQ, both will be required for our test setup. The experimental setup
is depicted below in Figure 3.

USB Connections to Laptop

Arduino DAQ Power

Motor Power on
Digital Sensor Output to Arduino Motor #1
USB DAQ
GND Pin 32 (Black)
+5V Pin 31 (Red)
PFI0 Pin 29 (Green)

Figure 3. Experiment Connection Setup

Arduino DAQ Connections

1. Power - The Arduino DAQ will be powered from its own wall adapter power supply.
For this experiment it will be necessary to turn on both power switches, i.e. the
switches labeled MICRO and MOTORS.

2. Communications -Your laptop must be connected to the Arduino microcontroller via a

USB serial cable. The Arduino_Communication_SubVI will enable you to select
which COM port on your laptop is associated with that serial link. The serial link
parameters (baud rate, parity, number of stop bits, etc) will automatically be set by
the subVI.
 3. Motor Under Test The motor will get power from the Arduino DAQ. The motor has
two yellow wires which must be connected to one set of motor terminals on the
Arduino (either M1+ and M1- which corresponds to motor #1 or else M2+ and M2-
which corresponds to motor #2).

USB DAQ Connections

1. Power/Communications The USB serial cable provides both power and

communication for the USB DAQ. This DAQ does not have a power on switch. As
soon as the USB cable is connected, the device will be active. LabVIEW will
recognize the device and enable you to program it.

2. Motor Under Test The digital optical interrupter sensor that provides pulse counting
data will get its power from the USB DAQ and will also provide its output signal to the
USB DAQ. For power, connect the black wire to pin 32 marked "GND" and connect
the red wire to pin 31 marked "+5V". The USB-6009 unit only has one input capable
of counting pulses and it is pin 29 marked PFI0. Connect the sensor output green
wire to pin 29.

Experiment Requirements & Implementation Guidance

1. Front Panel Design Requirements

One front panel shall be designed and implemented. Much of the LabVIEW experiences
you gained using the Arduino DAQ during Experiment 1 are directly applicable to
Experiment 2. Your instructor and T/A will help you accomplish your design, however, it
shall be up to the TEAM to divide the workload as appropriate to ensure the design is
complete, working properly, and all data is taken by the scheduled completion time. The
ability/inability of your TEAM to organize properly and complete the activities within the
allotted time will be noted by your instructor.

Detailed Front Panel Requirements (Jointly work as a TEAM)

As an input entitled Arduino Connection, the laptop COM port to use for
connection to Arduino DAQ shall be selectable via a drop down menu (Combo Box).
As an output entitled Communications Error, a red LED shall illuminate should
the Arduino Communications SubVI return a Hardware Error status. Otherwise the
LED shall be off.
As an output entitled Data Entry Error, a red LED shall illuminate if the Arduino
Communications SubVI returns a Data Input Error status. Otherwise, the LED shall
be off.
As an input entitled Motor ON/OFF, a vertical toggle switch shall enable or disable
motor operation. When in the ON position, the motor shall be enabled and a green
LED entitled Motor On shall illuminate. When in the OFF position the motor shall
be disabled and the Motor ON LED shall be off. Upon program start, this switch
shall be in the off position.
 A numeric control entitled Desired RPM shall allow the operator to enter the
desired motor speed. The valid motor speed range shall be 3000 to 9000 RPM. The
motor must not be allowed to operate outside of this RPM range.
Upon activating the Motor ON/OFF switch from the OFF to ON position, a
check of Desired RPM shall be performed to ensure it is in the valid range.
If not in the valid range, the motor shall not receive power, and a red LED
entitled Invalid RPM shall illuminate, otherwise the LED shall be off.
While the Motor ON/OFF switch is in the ON position, the Desired RPM
shall be rechecked for validity on any change. Upon detecting an invalid
RPM, all further commands to the motor shall cease and a red LED entitled
Invalid RPM shall illuminate, otherwise the LED shall be off. Upon receiving
a valid change request, the MCA will respond with the appropriate motor string
command.
An output entitled Motor Speed String shall display all motor speed
communication strings sent to the Arduino DAQ. The complete string shall be
displayed.
A numeric output indicator entitled Actual RPM shall display the actual motor
speed as calculated using the USB DAQ pulse counting data. Simultaneously a real
time waveform chart shall display the Actual RPM. The x-axis shall be time. The
Y-axis shall be Actual RPM calibrated from 0 -11000 RPM.
A numeric input control entitled Sample Time shall allow the operator to change
the time interval over which pulses will be counted to calculate Actual RPM.
"Sample Time" shall be a floating point number and shall be set in 0.1 second
increments.
A numeric input control entitled Step Size shall allow the operator to specify the
delta change in the motor speed command string to either increase or decrease
speed as required. "Step Size" shall be an integer in the range of 1-255 and shall
be set in increments of 1.

2. Motor Control Algorithm (MCA) Requirements

The MCA shall meet the following requirements. Note that a sample design satisfying these
requirements can be found on Canvas in the "Sample Motor Control Algorithm Flowchart".
You can use this as a starting point.

The MCA shall determine whether the current speed of the motor needs to be
changed by evaluating whether the Actual RPM is within a specified tolerance of the
Desired RPM (See Data Collection Requirements below.) If the MCA determines the
motor must either speed up or slow down, it shall formulate and send the appropriate
motor string command to the Arduino DAQ. If the MCA determines the motor is
already operating at the proper speed, no commands shall be sent to the Arduino
DAQ.

The MCA shall store the entire last ASCII motor speed command sent to the Arduino
DAQ.
 Upon initial program start and valid enabling of motor operation (i.e., the Motor
ON/OFF switch is turned on AND a valid Desired RPM is present), the MCA shall
send the Arduino a 50 (out of 255) speed command to begin its rotation (i.e.,
M1A50).

The MCA shall calculate Actual RPM by counting pulses from the digital sensor
over a period of time. The period of time shall be adjustable via the Sample Time
front panel control so that the effect of changing this value can be observed.

The MCA shall compare the calculated Actual RPM to the Desired RPM entered
on the front panel. The MCA shall determine if the actual motor speed needs to
increase, decrease, or stay the same to achieve the desired motor speed.

If the motor needs to speed up, an incremental increase shall be added to the
last motor speed command sent to the Arduino. This incremental increase,
called the Step Size, shall be adjustable via a front panel control so that the
effect of changing this value can be observed. (i.e., if the Step Size is set to
five and the last command sent was M1A50, the next command shall be
M1A55).
If the motor needs to slow down, an incremental decrease shall be subtracted
from the last motor speed command sent to the Arduino. This incremental
decrease shall be the same Step Size parameter used to increase motor
speed. (i.e., if the Step Size is set to five and the last command sent was
M1A50, the next command shall be M1A45)

The MCA shall check to ensure the motor speed strings sent to the Arduino DAQ are
valid, and remain in the range of 0 - 255. Remember a speed value of 0 (zero) will
leave the motor power at the last value sent. It has no effect on changing motor
speed!

3. Guidance for using DAQmx to count pulses and calculate RPM

There are four basic steps to counting pulses and calculating RPM. Your instructor will
demonstrate the procedure. Note that the USB DAQ must be connected to your laptop
to perform these steps.

1. Create a Counter Input task using the Measurement and Automation Explorer
(MAX) application. MAX will recognize the connected USB-6009 DAQ and will
know its capabilities, available tasks, and connection points. After opening MAX,
under Devices and Interfaces, select your connected USB-6009 DAQ. Select
"Acquire Signals, Counter Input, Edge Count". Select the only available counter
channel, "ctr0". Give the task a representative name such as Count Pulses so
you can easily reference it later in your program. LabVIEW will create a default
configuration, which satisfies our needs. Make no changes to the default
configuration.
2. Create the block diagram to initialize and read the counter data as shown below.
You will find the necessary icons in the block diagram Functions palette under
Measurement I/O, NI-DAQmx. Four functions will be needed:
a. Task Constant (You will set this to the task name you created in Step 1.)
 b. Task Start (This will start the pulse counting)
c. Task Read (This must be configured for counter, single sample, unsigned
32 bit integer (U32). The read will return the counter data.)
d. Task Stop (This will stop the counter and reset it back to zero.)
3. Use the Time Delay function in the Timing palette to control how long the
program will count pulses. Your "Sample Time" front panel numeric control will
be used to set the time delay duration. The Sample Time numeric control should
be set up (use properties) to increment in 0.1 second increments.
4. Place a While Loop around the block diagram as indicated below. Then create a
Boolean TRUE constant at the input to the STOP condition of the While Loop.
The while loop will ensure this block of code will execute without interruption.

Following is a "program" that will count pulses for a specified Sample Time and then
output a calculated Actual RPM. It should be created in your .vi first and then the rest of
your program built around it.

Note that the logic is implemented in a "while loop" with the stop button wired to Boolean
constant "True". This results in the while loop executing only one time, each time it is called
in your program.

4. Data Collection Requirements

Feedback systems are susceptible to stability problems. By stability problems we mean a
tendency to overshoot the set point when it is manually changed, or when an external
disturbance (such as load on a motor) moves us away from an existing set point. In the
extreme case, an improperly tuned feedback control system can result in self-sustaining
system oscillations. This effect generally renders the system useless, or even self-
destructive if the oscillations continuously increase in magnitude.
In our system there are two adjustable parameters in the Motor Control Algorithm that will
be tuned to modify system performance in response to a changing set point, Sample
Time and Step Size. You are required to design your own experiments to optimize
these two parameters over the entire range of system operation, 3000-9000 RPM. For
purposes of your experimentation:

Optimization means achieving a new set point (Desired RPM) in the "fastest time
possible" (i.e., get your IPhone stop watch out) without causing the system to go unstable,
defined as sustained oscillations of greater than plus or minus 3.0 % of the set point.

Since fastest time possible is the criteria, it is expected that using a quantitative
engineering approach you will be taking time data and presenting graphical depictions of
data with varying Sample Times and Step Sizes to arrive at your experimental
conclusions. Excel should be used to plot data. You will need to characterize the system
over its entire range of operation by testing a variety of typical operational scenarios.
So when designing your experiments be sure to consider large changes in set point, such
as from 3000 RPM to 9000 RPM and small changes in set point, such as 3000 to 4000
RPM. Consider also set points that increase motor speed, and set points that decrease
motor speed.

Your teams logic and quantitative (i.e. not guessing) experimental approach to
obtaining optimal values for Sample Time and Step Size over the entire range of
system operation is a significant portion of your grade. Think it through in advance.
Seek guidance/feedback from your instructor.

Your experimental approach, procedure, data collection/analysis and conclusions must be

thoroughly documented in the written report.

5. Written Report Requirements and Grading

Each of the three experiments conducted in Design II are group grades worth 6 points
towards your final grade out of 100. This lab report will be graded to a maximum score of
60 that will then be scaled down to 6 and summed into your final grade.

The organization, clarity, and presentation of your report shall count for 10 Points. The
report must be organized per the "Lab Report Template" that can be found on Canvas.

Present depictions of your tested LabVIEW design by including printouts of BOTH

the Front Panel AND Block Diagram. I.e., use the Print command to print out
both. Also to receive full credit you must print ALL cases that exist in case structures
you may have used in the design of your block diagram. (20 Points)
Experiment Design - Present your logical and quantitative experimental approach
to determining the best values for sample size and step size. Be sure to clearly
state your objectives, plan of attack to achieve those objectives, a clear step-by-step
procedure used to conduct your experiment, all raw data taken in clear tabular
format using Excel, all graphs uses to analyze data, and clear conclusions with
rationale (i.e. What are your recommended values for Sample Time and Step
Size and why were they chosen?) (20 Points)
 Design Assessment - The experimental hardware setup imposed restrictions on
the sophistication of the algorithm that could be implemented to control motor speed.
Based on an understanding of the data you were able to collect and analyze, and
the limitations of that data, what design improvements could you recommend to the
control and sensor components of the system to achieve better speed control?
What more sophisticated techniques could you recommend to improve performance
of the algorithm? (10 Points) (To maximize your Design Assessment grading
component, it is recommended you spend time researching "Feedback Control
Systems" on the Internet.)