LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Suggestions for programming acquisition and control sequence

Hi, I'm a LabView novice and need some advice.  I'm trying to figure out the best programming structure to use for my application.  Here's the task:

 

I'm measuring a meter output once every 5 sec, and will need to display and do analysis on the signal (analog, DC), as well as control a pump with a relay.

 

1. User inputs cycle variables

2. Cycle starts: pump on, display meter values, values not saved

3. at user defined time, pump off, display meter values, values not saved

4. at user defined time, pump off, display meter values, values saved

5. at end of cycle, pump on, saved values analyzed (rate of change) and results diplayed and saved

6. Cycle repeats (goto step 2) until stop button pressed

7. pump on, end program 

 

My question is what type of programming structure should I use?  Flat sequence, state machine, timed sequence, other?  Your help is appreciated.

Thanks. 

0 Kudos
Message 1 of 6
(2,963 Views)

I suggest a state-machine with event structure for your UI case.

 

Yik

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
Message 2 of 6
(2,956 Views)

Your application sounds like a really great fit for a state machine.  You have already done a good first cut at defining what the states will be.  You will probably want to refine them a bit further, but you have a great start.

 

Using a state machine architecture allows for far more flexibility than any kind of sequence architecture.  If you need to add a task in the future, for instance, it's as simple as adding another state to your state machine.  It also makes for much more readable code.

 

As your state definition, you should use a type-defined enumerated constant.  This allows you to add / delete states with minimal reprogramming of your application.  There is a lot of information on this forum about type-defined enums and their use...do a search and you'll come up with all kinds of great information.

 

You are to be congratulated for giving some thought up-front to your code architecture instead of just diving in and at some time down the road discovering you've created a monster.  Smiley Happy  Good job!  Do a little more research on the forum, write some code and try things, and then post back if you run into roadblocks.

 

d

Message 3 of 6
(2,953 Views)

At the first glance-

 

I would choose to implement this as an Event Driven Queued State Machine.  Not one of your suggestions. Smiley Wink  -Well you said "Other"

 

A flat sequence buys you very little except placing your "States" in seperate, side-by side frames  And we won't digress to stacked sequences since your next offering is a State Machine.

 

The State Machine Is a good option but would need an external method of timing to launch the States since there are two sources.  User Input and Time.

 

An Event Structure would seem to be the IDEAL source for the user interupts and a timed loop could enqueue the Acquisitions

Message Edited by Jeff Bohrer on 03-05-2010 02:11 PM

"Should be" isn't "Is" -Jay
Message 4 of 6
(2,951 Views)

Thanks for your help!  Is this the type of structure you're referring to?  (I'm looking for examples)

http://zone.ni.com/devzone/cda/tut/p/id/2962

 

Keith 

0 Kudos
Message 5 of 6
(2,932 Views)

I would look at the examples for queues first to gain an understanding of these funtions (especially as you might be familiar with data flow and Queues BREAK the paradigm)

 

Then go back and look over events-  You'll need them - but remember the events are Queued "behind the screen" so understanding queues FIRST is important.

 

I think you will have little trouble with the combination of "Producer loops" (Event and Timed Loop) once the concept of queues is learned.  And the old State machine should be a cakewalk by then too.

 

Feel free to ask questions though.  Its what we do here


"Should be" isn't "Is" -Jay
Message 6 of 6
(2,919 Views)