07-06-2005 10:15 AM
07-06-2005 08:53 PM
There is a way. You have to use more than one plot on the graph. Check out the help window for an XY graph and it will show you all the data structures that one of those graphs will take. The one you are looking for a an array of clusters where each element cluster is made up of arrays of X and Y points.
After each pass through your code, start a new plot.
Mike...
07-06-2005 11:41 PM
Everything (almost) is possible in LabVIEW. However, I don't quite understand the question. Could you attah a smaple program or a picture of what you want to do?
Could you explain in a few more words what "high mass" and "low mass" is. Is one of them x and the other y, are they two different plots with a x-variable that is not mentioned, e.g. time? Do you want to start over at [0,0]?
If you don't want to switch to a new plot, you could insert an extra element containing NaN as one of the values. This will create a gap, and the line from the last point to [0,0] will no longer show.
07-08-2005 09:06 AM
07-08-2005 09:37 PM
Nick;
Here's your code tweaked a bit. I don't have your hardware so I threw a case structure around your real code to create a "test" mode that displays a sine wave. In any case, each time you run the VI it generates a new sinewave 10 degrees offset from the last one. Hope this is what you meant. Also note the way I changed how the loop is stopping. Using the "Stop Sign" is Very Bad as it halts everything immediately--it does not shutdown gracefully.
Mike...
07-09-2005 12:18 PM
OK, here are some confusing parts in your code. Mike already mentione the STOP node. this is not how to stop a FOR loop. I a typical program, the program needs to continue with the results of the FOR loop wired to succesive code, that would not receive anything.
A FOR loop is only appropriate if you know beforehand how many times it should iterate. If you want to terminate according to some condition calculated during the execution of the loop, only a WHILE loop is appropriate.
Your code sends mixed messages to the loop. You wire a 10000 to the N, meaning that you intend to run it 10000 times. Yet you seems to always terminate it prematurely. You seem to try to set something to zero at iteration 9999, a point wiich is probably never reached.
Wouldn't it also be more reasonable to drop the three "divide by 50" and the "multiply by 50" and add a simgle "divide by 50" in the wire leading to your "simulate signal"?
It also is not very efficient to save a single point to disk at every iteration. You might want to autoindex it out of the loop and store the full array in one swoop at the end of the FOR loop (See, that's why the STOP node is a bad idea, you would not be able to do that! ;)).
My suggestion: calculate the linear ramp outside the loop and add a NaN at the end. Autoindex it to the loop so the loop runs once for each point. If NaN is encountered, skip the daq but add a NaN to the graph to create a gap. (Calculating the ramp in realtime, reading all controls, and testing for termination condition at every loop iteration seems like an unecessary complication. It can also cause unpredicatble behavior of one of the controls is changed during the run. Note that you only store the Y part of the data, so a variable x increment during the loop cannot be reconstructed.)
I made a simple example, stripping out all the DAQ parts and simulating some random data. I added a second loop so it repeats the experiment 10 times with random slopes for demonstration purposes. As you can see, the NaN suppresses the flyback trace. Just add your DAQ code back. Modify as needed.
07-09-2005 04:35 PM
Nick;
This situation is a good example of how there are always multiple ways to accomplish the same thing in LV. When choosing between approaches you need to consider the trade-off.
For example, with altenbach's way of creating multiple plots the code is very simple. You simply insert a single element with the value NaN into the array at the end of every run. The disadvantage is that all the "plots" will have the same stype attributes (line style, point type, color etc.) because as far as LV is concerned they are a single plot. In addition at the end if you want to work with the plots seperately, you'll need to parse one long dataset to get to them.
My approach on the other had has more complex code that will take you a while to understand. However, the benefit is that each plot is really a seperate plot so they can have seperate plot attributes (which might be very important if you are comparing data from different runs). I can image that if you have several plots on the screen keeping track of which white line means what could be a problem. Likewise, at the end of you want to work with them seperately you can without any added manipulation.
07-11-2005 09:11 AM
07-11-2005 10:26 AM
@Nick44448 wrote:
Does it really matter that we stop it with a stop node in a for loop? I don't understand why that is so bad. If you could clarify that, it would be deeply appreciated.
Yes, it is bad! It is like saying: "Do we really need to land the airplane every time on a runway? Wouldn't it be easier if we we all just jump out with a parachute at the destination and crash the plane?" 🙂
In a typical finished program, the code never stops until you exit the program. It runs when opened waiting for input. You would add another loop around such that you can make multiple runs as needed. When was the last time you had to start MS word or internet explorer manually after opening the panel? 😉
One of the great strengths of LabVIEW is the fact that you can have multiple loops in a single program for parallel tasks. Your method cannot stop only one single loop, but would kill everything, every time!
Also (as I said), for efficiency you should save the entire graph at once instead of writing a single point to disk at every iteration. Open the front panel of your "write LabVIEW measurement file" node. This is a tremendous amount of code that you execute at every iteration! If you would rewrite your code to autoindex y at the loop boundary and save all at once after the loop ends, stopping the loop with a "stop" node would immediately stop the entire VI and the "write" would not complete. However if you stop the loop correctly (replace it with a while loop and use a terminate condition), everything will finish nicely.
Don't use a FOR loop in your scenario! A WHILE loop works the same except that you don't need to know beforehand how many times it iterates and you can terminate the loop on any computed condition you desire.
I am sure you are aware of the online help. It is worth reading! In this case, the recommendations are:
In general, avoid using this function when you have a built-in termination protocol in a VI. For example, I/O operations should be performed in While Loops so that the VI can terminate the loop on an I/O error. Also, consider using a front panel stop button Boolean control to terminate the loop at the request of the user rather than using this function.
07-11-2005 10:34 AM
Don't do it that way because it is a VERY bad habit to get into. The proper way to end a FOR loop is for it to have executed all its iterations. Like was stated in another response, if you might need to quit sooner you don't have an application where a FOR loop is even appropriate. You need to be using a WHILE loop as in the code I posted.
Think about it this way, there are always things that need to be done to clean up after the main body of a program executes--like closing files, releasing references to things like DAQ devices, deinitializing instruments, etc. In the case of your program you don't see all that cleanup because the DAQ VIs take care of it for you behind the scenes--or at least they do if you don't abort them early.
You should never use the "Stop Sign" to terminate your code--ever. I can honestly say that in 20 years of working with LV I have never seen a legitimate use of that function. Trust me on this one, if you haven't been burned by it yet, it's only a matter of time.
IMHO, this function is one of the few things that NI should pull out of LV and say to heck with backwards compatability.
Mike...