Suggestions on programming technique for new VI

[TMDATA]

Over the next few weeks I am going to start to build a new vi, and I am looking for suggestions on what programming technique should be used for what I am trying to accomplish.  A broad view is 6 solenoids open/close (via analog out), an air tank is filled, a water tank is filled.  Once everything is initialized, solenoids open/close and a motor is turned on (analog out), and analog in data is written to file.  Once complete everything is restart automatically.

Now for a little more detail.  The first thing the vi will be doing is the vi will open a solenoid (via analog out) which manual fills a water reservoir then after say 5 mins later the solenoid closes.  Concurrently the vi will be continuously monitoring bottle pressure via analog in, closing a solenoid via analog out (discharge line), and opening a solenoid via analog out (to fill pump).  When the bottle pressure reaches a certain level, the solenoid that is hooked to the pump will close (analog out), and wait a certain amount of time.  After that time has elapsed, the vi will check bottle pressure and see if it need to be refilled due to temperature change.  If a refill needs to take place it will close and reopen the respective solenoids, fill, and enter the wait period again.  Once the bottle pressure is within a set limit, some solenoids will close, and some will open via analog out.  The test will automatically start, which a profile via analog out will be sent to a motor controller, and saving analog in data to file at the same time.  Once the test is complete the whole process will start over again.  I am going to try and automate this so during any part of this process if any pressure reaches above a set point (analog in), the test aborts and vent solenoids open (analog out).  Passive relief valves will be in place, as a backup.  It would also be nice to have a diagnostic to say why test failed, if the test failed it will require a manual reset by the user, once they have completed a safety checkout to resume automatic testing.

I am thinking a I might need a 8 ch analog out card, to control each solenoid independently of each other.  We currently have a multifunction daq card with 16 analog in/ 2 analog out.  Any problems anyone might see?  Suggestions?  Thanks for any help!

[mikeporter]

Given the description you have provided, I would be looking at a state-machine to provide the application's overall structure - perhaps built into the event structure controlling the user interface, perhaps as a loop separate from the GUI - there's not enough detail to tell. The first approach is simpler, but might not be feasible based on response time requirements. The second is more complex, but is also more flexible in that it opens the possibility of moving the state-machine to a separate system (like a LV-RT platform).

Viewed from another way, the application should be data-centric. In other words it should be built wrapped around a database. All setup information would come from this database and all test results would go into it. This structure gives you security, repeatability and provides an application-independent data store for results.

Mike...

[TMDATA]

I am sketching this up in concept, and have a question. The analog in/analog out would be outside of the state machine, in a while loop correct?  That way any state would have access to the analog in channels along with commanding any of the analog out channels to control the solenoids.  Or should there be a state that is "initialize" where the analog in & analog out is configured?  Thanks for any help

[mikeporter]

Where the analog IO ends up is a function of how long it takes to complete. If the IO process is a couple hundred milliseconds or so, it can go right in the state machine. If it takes several second, it's better to have it in its own process loop that you control from the main loop. The real issue is the responsiveness of the user interface.

Whether to have a separate initialization state is a function of the nature of the state machine. If you will only do the initialization once, you can put it as something that gets executed before the state-machine starts. If on the other hand there might be a need for the system to be re-initialized to a startup condition, have it as a separate state that can be used for either startup or reinitialization.

Mike...

[modicon]

A quick observation...usually, solenoid valves are digital devices, not analog.  You may be able to get away with a lot less I/O if you are switching 16 relays at 24v instead of one 16 bit 4-20ma analog signal driven full off/full on..

As as has also been observed here frequently, real-time control of valve hardware from a PC prone to hangups, crashing, software bugs etc, may have safety issues in tow.  Some of us prefer using small dedicated PLC's for such hardware operation, and save Labview for the interface...