How to make a Do-It button?

[Frank Hamilton]

I'm an experienced programmer, new to Labview, and struggling with how
to do simple things.

I'm trying to create a momentary push-button, where when you click the
button, it performs some action. In my case, I want it to execute a
method in an ActiveX COM object, but the action doesn't much matter,
it's the button logic that gets me.

The only way I can see to do this is like this: Make the button
mechanical action Latch when pressed (or latch when released). Tie the
button output to a while loop , and make the loop "stop on true". Add
a wait till next ms multiple timer to the while loop, not connected to
anything except an input with, say 50 mS constant. Run the automation
refnum wire through the while loop, not connecting
to anything in the
loop, but tunneling through it, and then connecting to my ActiveX
method (outside the while loop). Then put this whole thing in another
while loop, that runs forever, or perhaps is tied to the "power"
switch.

OK, that seems to work, but it seems like a remarkably complicated way
of doing something that is very simple, and very common. Is there an
easier way? What am I missing?"

I have looked through the manuals and help files (LV 6), with no
success. I have also looked through the examples, and have not found
one that seems to do what I need. If it's there, please point me in
the right direction.

Speaking of examples, I find the examples hard to learn from. Is there
a way, when looking at a diagram, to tell what function a particular
icon performs? If you're new to Labview, you don't know the symbols,
and there's no fly-over help or other way, that I can see, to tell
what tool or function corresponds to a particular tool (other than
searching through the toolbars
).

Thanks for your help,

--
Frank Hamilton
Please reply to the group

[CraigGraham]

Frank Hamilton wrote in message
news:0pinqssl5jucsja48ji62b949ujao0l6en@4ax.com...


> OK, that seems to work, but it seems like a remarkably complicated way
> of doing something that is very simple, and very common. Is there an
> easier way? What am I missing?"

No easier way as far as I'm aware. Labview is dataflow driven, rather than
event driven as you seem to want it to be. If you want it to do something
when you press a button, you have to poll that button periodically to see if
it's been pressed. That's how even the "event driven" languages like Visual
Basic work behind the scenes, in any case.

> Speaking of examples, I find the examples hard to learn from. Is there
> a way, when looking at a diagram, to tell what function a particular
>
icon performs? If you're new to Labview, you don't know the symbols,
> and there's no fly-over help or other way, that I can see, to tell
> what tool or function corresponds to a particular tool (other than
> searching through the toolbars).

If you have the help window open, then when the mouse pointer is placed over
a node in an active window the help window will show the pinout, name and
description of that node. Additionally, if you have the wiring tool active
and put it over a wire, the help window shows you the datatype of the wire,
which is very handy when working with clusters of arrays of clusters, for
instance!

[markwysong]

Frank,

Seems painfully complicated to me. What you can do is put your button
inside a while loop and use the timer as you are now. Stop the loop
with a stop button. Make your "do-it" button a latch when released
mechanical action, and wire it to a case statement, where the "true"
case executes your Active-X component. When the button is pressed, your
code is run, but the button then returns to false. In that condition,
nothing happens.

Hope that helps.

Mark

In article <8ogkde$apm$1@sponge.lancs.ac.uk>,
"Craig Graham" wrote:
>
> Frank Hamilton wrote in message
> news:0pinqssl5jucsja48ji62b949ujao0l6en@4ax.com...
>
> > OK, that seems to work, but it seems like a remarkably complicated
way
> > of doing something that is very simple, and very common. Is there an
> > easier way? What am I missing?"
>
> No easier way as far as I'm aware. Labview is dataflow driven, rather
than
> event driven as you seem to want it to be. If you want it to do
something
> when you press a button, you have to poll that button periodically to
see if
> it's been pressed. That's how even the "event driven" languages like
Visual
> Basic work behind the scenes, in any case.
>
> > Speaking of examples, I find the examples hard to learn from. Is
there
> > a way, when looking at a diagram, to tell what function a particular
> > icon performs? If you're new to Labview, you don't know the symbols,
> > and there's no fly-over help or other way, that I can see, to tell
> > what tool or function corresponds to a particular tool (other than
> > searching through the toolbars).
>
> If you have the help window open, then when the mouse pointer is
placed over
> a node in an active window the help window will show the pinout, name
and
> description of that node. Additionally, if you have the wiring tool
active
> and put it over a wire, the help window shows you the datatype of the
wire,
> which is very handy when working with clusters of arrays of clusters,
for
> instance!
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

[Hans-Jürgen Philippi]

<< I'm trying to create a momentary push-button, where when you click the
button, it performs some action. >>

Hi Frank,

well, as Craig mentioned before, you have to get warm with the fact that
LabVIEW is dataflow and NOT event driven like other languages (Visual Basic,
Delphi...). That is: Your program (the whole VI) runs in a continous loop
and if want want to "simulate" some kind of event handling within, you have
to take care for it yourself!
In your *case*, indeed I preferred a boolean *case* structure to serve as an
event handler: Simply wire the described button with the structure and put
the related code in the TRUE case, that's it.

<< Speaking of examples, I find the examples hard to learn from. Is there a
way, when looking at a diagram, to tell w
hat function a particular icon
performs? >>
There is, and in fact it's much more efficient than any online help I've
seen from any other development tool so far, including the named above: Just
press [CTRL]+[H] to open the LabVIEW function help window. Now move the
mouse pointer over the diagram functions or function palettes, and the help
window will display interactive help for any function, if available.
I'm sure, once you've understood the very basic LabVIEW principles, you will
find the delivered examples useful - cause they ARE useful to learn from.

After all, I can only say: Be patient.
I used to work with Visual Basic only, and when I introduced myself into LV
3 years ago, I found many things rather peculiar, too. It took some time to
understand the complete different approaches of dataflow and event driven
languages - and now I see that both have their own advantages/disadvantages.
Believe me, LabVIEW is a real cool + powerful tool. Especially when you have
the pleasure to wo
rk with the sexy new LV 6.0i, like you do, you lucky one!
🙂

Greetings + good luck,
Hans

[Frank Hamilton]

Thanks for everyone's suggestions.

Using a case statement rather than the internal while is much better.
My solution worked OK for one button, but failed miserably with two.
And the case is cleaner and easier to do.

Also thanks for the pointers to the context sensitive help. I hadn't
discovered that yet, and it does help.

I have to disagree about the usefulness of the examples. They have
almost no documentation, so it's often very hard to even tell what
they are *supposed* to do, let alone how they do it. And it's hard to
find examples of the stuff I want help with. I couldn't find an
example of a Do-It button, for example, though maybe it's there
someplace, but how would you look it up?

Just my opinion.., but if I shipped C++ examples that were as
poorly
commented and as poorly documented as the Labview examples, I'd be
fielding complaints all over the place. 🙂

--
Frank Hamilton
Please reply to the group

[Kevin_work]

Frank Hamilton wrote:

> Thanks for everyone's suggestions.
>
>
> I have to disagree about the usefulness of the examples. They have
> almost no documentation, so it's often very hard to even tell what
> they are *supposed* to do, let alone how they do it. And it's hard to
> find examples of the stuff I want help with. I couldn't find an
> example of a Do-It button, for example, though maybe it's there
> someplace, but how would you look it up?

I have worked with LabVIEW a long time so I usually know where to
go for examples. I will agree that the ones provided are rather sparse.
I have often found it amusing that NI has a paper on how to document
VIs they just never seem to follow it EVEN ON SELLABLE APPS !!!!

I was also rather disappointed with t
he 6i. I would have liked to
see examples on the new goodies without an intense search.

Oh Well maybe I have gotten lazy
Kevin Kent

[Greg_McKaskle2]

> > I have to disagree about the usefulness of the examples. They have
> > almost no documentation, so it's often very hard to even tell what
> > they are *supposed* to do, let alone how they do it. And it's hard to
> > find examples of the stuff I want help with. I couldn't find an
> > example of a Do-It button, for example, though maybe it's there
> > someplace, but how would you look it up?
>
> I have worked with LabVIEW a long time so I usually know where to
> go for examples. I will agree that the ones provided are rather sparse.
> I have often found it amusing that NI has a paper on how to document
> VIs they just never seem to follow it EVEN ON SELLABLE APPS !!!!
>
> I was also rather disappointed with the 6i. I would have liked to
> see examples on the new goodies without an intense search.
>

A couple comments. A least some of this is a proble of terminology.
A Do-It button isn't something you will find in the index of any of
the LV manuals, and I don't believe the ones at the book store will
have it either. That just isn't what it is called in LV, and while
I know what you mean, I don't believe that I've ever heard that name
used for it.

Two examples that you may find useful, from examples/general/Booleans.llb,
are Using Buttons for Options.vi and Mechanical Action of Booleans.vi.
Also, while its always difficult to have "enough" documentation, you may
not be finding what is there. Now that you are using the Help window, you
may want to be sure to idle over the front panel controls, as they can have
context help per control, and idle over the icon in the upper right of the
window. This help is often written for the person that will use the VI
as a function call rather than a panel, but its still helpful.

If there are specific terms that you are looking for and can't find in
the examples, please submit something to technical support. The examples
and documentation are constantly being updated. They can always use help
in knowing what areas are missing or are hard to find.

As for documentation on what is new in 6i, assuming that you have an
updated edition and not a new edition, look for the upgrade notes. They
are the most concise way to read about the new functionality. The examples
that show off 6i are organized functionally rather than according to when
they were introduced, which makes it hard to slice things the way you are
asking for. I suspect that soon the web site will contain some
VIs and web pages to show off 6i. They will first appear at the next
round of user group meetings, then make their way to the web. So, you
may want to make it to the next meeting in your area.

Greg McKaskle

[CraigGraham]

Frank Hamilton wrote in message
news:hploqskr65829cb6gb7bj8p1refio4k31u@4ax.com...
> Thanks for everyone's suggestions.
>
> Using a case statement rather than the internal while is much better.
> My solution worked OK for one button, but failed miserably with two.
> And the case is cleaner and easier to do.

Not sure how you did the two buttons, but what I tend to do if I have
several Boolean controls is to assemble them into an array and then convert
the Boolean array to an integer large enough to hold all the Booleans. The
front panel itself can hold the Booleans in an array if the panel
arrangement makes it convenient.You can then tell if any button has been
pressed because the int is non-zero, and if you assume only one butt
on will
be pressed at a time you can wire the number to the selector of a case
structure and make different cases for different values of the int to handle
each button press. Have a case, -1 for example, corresponding to an invalid
input and set that as the default, so it's called to clean up for all the
cases you haven't explicitly handled.

I did a routine a while back that takes such a number and (as I recall using
logs) returns a number corresponding to the button pressed- 1, 2, 3, 4 etc
instead of 1, 2, 4, 8. If two buttons are pressed simultaneously just treat
it as an invalid input and pop both of them back out. If it becomes a
problem, increase the rate at which the panel is polled.

[Mikael_Garcia]

A short note regarding your button-number method. I have also used the logarithm method to calculate the button number and it works just fine. But if you have an array of button-booleans and want to find out what button was pressed, you can also use the search 1D array function and look for a TRUE in that array. The function will then give you the index, i.e. button number. If no button is pressed it will return -1. /Mikael

[CraigGraham]

I don't know if this was in reply to an old mssage from me or not, but I
used to be in the habit of using the logarithm method to find the single
unique true in an array of booleans. However, this method screws up if your
array of booleans- or buttons- is longer than the bitlength of the datatype
you're using. This limits the technique to 32 booleans. In addition, I
suspect converting the array to a number and then taking the log is actually
quite an inefficient process.

The method I use now isn't to use "search 1D array"; I use a for loop to go
through the whole array. When a true is found, the current index is passed
to an output terminal. If a flag for "found?" is false, it's set to true. If
it's already true, an error flag is
set since there isn't a unique true.

Using a single search 1D array will only return the first true without doing
a check for multiples- although perhaps using two search 1D arrays strung
together- the first to give you the first true and the second to verify none
others exist- is a more elegant solution than mine. It's not sufficiently
more efficient to make it worth me digging mine out for another rewrite
though.

Mikael wrote in message
news:5065000000050000003A330000-993342863000@exchange.ni.com...
> A short note regarding your button-number method. I have also used the
> logarithm method to calculate the button number and it works just
> fine. But if you have an array of button-booleans and want to find out
> what button was pressed, you can also use the search 1D array function
> and look for a TRUE in that array. The function will then give you the
> index, i.e. button number. If no button is pressed it will return -1.
> /Mikael