ME4234 Assignment 1 - sdgsd PDF

Preview

Summary

sdgsd...

Description

ME 4234: Dynamic Systems and Control Lab HW 1: LabVIEW Programming Basics and Intro to Simulation LabVIEW Introduction Problem 1.1: Obtain a copy of latest LabVIEW Development Environment for your personal use. Problem 1.2: View the video “Writing Your First LabView Program.” Problem 1.3: Complete the “LabView Environment” quiz. You must score at least 40/50 to continue the assignment. You may retake the quiz until you reach this score. Problem 1.4: View the “LabView Programming Tutorial” video. This shows how to create a LabVIEW program to convert Celsius to Fahrenheit. Problem 1.5: Write a LabView program to convert Fahrenheit to Celsius. Save your VI as Assignment1_Problem5. Problem 1.6: Complete the "FtoC" quiz. You must score 20/20 in order to continue the Assignment. You may retake the quiz until you reach this score. After successfully completing the quiz, upload your program from Problem 1.5 on Blackboard. LabVIEW Loops and Simulation Now that you have some experience programming in LabVIEW we will see how LabVIEW can be used to create real-time simulations. That is, we will use LabVIEW to make our computers imitate and predict the behavior of physical systems. Because LabVIEW is interactive, we can use these simulations to explore how a physical system will respond to various inputs. We can make the simulation run in real time, that is, at exactly the speed the real system will run at, or we can speed it up or slow it down as we wish. These kinds of interactive simulations are different than the way you may be used to doing scientific computing, in which the program just runs until it gets an answer. In that case we usually want the program to finish as quickly as possible. Throughout the course we’ll use interactive simulations in the assignments to understand the upcoming lab, so that by the time we get to the actual hardware the underlying ideas are already familiar. In this first assignment though we will just get some experience with the basics.

Fig. 1. TimerSM VI state actions and transitions. Most programs in the course will involve time. For this assignment we have uploaded a VI that implements a timer. The VI is written using a LabVIEW programming pattern called a state machine. State machines are a very flexible and scalable way to write LabVIEW programs. We are going to use them throughout the course. Figure 1 shows the state actions for this VI. Don’t worry if it isn’t clear yet; for now we will focus on individual components of the program and not the overall structure. (The programming pattern that LabVIEW programmers call a state machine differs somewhat from the more widely used notion. We will follow the NI custom.)

Fig. 2. TimerSM front panel. Figure 2 shows the TimerSM front panel. The VI is started with the run arrow, and stopped with the Stop button. Reset sets the simulation time back to zero, and re-reads the loop delay and simulation time step values, which the user may change while the VI is running.

Fig. 3. TimerSM “take time step” state. The loop delay and simulation time step represent two different kinds of time. The time displayed on the front panel is the simulation time, which is controlled by the simulation time step, Ts. Physical time is the amount of time the program actually takes to run, and is controlled by the loop delay input, T d. Simulation time is often not the same as physical time. For example, if we are modeling vibrations of a nanoresonator, we may want each tick of our simulation clock to be on the order of one-millionth of a second. On the other hand, if we are modeling, for example, astronomical motions, each simulation clock tick might represent months or years. The simulation time step input is exactly the simulation time corresponding to one clock tick. In these examples, we certainly don’t want the actual time required for the program to run to be the same as the simulation time. For the nanoresonator that wouldn’t even be possible, since the resonator vibrates faster than LabVIEW can run. But even if it were possible, displaying the data that fast would make it unreadable by the user. So in this case we want physical time to pass much more quickly than the simulation time. On the other hand, if we are simulating something very slow, then it is silly to wait ten years for the program to complete, when the computer is capable of solving the entire problem in a few seconds. In this case we want physical time to pass much more slowly than simulation time. The VI is built on a structure called a WHILE loop that just repeats the commands inside of it over and over until the user presses the Stop button. In a LabVIEW state machine each iteration of the WHILE loop corresponds to a state action and state transition. In this VI one state action increments the simulation time, while another implements the physical time step. Figure 3 shows the part of the VI that increments the simulation time. The WHILE loop is the outermost gray box, with the letter “i” in the lower left corner and a stop sign icon in the lower right. All this part of the program does is add one to the iteration counter. Figure 4 shows the part of the VI that

implements the physical time. The Wait block, which looks like a wristwatch, waits the specified amount of time before completing. The WHILE loop cannot complete until the Wait block executes.

Fig. 4. TimerSM “delay” state action. Try answering the following questions. You don’t have to hand them in, but they may be on the lab quiz, or the instructors may ask you about them in the lab. Problem 2.1: Use TimerSM.vi for Problem 2.1. These do not have to be handed in. a) Run the VI as shown in Fig. 3, with Loop Delay set to 100 ms and Physical Time Step set to 100 ms. Does the elapsed time displayed by the VI run slower, faster, or about the same as physical time? b) Change Loop Delay to 10 ms. Does the elapsed time displayed by the VI run slower, faster, or about the same as physical time? c) Change Loop Delay to 1000 ms. Does the elapsed time displayed by the VI run slower, faster, or about the same as physical time? Now do the following programming exercise, and upload the modified VI: Problem 2.2: Read about the Quotient & Remainder block in the LabVIEW reference of your choice, and modify the VI to add a display for hours. Upload the modified VI to Blackboard.

Circuit Simulation Now lets use this basic programming pattern to simulate a physical system. Figure 5 shows a voltage divider circuit.

Fig. 5. Voltage divider circuit. The total resistance is R 1 + R2, and so Ohm’s law gives the current in the loop as ‫ܫ‬ൌ

ܸௌ ܴ ଵ ൅ ܴଶ

Then the voltage drop across R 1 is ܸ஻஼ ൌ ܴଵ‫ ܫ‬ൌ

ܴଵ ܸ ܴଵ ൅ ܴଶ ௌ

The notion of “time” in a simulation like the timer VI is different than time in the physical world in a very important way. In everyday experience, time is a continuous flow. But in the VI, time elapses in steps of T s and no events can occur between iterations of the WHILE loop. So the variables of the physical system are functions of time, say V S (t) or I(t), but the variables of the simulation are functions of the iteration count i. Since the simulation time is t = iT s, we can write VS(iT s) or I(iTs). More compactly, we write V S [i] or I[i], where the dependence on the simulation time step is understood. In terms of the input V S[i], ‫ܫ‬ሾ݅ሿ ൌ ܸ஻஼ሾ݅ሿ ൌ

ܸௌ ሾ݅ሿ ܴଵ ൅ ܴଶ

ܴଵ ܸ ሾ݅ሿ ܴ ଵ ൅ ܴଶ ௌ

Let’s modify the timer VI to simulate the changes in current I and voltage V BC as the source voltage V S varies. Because the state machine structure clearly organizes the tasks that the program performs, it is easy to add a couple more steps, as in Fig. 6.

Fig. 6. VoltageDividerSM VI state actions and transitions. Figure 7 shows the front panel of a VI, VoltageDividerSM.vi, that implements these equations. We’ve added a few other features, like tabs, that make it easier to use more complicated VIs. Again, you don’t have to know how to do this yet, just to be able to use it. The input voltage is changed with a knob, and outputs are displayed on a LabVIEW chart. A chart lets you watch your simulation while it is running. Soon we will also use graphs that plot a bunch of data all at once. Charts and graphs are very important in LabVIEW. Use context help, and/or read more about them in your LabVIEW references.

Fig. 7. VoltageDividerSM simulation with chart. The following problem does not have to be handed in, but you may be asked questions about it in the lab or on the lab quiz. Problem 2.3: Run VoltageDividerSM.vi and see how the output voltage changes as you vary the source voltage. Change the resistor values R1 and R2 and see how this affects the circuit. Try adding the current I to the chart. You may have already noticed room for improvement in these VIs. Here are some things that could be done a lot better:

1. The number of wires across the top of the block diagram goes up every time we add new functionality to the program. Pretty soon they will take over all the available space. Is there any way to organize them more sensibly? 2. The chart is good for keeping track of the outputs as we are running, but we may want a record of the entire experiment. Can we add graphs to this VI? 3. As written now, the only way to stop the simulation is to exit the program. Can we add a button to start and stop the simulation without exiting the program? Give some of these a try. Any other changes you think should be made? Try those too!

Now "Assignment 1 - Answer Script" should be available. Take it before you come to the lab....