Creating then saving an array

[bmunden]

Ok, I've created a while loop that's slowly becoming a state machine.  I eventually want this to self-orchestrate, but that's a later issue.  Right now, I need to create an table of signals, but I don't want to hang up the current iteration while LabVIEW waits for the user to enter in a filepath.

I was thinking of creating a graph/table, and then asking the user if/where they want to save the file.  Any thoughts?

[RavensFan]

I think you could certainly store your data in a table, graph, or even an array until the point of time the user enters an appropriate file path.  You may even want to make sure they have a file path entered before the acquisition loop begins.

I noticed you added an express VI called relay.  I had never seen that one before and it looks pretty interesting.  I don't think it will do what you want though.  Is this the structure you added for handling the yes or no of writing the data to the file.  If you have it set to true, then the signals will pass through to the write to file, however if it is set to false, it will just write out zeroes.  The data output won't be turned off, just zeroed out.  I think you would want the structure like I put into the VI in the message here.

Other tips:

In your case structure, you have a node in the middle on the right that is hollow.  That means it has unwired inputs.  At first I couldn't see it as I flipped through your case structure, it seemed as if wires were going into and out of the tunnel node in every case.  But as I looked closer, I discovered you had a tunnel overlapping a tunnel.  The ones on the inside were going to one tunnel, the wires on the outside were coming out of the other.  Use your cursor and drag a tunnel node down.  Flip through every case and you will see.  I highly recommend using the clean up wire shortcut often.  If you have wires that disappear behind other functions, or overlap in awkard ways, (like the signal wire going into the Formula 2 VI) right click on the wire and select Clean Up Wire.  It will go a long way in keeping your code clean and readable and preventing issues such as this.

While the Express VI's give a quick way to get started on code, you should try to avoid them where you can.  For example, your 5 formula Express VI's could be easily replaced with more basic labview functions.  What I have noticed is that your VI file size has already grown to about 800 KB, but you really haven't laid down that much code yet.  I think this is caused by the generous use of these Express VI's.

If you haven't attended the NI Labview Basics 1 and 2 courses yet, I would highly recommend them.  You can also search the forums for some references others have made to some online LV tutorials.

[bmunden]

Ravens Fan:

The Relay guy is just a shot in the dark.  There's a switch in the dialog that configures it to either put out 0's or no data when it's not enabled.  I've just been using Express VIs because they're simple and user-friendly.  I don't have the time I wish I had to learn lighter algorithms.  I would like to lighten things up, though, but getting the thing to work first is my priority.  The only thing I wouldn't be able to do on my own so far is the DAQ Assistant Analog input and Analog output.  The formulas and graph express guys are excessive.

I was hesitant to put that VI up--I hadn't had time to clean up wires.  It's a good habit, albeit an indication of a lapse in end-user convience development.  The wires should repel each other and automatically be clean, like in some of the newer open-source Pspice simulators.

Anyway, I really appreciate your advice and time.  Hopefully I can have a working demo by the end of the week-- independent research project design review : ).  Thank goodness I'm not a EE, I'd be dangerous.

-Brandon

[RavensFan]

---

bmunden wrote:
Ravens Fan:

The Relay guy is just a shot in the dark.  There's a switch in the dialog that configures it to either put out 0's or no data when it's not enabled.  I've just been using Express VIs because they're simple and user-friendly.  I don't have the time I wish I had to learn lighter algorithms.  I would like to lighten things up, though, but getting the thing to work first is my priority.  The only thing I wouldn't be able to do on my own so far is the DAQ Assistant Analog input and Analog output.  The formulas and graph express guys are excessive.

I apologize for my earlier comment.  I now see the nuance in the dialog box for the setting where it outputs empty data if you want when set to false as opposed to a series of zeroes which was the way I originally read it.  I'd still recommend the case structure, but the Express VI could work as well.

 
I was hesitant to put that VI up--I hadn't had time to clean up wires.  It's a good habit, albeit an indication of a lapse in end-user convience development.  The wires should repel each other and automatically be clean, like in some of the newer open-source Pspice simulators.

I understand.  I just want to suggest ways to keep things clean as you go along.  Something like the mismatched wires can cause you major headaches in debugging later on.

Anyway, I really appreciate your advice and time.  Hopefully I can have a working demo by the end of the week-- independent research project design review : ).  Thank goodness I'm not a EE, I'd be dangerous.

You're welcome.  It seems like an interesting project you are working on.

-Bill

-Brandon

---

[bmunden]

Here's what I'm eventually shooting for.  If the pseudocode is too hard to read, don't worry about it.  This was just a good way for me to collect my thoughts.  Also, ignore solenoid 5.






{Default Digital Relay States}
Solenoid 1 = CLOSED
Solenoid 2 = CLOSED
Solenoid 3 = CLOSED
Solenoid 4 = CLOSED
Solenoid 5 = OPEN

Pump 1 = OFF
Pump 2 = OFF

{Defined Values}
Tank 1 Set Pressure = 4.2 psi
Tank 2 set Pressure = -220 cmH2O

{Prepare Tank 1, Tank 2}
while (Tank 1 Current Pressure <= Tank 1 set Pressure) OR (Tank 2 Current Pressure >= Tank 2 set Pressure)
    if (Tank 1 Current Pressure <= Tank 1 set Pressure)
        Solenoid 2 = OPEN
        Pump 1 = ON
    end

    if (Tank 2 Current Pressure >= Tank 2 set Pressure)
        Solenoid 4 = OPEN
        Pump 2 = ON
    end
end

Solenoid 2 = CLOSED
Solenoid 4 = CLOSED
Pump 1 = OFF
Pump 2 = OFF

{Inflate Tank 3}
Solenoid 5 = CLOSED
Tank 3 set Pressure = 3.5 psi
while (Tank 3 Pressure < Tank 3 set Pressure)
    Solenoid 1 = OPEN
end
Solenoid 1 = CLOSED

{Deflate Tank 3, Collect Data}
Tank 2 Start Pressure = Tank 2 Current Pressure
Solenoid 3 = OPEN
for (4 Seconds)
    X = Tank 2 Current Pressure - Tank 2 Start Pressure
    Y = Integral(Tank 2 Current Pressure, dt)
    Graph(X,Y)
    Save(X,Y) to user-defined filepath/filename
end

{Done}
Solenoid 1 = CLOSED
Solenoid 2 = CLOSED
Solenoid 3 = CLOSED
Solenoid 4 = CLOSED
Solenoid 5 = OPEN

[bmunden]

Actually, the story goes like this.  A professor from the Vet school on campus (Purdue) had an original system that needed to be calibrated with manometers, voltmeters, and pressure gages.  This LabVIEW VI and a DAQ I/O board was intended to make the process go much faster.

Towards the end of the semester, I came up with a new design that doesn't need any solenoids, pumps, pressure gages, and is deadly accurate.

Now I have to complete both designs before the semester ends.  Lesson learned.

[RavensFan]

Hi Brandon,

A few more things I might suggest to help you.

1.  Take a look at the template for a standard state machine.  Menu File/New... /  gives a list of various templates.  See how the current state is passed through a shift register.  Your booleans for each pump and solenoid valve will need to be passed through shift registers, as well.

2.  You will probably have an architecture with at least 2 loops.  One loop being the state machine that tracks the current state and sets the pumps and valves accordingly.  The other loop being the one doing the acquisition and passing the data out to a file.  (Other architectures such as master/slave, producer/consumer may need to be built in here as well.  For example, the acquistion is done in the producer loop, but the data is passed to the consumer loop in a queue for actual writing out to a file.  But I wouldn't worry too much about that as of yet.)

3.  I would recommend that you set the pumps and solenoids explicitly in each state rather than just doing the not operators to switch them for safeties sake.  Suppose you think you are going from state A to state B where you know a pump is on in A and you are just flipping it off in B.  No problem.  But for some reason, you are actually in state C where the pump is already off, if you "flip it" by using the not operator in the state B case, then you accidentally flip it on when you actually want to made sure it is off.

It is good that you have the test mapped out and the pseudo code written out to show what you want to do.  That should definitely help in translating your thoughts into LV code.

-Bill

[bmunden]

I can see where I need two loops.  That was my original VI.  But I thought loops would simultaneously exchange data in real-time.  I don't see the state machine template anywhere--do you have a copy?  I'm running 8.0

[RavensFan]

You should be able to find the templates by going to File then New... on the menu system.  It will pop up with the following dialog box.

I have attached a .vi file created from the template as well as a .ctl control which contains the states for the state machine as a type def.  (You can search the forums for discussions of state machines and type defs. for better explanations on how they work.)

There are special functions you can use to get data out of one loop and into another without stopping the loops.  One would be a local variable which works for some simple things like getting a stop button to stop more than one loop.  For local variables, you should only have 1 writer, but could have multiple readers.  Many issues can happen with local variables.  There is no guarantee the other program location will get the data before it gets overwritten.  Also search the forum for information on "race conditions".

The more advanced functions for transferring data are queues and notifiers.  The templates for these are under producer/consumer and master/slave design patterns.

Message Edited by Ravens Fan on 04-17-2007 09:34 AM

[bmunden]

Here's the new state-based VI.  I'm still working on a good way to temporarily remember the data before I choose to put it into hard memory.  It's still a big file at 740 kb, but 90% of that are the express VIs to the left and right.  I have no idea how to replace those, and they work as is, so I'm happy.

Message Edited by bmunden on 04-19-2007 10:38 AM