Sunteți pe pagina 1din 25

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/321096750

Lab Report 3: Labs 6 & 7 MEM459/MEM540-Control Applications of DSP

Technical Report · May 2015


DOI: 10.13140/RG.2.2.34466.73922

CITATIONS READS
0 3,930

5 authors, including:

Mathew Michael Smith


Drexel University
15 PUBLICATIONS   0 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Optimized Design of Back Pressure Regulation through "Fluid-Spring"-Returned Orifices View project

Optimal Use of Throttling Space for Dropping Pressure without Cavitation View project

All content following this page was uploaded by Mathew Michael Smith on 16 November 2017.

The user has requested enhancement of the downloaded file.


Lab Report 3: Labs 6 & 7
MEM459/MEM540 - Control Applications of DSP

28 May 2015

Group Members:
Ryan Kopec, Young Kwang Lee, Lauren Nutt, Michael Simeoni, Mathew Smith
Table of Contents
1. Lab 6
1.1. Introduction
1.2. Theory
1.3. Experimental Procedure
1.3.1. Hardware Set-up
1.3.2. Software Set-up
1.3.3. LabVIEW Simulation Set-up
1.4. Results
1.4.1. PID Speed Feedback Control of the DC-Motor
1.4.2. PID Position Feedback Control of the DC-Motor
1.5. Discussion
1.5.1. Discrete-time Integration and Differentiation
1.5.2. Modeled and Simulated Response Analysis
1.6. Conclusion
2. Lab 7
2.1. Introduction
2.2. Theory
2.3. Experimental Procedure
2.3.1. Hardware Set-up
2.3.2. Software Set-up
2.4. Discussion
2.6. Conclusion
3. References
Appendix
Motor Speed PID Responses
Angular Position PID Responses
Derivation of C Code for PID Implementation

1
1. Lab 6
1.1. Introduction
The experiment was to design a PID feedback controller for the speed and position of a
DC motor. These controllers were designed around the mathematical models derived in Lab 4.
Closed-loop simulations were performed for each PID controller. After analyzing these
simulations, the controllers were then implemented in real-time on the system. The objective of
the experiment was to observe the effects of changing the respective controller gains on the
system response as well as comparing the simulation response to the real-time response.

1.2. Theory
A widely common method used in control applications is PID control. This control
scheme utilizes the error between the system output and the desired setpoint to appropriately
adjust the system input. As the name indicates, the specific data that is fed back through the
system is the integration and derivative of the error as well as the error itself, each of which
multiplied by scaling factor. A simple block diagram showing the operation of PI is shown below
in Figure 1. In the figure, y(t) is the system output, r(t) is the setpoint, and u(t) is the controlled
input into the system.

Figure 1. Simplified Block Diagram of PI Control

The PID gains can be altered to manipulate the system's response appropriately. In
theory, increasing the proportional gain decreases the rise time and steady-state error of the
response, but consequently increases the percent overshoot. Increasing the integral gain has
the same effect while eliminating the steady-state error, but increases the settling time.
Increasing the derivative gain will decrease percent overshoot and settling time. Tuning these
gains simultaneously to achieve particular response requires both skill and some trial and error,
however there exist some procedures that yield decent results such as the Ziegler-Nichols or
Cohen-Coon method. This lab does not seek to find the optimal PID gains for control of the DC
motor, but instead strives to corroborate the aforementioned effects of changing the proportional
and integral gains.

2
A discrete-time PID controller builds off the continuous-time controller, but compensates
for the latency, or delay, associated with each iteration. The continuous time models derived
from differential equations are analog signals, and are manipulated using the Laplace Transform
and block diagram reduction techniques. Further, the continuous-time models must be
converted to digital signals using an analog to digital converter (ADC) before processing with
software can be performed. The new digital (discretized) signals can be manipulated with
software using the Z-Transform (numerical integration). This essentially accounts for the
sampling period, or step size, between measurements. Figure 2, below, shows the
implementation of signal converters. This allows for the computer to be able to interpret the
analog input from the system, manipulate it, and send out a control response which the system
can respond to.

Figure 2. Signal Converter Implementation for a Digital Controller [1]

Numerical integration is performed using the same error signal, e(t), and a new form of
the controller, m(t). If x(t) represents the numerical integral of e(t), the Z-Transform produces the
equation below, where T is the sampling period and x(kT) is from the difference-equation
transform.

The new discretized form of the PI controller is given by m(kT), with and representing the
same controller constants from the continuous-time model.

The solution of the discrete-time model is given by m(t), with the a and b coefficients in general
form. This is also termed a linear time-invariant analog filter, because the differentiation on the
e(t) and m(t) terms return the model to the time domain.

1.3. Experimental Procedure


1.3.1. Hardware Set-up
The DC motor with optical encoder was connected to the MOTOR head pins on the left
side of the H-Bridge board. The eZdsp pins were connected to the H-Bridge pins as described
in Table 1, below. The pins of the H-Bridge are labeled on the board directly and can also be
seen in Figure 3.

Table 1. Set-up Pin Connections

3
eZdsp P8 Pins H-Bridge Board Pins

33 1

34 2

9 3

10 4

39 and/or 40 GND

Figure 3. H-Bridge Board Diagram For Pin Number Reference [1]

1.3.2. Software Set-up


To test the discrete speed controller, the the CCSv3.3 project 6s_PIDspd_fdbkcntrl_A
was migrated to CCSv5.2. The project was then debugged, built, and run. This program had a
reference with a period of 5 seconds. The reference was set to 50 RPM for the first second, 200
RPM deg for the next two seconds, and then back to 50 RPM for the remainder of the period.
The motion of the motor shaft was observed along with the value changes of ref_speed,
rpmnew, EPwm1Regs.CMPA.half.CMPA and EPwm1Regs.CMPB in the Expressions View
window utilizing Real-Time mode. After 20 seconds, the program was suspended and the data
for inp_graph and rpm_graph was recorded. This process was repeated for seven different sets
of PID gains. The first set of gains was held as the baseline and is tabulated in Table 2, below.
After the baseline, the gains were changed such that two of the gains were held at the baseline
value and the third was either doubled or halved from the baseline value.

Table 2. Baseline PID Gains for Speed Control


Kp Ki Kd

0.15 1.0 0.01

For position control, the project 6s_PIDspd_fdbkcntrl_B was created in CCSv5.2. Once
created, the program was debugged, built, and run. This program also had a reference with a
period of 5 seconds. The reference was set to 0 deg for the first second, 90 deg for the next two

4
seconds, and then 0 deg for the remainder of the period. The program was run for at least 20
seconds before it was suspended and the data for inp_graph and angle_graph was recorded.
The program was rerun and the process repeated for seven different sets of gains. The first set
of gains was held as the baseline and is tabulated in Table 3, below. After the baseline, the
gains were changed such that two of the gains were held at the baseline value and the third was
either doubled or halved from the baseline value.

Table 3. Baseline PID Gains for Position Control


Kp Ki Kd

0.6 0.7 0.01

1.3.3. LabVIEW Simulation Set-up


To evaluate the mathematical model from Lab 4 against the experimental results, a PID
simulation was created using LabVIEW programming software. The transfer function of the
model characterizes the input/output relationship between angular velocity and applied duty
cycle, and could be tested as such. An overview of the block diagram for the simulation is
shown below in Figure 4. Visibly inside of the block diagram is the transfer function of the simple
linear model, , which has the generic form:

Figure 4. Block Diagram of LabVIEW Simulation (Angular Velocity Response)

In the simulation, three pulse signals are generated which each characterize a particular time
section of the desired reference to be sent to the motor, as explained in the section prior. These
signals are then summed and passed through the transfer function. The simulated response is
then generated and graphed on the front panel of the VI. The response data is also exported to
Excel to allow for the analysis and comparison with the experimental data.

5
A separate LabVIEW simulation was created to experiment with the PID control of the
DC-motor’s angular position. To create the transfer function that related angular position and
applied duty cycle, an integrator block was simply added onto the previous transfer function in
the LabVIEW simulation.
In addition to these continuous motor simulations, discrete-time versions were also
created in LabVIEW; their responses to the different PID gains were captured and analyzed as
well. The discretized versions of both the angular velocity and angular position characterizing
transfer functions were generated by converting over their continuous counterparts. The state
space representation of the continuous plant model can be represented as:

In the case of the transfer function for angular velocity, these state space values are ,
, , and . In the case of the transfer function for angular position, these values
are no longer scalars and are instead matrices, with dimensions 2x2, 2x1, 1x2 and 1x1
respectively. Given a sampling period of , one can then define and
. This allows one to write the discretized version of the state space model:

where, , , , and ∫ . Lastly, the discretized version


transfer function can be created from the following formula,

where is the identity matrix of the same size as . Inside of the LabVIEW simulation itself,
integrators and differentiators were converted from continuous to discrete versions.

1.4. Results
1.4.1. PID Speed Feedback Control of the DC-Motor
Figures 5 through 7 presented below show the angular velocity response of the physical
DC-motor to individual changes in , , and respectively. For these graphs, ,
, and is used as a baseline while the investigated parameter is both halved
and doubled. The subsequent two graphs, Figures 8 and 9, show respectively the most similar
and dissimilar responses between actual and simulated results at certain PID gain
combinations. Other comparison graphs for different combinations of , , and are
presented in Figures 17 through 21 located in the Appendix.

6
Figure 5. Real-Time Response for Ki = 1.0, Kd = 0.01, and Varying Kp

Figure 6. Real-Time Response for Kp = 0.15, Kd = 0.01, and Varying Ki

7
Figure 7. Real-Time Response for Kp = 0.15, Ki = 1.0, and Varying Kd

Figure 8. Actual, Continuous and Discrete Model Response for Kp = 0.15, Ki = 1.0, Kd =
0.005

8
Figure 9. Actual, Continuous and Discrete Model Response for Kp = 0.3, Ki = 1.0, Kd =
0.01

1.4.2. PID Position Feedback Control of the DC-Motor


Figures 10 through 12 presented below show the angular position response of the
physical DC-motor to individual changes in , , and respectively. For these graphs,
, , and is used as a baseline while the investigated parameter is both
halved and doubled. The subsequent two graphs, Figures 13 and 14, show respectively the
most similar and dissimilar responses between actual and simulated results at certain PID gain
combinations. Other comparison graphs for different combinations of , , and are
presented in Figures 22 through 26 located in the Appendix.

Figure 10. Real-Time Response for Ki = 0.7, Kd = 0.01, and Varying Kp

9
Figure 11. Real-Time Response for Kp = 0.6, Kd = 0.01, and Varying Ki

Figure 12. Real-Time Response for Kp = 0.6, Ki = 0.7, and Varying Kd

10
Figure 13. Actual, Continuous and Discrete Model Response for Kp = 1.2, Ki = 0.7, Kd =
0.01

Figure 14. Actual, Continuous and Discrete Model Response for Kp = 0.3, Ki = 0.7, Kd =
0.01

1.5. Discussion
1.5.1. Discrete-time Integration and Differentiation
The implementation of the discrete-time PID controller, whose C-code derivation is
located in the Appendix, required the usage of both discrete time integrators and differentiators.
This is required to perform digital signal processing because the motor speed signal is a
discrete series of values describing performance. The discrete time integrators and
differentiators allow the system to interpret the system response based on current, future, and
past data. This is essentially caused by a delay, or latency, when using digital processing; the

11
signal being processed is a reconstruction of an analog signal using a specific sampling period.
Discrete-time integrators allow the system to compensate for fluctuations between
measurements. Discrete-time differentiators allow the system to compensate for predicted error
before the next iteration.
Whereas continuous-time systems can be described with differential equations and
analyzed using Laplace transforms, discrete-time systems use difference equations to analyze
signals over a fixed period. The entire signal can be represented (approximately) by considering
each sample at each period, along with the sample from the previous iteration. The current
signal or value is a sum of the current sample, the previous sample, and the predicted next
sample. The difference equations take on physical meaning when the sampling rate/period of
hardware is considered.
These difference equations are derived from Riemann sums, where a signal occurring
over a specific interval is analyzed. Given the first two samples of a discrete signal, a controller
can reconstruct the system and analyze it like an analog signal. The controller performs
corrections based on the changes during sampling, and then outputs a reconstructed signal.
This is analogous to using analog-to-digital conversion before processing, and then using
digital-to-analog conversion to create the output.

1.5.2. Modeled and Simulated Response Analysis


Evident from the actual and modelled responses of both speed and position control, the
proportional controller gain, , adjusts the system output by scaling the system error. This
allows the system to respond faster if is increased, however, this significant change in
system output can cause overshoot in the desired response. The integral controller gain, ,
allows the system to consider accumulated error and adjust the system output accordingly.
Ultimately, increasing removes the steady-state error from the response at the cost of
increasing percent overshoot and settling time. The derivative controller gain, , utilizes the
rate of the change of the error, essentially predicting where the system response is headed, to
steer the control effort. Overall, increasing decreases percent overshoot and settling time of
the response.
In the case of angular velocity response, the results from the simulations are a decent
approximation of the response observed from the physical experimentation. Moreover, the
continuous and discrete mathematical models exhibit nearly exact same responses. Figure 8
shows the closest matching actual and model response pair. It can be observed that the actual
response has a sharper rise and fall than the model, but both responses have the same steady-
state value for each section of the response. Figure 9 shows the worst matching actual and
model response pair. In this plot, the rising and falling slope of the simulated responses are less
steep than the physical response, akin to the previous figure, but their shape is much more
smooth, in particular, neglecting the kink around the one second mark in the actual model
response.
In the case of angular position response, the shapes of the modeled and actual
responses are radically dissimilar from one another for nearly all PID gain combinations. The
continuous and discrete models generally shared the same overall trend, however they did not
match as closely as in the angular velocity case. Through additional experimentation, it was
found that if the gains were quadrupled from their supposed values in the simulations, both the

12
continuous and discrete modeled responses closely matched the actual response. This
indicates that a possible scaling issue caused the original discrepancy in the angular position
responses. However, a more probable cause of this discrepancy is from the fact that a linear
model is used to approximately represent a nonlinear physical model. These nonlinearities can
arise in the physical model in the form of start up friction in the DC motor’s drive shaft and gears
and the limited resolution of the optical encoder.

1.6. Conclusion
The objective of this experiment was to design a PID feedback controller for the speed
and position of a DC motor. Through both physical testing and simulations, the individual effects
of manipulating proportional, integral and derivative on the system’s response were examined
and characterized. For speed control, the actual and simulated (both discrete and continuous)
responses mostly matched. On the other hand, for angular position control, large discrepancies
between the responses were observed, most likely a result from using a linear mathematical
model to approximate a physical nonlinear system.

13
2. Lab 7
2.1. Introduction
This experiment had four primary objectives, the first of which was to learn how to use
an Analog-to-Digital Converter (ADC) to convert an analog voltage into a digital signal and
combine it with a precision Fahrenheit temperature sensor to implement a digital thermometer.
This was accomplished utilizing 7s_tmprtr_msrmnt_A with the ADC in the DSP. The second
objective was to use the reading from the thermometer for the simple on-off control of a cooling
fan. This was accomplished utilizing the 7s_tmprtr_onoff_cntrl_B project which turned on the fan
when the temperature of the sensor exceeded a prescribed value and turned the fan off when
below that value. The third objective was to incorporate a CPU timer interrupt in the simple on-
off control program so that the temperature comparison and control action were only executed
once during a prescribed sampling period of 10 ms. This was accomplished by modifying
7s_tmprtr_onoff_cntrl_B into 7s_tmprtr_int_onoff_cntrl_C. The fourth and final objective of this
experiment was to replace the simple on-off controller with a more robust PID controller which
would utilize the same interrupt scheme.

2.2. Theory
The temperature sensor used in the experiment was National Semiconductor’s LM34
Precision Fahrenheit Temperature Sensor, an analog sensor that outputs a voltage proportional
the the temperature at the sensor’s surface. As this sensor has a very linear response, it is easy
to extrapolate accurate temperatures from the given voltage output. The configuration of the
LM34 connections can be seen below in Figure 15. +VS represents the positive power supply,
VOUT is the temperature sensor analog output, and GND is the device’s ground pin.

Figure 15. National Semiconductor Precision Fahrenheit Temperature Sensor [2]

2.3. Experimental Procedure


2.3.1. Hardware Set-up
The +VS and GND wires of the LM34 temperature sensor were connected to SENSOR
pins 3.3V and GND of the H-bridge board, respectively. The VOUT wire of the LM34 temperature
sensor was connected to ADCINB0 which is at P5:pin1 of the OUT eZdsp board. It was ensured
that the output of the thermometer VOUT at no time exceeded 3V. The GND pins of the H-bridge
board were connected to one of the ground pins of the ADC ports, i.e., odd P9 pins from 1 to 19.

14
For the purpose of calibration it was ensured that P5:pin9 (ADCREFM 0.546V) was connected
to P5:pin8 (ADCINB7) and P5:pin10 (ADCREFP 1.292V) was connected to P9:pin16
(ADCINA7). The VREFLO (P9:pin18) was connected to one of the ground pins. The PWM
(ePWM2) signals at eZdsp P8:pin11 and pin12 were connected to TO CONTROLLER pins 3
and 4 of the H-Bridge board to control the fan. Lastly, the cooling fan was connected to the H-
bridge. A reference table for the eZdsp pin and signal relations can be found in Table 4, below.
A diagram of the required connections can be found below in Figure 16.

Table 4. eZdsp P5/P9, Analog Interface Connector


P5 Pin # Signal P9 Pin # Signal P9 Pin # Signal

1 ADCINB0 1 GND 2 ADCINA0

2 ADCINB1 3 GND 4 ADCINA1

3 ADCINB2 5 GND 6 ADCINA2

4 ADCINB3 7 GND 8 ADCINA3

5 ADCINB4 9 GND 10 ADCINA4

6 ADCINB5 11 GND 12 ADCINA5

7 ADCINB6 13 GND 14 ADCINA6

8 ADCINB7 15 GND 16 ADCINA7

9 ADCINB8 17 GND 18 ADCL0*

10 ADCINB9 19 GND 20 No Connect

Figure 16. H-Bridge Connection Diagram [1]

15
2.3.2. Software Set-up
For the first part of the experiment the simple thermometer project,
7s_tmprtr_msrmnt_A, was migrated from CCSv3.3 to CCSv5.2. The program was debugged,
built, and run. Real-Time mode was utilized to observe registers of interest in the Expressions
View window. To verify that it was working correctly, the LM34 temperature sensor was held so
that it could detect an increasing temperature due to body heat.
The second part of the experiment called for the creation of the CCSv5.2 Project
7s_tmprtr_onoff_cntrl_B to implement the simple on-off control of the cooling fan using
temperature feedback. Once the program was successfully created it was debugged, built, and
run. Real-Time mode was used to monitor registers of interest in the Expressions View window.
The LM34 temperature sensor was held so that it could detect an increasing temperature due to
body heat and turn on the fan. Once the fan turned on, the temperature sensor was released,
allowing it to cool down and trigger the command to stop the fan. The value of ref_temperature
was changed and the above two steps were repeated.
The third part of the experiment required the project 7s_tmprtr_int_onoff_cntrl_C to be
migrated from CCSv3.3 to CCSv5.2. Real-Time mode was used to monitor registers of interest
in the Expressions View window. The LM34 temperature sensor was held so that it could detect
an increasing temperature due to body heat and turn on the fan. Once the fan turned on, the
temperature sensor was released, allowing it to cool down and trigger the command to stop the
fan. The value of ref_temperature was changed and the above two steps were repeated.
The last part of the experiment called for the CCSv5.2 project 7s_tmprtr_PID_cntrl_D to
be created. Once created, the project was debugged, built, and run. Real-Time mode was used
to monitor registers of interest in the Expressions View window. The LM34 temperature sensor
was held so that it could detect an increasing temperature due to body heat and turn on the fan.
Once the fan turned on, the temperature sensor was released, allowing it to cool down and
trigger the command to stop the fan. The value of ref_temperature was changed and the above
two steps were repeated.

2.4. Discussion
The purpose of the ADC is to convert a continuous analog signal, in this particular case
voltage, into a readable digital output that represents the signal’s magnitude. The conversion
process requires the discrete sampling of the input which in turn generates a series of discrete
output values. There are wide variety of ADCs which each use a different operating method.
However, one of most common operating methods is to have the input voltage signal charge an
internal capacitor. The stored charge is then dissipated across an internal resistor and the
microcontroller records the duration of discharge in clock cycles of the CPU timer. The particular
number of cycles is the discrete output of the ADC.
The resolution of an ADC is based on the number of discrete values the converter can
produce over the range of analog values. These values are stored in binary form, and thus
resolution is typically expressed in bits. From the accompanying documentation, for the eZdsp
one can find that it has an on-chip 12 bit ADC converter. This means the ADC can store up to
4096 unique values, two per bit, and thus the numerical resolution is 1/4096 of the full
measurement range.

16
The temperature sensor used in this experiment outputs an analog signal (voltage)
proportional to the temperature in degrees Fahrenheit. Analog signals have values strictly
between 0 and 255; so this entire range (256) must represent the range of the sensor. The
analog values are mapped to the maximum and minimum temperature values detected by the
sensor; this leads to a corresponding measurement resolution. An important note is the
requirement of a reference voltage. Many microcontrollers use 5 volt logic; however, in this
experiment 3.3 volt logic was used. This is essentially the threshold for the high/low logic
behavior; for 3V3 logic, the threshold for a ‘high’ (1 in binary) or on signal is 2.4 volts. Any
voltage less than this is considered a ‘low’ signal and is switched off (0 in binary).
The mapping of temperature values is performed in discrete-time, and hence the
resolution is dependent on the number of bits in the reconstructed signal. For the case of the
LM34, it is a 12-bit conversion. The output must be decoded one significant digit at a time.
Considering ‘temp1’ to be the analog reading from the sensor with 12-bit resolution (4096 bits),
the scaling factor converts to temperatures by multiplying the analog reading by a reference
voltage, dividing by 4096, and multiplying by the sensor’s sensitivity coefficient, calculated as
follows:

where the is the operating measurement range of the sensor divided up into the smallest
resolution unit, and is the conversion from voltage to degrees Fahrenheit, as specified by
the LM34’s accompanying documentation. The minor discrepancy between the derived scaling
factor and the one used in the code could be due to the LM34 being tested to have a slightly
different conversion between voltage and temperature.
Both programs use a simple on-off controller which is simply dependent on checking the
current temperature against a reference temperature and subsequently checking a boolean
condition. However, 7s_tmprtr_int_cntrl_B continuously checks temperature and sets the fan
condition whereas 7s_tmprtr_int_cntrl_C utilizes interrupts so that this check-set process only
occurs once within a certain time interval. This means that less computational power needs to
be used by 7s_tmprtr_int_cntrl_C to achieve the same results as 7s_tmprtr_int_cntrl_B
assuming a properly chosen time interval.
As stated previously, increasing the proportional gain decreases the rise time and
steady-state error of the response, but consequently increases the percent overshoot.
Increasing the integral gain has the same effect while eliminating the steady-state error, but
increases the settling time. Increasing the derivative gain will decrease percent overshoot and
settling time.
In the case of the temperature control system utilized in this experiment, a high percent
overshoot and an oscillatory response needed to be avoided. This is because the fan could burn
out if the fan-speed command was set too high. However, this particular issue was prevented in
the code by limiting the maximum speed of the fan with a saturation function. An oscillatory
response could also require the fan to have quick changes in speed, putting unnecessary load
on the fan. Also, an oscillatory response around the reference temperature would cause the fan

17
to “twitch” on and off. Typically, one wants to avoid turning a system on from a complete stop as
it requires more effort or energy to do so. This means the desired performance would be a very
well damped response. One can achieve a desired performance by knowing the theoretical
effects of altering PID gains and observing the fan’s behavior.
The default PID gains for this system were 50, 0.7, and 0.01 for proportional, integral,
and derivative gains respectively. Using these values, an oscillatory response with a seemingly
significant overshoot was seen. A variety of other PID gains were tested via a visual inspection
of the fan response as well as a rough estimate of cooling time. It was found that PID gains of
60, 0.4, and 0.02 for proportional, integral, and derivative gains, respectively, produced desired
results. There was an overall short cooling time. The fan appeared to have little to no overshoot
in its start-up speed. Lastly, there was no visible oscillations in fan speed during operation or
after the temperature reached its threshold. This last quality was key in determining desired
gains as for many responses one could see the fan jitter for a short period of time after the
temperature dropped below the threshold.
The on-off controller is easier to create code for and implement as it does not require
any more significant mathematics than temperature conversion. Also, if compared to an
improperly tuned PID, the on-off controller could be more effective. However, if a good model
can be created for the system, or if there are easily identifiable visual clues to interpret PID
behaviour, PID control becomes relatively easy to design and tune. The PID controller
implemented during the experiment was able to achieve a shorter cooling time than the simple
on-off controller.

2.6. Conclusion
The first objective this experiment was to observe the effects of utilizing interrupts in the
implementation of a discrete controller. Interrupts allow one to better coordinate computational
resources and ensure that processes are being carried out efficiently and in a logical
progression, rather than processes simply running as resources are available. The second
objective was to compare an on-off controller with a PID controller, both utilizing interrupts. The
benefit of an on-off controller is a simpler algorithm, which makes for easy implementation and
the creation of an acceptably efficient controller. While PID requires more effort, both in terms of
coding and tuning, it can also provide much more efficiency in terms of power use and cooling
time.

18
3. References
[1] Chang, B.C., Salman, M. U., Lab Manual, “Lab 7, Temperature Measurement and Fan
Control Using PID Feedback– DSP28355, CCSv5.2” May 2015
[2] Texas Instruments. “LM34 Precision Fahrenheit Temperature Sensors” Online. Available:
http://www.ti.com/lit/ds/symlink/lm34.pdf (Accessed: May 24, 2015).

19
Appendix
Motor Speed PID Responses

Figure 17. Actual vs Models’ Response Figure 18. Actual vs Models’ Response
Kp = 0.15, Ki = 1, Kd = 0.01 Kp = 0.075, Ki = 1, Kd = 0.01

Figure 19. Actual vs Models’ Response Figure 20. Actual vs Models’ Response
Kp = 0.15, Ki = 0.5, Kd = 0.01 Kp = 0.15, Ki = 2, Kd = 0.01

Figure 21. Actual vs Discrete Model Response


Kp = 0.15, Ki = 1, Kd = 0.2

20
Angular Position PID Responses

Figure 22. Actual vs Models’ Response Figure 23. Actual vs Models’ Response
Kp = 0.6, Ki = 0.7, Kd = 0.01 Kp = 0.6, Ki = 0.035, Kd = 0.01

Figure 24. Actual vs Models’ Response Figure 25. Actual vs Models’ Response
Kp = 0.6, Ki = 1.4, Kd = 0.01 Kp = 0.6, Ki = 0.7, Kd = 0.005

Figure 26. Actual vs Models’ Response


Kp = 0.6, Ki = 0.7, Kd = 0.02

Derivation of C Code for PID Implementation


/* Discrete-Time PID-Controller based on Feedback Program from MEM-459

21
I will use the base program and define the working difference functions. This assumes
that I have the actual RPM motor speed returned from the original lab files.

This code uses the basic PID controller feedback loop in conjunction with the reference signal,
resulting error signal, and the hardware/software specified time step.
*/

#include "DSP28x_Project.h" // Device Header file and Examples Include File

# define scalefactor_angle 0.017578125 // 360/(512*10*4)=0.017578125


//This number is computed based on 512 slots per revolution, 10:1 gear ratio,
//quadrature 4x multiplier, 360 deg/rev
# define scalefactor_rpm 0.29296875 // scalefactor_angle*(6000/360)

// Prototype statements for functions found within this file.


void InitEPwm1Cntrl(void);
interrupt void cpu_timer0_isr(void);
interrupt void ecap1_isr(void);
interrupt void ecap2_isr(void);
void InitECapture(void);
void InitECapGpio24_25(void);

// Global variables used in this example


Uint32 EPwm1TimerIntCount;
Uint32 ECap1IntCount;
Uint32 ECap2IntCount;
int QA_kminus = 0, QA_k = 0;
int QB_kminus = 0, QB_k = 0;
long int num_of_ints = 0;
int cntrl, counter=0;
float angle_deg = 0;
int ints_in_10ms = 0;
float rpmold, rpmnew=0, err=0, mk=0, xk=0, xkminus=0, kp, ki, kd;
float ref_speed=100;
float rpm_graph[500]=0;
float inp_graph[500]=0;

// Initialize errors and RPM old and new variables


float errOld = 0;
float errNew = 0;
float RPM_actual = 0;
float RPM_new = 0;
float RPM_old = 0;

22
// The actual differencing function

Discrete_Time_PID_Control()

/* Call once per sampling period, which is the time interval over number of samples.
500 samples / 5 seconds = 10 milliseconds
*/

begin

RPM_actual = measure_RPM(); // Get the measured RPM of motor from


original class file
RPM_new = RPM_current;
err = ref_speed - RPM_actual; // Calculate current error

//Numerical integration and linear time-invariant functions


xk = err + xkminus;
mk = kp*(xk - xkminus) + 0.005*ki*(xk + xkminus) + kd*(xk-xkmius)/0.005; // Because
delta_T = 0.005
xkminus = xk;
mk_Old = mk;
end;

23

View publication stats

S-ar putea să vă placă și