CHALLENGE: Seek general architecture / suggestions for THIS project I'm doing...HELP!

[jymoon]

Ok, here's what I need - ANY suggestions for the way I should implement my project. Suggestions may include how while loops/sequences/clusters of arrays can/should be placed in my project.

Here's the scope:
I'm creating an automated slide processor which will have a PC (where d labview program sits) controlling 12 heating chambers. Functions for these chambers include, dispensing liquid from (any 5) reservoirs, asperating liquid from the chamber, heating of chamber to XX temperature.

I need an interface which will:
1) allow user to select which process (each process consist of ordered steps..eg. Dispense from reservoir, then Heat chamber to specific temperature, then Flush).


2) The "Operation" interface should allow user to select a process for each chamber, and user can START each chamber's process and ABORT/STOP.
Each chamber will be controlled seperately.

3) The "Monitor" interface allows user to look at the current Step (of the process) being executed and the current conditions (eg. current temperature).

Looking at the Scope..what's the BEST PRACTICE programming structure should I adopt using labview..

Any suggestions, I mean Anything really, will be most welcomed!

Regards.
Tommy

[wiebe@CARYA]

I've successfully implemented similar programs using a buffered statemachine
with multiple processes.

An explanation (assuming you are familiar with a state machine):
*********
Instead of an string or enumerated the buffered SM has an array of states.
A buffered SM with multiple processes has an array with clusters in it, with
an array of states.

Here's the trick.
Make a VI that takes the data structure descibed above. This is the state
handler.
Make each state so, that it leaves the state emediately.

Each of the processes the user can start, uses the same physical state to
execute (that is, you make each step needed for one process, and the other
processes use the same states). Is there an error in the processes? Fix it
ones, and all processes are fixed!

Use a shift register, a LV2 Global, Locals on the front panel, or a
reference file to store data for each process. But the data should be an
array. A state should work for each process, and thus an index of the active
process should be used to index the data array, and to get the needed data
for *all* processes.
*********

This method makes it a bit harder (but not impossible) to have popups etc.

Also, be aware that it is very flexible! This seems great, but you should
plan it, and then make it. This way you can easilly document it afterwards.
The possible state transactions are enormous, but using more than two or
three will make it impossible to make any kind of flow chart of the program.

(The greatest this about a state machine is this: each state has very
limited functionality {, e.g. init multimeter, init scope, read value,
update chart, wait for start, etc}. This functionality can be documented
easilly. The relation between states can be documented easilly. Ergo, the
entire program can be documented easilly!)

This might not be the solution you want, because it is kinda difficult. But
once you get the hang of it, you'll never want anything else!

I Hope I makes any sence explaning this, I know the architecture does!

Regards,

Wiebe.


"jymoon" wrote in message
news:50650000000800000083540000-1027480788000@exchange.ni.com...
> Ok, here's what I need - ANY suggestions for the way I should
> implement my project. Suggestions may include how while
> loops/sequences/clusters of arrays can/should be placed in my project.
>
> Here's the scope:
> I'm creating an automated slide processor which will have a PC (where
> d labview program sits) controlling 12 heating chambers. Functions
> for these chambers include, dispensing liquid from (any 5)
> reservoirs, asperating liquid from the chamber, heating of chamber to
> XX temperature.
>
> I need an interface which will:
> 1) allow user to select which process (each process consist of ordered
> steps..eg. Dispense from reservoir, then Heat chamber to specific
> temperature, then Flush).
>
> 2) The "Operation" interface should allow user to select a process for
> each chamber, and user can START each chamber's process and
> ABORT/STOP.
> Each chamber will be controlled seperately.
>
> 3) The "Monitor" interface allows user to look at the current Step (of
> the process) being executed and the current conditions (eg. current
> temperature).
>
> Looking at the Scope..what's the BEST PRACTICE programming structure
> should I adopt using labview..
>
> Any suggestions, I mean Anything really, will be most welcomed!
>
> Regards.
> Tommy

[wiebe@CARYA]

Hi,

Using this achitecture, its possible to start and monitor more than one
process at desired time.

E.g. process 5 is started, process 3 is almost finished, while process 2 is
started by the user.

If you only need one process running at once, use a normal buffered state
machine.

Regards,

Wiebe.


"Wiebe@AIR" wrote in message
news:aiaup8$3o4$1@news1.xs4all.nl...
> I've successfully implemented similar programs using a buffered
statemachine
> with multiple processes.
>
> An explanation (assuming you are familiar with a state machine):
> *********
> Instead of an string or enumerated the buffered SM has an array of
states.
> A buffered SM with multiple processes has an array with clusters in it,
with
> an array of states.
>
> Here's the trick.
> Make a VI that takes the data structure descibed above. This is the state
> handler.
> Make each state so, that it leaves the state emediately.
>
> Each of the processes the user can start, uses the same physical state to
> execute (that is, you make each step needed for one process, and the other
> processes use the same states). Is there an error in the processes? Fix it
> ones, and all processes are fixed!
>
> Use a shift register, a LV2 Global, Locals on the front panel, or a
> reference file to store data for each process. But the data should be an
> array. A state should work for each process, and thus an index of the
active
> process should be used to index the data array, and to get the needed data
> for *all* processes.
> *********
>
> This method makes it a bit harder (but not impossible) to have popups etc.
>
> Also, be aware that it is very flexible! This seems great, but you should
> plan it, and then make it. This way you can easilly document it
afterwards.
> The possible state transactions are enormous, but using more than two or
> three will make it impossible to make any kind of flow chart of the
program.
>
> (The greatest this about a state machine is this: each state has very
> limited functionality {, e.g. init multimeter, init scope, read value,
> update chart, wait for start, etc}. This functionality can be documented
> easilly. The relation between states can be documented easilly. Ergo, the
> entire program can be documented easilly!)
>
> This might not be the solution you want, because it is kinda difficult.
But
> once you get the hang of it, you'll never want anything else!
>
> I Hope I makes any sence explaning this, I know the architecture does!
>
> Regards,
>
> Wiebe.
>
>
> "jymoon" wrote in message
> news:50650000000800000083540000-1027480788000@exchange.ni.com...
> > Ok, here's what I need - ANY suggestions for the way I should
> > implement my project. Suggestions may include how while
> > loops/sequences/clusters of arrays can/should be placed in my project.
> >
> > Here's the scope:
> > I'm creating an automated slide processor which will have a PC (where
> > d labview program sits) controlling 12 heating chambers. Functions
> > for these chambers include, dispensing liquid from (any 5)
> > reservoirs, asperating liquid from the chamber, heating of chamber to
> > XX temperature.
> >
> > I need an interface which will:
> > 1) allow user to select which process (each process consist of ordered
> > steps..eg. Dispense from reservoir, then Heat chamber to specific
> > temperature, then Flush).
> >
> > 2) The "Operation" interface should allow user to select a process for
> > each chamber, and user can START each chamber's process and
> > ABORT/STOP.
> > Each chamber will be controlled seperately.
> >
> > 3) The "Monitor" interface allows user to look at the current Step (of
> > the process) being executed and the current conditions (eg. current
> > temperature).
> >
> > Looking at the Scope..what's the BEST PRACTICE programming structure
> > should I adopt using labview..
> >
> > Any suggestions, I mean Anything really, will be most welcomed!
> >
> > Regards.
> > Tommy
>
>

[storeyk]

I am interested in your buffered state machine for multiple processes, but i cant figure it from your explanation. Could you include an example vi to illustrate it please?

Kim

[wiebe@CARYA]

Kim,

At AIR we have developed a template for this (, to use in Pilot Plants in
particular).

I can send you (and other interested people) the template VI's.

This template idea is documented, and ready to fit into our project
management system (following GAMP method). This method enables us to
engineer software, test it, document it, validate it, and build reusable
moduls. The result is validated software, documented at all levels, and a
development process that is guided through all stages.

Why do I tell you this? Just to let you know there's more than just the
template. We are going to make a product out of this. Not just the template,
but the entire thing. We are using it ourself, but think other commercial LV
users can beni
fit from it.

Conclusive: I can (and will) send you the template code (2% of the work),
but cannot send all documentation about it. And I cannot promise support for
it, but if I find time I'll try to help (to some extend). I'm not sure if
someone can use the template code without the documentation. And ofcause the
code is not perfect (jet...).

I hope you will study it, and maybe use it as an inspiration or for personal
use (and comment or suggestions are welkom). Commercial use of the template
is not allowed.

Regards,

Wiebe.



"storeyk" wrote in message
news:5065000000050000002F900000-1027480788000@exchange.ni.com...
> I am interested in your buffered state machine for multiple processes,
> but i cant figure it from your explanation. Could you include an
> example vi to illustrate it please?
>
> Kim

[wiebe@CARYA]

BTW:
I will need your adress. Drop me a mail please...


"storeyk" wrote in message
news:5065000000050000002F900000-1027480788000@exchange.ni.com...
> I am interested in your buffered state machine for multiple processes,
> but i cant figure it from your explanation. Could you include an
> example vi to illustrate it please?
>
> Kim

[Mache]

Hi All,

Unless I am mistaken - I think the "Buffered State Machine" is "Queued State Machine". I think once you understand the State Machine there are many variants of this. Here are Links for Examples of "Queued State Machine"

http://zone.ni.com/devzone/explprog.nsf/6c163603265406328625682a006ed37d/b732f36e0d3c682f862569ec0070bd90?OpenDocument

http://zone.ni.com/devzone/explprog.nsf/6c163603265406328625682a006ed37d/45362df554a634ea86256a5d006390c9?OpenDocument

Regards,

Mache

[UFAPA Steve]

You may also want to investigate GOOP. (G object oriented programming.)

http://zone.ni.com/devzone/devzone.nsf/webcategories/8CF4C1FC9432BAAA862567AC00581392?opendocument&node=DZ52067_US

The LabVIEW object oriented philosophy uses references to create / destroy / access instances of an "object" (in your case a heating chamber). To get a quick example of this philosophy, check out LabVIEW's implementation of Config File or Report Generation VIs. (See attached block diagram.)

A company (Endevo, I think) has produced a "Goop wizard," which is free to download and play around with. It strikes me that the heating chambers are not
that complicated individually. So, the object oriented philosophy may work out nicely and be easy to implement.


The link above should be a good starting point. In case you're curious, it took me a solid day to get a handle on GOOP. It was then fairly quick (days) to try out a real project, and it works successfully and reliably. However, the GOOP wizard is very clunky and since the intial project, I haven't really used GOOP.

Hope that helps,

Steve

[Labviewguru]

The first thing you need to do is to outline the problem (your project definition). Document all factors involved, all features needed, and be sure to include any scalability needs, or future upgrades. You have to have a complete understanding of the problem before you can tackle it.

Once you have done this (defined the problem), you can work on a solution, which appears to be the stage you are in right now (whatever you do, don't skip any stages.) You should spend a great deal of effort on this phase, the design phase, of your project. You should consider all factors in the design of your software. If you are unable to do this, then I strongly suggest hiring someone that can help. You don't necessarily have to have a LabVIEW programmer, but you should AT LEAST have someone that knows software architecture working on the project. Without that knowledge, you are going to waste a lot of everyone's time.

Software architecture, design in other words, is the most important, and also the most overlooked factor in a project. Most people, especially customers, want to see coding start immediately. This is not a good idea. However; realizing that customers are this way, and also in conjuction with your design, you can code up some emulations, sample GUIs, and even start creating some basic objects (OOP) at this stage to satisfy the customer's need to see code. Understand, that this code will likely have little or nothing to do with the project itself, and should not be considered part of the source code.

The design phase is the most important. Simply trying to put out suggestions, and hope for the right answers on this forum, I would argue, is not the best method for this phase. You need to formulate a better understanding of your problem. If you lack experience with design, but can't hire a professional, then perhaps you should post much more specific questions, or do a little bit of research (buy a Programming Design, or Software Architecture book, or start with the Programming Design topic on this forum - albeit it is very much incomplete, and lacking from participation)

Perhaps the best suggestion I can offer you at this point is: Keep it Simple.

If you don't understand some of these program designs, don't use them. If you don't understand GOOP, don't use it. Trying to learn complex designs or something as complex as GOOP may in fact be counter productive.

This project sounds like it is pretty simple, and shouldn't take you more than a few months. Of course, I'm basing that only on the information you provided, and may not be realistic. If this project IS short, then unless you are a wiz at learning OOP, I would suggest bypassing that. However; if this is a huge project, then perhaps you should consider that learning GOOP, while an initial delay in the project, may be beneficial in the long run because of the efficiency gained by using it.

Above all else, I strongly suggest using a structured approach to programming. If you go to the Topics, and look at the one about Programming Guidelines, you will find a lot of useful information. I am in the process of formally documenting the programming guidelines I use and implemented wherever I worked, but if you would like an advanced copy, perhaps something could be arranged. However; there are several suggestions and even documented guidelines in that thread that would be helpful to you.

Good luck on the project.

[jymoon]

Hey, I would very much appreciate it if you could send me a template to help me piece up the jigsaw.. wat was explained makes sense, and THANKS!! It will be great to receive an example from you..

My email address: tommy_low@nyp.gov.sg

Any other emails/egs are most welcomed!!