Automating an experiment

[bmunden]

I'm writing a big VI for the first time.  I'm going to be running an experiment, turning on and off some solenoids and pumps via the digital outputs (and a relay board), and taking in some analog signals.

What's the cleanest way to do this?  I want to display the sensor information at all times, so I have things wired up to continuously sample data and display them on some gages in the front end.

I'm doing things like this:

1. Open solenoids.
2. Turn on pump 1 until Analog_Pressure_1 reaches 90 kPa.
3. When Analog_Pressure_1 reaches 90 kPa, close solenoid_3 and solenoid_4.
4. Take a bunch of data, print it on a plot, and stop when Analog_Pressure_2 reaches XX value.
5. Close solenoids.
6. Save file.

I think you get the idea.  I was thinking of using sequences, but all the NI documentation says to use "Data flow".  I'm in hydraulics, but I have no idea how to flow data.

[bmunden]

Here's my VI so far, in LabVIEW 8.0

[devchander]

State machine design pattern is the way to go

[bmunden]

Hm.  States.  I can't tell if I'm supposed to buy this toolkit or not.

[bmunden]

I think my needs are a little different.  State Machines appear useful for maintaining, well, states. 

In my case, I have to pressurize one tank to a user-defined pressure, put the other tank under vacuum to a user-defined vacuum, then seal off the connections using solenoids so that everything's air tight.  Then, I pressurize the lungs of an animal with the pressure tank, close things off, open another solenoid that's connected to the vacuum tank, and measure the pressure data as the vacuum empties (safely) the animal's lungs.

Things are pretty sequential.

[devchander]

Sounds frightening!

[smercurio_fc]

State machines are not for maintaining states. They're for controlling program flow based on stimulus and rules. They're a fundamental design paradigm that would serve you well since it will make your program more robust that using a simple sequence frame. You do not need the State Diagram Toolkit to create a state machine. I've created tons of state machines without it. Would it be easier? Certainly. But not necessary.

As you said, you're in hydraulics, and you "have no idea how to flow data". This, to me, screams that you first need to understand LabVIEW and general programming before trying something like this, especially since you seem to be dealing with live animals.

I would strongly suggest that you start in the NI Developer Zone and go through the LabVIEW tutorials first before trying something like this. Given your specific application you may find it worthwile to consider hiring a consultant who can do the job for you.

[bmunden]

I tend to understate things.  I've designed a few digital and analog circuits for pulse width modulation, programmed in C, and done other entry-level electrical engineering tasks.  There's a multi-tier hierarchy of failsafe mechanisms in place.  If the system locks up, the solenoids default open.  If the solenoids sieze, there's a three-way valve.  If the three-way valve is stuck, there's an abort button.  The pumps aren't capable of delivering dangerous levels of pressure or vacuum to the animal.  Finally,we don't deal with animals until the product is first tested on a simulated respiratory system.

The issue here is familiarizing myself with LabVIEW's modular non-sequential programming mechanism, which was advertised as being a clean, simple way of automating experiments and measuring data.

Message Edited by bmunden on 04-13-2007 10:04 AM

[bmunden]

So, here's another avenue.  I'm using a buffer driver to drive relays for the pumps and solenoids.  Data is continuously sampled from pressure transducers and thermocouples.  Instead of worrying about automation, I can just allow the user to prime the tanks manually by switching pumps and relays on and off via booleans.

This brings me to the next issue of controlling individual lines of the digital I/O ports.  It's not necessarily intuitive.

[LV_Pro]

Well the following message was in answer to your response earlier, but apparently I type too slowly!    You address a few issues of safety, but keep revisiting them throughout the process, I can't stress how many times I have had supposedly "foolproof" systems find new and frightening failure modes! As I once pointed out to a professor when he gave a class assignment to design and write a "foolproof" data entry/control program, the best we could hope for is a "fool resistant" one, it seems "fools" are devilishly ingenious at find our program's flaws.



You don't need the state machine editor add-on to do states. A state machine is just a way of sequentially doing things that can break the sequence based on its internal logic. It (a state machine) gives you more flexibility to add steps that may only be conditional, for instance, if in your application you detect a fault in the pressurization part of your sequence a state machine would allow you to go directly to an error handling step rather than continue along with all the steps. It is quite scarey to be running experiments on living organisms running on Windows (or most other non-Real time operating systems), with software developed by inexperienced programmers. I'm not trying to belittle your abilities, but having programmed for three decades, the last 14 years using LabVIEW almost exclusively, I can say that the ways that programs will behave unexpectly grows exponentially with its complexity, and that is without the addition of hardware. Be careful, run the test numerous times without your test subjects (try a balloon at first, sounds like it might provide enough of simulation, although lungs are really quite fragile), while varying parameters, like unexpectedly disconnecting various pieces of hardware. Make sure that there are numerous places that you check limits before applying them, etc.

Good Luck.

Message Edited by LV_Pro on 04-13-2007 11:33 AM