CARDIFF UNIVERSITY SCHOOL OF ENGINEERING

DC Motor Speed Control

Project Report
Philip Strong 31/3/2012

Acknowledgments
The author would like to express appreciation to the following people for their assistance and encouragement throughout this project.

Dr M Ghassempoory

Project Supervisor School of Engineering, Cardiff University

Dr R Philp

Project Moderator School of Engineering, Cardiff University

Mr R Rogers

Laboratory Technician School of Engineering, Cardiff University

Mr R Pope

Debugging help Student, Cardiff University

Mr E Collins

Parts selection and design help Graduate, Cardiff University

License
This document is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

-1-

Abstract
This paper documents the design and construction of a DC motor speed controller controlled by a computer. The requirements are defined and then the design process explained. The final product is exhibited followed by a discussion of the success of the project, with suggestions for how to further improve the device. The project was successful, however a noise related bug was found with the over-current protection feature; the report includes recommendations to overcome this.

-2-

Contents
Acknowledgments .................................................................................................. - 1 License ................................................................................................................... - 1 Abstract .................................................................................................................. - 2 CD-ROM contents .................................................................................................. - 6 List of Figures ......................................................................................................... - 7 List of Tables .......................................................................................................... - 7 Nomenclature ......................................................................................................... - 8 1. Introduction ...................................................................................................... - 9 1.1. 1.2. 1.3. About this report ........................................................................................ - 9 Project aims .............................................................................................. - 9 Requirements definition .......................................................................... - 10 -

2. Background and Research ............................................................................ - 12 2.1. 2.2. 2.2.1. 2.2.2. 2.3. 2.3.1. 2.3.2. Existing products and related works ........................................................ - 12 Motor driver ............................................................................................. - 12 National Semiconductor LMD18200 .................................................... - 13 Linear Technology LT1160 .................................................................. - 13 Control system ........................................................................................ - 13 Microchip PIC....................................................................................... - 14 Arduino ................................................................................................ - 14 -

3. Development.................................................................................................. - 15 -

-3-

3.1. 3.1.1. 3.1.2.

Hardware design ..................................................................................... - 15 High level design.................................................................................. - 15 Functional description .......................................................................... - 15 MCU ................................................................................................. - 16 Optoisolation..................................................................................... - 16 Comparator....................................................................................... - 16 5V PSU ............................................................................................. - 17 Other components ............................................................................ - 17 Schematic design................................................................................. - 17 PCB design .......................................................................................... - 19 Track width and placement ............................................................... - 20 Switching power supply .................................................................... - 20 Autorouting ....................................................................................... - 21 -

3.1.2.1. 3.1.2.2. 3.1.2.3. 3.1.2.4. 3.1.2.5. 3.1.3. 3.1.4. 3.1.4.1. 3.1.4.2. 3.1.4.3. 3.2. 3.2.1. 3.2.1.1. 3.2.2. 3.2.3. 3.3. 3.3.1. 3.3.2.

Software design ...................................................................................... - 21 High level design.................................................................................. - 21 Arduino firmware .............................................................................. - 21 RPM measurement .............................................................................. - 23 Serial protocol ...................................................................................... - 24 Final product ........................................................................................... - 24 Hardware ............................................................................................. - 24 Arduino firmware .................................................................................. - 25 -

-4-

3.3.3.

Test software ....................................................................................... - 25 -

4. Conformance ................................................................................................. - 27 4.1. 4.2. Requirements conformance .................................................................... - 27 Testing .................................................................................................... - 28 -

5. Discussion ..................................................................................................... - 31 5.1. 5.2. 5.3. 5.3.1. 5.3.2. 5.3.3. 5.3.4. Time management .................................................................................. - 31 Problems encountered ............................................................................ - 31 Further work ............................................................................................ - 33 Current limitation and threshold ........................................................... - 33 Advanced motor control ....................................................................... - 33 Transfer protection to Arduino ............................................................. - 34 Decrease size and current capability of on-board 5V PSU .................. - 34 -

6. Conclusion ..................................................................................................... - 35 References ........................................................................................................... - 36 Appendix A Schematic diagram ........................................................................ - 37 Appendix B Arduino code .................................................................................. - 38 -

-5-

CD-ROM contents
This document attaches a CD-ROM with related material. The contents of this disk are as follows.

Report (DOCX and PDF) Test Application Arduino firmware KiCad schematic FreePCB PCB design

-6-

List of Figures
Figure 1 - Hardware block diagram ...................................................................... - 15 Figure 2 - Schematic diagram .............................................................................. - 18 Figure 3 - PCB design .......................................................................................... - 19 Figure 4 - Arduino firmware block diagram........................................................... - 22 Figure 5 - Rotary encoder signal (Potma, 2004) .................................................. - 23 Figure 6 - Photo of populated PCB ...................................................................... - 25 Figure 7 - Test application screenshot ................................................................. - 26 -

List of Tables
Table 1 - Summary of requirements ..................................................................... - 11 Table 2 - Protocol definition .................................................................................. - 24 Table 3 - Requirements conformance .................................................................. - 27 -

-7-

Nomenclature
Abbreviation PWM PCB MCU DAC PID RS232 Meaning Pulse width modulation Printed circuit board Microcontroller Unit Digital to Analogue converter Proportional Integral Derivative A standard for serial communications and control signals between devices I2C Inter-Integrated-Circuit, a serial data bus for communicating between integrated circuits PIC Peripheral Interface Controller, a microcontroller designed and manufactured by Microchip AVR FPGA Net A microcontroller designed and manufactured by Atmel Field programmable gate array Wire network, a series of connected traces on a PCB

-8-

1. Introduction
1.1. About this report This report documents the research, process and results used and obtained throughout the project. The first chapter introduces the project and summarises the development process. The second chapter outlines the research undertaken throughout the project and gives an insight into the relative advantages of the available options. Chapter 3 discusses the decisions made, the steps taken whilst designing the system and demonstrates the finished product and accompanying software interface. Chapter 4 compares the final product with the initial requirements, and describes the techniques and results used to test the system. Chapter 5 discusses the success of the project and suggest recommendations for improving the system, and chapter 6 concludes the report. 1.2. Project aims Several milestones were set to control the development process, which have been outlined below. Project planning: Produce a plan which includes initial project aims and requirements, a time management plan and research of existing related projects. Research: Compare and consider methods of implementation. Research areas are predominately related to parts selection and then interfacing the various parts to each other. Specific attention is to be paid to methods of protection, robustness of the driver and interfacing the driver with the computer.

-9-

Design and prototype: Propose a draft schematic diagram and then construct a prototype. Note issues with the prototype and change the schematic where appropriate. Design a PCB based on the successful final prototype. Manufacture and populate the PCB with the circuit: Implement the hardware design designed in the previous objective, and test to ensure the circuit functions as it should. Write and optimise a firmware for the microcontroller: With a working hardware device defined it will be possible to write a firmware to control all the features. System testing: Test the combined hardware and software, ensuring that the firmware is adequate for the hardware functions. Compare the product to the initial specification to ensure the product is fit for purpose. Test each component individually making sure there is nothing overlooked. Evaluation of the product: Suggest any further work for the design and implementation. Project report: Issue a full report, documenting the planning, research, design implementation and discussion of the product. 1.3. Requirements definition The specific requirements of the system were defined early, and did not change significantly throughout the course of the project. The requirements are outlined below and summarised in Table 1. A power requirement is imposed; the driver must be able to supply a current of 3A at 50V continuously, in a forward and reverse state. A brake must also be available to stop the motor. Robustness of the system is critical, and several protections must be - 10 -

considered; thermal shutdown, over-current shutdown and short circuit protection must be apparent, as well as full optical isolation between the motor driver and the control system. The final basic requirement was to allow the system to communicate with the host computer over an RS232 interface. Further, optional specification definitions offered were to provide the system a USB interface, and read back the RPM of the attached motor. The frequency of the PWM signal was required to be outside of the audible range, so that the motor would not emit a high frequency tone whilst powered up. The final optional requirement was allowing multiple motors to be controlled with the system. Description Voltage and current Controls Robustness Requirement 50V, 3A Speed, direction and brake Thermal protection Protection Connection Motor control Motor feedback Full optoisolation PWM frequency outside the audible range RS232 (USB as further requirement) Allow multiple motors to be controlled by the system (as further requirement) Multiple motors RPM sampling (as further requirement) cut-out, over-current cut-out, short circuit

Table 1 - Summary of requirements

- 11 -

2. Background and Research

2.1. Existing products and related works There are many motor drivers available on the market; however few come close to the requirements of this project. The closest product found to the requirements of this project is an Atmel AVR based dual motor controller employing PID control and interfacing over an RS232 connection. However, the limitations of this motor driver are that it requires multiple voltage sources, and that no attention has been paid to the robustness of the circuit. The board appears to use the National Semiconductor LMD18200. This can be found at the following URL: http://www.procyonengineering.com/embedded/motorcontrol/motorctrl-avr/ Another related product is a 50V, 5A dual motor controller. This motor controller has multiple methods of interface, via I2C, analogue voltage input, and an RC servo interface. Again, this motor controller pays little attention to protections, and appears to have no current threshold, thermal sensing or electronic isolation. This motor board uses discrete MOSFETs to drive the motors. This can be found at the following URL: http://www.zagrosrobotics.com/shop/item.aspx?itemid=601 2.2. Motor driver The requirement for the motor was the ability to drive a current of 3A at a voltage of 50V. For this to be possible, some form of electronic control would be necessary to convert a control signal, likely to be logic level, to the high voltage and current required. A dedicated H-bridge chip was selected for its simplicity, ease of interface - 12 -

and cost efficiency. The other options were using a mechanical relay, which would be noisy, inefficient, slow and unreliable, and to create an H-bridge using MOSFET chips, which would be more difficult to interface, increase the chance of failure and provide less protection features. The following commercially available H-bridge chips which fulfilled the requirements were considered. 2.2.1. National Semiconductor LMD18200 The National Semiconductor LMD18200 is a 3A, 55V H-bridge in a TO-220 package, whilst being capable of handling a 6A peak current for 200ms. This chip includes a thermal warning output, thermal shutdown, short circuit protection and current sense capabilities. Compatible with TTL and CMOS inputs, and with internal clamp diodes and charge pump, the LMD18200 is simple to interface to a microcontroller based control system. (National Semiconductor, 2012) 2.2.2. Linear Technology LT1160 The Linear Technology LT1160 is a half-/full-bridge power MOSFET driver, capable of driving a peak current of 1.5A for 10s at 60V. This chip offers under voltage protection but no short circuit protection, current sensing or thermal shutdown. 2.3. Control system For the control system, it was apparent that a microcontroller was the only option which combined the PWM ability and general purpose input / output with the serial interface required, whilst remaining cost effective. Other options would include discrete logic, which was disregarded due to high complexity, cost and inability to modify, and an FPGA based system, which would be less cost efficient with no benefit. Two mainstream microcontroller options were considered, the Microchip PIC series and the Arduino prototyping platform. - 13 -

2.3.1. Microchip PIC The PIC series from Microchip comprises of an expansive range of microcontrollers varying in physical size, specification and capability. Many devices have a serial interface, capture / compare / PWM and analogue to digital conversion, as well as many other features. The PIC series can be programmed in many languages including BASIC, C and assembler. (Microchip, 2006) 2.3.2. Arduino Arduino is an open source prototyping and development platform based on the Atmel AVR series of microcontrollers. The hardware is simple to use, with USB connectivity and pin sockets to connect wires to. The programming environment is based on C++ with an abstraction layer to simplify the syntax for ease and speed of programming. The Arduino can utilise raw AVR assembler to write timing critical routines or to increase performance. The Arduino can take advantage of all the features available on the AVR microcontroller, such as PWM output, analogue to digital conversion, precise timing and a serial interface. (Arduino, 2012)

- 14 -

3. Development
In this section, the steps pursued to design the system will be outlined, from a hardware and then a software perspective, whilst outlining the reasons behind certain choices and the considerations made when selecting methods. 3.1. Hardware design 3.1.1. High level design The first step in the design of the hardware was to produce a block diagram describing the functional characteristics of the system. The final block diagram can be seen in Figure 1.

Figure 1 - Hardware block diagram 3.1.2. Functional description The block diagram shows the functional layout of the system; however the purpose of each component may be unknown. The reasoning behind the functional components being chosen will be discussed.

- 15 -

3.1.2.1.

MCU

An early design proposed contained the microcontroller on the motor driver board itself, making the system a fully contained unit to be interfaced with a computer. It was later decided that the driver board should be physically separated from the microcontroller and connected via a cable, to allow the use of the driver board to be more flexible. This arrangement allows the system to fulfil partially the extra requirement to control multiple motors. By allowing the drive circuitry to be separated from the control, it would be a simple process to add a second driver to the microcontroller if required, but also allow the cost to be reduced if only one motor is required to be driven. 3.1.2.2.

Optoisolation

A key requirement of this system was robustness and safety. Optoisolation electronically isolates both sides of the circuit, so that any unwanted voltage spikes on one side would not transfer to the other, thus protecting the microcontroller and the computer connected to it. As the frequency of the PWM would be outside the audible range, a fast switching optoisolator was chosen to allow the signal to propagate from the controller to the motor driver uninhibited. With a 60KHz signal with 256 varying PWM levels, an optoisolator with a speed of 15MBaud was required, however in testing a 10MBaud optoisolator proved sufficient. 3.1.2.3.

Comparator

The chosen H-bridge motor driver, the National Semiconductor LMD18200, has a CS (current sense) pin which provides 377A per 1A drawn at the output (National Semiconductor, 2012). This current is passed through a 1.8K resistor to create a voltage of 0.68V per amp drawn at the output. This is fed into one input of a - 16 -

comparator; the other input is attached to a potentiometer to create a voltage threshold. If the current drawn exceeds the preset threshold, the current warning pin is activated to warn the microcontroller that the current threshold has been breached. 3.1.2.4.

5V PSU

As the motor driver is electronically isolated from the microcontroller and USB power source, the motor driver is required to generate its own 5V power source from the input voltage source, to drive the optoisolators and comparator. As the supply voltage range of the H-bridge is from 12-55V, a switched mode power supply was chosen to provide a stable 5V voltage at a range of input voltages, whilst not emitting excess heat and requiring its own cooling. 3.1.2.5.

Other components

As the optoisolator chips were active low, it was apparent that when disconnected from the microcontroller or in a fault situation, the output of the optoisolator would remain high. In the case of the brake and direction input, this is irrelevant however the PWM input being held high would cause the attached motor to run at its maximum RPM. As such an inverter was connected to the output of the optoisolator to ensure that a fault or disconnection would result in the motor receiving no power. 3.1.3. Schematic design The block diagram was then used to create a schematic diagram, using the chosen parts. The schematic can be viewed in Figure 2, a full size version can be found in appendix A. The open source software package KiCAD was chosen for the design of the schematic. The component choices were made based on the recommendations and figures given in the datasheets of the respective components. - 17 -

The Arduino platform was chosen as the microcontroller to drive the control system, due to its clear and powerful programming interface and built in USB-to-serial conversion. The National Semiconductor LMD18200 H-bridge was chosen as it included the required protection circuitry and was easily interfaced with a microcontroller. The National Semiconductor LM2576HV-5.0 was chosen as the 5V power source, as it was capable of generating 5V with an input voltage range of 7V 60V, and a current of 3A to allow for future expansion. The optoisolator chosen was the Vishay VO2631, chosen due to its logic level inputs and outputs, high switching rate and ability to have 2 channels per 8 pin DIP chip.

Figure 2 - Schematic diagram - 18 -

3.1.4. PCB design A PCB was designed using the FreePCB PCB design package, based on the schematic diagram of the circuit. Considerations were made during the design of the PCB to ensure robustness and safety. The final design for the PCB is shown in Figure 3.

Figure 3 - PCB design

- 19 -

3.1.4.1.

Track width and placement

Due to the high current nature of the project, adequate track width was paramount to prevent damage to the circuit and reduce the risk of failure. Using a PCB track width calculator, a width of 160mil (1mil = 1 thousandth of an inch) was decided upon for the high current parts of the circuit. The peak current of 6A was used, with a peak voltage of 55V. The allowed temperature rise was 10C and a copper thickness of 70m was assumed. This resulted in a recommended track width of 154mil, so a 160mil track was used. The calculator can be found at the following URL: http://www.desmith.net/NMdS/Electronics/TraceWidth.html The datasheet for the LMD18200 H-bridge recommended the VS pin have a heatsink of a 1 square inch copper area, to allow heat to be dissipated in the case of a current spike, which was implemented as part of the Vin trace. The optical isolation was implemented to prevent there being any electrical connection from one side of the board to the other. This meant that there should be no copper connection from either side, and so there was no copper trace placed underneath the optoisolator chips. A ground plane was added to the board to increase resistance to interference, reduce time for the board to be milled, and reduce wear on the PCB manufacture hardware. 3.1.4.2.

Switching power supply

The switching power supply on the circuit board required specific layout requirements. The most notable requirement is ensuring the external components are as close to the chip as possible, with minimum ground loops (National

- 20 -

Semiconductor, 2004). This meant a balance had to be struck between a well performing power supply and ease of construction. The decision was made to optimise the performance of the power supply at the cost of the components being very close together. 3.1.4.3.

Autorouting

The FreePCB package used to design the PCB contains an autorouting function to automatically route the traces. This is done by attaching pins on the chips to nets, which are then connected via traces at the autorouting stage. To ensure optimum safety and performance, part of the routing was done by hand before allowing the autorouter to function. This allowed the high current traces to be routed with a sufficient gap between them to prevent against shorting. Critical traces related to the 5V power supply were also hand routed to prevent the autorouter from causing problems. 3.2. Software design The software for the system comprises of two packages; a firmware for the Arduino microcontroller and a test application for the host. The Arduino was responsible for communication with the host, generating the signals to control the motor driver, and interpreting the signals from the rotary encoder on the motor. The host test application would have to send commands to the Arduino, and display the received commands. 3.2.1. High level design 3.2.1.1.

Arduino firmware

The Arduino firmware design is very simple. The process is shown in Figure 4. - 21 -

INIT Start RS232 link Define PWM frequency Set pin directions

GET DEVICE STATUS Sample RPM and pin states Send values to host

GET SERIAL DATA Is there data in the serial buffer?

UPDATE OUTPUTS Set new PWM duty cycle, direction and brake states

Figure 4 - Arduino firmware block diagram With this design, it is assumed that the host will monitor the status of the current and thermal flags, and take appropriate action if either is to change state. This would result in a maximum of an 80ms delay between the flag occurring and the corresponding reaction, however this could be mitigated by programming the protection into the Arduino firmware.

- 22 -

3.2.2. RPM measurement The expected input from the motor is a rotary encoder. The number of pulses per rotation is unknown, so this will need to be definable in the Arduino firmware. The signal from a rotary encoder is shown in Figure 5 - Rotary encoder signalFigure 5.

Figure 5 - Rotary encoder signal (Potma, 2004) By attaching signal A to an interrupt, and incrementing a counter, we can count the number of pulses made. If this number is sampled and cleared at a regular interval, the RPM can be calculated. To determine the rotational direction of the motor stator, the state of signal B can be determined as the signal A interrupt is fired. When the motor is turning right and signal A is at its rising edge (at point 1), signal B is low. When the motor is turning left and signal A is at its rising edge (at point 3), signal B is high.

- 23 -

3.2.3. Serial protocol A serial protocol was designed to allow the host to communicate with the microcontroller. The protocol consists of 8 bytes, where each unit of data is at least one byte. The first byte is a start byte, which is 0x0F. Both the host and the Arduino listen for this start byte before parsing the next 7 bytes. This ensures that the start of the packet is synchronised with the protocol parser and will stop the wrong byte being interpreted as another. This is important as the Arduino could read another byte as power, and turn the speed of the motor up when unwanted. The protocol is defined in Table 2. Byte ID 0 1 2 3 4 5 6 7 Control packet START_BYTE Power Brake Direction NULL_BYTE NULL_BYTE NULL_BYTE NULL_BYTE Status packet START_BYTE Current flag Thermal flag RPM MSB RPM LSB NULL_BYTE NULL_BYTE NULL_BYTE

Table 2 - Protocol definition 3.3. Final product 3.3.1. Hardware The PCB was manufactured by Cardiff University using a PCB mill and was then populated with the components by the author. A photograph of the finished product is shown in Figure 6.

- 24 -

Figure 6 - Photo of populated PCB 3.3.2. Arduino firmware The Arduino firmware was implemented as per the design. Notable considerations were the use of direct C commands rather than native Arduino commands for pin manipulation, to improve performance. The entire Arduino firmware can be seen in appendix B. 3.3.3. Test software C# was used to implement a small test application to control the motor driver. This application sends bytes conforming to the protocol to the Arduino based on the state

- 25 -

of the onscreen controls, and displays the received data. A screenshot of the application can be seen in Figure 7.

Figure 7 - Test application screenshot

- 26 -

4. Conformance
4.1. Requirements conformance The design conforms to the requirements initially specified. The requirements and actual specification are shown in Table 3. As can be seen, the project comfortably exceeded all given requirements. Description Voltage and current Requirement 50V, 3A Actual specification 12-55V input, 3A continuous (6A peak) Controls Speed, direction and brake Robustness Thermal cut-out, overcurrent cut-out, short circuit protection Protection Full optoisolation Speed, direction and brake Thermal cut-out, overcurrent cut-out, short circuit protection Full optoisolation and zero copper between host and motor driver Connection RS232 (USB as further requirement) Motor control PWM frequency outside the audible range Motor feedback Multiple motors RPM sampling Allow multiple motors to be controlled by the system RPM sampling Modular approach to allow multiple drivers to be controlled by the same microcontroller 62.5KHz PWM frequency USB via Arduino

Table 3 - Requirements conformance

- 27 -

4.2. Testing The system was tested at many stages during the development, from the prototyping stage to after the production of the PCB. The main testing was done after the PCB had been manufactured and will be the focus of this section. The testing documentation consists of a test, an expected outcome and an actual outcome. If the outcome is not as expected, a justification will be provided.

Test

Connection established between PC and motor driver. An LED was attached to the power control pin, and the power bar manipulated in the test application.

Expected Brightness should change proportional to the position of the outcome Actual outcome slider. Brightness changes proportional to the position of the slider. PASS

Test

Motor speed changes respective of the input from the computer.

Expected As power byte increases, motor speed should increase. outcome Actual outcome Motor speed increases proportional to the amount of power requested by the host. PASS

Test

Motor direction changes respective of the input from the computer.

Expected When toggling the direction in the test application, motor outcome Actual outcome direction should change. Motor direction changes correctly. PASS

- 28 -

Test

Thermal warning flag pin is correctly connected to the controller.

Expected outcome Actual outcome

When the pin is manually pulled low, the thermal warning flag pin would go high. Thermal warning flag goes high as expected. PASS

Note: It was decided that attempting to test the warning flag feature would be unsafe in the available environment, and could risk damaging the motor driver board as it would require increasing the heat of the driver chip to 145C. The test assumed the thermal warning flag feature was functional in the motor driver chip.

Test

Over-current flag goes high when current goes over the preset threshold.

Expected outcome Actual outcome

Current flag is low until the current reaches the threshold.

Current flag gives inaccurate readings, output is very noisy. FAIL

The output of the current sense pin on the motor driver chip provides 377A per amp drawn by the output. Current spikes are likely, and the current drawn is not consistent. This results in a noisy output which causes the current flag to be unreliable. Possible solutions to this problem are posed later in the report.

Test Expected outcome Actual outcome

PWM frequency is above audible range. When running the motor, there should not be a fixed, high frequency whine from the motor. The motor does not make any high frequency whine. PASS

- 29 -

Test Expected outcome Actual outcome

RPM is measured using the rotary encoder signals. RPM measurement rises in the test application when power supplied is increased. RPM display rises proportional to power applied. PASS

The accuracy of the RPM measurement cannot be guaranteed, as no RPM measurement equipment was available for comparison. However the RPM measurement feature can be used to give an indication of the relative speed of the motor.

- 30 -

5. Discussion
5.1. Time management A Gantt chart was created at the beginning of the project to manage the flow of time. As the initial time plan was to include April, time pressure was increased towards the end of the project, and as such there was less time to complete the report than was expected. The Gantt chart is shown in Figure 8. Objective Oct number 1 2 3 4 5 6 7 8 Nov Dec Jan Feb Mar Apr

Figure 8 - Project Gantt chart The objectives referred to in Figure 8 are as described in the project aims; a summary is as follows. 1. 2. 3. 4. 5. 6. 7. 8. Project planning Research and compare different methods Design and prototype Manufacture and populate PCB Write and optimise microcontroller firmware System testing Product evaluation Project report

5.2. Problems encountered During the project, several problems occurred which had to be overcome to ensure the completion of the system. The problems which occurred will be discussed along with the solutions posed. - 31 -

The 5V power supply initially used a National Semiconductor LM5009 150 mA StepDown Switching Regulator. This would not provide a stable 5V output on breadboard, which could be due to poor placement of external components. As it was unclear as to whether this was down to the placement of the components or the design of the circuit, it was decided that another voltage regulator would be used. The solution was to use a National Semiconductor LM2576 switching power supply, which when implemented on breadboard gave a very stable 5V output. During the design of the PCB, it was necessary to have two different track widths for the same net, however the FreePCB software makes this very difficult. The solution to this problem was to create two separate nets; one for the high current traces and one for the low current traces. This was then joined by the laboratory technician using Altium Designer. When machining the PCB, there were two problems. The first problem was that the alignment camera was not fully calibrated prior to milling. This resulted in the holes being drilled approximately 2-3mm from where they were intended to be, thus causing the board to be unusable. The second problem was a translation problem from the schematic and prototype to the PCB design. Two small pin misplacements caused the Vcc and GND pins on one of the optoisolators to be swapped. The first PCB machining problem was fixed by the laboratory technician, and the PCB remilled. The second problem was fixed by redesigning a small area of the PCB and having the PCB re-milled.

- 32 -

5.3. Further work 5.3.1. Current limitation and threshold The requirements stated robustness of drive and protection as a key element in the design. However, the current sensing turned out to be buggy and ineffective, with spikes causing the current limit flag to go high even when under light loads. There are several potential solutions to this problem. Firstly, a software filter could be implemented to require the current limit flag to be high for a set period of time, allowing for noise. The current limit flag could be sampled at a regular rate, and only after several concurrent high states would a subroutine be called to take action. Another method would be to include a filter on the output of the current sense pin of the H-bridge. This would filter the noise and only allow the state to be registered when the pin had been high for a predetermined time. A final method would be to use another H-bridge chip with a built in comparator, such as the National Semiconductor LMD18245. This chip contains a 4-bit input to a DAC as one input to the comparator, and the current sense pin attached to the other input. This will allow a constantly variable current threshold which can be controlled by the microcontroller. (National Semiconductor, 2012) 5.3.2. Advanced motor control To improve the functionality of the system, more advanced motor control could be implemented by adding to the microcontroller firmware. The data the microcontroller can utilise is the rotational speed of the motor, the number of rotations, the position of the motor stator and the power being supplied to it. Using this information, it would be possible to implement a PID control system to maintain a constant RPM or move

- 33 -

an attached device to a specific position. Thus the system could be reprogrammed to act as a servo controller for an industrial application. To prevent physical damage and potential overheating, a stall prevention could be implemented, to cut the motor out when not rotating. This would allow the system to warn the host that the motor has stalled so that the mechanical problem can be traced. 5.3.3. Transfer protection to Arduino At present, the Arduino acts as a transfer layer between the host and the motor driver. It is assumed that the host will be programmed to monitor the thermal and current flags, and to take appropriate action. This functionality could be moved to the Arduino firmware to increase the speed of response and decrease the chance of failure. 5.3.4. Decrease size and current capability of on-board 5V PSU The on-board 5V power supply was chosen for its stability of voltage and ease of integration; however a smaller, lower current alternative could be used in its place to reduce the size and weight of the board, as well as the component costs.

- 34 -

6. Conclusion
The goal of this project was to design and create a DC motor speed controller. The requirements were clear and concise, giving basic requirements and additional requested features for implementation if time were to allow it. The product was manufactured using commercial of the shelf components, and communicates with the host system using an Arduino prototyping board. Overall, the final product exceeds the requirements, including the additional requested features. Potential problems with the system have been identified, with methods to improve the system suggested. If the author were to undertake this project again, a similar design process would be employed, as it was felt that this was successful and resulted in an adequate final product. However, more time would be spent on the design of the microcontroller firmware, as the current system is lacking in features and does not act on the protections offered by the motor driver board.

- 35 -

References
Arduino, 2012. Arduino FAQ. [Online] Available at: http://arduino.cc/en/Main/FAQ [Accessed 23 3 2012]. Microchip, 2006. 8-bit PIC Microcontroller Solutions. [Online] Available at: http://ww1.microchip.com/downloads/en/DeviceDoc/39630C.pdf [Accessed 23 3 2012]. National Semiconductor, 2004. LM2576/LM2576HV Series SIMPLE SWITCHER 3A Step-Down Voltage Regulator. [Online] Available at: http://www.ti.com/lit/ds/symlink/lm2576.pdf [Accessed 25 3 2012]. National Semiconductor, 2012. 3A, 55V DMOS Full-Bridge Motor Driver. [Online] Available at: http://www.national.com/pf/LM/LMD18245.htm [Accessed 25 3 2012]. National Semiconductor, 2012. LMD18200 3A, 55V H-bridge. [Online] Available at: http://www.national.com/pf/LM/LMD18200.html [Accessed 23 3 2012]. Potma, C., 2004. Bascom and AVR, Encoders. [Online] Available at: http://www.qsl.net/pa3ckr/bascom%20and%20avr/encoders/index.html [Accessed 26 3 2012].

- 36 -

Appendix A Schematic diagram

- 37 -

Appendix B Arduino code

//////////////////////////////////////////////////// // // // Philip Strong 2012 // // // // DC Motor Speed Controller // // // //////////////////////////////////////////////////// // // // // // // // // // // // // // // // // // // This sketch translates the serial protocol as defined below into controls for the related motor controller board. There are 255 steps of PWM control set to 62.5KHz, to ensure it is out of the audible range. The current and thermal pins are monitored. Packet definition The packet is comprised of 8 bytes. The control packet (incoming) contains 4 blank bytes for future expansion. The status packet (outgoing) contains 3 blank bytes for future expansion. The packets are defined as follows. Byte ID 0 1 2 3 4 5 6 7 Control packet START_BYTE Power Brake Direction NULL_BYTE NULL_BYTE NULL_BYTE NULL_BYTE Status packet START_BYTE Current flag Thermal flag RPM MSB RPM LSB NULL_BYTE NULL_BYTE NULL_BYTE

#define #define #define #define #define #define #define #define

ENCODER_PULSES_PER_ROTATION 1000 SPD 5 // Define pins BRK 6 DIR 7 THR 11 CUR 12 START_BYTE 0x0F NULL_BYTE 0xFF

byte power, timeout; // Default power status, recommended 0 boolean direction = false; // Default direction status boolean brake = true; // Default brake status, recommended true unsigned int rpm = 0; // int is 16 bit, assumed RPM will be less than 65536 unsigned int tempRPM = 0; void setup() { TCCR0B = TCCR0B & 0b11111000 | 0x01; // Sets TCCR0B (timer 0) to 62.5KHz Serial.begin(57600); // Start serial communications at 57600 baud pinMode(SPD, OUTPUT); // Define pin directions pinMode(BRK, OUTPUT); pinMode(DIR, OUTPUT); pinMode(THR, INPUT); pinMode(CUR, INPUT); attachInterrupt(0, rpmInterrupt, RISING); // encoder pin on interrupt 0 (pin 2) }

- 38 -

// Every 40ms the Arduino checks the serial buffer for data, if new data is // received the outputs are updated. The RPM is calculated, then the status // of the device sent to the host Could be made more precise using millis() // rather than delay() to ensure exactly 40ms void loop() { delay(2560); // 40ms adjusted for timer 0 change by multiplying by 64. if(getValues()) updateValues(); // Update the output if the values have been changed by serial if (timeout > 15) resetValues; // Kill motor and brake if data connection lost until connection re-established rpm = tempRPM * 1500 / ENCODER_PULSES_PER_ROTATION; tempRPM = 0; sendValues(); } // Send status of values to the computer void sendValues() { Serial.write(START_BYTE); Serial.write(digitalRead(CUR)); Serial.write(digitalRead(THR)); Serial.write((rpm>>8)&0xFF); // Send high byte of RPM Serial.write(rpm&0xFF); // Send low byte of RPM Serial.write(NULL_BYTE); // Reserved byte Serial.write(NULL_BYTE); // Reserved byte Serial.write(NULL_BYTE); // Reserved byte } // Checks RX buffer for data and if present decodes the packet byte getValues() { if(Serial.available() > 7) { byte counter = 0; // This segment syncronises the reader with the start of the packet to // ensure the data is read correctly. Failure to do this could result //in the wrong byte being interpreted, and as such the motor being //given more power than is desired. for (byte i = 0; i < Serial.available(); i++) { if(Serial.read() == START_BYTE) { power = Serial.read(); // Power brake = Serial.read(); // Brake direction = Serial.read(); // Direction Serial.read(); Serial.read(); Serial.read(); Serial.read(); // Purge null bytes timeout = 0; i = 255; } } return 1; } else { return 0; timeout++; } }

- 39 -

// Updates the outputs based on the global variable states void updateValues() { if(brake) { //digitalWrite(BRK, LOW); bitClear(PORTD, 6); // Optimise digitalWrite(BRK, LOW); analogWrite(SPD, power); } else { bitSet(PORTD, 6); // Optimise digitalWrite(BRK, HIGH); if(direction) bitSet(PORTD, 7); else bitClear(PORTD, 7); // Optimise digitalWrite(DIR, direction); analogWrite(SPD, power); } } // In warning situations, all values are reset to 0 void resetValues() { power = 0; brake = 0; direction = 0; updateValues(); } // Counts the number of pulses from the motor void rpmInterrupt() { tempRPM++; }

- 40 -