Labview Design Tips

Question

Hello all,
I have difficulites in designing bigger Labview applications. I have
got a huge program which is related to what I have to develop. But
this sample program uses *many* global variables, it is a mess for me.
Therefore, I decided not to use global variables in my application.
Now I realize that this is not so easy in Labview. These are my
problems:
I certainly want to modularize. Is it true that *all* the inputs and
the outputs of a sub-VI must be controls? As a consequence I have to
use a lot of dummy controls that shouldn't be visible in the front
panel.
Another problem is the number of terminals of a sub-VI. I have tried
to bundle the input and output wires into a cluster and vise vera. But
this seems to be too cumbersome: First I have
to create a dummy
cluster control (the shell). Then I have to include the controls
(dummy or not) into the cluster shell. I have no idea how to draw the
shell across the controls if they are scattered in the panel. The only
possiblity I can see is to create additional dummy controls in the
cluster shell and copy the values of the 'real' controls to them. Then
I have a cluster link between sub-VI. Inside the sub-VIs I have to
bundle/unbundle the clusters. This only makes sence if I use 'Bundle
By Name'. But then I first have to bundle the lines into a cluster and
then give all the lines a name.
Probably the most useful design is as follows: Create a (dummy) VI
which contains only controls. The wires of the controls are the
interface lines between all sub-VIs. Create and use global variables
of the controls.
I am expectant to hear expert design ticks.
Bye
Johannes

Answer 1

Hello Wiebe,
thanks very much for your answer. Your advices are interesting.
I come from an object oriented background, mostly Java, but I have
also come across Python, C++, Smalltalk, and Eiffel. These languages
are mostly non-visual (well, except for GUI builders). On the other
hand, they support polymorphism which is only supported to some extend
in LabView. Also, I can't define new data types (classes) in LabView.
For instance, I have had the following difficulty in LabView:
At a certain point in a VI there is a cluster connecting the sequences
of a frame. The cluster contained only numeric lines, so I could have
used an array as well. Now, I wanted the following: One line of the
numeric lines should behave polymorphic at run time. Depending on an
option menu the line should sometimes be numeric, sometimes be an
array of numerics itsself. The cluster and the sub VIs connected to
the cluster shouldn't care about what is inside the cluster. But in
LabView, cluster is not cluster. Some sub VIs indeed behaved
polymorphic, but not all. After trying this and that I gave up. Now
the line (inside the cluster) which should have been polymorphic is
always of type array and most of the time the array contains one
'real' element and several dummy elements just to remain type-save.
Not a 'nice' solution in my mind. In an OO-language I whould have
defined an abstract class 'Parameters' and implemented (inherit) the
subclasses as needed and so on.
Another problem which was related to that above: The input was a
string control. It has to be checked if this control is empty or not
(Empty String/Path VI). Now I had an array of string controls as input
and it has to be checked if any of this string controls is empty. But
the 'Empty String/Path' VI doesn't (polymorphically) accept multiple
strings or string arrays and the 'logical and' VI doesn't accept
multipe inputs. I did the following to get the desired behavior: First
convert the array of string to a cluster (Array to Cluster VI). Then
unbundle the cluster to get the strings. Then check each single string
with 'Empty String/Path' respectively. Then build an array of booleans
with the boolean outputs of the 'Empty String/Path' VIs. Then, after
all, connect the output array of booleans to a 'And Array Elements'
VI. The output of this VI was *sweat* the output I wanted to have.
There are probably better ways to get the above behavior. I just have
to get used to another paradigm.
On Wed, 22 Jan 2003 11:44:09 +0100, "Wiebe@AIR" wrote:
>Inputs must be controls, outputs must be indicators...
I get to understand that
By the way: Is there an easy way to group MMI controls to get compount
controls? I often would like to group a decoration together with some
controls. If I want to move the whole group then I always have to draw
a line with the pointing device to include all the elements. Or I have
to select all elements with the shift key.
>
>If you design modules, you should try to group them. Not every group will
>need to have all inputs. Catagories to group by are: drivers for hardware,
>window tools, MMI vi's, utilities, string manipulation, general file I/O,
>app specific file I/O. E.g. an application specific file I/O function might
>only need a 2d array and a file name. The module stores the file to the
>path. No need for all the other inputs.
>
>Mixing a hardware dirver with e.g. arithmetics is a mistake. This prevents
>the reuse of the hardware driver, and the arithmetics.
Sounds interesting. I am used to the Model-View-Controller approach in
Smalltalk: The Model is the actual behavior of the application (the
data), the View is the representation on the screen (the look), and
the Controller is responsible for user interaction (the feel).
Sometimes the View and the Controller are together, but the main point
is that you should separate the representation and the user handling
from the data.
What do you mean by hardware driver? I have to use a DAQ-card and a
GPIB device in my application. I get several inputs from the DAQ-card,
an output of the application is sent to the GPIB device. Now, should
there be one (or several?) VI just reading from the DAQ card and
writing to the GPIB?
>An exception to this
>is the MMI. In LabVIEW the MMI window it often the window that controls the
>process, and thus calls all the other subvi's that are needed in the
>process.
I have a start screen the user have to input all data necessary for
the measurements. Then another screen showing the measuring process
appears. Probably there should be a splash screen before the start
screen and a status screen at the end (but this is cosmetics). So I
have at least two MMI VIs.
>> Probably the most useful design is as follows: Create a (dummy) VI
>> which contains only controls. The wires of the controls are the
>> interface lines between all sub-VIs. Create and use global variables
>> of the controls.
>
>I still cannot see why you need all the controls on every subvi...
You are right, I don't need all of them on every subvi. But if I use
globals (I do not now) it is probably better to centralize all of them
in one subvi. If a certain VI uses a certain global reference it is
probably better to know that it is always defined in one 'globals' VI.
Johannes