LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Need a xy graph to referance back to 0 at the end of a run

I'm using Labview Express 7.0 and i'm running a xy graph with a low mass and high mass.  At the end of the run, i would like the graph to put a 0 on the graph after the designated high mass.  I've tryed a few things but all it does is connect the line from the beginning of the graph to the last point, i want the graph to start over with another point that is zero.  I'm not sure if there is any possible way of doing this, but if you think there is, give me some advice.
0 Kudos
Message 1 of 12
(3,042 Views)

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...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 12
(3,025 Views)

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.

 

0 Kudos
Message 3 of 12
(3,019 Views)
Here, I'll attach an example of my program to you, i want the graph to start over at 0 after it has reached the final mass.  I dont want it to make a line attaching the last point to zero on the graph though.  When it does this it makes a line straight across the bottom of the screen because zero is at the beginning of the screen.  I want the graph to start over at 0 again after the final mass.
0 Kudos
Message 4 of 12
(3,005 Views)

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...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 5 of 12
(2,987 Views)

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.

0 Kudos
Message 6 of 12
(2,981 Views)

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.

So consider the trade off and how you will be using the tool when choosing between implementations.
 
Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 7 of 12
(2,884 Views)
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.
0 Kudos
Message 8 of 12
(2,970 Views)


@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:


QUOTE from online help: If you need to abort execution of all VIs in a hierarchy from the block diagram, you can use this function, but you must use it with caution. Before you call this function with a TRUE input, be sure to complete all final tasks for the VI first, such as closing files, setting save values for devices being controlled, and so on. If you put this function in a subVI, you should make its behavior clear to other users of the VI because this function causes their VI hierarchies to abort execution.

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.


 

Message 9 of 12
(2,960 Views)

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...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 10 of 12
(2,871 Views)