FPGA Controlled Laser Cutting Device

Final ReportProject: Dec03-07

Client:National Instruments

David GardnerChad Humberstone

Faculty Advisors:

Professor Mani MinaProfessor Diane Rover

Group Members:Joel SchneiderJeremy Booher

Adam PritzRaymond Baker

11/18/2003

1Frontal Materials

1.1Table of Contents

Frontal Materials.............................................................................................................................i

Table of Contents..................................................................................................................iList of Figures......................................................................................................................iiList of Tables......................................................................................................................iiiList of Symbols...................................................................................................................ivList of Definitions................................................................................................................v

Introductory Materials...................................................................................................................1

Executive Summary.............................................................................................................1Acknowledgement...............................................................................................................1Problem Statement...............................................................................................................1Operating Environment.......................................................................................................2Intended User(s) and Intended Use(s).................................................................................2Assumptions and Limitations..............................................................................................3Expected End Product..........................................................................................................3

Project Approach and Design Results..........................................................................................4

End Product Functional Requirements................................................................................4Resultant Design Constraints...............................................................................................5Approaches Considered and One Used...............................................................................6Detailed Design...................................................................................................................7Implementation Process.....................................................................................................13End Product Testing..........................................................................................................14Project End Results............................................................................................................15

Resources and Schedules..............................................................................................................16

Resource Requirements.....................................................................................................16Schedules...........................................................................................................................19

Closure Materials..........................................................................................................................22

Project Evaluation..............................................................................................................22Commercialization.............................................................................................................22Recommendations for Additional Work............................................................................23Lessons Learned................................................................................................................23Risk and Management.......................................................................................................23Project Team Information..................................................................................................24Closing Summary..............................................................................................................24

i

Closing Summary..............................................................................................................25

1.2List of Figures

Figure 3.4.1……………………………………………………………………………….7Figure 3.4.2…………………………………………………………………………….....8Figure 3.4.3……………………………………………………………………………….9Figure 3.4.4…………………………………………………………………………...…10Figure 3.4.5……………………………………………………………………………...11Figure 3.4.6……………………………………………………………………………...12Figure 3.4.7……………………………………………………………………………...13

ii

1.3List of Tables

Table 4.1.1………………………………………………………………………………17Table 4.1.2………………………………………………………………………………17Table 4.1.3………………………………………………………………………………17Table 4.1.4………………………………………………………………………………18Table 4.1.5………………………………………………………………………………18Table 4.1.6………………………………………………………………………………18Table 4.2.1………………………………………………………………………………20Table 4.2.2………………………………………………………………………………21

iii

1.4List of Symbols

None

iv

1.5List of Definitions

FPGA - FPGA stands for field-programmable gate array. It is an ASIC that can reprogrammed after it is manufactured; a programmable logic device.

Servo Motor - Many applications place high demands on modern drive technology with regard to positioning accuracy, speed accuracy, torque stability, overload capability and dynamic performance. Servo drives are drive systems that show a dynamic and accurate response over a wide speed range and are also capable of coping with overload situations. In this case, the terms "servo drives" and "dynamic drive" mean one and the same thing. They always refer to AC permanent-field synchronous motors and their associated control systems.

Signaling - The use of signals for controlling communications

Triggering - A pulse or circuit that initiates the action of another component.

PXI - PXI is also known as Compact PCI. PXI is a modified PCI bus. It is a more rugged form-factor.

VHDL – VHDL is a specialized programming language used by engineers who design electronic hardware.  “HDL” stands for "Hardware Description Language".

VI – Virtual Instrument, these are the files that are created in LabVIEW FPGA and compiled to run on the PXI device. They are written in LabVIEW code.

v

vi

2Introductory Materials

2.1Executive Summary

A summary and overview of the project.

The goal of the project was to develop a controlled laser system that can effectively operate on a desired medium. The aim was to produce a modular application that is adaptable for multiple operations; anything from cutting plastic to performing laser eye surgery. To accomplish this modularity, the first step was to successfully control the laser’s position and movements on a 2-dimensional plane. This project made use of parallel I/O to control and monitor the motors and stages. To accomplish this multiple timed I/O problem, the National Instruments LabVIEW FPGA module was used. FPGA hardware gave the application greater control of the hardware level I/O measurements and timing. Using the LabVIEW FPGA software to develop the control logic was more productive than coding in VHDL, plus it provided a built-in user interface courtesy of LabVIEW. With this combination, the task of development was drastically simplified while still yielding an extremely precise application.

2.2      

AcknowledgementA word of thanks to our sponsoring client.

The client for this project is National Instruments. National Instruments contributed to the project by supplying the software and hardware that will be used.

2.3     

Problem StatementA statement that defines the problem to be solved.

General Problem Statement

A procedure must be controlled using the LabVIEW FPGA module. This procedure must not only simply control the motion of an object, but it must also get feedback from the object to control another aspect of the movement. The final product must be able to control all inputs and outputs accurately and without a lag between receiving feedback from the object and correcting the motion of the object. The motion of the object must be extremely precise at all times. The object to be controlled will be a laser, suitable for cutting materials. This means that the motion must be controlled accurately within the acceptable boundaries of the industry, and the intensity of the laser must be controlled at all times.

1

2.4Operating Environment

The environment our application is exposed to.

The program to control the laser will be on a computer indoors. The condition of the environment will be clean and no damage will be expected from dust or other particles. The laser itself will be in the same environment. The laser will not be dropped in use. There will be no extreme temperatures involved in the environment.

2.5Intended User(s) and Intended Use(s)

Definitions of the intended users and uses of the system.

Intended Users

The users of this program will be adults. Users could be either male or female. Users must be familiar and comfortable with computers. Users must have knowledge of the procedure to be done. If the laser will be used for eye surgery, the users must have a degree from a university and experience with laser eye surgery. If it is to be used for cutting something, the users must know where the object must be cut and how much power is needed to cut the object.

Intended Uses

This program is to be used to control a laser. Intended uses are any uses that could be accomplished by using a laser. These uses include laser eye surgery and cutting materials precisely. Intended uses do not include cutting large objects.

2.6Assumptions and Limitations

Lists the assumptions and limitations regarding the user and system.

AssumptionsThe assumptions made about the user and system.

The end product will operate in a clean operating environment. Only one user will operate the laser at a time There will be no unnecessary people in the vicinity of the laser while operating. The computer used will be capable of running LabVIEW.

2

The laser will cut material in a pattern specified by the user’s FPGA program.

LimitationsThe limitations of the system.

Time is limited. There are only two semesters to complete the project, the first being used solely for project planning.

The laser will need to be controlled, in three dimensions, precise enough for laser eye surgery applications.

The LabVIEW FPGA software is not capable of performing floating-point calculations.

The feedback of the laser must be able to read the intensity to an accuracy of 0.1mW/cm2.

The speed of the system will be limited to LabVIEW FPGA I/O time. The group could not implement a control algorithm for an arc due to the fact that

LV FPGA does not have trigonometric functions or derivatives. Also, the group did not have expertise in control problems.

2.7      

Expected End Product

The end product will be a program that controls a laser that moves in a predefined path on a two-dimensional coordinate system. The program will be written using the LabVIEW FPGA module. A user’s manual will also be written. Weekly project reports will be written and sent by email.

3

3

Project Approach and Results3.1

End-Product Functional RequirementsFunctional requirements define what the project should and should not do.

The LabVIEW FPGA laser controlling application should: Control all motor drives completely in hardware. The software that used to

control the stepper drives should be completely removed. The stepper drives should now be controlled using hardware signals directly from LabVIEW FPGA, bypassing the indexer that used to send these signals. This will showcase the hardware determinism of LabVIEW FPGA.

Use feedback signals from the stepper drives as inputs to LabVIEW FPGA. The stepper drives send out signals to indicate when each axis has reached each limit and when it is in the home position. LabVIEW FPGA should use these input signals in the algorithms to make control decisions based on the critical limit locations and the home position. This incorporation of input signals will showcase the parallelism of LabVIEW FPGA.

Implement a complex control algorithm. The scope of this project is not to develop or fully understand a control algorithm for coordination of the movement of 2 axes in a useful pattern. However, control algorithms are easily accessible and they can easily be transferred into LabVIEW FPGA code. The LabVIEW programming language’s main strength is that it enables engineers who are not experts in something to easily prototype and build systems because of the intuitive feel it gives its users. LabVIEW FPGA extends LabVIEW into such areas as control, so this application should show off the ability of LabVIEW FPGA to empower its users.

Become a great demo for National Instruments. The goal of this project is the incorporate the hardware determinism, parallelism and ease-of-use of LabVIEW FPGA into one solid package. The engineers working on this project are not experts on control, but they are passionate about solving hardware and software problems. This project should give National Instruments a great example of how LabVIEW FPGA can empower an engineer to succeed outside of his or her specialty area.

The LabVIEW FPGA laser controlling application should not: Use any existing application to control the stepper drives. The digital signals that

are sent directly to the stepper drives should originate from LabVIEW FPGA only.

4

3.2

Resultant Design ConstraintsThe design constraints for the project are a combination of the assumptions, limitations,

functional requirements and group members’ ideas.

The design constraints for this project are as follows: LabVIEW FPGA must generate the digital pulses to control the motor drives.

This will showcase the hardware determinism of LabVIEW FPGA and remove all previous applications that controlled these motor drives. The possibility of LabVIEW FPGA controlling these motors was established early in the project’s life to ensure that the project would be feasible.

Parallelism should be demonstrated by using feedback signals from the motors. Limit positions and home position can be determined from the motor’s output. LabVIEW FPGA must include these signals in its control loop in order to show that input signals can be analyzed while control is being performed.

The engineers on this project shall go beyond hardware and software to demonstrate a working control algorithm in LabVIEW FPGA. This will show off LabVIEW FPGA’s ease-of-use and give National Instruments a great demo.

The hardware and software needed for this project must be provided by National Instruments in a timely manner. There was some initial delay in the project because the group was waiting for many pieces of software. All software and hardware was delivered on time and it was free, so that ensured the project’s budget was not affected.

The group needed to find a 3-axis stage for the project with a stepper motor for each axis. Buying a new or used stage was not an option for the group due to budget constraints. The group managed to get the needed stage from a generous faculty advisor of the project. This ensured that the project stayed on track.

The group must take into consideration all of LabVIEW FPGA’s current limitations when coding the control algorithm. These current limitations include: no floating-point arithmetic, a limited subset of LabVIEW functions and an FPGA with a size of 1000 logic cells. The fact that the FPGA chip only has 1000 logic cells means that the VI’s, which compile into VHDL, must compile to use 1000 logic cells or less.

The group came to the consensus that it wanted to further show off LabVIEW FPGA’s capabilities by moving 2 or 3 axes of the stage simultaneously. In order to do this, the group wants to implement the control algorithm for a set of triangles that share the same origin. The challenge in the control problem is to get the laser to always return to the origin on the same path for every triangle.

5

3.3

Approaches Considered and One UsedThe purpose of this section is to discuss all the approaches considered in solving the

problem and detail the approach used.

In the early stages of the project, it was mandated that this project use LabVIEW FPGA in order to control the motion of a laser, so the approaches that were considered in this project were how to achieve this motion with LabVIEW FPGA.

The first approach considered involved using previously existing National Instruments drivers to move a 3-axis stage. The laser was going to be moved in a manner to cut a surface. One example of this cutting could be an eye in laser-eye surgery. LabVIEW FPGA was going to be used to take parallel measurements and control the motion and laser accordingly. These measurements include temperature, pressure and intensity of laser on the cutting surface. The advantages of this approach include that it would showcase the parallelism of LabVIEW FPGA and use limited control from LabVIEW FPGA. The disadvantages are that the stages would not be controlled by LabVIEW FPGA and National Instruments wanted the group to do just that.

The second approach considered was using raw digital signals from LabVIEW FPGA to directly control the stepper motors on the stage. This approach would also take parallel readings from limit signals and incorporate those into the control algorithm. The advantages of this approach are that this is exactly what National Instruments wants out of the group and it does the best job of showcasing the hardware determinism, parallelism and ease-of-use of LabVIEW FPGA. The disadvantages of this approach are that it requires the group to learn about control algorithms.

The second approach was selected, because this is exactly what National Instruments wants out of the group and it does the best job of showcasing the hardware determinism, parallelism and ease-of-use of LabVIEW FPGA.

6

3.4

Detailed DesignThe purpose of this section is to explain the entire design to the audience.

Figure 3.4.1 - Block diagram of connectivity of modules.

The laptop contains LabVIEW FPGA software.

The PXI chassis contains the LabVIEW Real-time operating system and houses the PXI-7831 card.

The PXI-7831 card contains the FPGA chip and all of the IO resources for LabVIEW FPGA.

The signal connector block allows for direct access to all of the IO resources on the 7831R card.

The motor drive takes inputs from LabVIEW FPGA and sends appropriate signals to control the stepper motor.

The stepper motor receives digital signals from the motor drive and moves one axis of the stage.

The limit circuit takes output from the stepper motor and sends appropriate signals back to 7831R card.

Laptop PXI Chassis

7831R(FPGACard)

Stepper Motor

MotorDrive

Signal Connector

Block

Ethernet PXI Bus

Shielded connector cable

Jumper Wires Factory Cable

LimitCircuit

Closed Control Loop Factory Cable

JumperWires

7

Figue 3.4.2 - Complete hardware setup for one axis (more details below)

Above is a detailed picture of the project setup. A laptop connects to white PXI chassis over Ethernet. This is how VI’s that are compiled into VHDL are downloaded to the FPGA chip on the 7831R (reconfigurable FPGA) card. The 7831R card in the PXI chassis sends and receives signals to and from the motor drives. The motor drives send signals to the stepper motors on each axis of the stage.

The core of the project is LabVIEW FPGA. It is a programming language that is installed on the laptop. The control algorithm is written in LabVIEW FPGA, compiled and then downloaded to the FPGA chip on the PXI-7831 reconfigurable card. This VI runs in hardware on the FPGA. It has access to 96 DIO ports, 8 analog inputs and 8 analog outputs.

8

Figure 3.4.3 - PXI Chassis containing PXI 7831 reconfigurable FPGA card

The laptop is where LabVIEW FPGA code is compiled into VHDL and then into a bit stream. The bit stream is then downloaded to the FPGA chip over Ethernet. Then the VI can run continuously on the FPGA chip to control the motor drives.

9

Figure 3.4.4 - Signal connector box for PXI 7831R card.

The signal connector box is where all of the IO resources are accessed. The digital outputs are used as inputs to the motor drives. The motor drive is how the raw LabVIEW FPGA signals are sent to the stepper motors to make them move. The interface to the motor drives is a STEP+, STEP-, DIRECTION+ and DIRECTION- signal. STEP+ needs a digital pulse of 10us. to move one step. STEP- needs a reference GND signal at all times. DIRECTION+ needs a digital “1” to move clockwise and a digital “0” to move counterclockwise. DIRECTION- needs a reference GND signal at all times. Taking these considerations into account, the group implemented a control algorithm in LabVIEW FPGA to showcase parallelism of movement of 2 axes at the same time.

10

Figure 3.4.5 - 25-pin wiring harness connects the motor drive to the IO resources from LabVIEW FPGA.

The interface to the motor drive is explained above. The wiring harness in Figure 5 is the sturdy piece of hardware that connects the digital IO signals to the digital interface on the motor drive. The motor drive then sends out the digital signals to the stepper motor for the corresponding axis.

11

Figure 3.4.6 - The 3-axis stage for the motion of the laser.

The 3-axis stage is the critical piece of hardware that allows for the motion of the laser. It consists of 3 axes, each with its own stepper motor. Each motor requires signals from one motor drive. The current setup shows only the use of one motor drive for simplicity purposes. The final control algorithm incorporates the simultaneous motion of 2 axes in the shape of a triangle. All triangles return to the origin on the same path.

12

Figure 3.4.7 - Circuit that converts analog voltages from limit switches to digital signals.

The group read in these digital signals using this circuit to incorporate limit signals into the control algorithm. If LabVIEW FPGA received a digital “1” from any limit indicator of a stepper motor, the code immediately stopped motion past the limit of that motor.

The development of this circuit and the use of the limit signals in the control algorithm is currently in progress. When this is finished a complete control loop will be implemented in the algorithm.

The final control algorithm met every expectation of the group and was a success.

Project parts with cost:LabVIEW FPGA module: $1,995 (donated to group)LabVIEW 7 Express software: $3,495 (donated to group)PXI chassis: $5,190 (donated to group)PXI-7831R card: $2,495 (donated to group)Signal connector blocks (2): $5903-axis stage (estimated): $1,000 (donated to group)Total project cost: $11,615

3.5Implementation Process

The following consists of the details of the implementation process.

13

Upon receiving the motors, they were first tested with their own software and indexer. This was to ensure that the group had a working set of motors. The computer connected to the indexer was powered up and the software was started. The motors were initialized with the standard procedure, described to the group by Ed Jackson. The motors worked with 10-microsecond pulses. All three motors were operated using the software and brought to their limits to test the limit switches.

The motors worked successfully with the software they came with. It was found that the stages had 400 steps per revolution, 5 revolutions per inch of movement, and a full range of motion of 18 inches.

For easier access, the motors and stages were moved to the senior design lab. This ensured that the group members would have access to the motors any time the building was open.

The pin assignments for the motor drives were determined by looking up the manual online. A diagram with the pins was found, and wires were run directly from the drive to the FPGA module. This worked inefficiently. A group member had to hold the wires in during operation. It was necessary to construct connectors to connect the motor drives to the FPGA module. Three 25-pin D-type connectors were constructed by the group for use in the project. They were connected to the drives, eliminating the need for a person to hold the wires.

A program was written to move the stages. Upon successful movement of the stages, the program was changed to attempt to detect the midpoint of the stage. Examination of the limit switch operation showed that the midpoint switch did not function as a detector, but was only useful in a specific part of the packaged software.

To test the limit switches of the motors, a program was written to move the stages by only 10 steps at a time and stop upon detection of a limit. The limit detection circuit for the indexer was found in the manual. The group built a replica of the internal circuit to use in limit detection.

Code was added to the programs to continuously track the position of the stages with a counter. This would ensure that the exact position of the stages would be known at all times.

New programs are being written to move the stages in patterns for demonstrations.

3.6End-Product Testing

The following consists of the details of the end-product testing.

The testing of the design took place on the primary PXI chassis. This chassis was set up at the residence of Adam Pritz for use by all members of the group. The primary PXI chassis housed the FPGA module. All the necessary software for the application ran on the PXI computer.

All aspects of the group’s control and communication software were tested. This includes communication algorithms between FPGA and the motor drives,

14

control algorithms implemented on the FPGA and the limit signals sent by the motors.

The limit switches of the motors were tested to determine their exact signals with the group’s apparatus. A detection algorithm was inserted into the programs to protect the motors.

Patterns are written into programs. A pointer is attached to the stages, and when the stages move the pointer’s movement is clearly visible, showing that the FPGA program is working properly.

3.7Project End Results

The following are the details of the project’s end results.

Programs have been written to control and track the movement of three motors. The programs work through LabVIEW, specifically the LabVIEW FPGA module. The programs utilize the limit switches of the motors to ensure that the motors are not damaged.

15

4Resources and Schedules

4.1Resource Requirements

The group had a planning session where time, talents, and resources were discussed and allotted. Everyone in the group will take an active role in each task of the project, but to differing degrees. The original estimates for personnel resource requirements are reflected in Table 4.1.1, which proceeds. Adam Pritz interned at NI. He had many contacts within the company. Therefore, he was responsible for contacting employees at NI about products. He also contributed to the documentation of the project, using his knowledge of LabVIEW FPGA. Joel Schneider has also interned at NI and had many contacts within the company. Because of this, he took the lead role in project documentation. He will also aid in contacting employees at NI with any questions or concerns. Jeremy Booher took the lead role in getting the hardware working. Raymond Baker worked closely alongside the rest of the group in every facet of the project. The personnel resource requirements have been totaled to reflect the time spent on the project, and the actual totals are shown in Table 4.1.2.

The software for the project was donated by National Instruments. This included the LabVIEW operating software and the LabVIEW FPGA software. The motors, drives and stages were donated by one of the faculty advisors, Mani Mina. The group assumed the responsibility for the costs of the project poster, laser and wires to connect the motors to the FPGA hardware. The original individual cost estimates of all hardware, software and other tangible necessities are included in Table 4.1.3, which proceeds. Table 4.1.3 also contains time estimates for preparing and ordering each product. The actual material costs are shown in Table 4.1.4. The poster materials cost more than anticipated.

For the purposes of completeness, two totals for resource requirements are presented. The first total is the actual cost of the project. It ignores the cost of student labor, because in this project the labor was donated. The second total includes the equivalent cost of student labor based on the hours worked. In a situation where labor was paid, this is what the project would have cost. Table 4.1.5, which proceeds, clearly labels all excessive costs for parts and materials. The original estimates for the project poster, laser and plastic pieces for cutting have been included there. When the project objectives changed, the material resources changed. Table 4.1.6 shows the actual project costs.

16

Estimated Resource Requirements

Table 4.1.1 Estimated Personnel Effort Requirements - personal time contribution estimates by task.

Personnel Name Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 TotalsAdam Pritz 3 3 55 22 22 8 8 26 147

Joel Schneider 4 1 47 25 20 10 8 25 140Raymond Baker 2 1 48 23 22 7 8 20 131Jeremy Booher 4 1 55 23 19 9 8 22 141

Totals 13 6 205 93 83 34 32 93 559

Table 4.1.2 Actual Personnel Effort Requirements - personal time contribution estimates by task.

Personnel Name Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 TotalsAdam Pritz 3 3 45 19 18 6 8 22 124

Joel Schneider 4 1 35 20 16 10 6 23 115Raymond Baker 2 1 40 18 22 7 8 18 116Jeremy Booher 4 1 42 23 19 9 8 22 128

Totals 13 6 162 80 75 32 30 85 483

Table 4.1.3 Other Required Resources – original estimates of time and cost requirements for all project necessities.Item Team Hours Other Hours Cost

Project Poster 10 0 $50Cutting Laser 8 2 $100

Plastic 6 2 $40LabVIEW FPGA 0 1 DONATED

LabVIEW 0 1 DONATEDNI PXI-1000B 0 1 DONATEDNI PXI-7831R 0 1 DONATEDNI PXI-8176 0 1 DONATED

NI Motion Solution 0 1 DONATEDTotals 24 10 $190

Table 4.1.4 Other Required Resources – actual time and cost requirements for all project necessities.

17

Item Team Hours Other Hours CostProject Poster 18 0 $75Laser Pointer 8 2 $15

Wires and Connectors 6 2 $30LabVIEW FPGA 0 1 DONATED

LabVIEW 0 1 DONATEDNI PXI-1000B 0 1 DONATEDNI PXI-7831R 0 1 DONATEDNI PXI-8176 0 1 DONATED

Motors and Drives 0 1 DONATEDTotals 32 10 $120

Table 4.1.5 Estimated Project Costs - prices for project necessities funded by group.Item Without Labor With Labor

Parts/MaterialsPoster $50 $50Laser $100 $100Plastic $40 $40

Subtotal $190 $190Labor at $10.50 per

hourAdam Pritz $1291.50

Joel Schneider $1323Raymond Baker $1260Jeremy Booher $1281

Subtotal $5155.50Total $190 $5345.50

Table 4.1.6 Actual Project Costs - prices for project necessities funded by group.Item Without Labor With Labor

Parts/MaterialsPoster $75 $75Laser $15 $15

Wires and Connectors $30 $30Subtotal $120 $120

Labor at $10.50 per hour

Adam Pritz $1543.50Joel Schneider $1470

Raymond Baker $1375.50Jeremy Booher $1480.50

Subtotal $5869.50Total $120 $5989.50

4.2Schedules

18

In this section are two Gantt charts. The first Gantt chart spans Figure 4.2.1. This is the project schedule Gantt chart. It illustrates the tasks and associated subtasks versus the proposed project calendar. It includes information regarding the time of completion for finished tasks. The second Gantt chart spans Figure 4.2.2. This is the project deliver-ables Gantt chart. It illustrates when the project deliverables will be delivered. It also in-cludes the completion times for finished tasks.

The project schedule Gantt chart is complete with eight tasks and associated subtasks. It contains the timeline that was followed by the project during the two semesters when the project was active. Time away from school, including spring break, summer break and thanksgiving break, was accounted for in the calculations. Figure 4.2.1 contains the project schedule Gantt chart.

The project has two deliverables. The first of these was the LabVIEW program, which controls the laser. Work began at the onset of the second semester and will conclude just after Thanksgiving Break. The other deliverables are weekly progress reports that have been sent out describing the group’s activities and milestones. A final evaluation of the progress will be presented in December 2003. Figure 4.2.2 contains the project deliverables Gantt chart.

19

20

21

5Closure Materials

Final materials presenting evaluations and going beyond the scope of this project

5.1Project Evaluation

Evaluation of the project by individual milestones and overall

Milestone 1: Finding appropriate control algorithm Fully Met

Milestone 2: Implement control algorithm in LV FPGA Software Fully Met

Milestone 3: Control motors using LabVIEW FPGA hardware Fully Met

Milestone 4: Deterministically control motion device Fully Met

Milestone 5: Adding other control variables (optional) Partially Met

The individual milestone evaluations are combined into a total project evaluation by taking the main four milestones (1-4) and judging how well they have been met. Since all four have been met the total project is a success.

5.2Commercialization

Feasibility of commercializing the product created by project

Is commercialization possible for this project?Yes, if the application was more complex and robust.1. What might be the cost to produce the product?

$70002. What might be the street selling price of the product?

$10,0003. What might be the potential market for the product?

Precise controlled motion applications that have the necessity for parallel I/O. A good example would be a very precise application where tight determinism is needed. This demo showcases the capabilities of LabVIEW FPGA. This project’s main purpose was as a demonstration for this pioneer product.

22

5.3Recommendations for Additional Work

Possible further projects that could be carried on from this project

● An enhanced prototype version of the productCreate an application that requires a more precise design.

More accurate movement could be achieved with a more precise control algorithm or possibly other modifications that have not been researched

Create an application that requires more stringent timing.The movement could be produced more quickly by optimizing the control algorithm.

● A redesign of the productMake a non-FPGA based LabVIEW application without the determinism and parallel I/O of the FPGA. This would hit a different segment of the market and would cost less to create. This could also provide a benchmark to test FPGA setup against.

5.4Lessons Learned

Lessons learned over the course of the project and working with team

1. What went wellGroup work and problem solving

2. What did not go wellDelay in receiving SoftwareInability to acquire hardware in a timely manner

3. Technical knowledge gainedProgramming using FPGA hardware capabilitiesReal Time programming

4. Non-technical knowledge gainedProject management Overcoming shortcomings

5. What would be done differently if the project was to be done againObtain hardware and software during the first month

5.5Risk and Risk Management

Risks that were predicted and encountered and how they were handled

1. The anticipated potential risks and planned management thereofIt was anticipated that there would be a risk of the hardware and software not operating as assumed. It was anticipated that there would be a risk of lack of money and time to create a robust application.2. The anticipated risks encountered and the success in management thereof

23

It was not feasible to obtain a laser capable of cutting or engraving a surface, so the design was adapted to create a trace.3. The unanticipated risks encountered and the attempts to manage that were usedThe software was not received within the timeframe that was assumed, so other parts of the project were pursued such as finding a suitable control algorithm.It was assumed that NI would provide motion hardware but this was not true, so Professor Mina offered the use of motors and stages ISU had.4. The resultant risk management changes that were made as a result of encountering the unanticipated risksIt has been learned to assume all risks as possible. It is best to always have a second option for when the first one fails.

5.6Project Team Information

Contact information for all parties involved with the project

Client Information:

National Instruments CorporationContact: Chad Humberstone11500 N Mopac Expwy

Austin, TX 78759-3504Corporate Phone: (512) 683-0100 Contact Phone: (512) 683-5863Fax: (512) 683-8411E-mail: Chad.humberstone@ni.com

Faculty Advisor Information:

Diane Rover3227 Coover Hall Dept. of Electrical and Computer EngineeringIowa State UniversityAmes, IA 50011Phone: (515) 294-7454Fax: (515) 294-8432E-mail: drover@iastate.edu

Mani Mina341 Durham Dept. of Electrical and Computer EngineeringIowa State UniversityAmes, IA 50011Phone: (515) 294-3918

24

Fax: (515) 294-1152E-mail: mmina@ee.iastate.edu

Team members:Adam Pritz Team Leader Computer Engineering2144 Sunset Dr.Ames IA, 50014Phone: (563) 650-3069E-mail: apritz@iastate.edu

Joel SchneiderCommunications CoordinatorComputer Engineering2144 Sunset Dr.Ames IA, 50014Phone: (563) 650-5022E-mail: schneidr@iastate.edu

Jeremy BooherElectrical Engineering4733 Toronto St. #210Ames IA, 50014Phone: (515) 292-7751E-mail: jbooher@iastate.edu

Raymond (Eric) BakerComputer Engineering1320 Gateway Hills Park Dr. #509Ames IA, 50014Phone: (515) 708-0082E-mail: ebaker@iastate.edu

5.7Closing Summary

Summary of the problem, approach and solution of project

The problem that this project addressed was to control a motion device using LabVIEW FPGA. The final product is intended to provide a useful demonstration application for the client. The motion device that was controlled was a three dimensional stage apparatus. Two axes of motion were implemented. This was done using National Instrument’s PXI Controller with LabVIEW FPGA hardware and software to control Parker stepper motors and stages in the two dimensional plane. The digital output from the FPGA controls the motors via the motor drives and the analog inputs gather feedback from the FPGA.

25