LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Events structures with clusters?

I have a cluster of buttons and numerics and I want to use an event structure to look for button clicks. Typically when I use an event structure, I put the control inside the event, but I can't since it is a cluster and there is one event for each button. Is it okay to have the cluster outside of the event structure?

Thanks.
Kasey
Message 1 of 12
(3,446 Views)
It's OK to do that, but you need to set it up correctly.

With the cluster outside the Event case, it's value will be updated before the Event is triggered. So if you wire the cluster into the Event Structure, you're likely not to get the new value that triggered the event. This is because the value of the cluster will be read and sent to the structure tunnel beforethe event is triggered.

Inside the Event cases, use the terminals on the left side of the border. One of the selections in the border terminals will be "NewVal". This will output the new value that triggered the event. Wire to this to ge the new value to operate on.

Ed


Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
0 Kudos
Message 2 of 12
(3,435 Views)
There is one way of dealing with event structures, controls, and indicators, that I have adopted. I put all of my controls and indicators in the first frame of a stacked sequence structure. For the remainder of the program, everything is accessed through property nodes. This way there are no wires being passed in between even structures, queues, etc. This is extremely important if you start paralleling your architecture. For example, using dual while loops in parallel, one loop collects event, does pre-processing, and then places an action to be performed on a queue running in the other loop. This cannot work with wires being passed into them while the property nodes ensure good data flow.
0 Kudos
Message 3 of 12
(3,422 Views)
Every time one of those property nodes is read or written to, the execution engine must stop what it's doing, switch to the user interface thread, act on the property node, update the front panel, switch back to the original thread and continue. This is actually a very inefficient way to program. It may look nice on the block diagram, but that has nothing to do with how your program will run. Running a wire from point to point is the most efficient way to move data.

A property node is really for operating on the properties of your front panel items. You'd even be better off using local variables to do your reading and writing since they don't demand an immediate switch to the user interface thread, everything gets updated when the execution engine has time. Though this does create extra copies of data in memory.

If you need to pass data from one loop to another, use a queue. There are some nice templates that ship with LabVIEW showing you how to do this. Open the Template Browser (File>New...) and look under ‘Frameworks’ then ‘Design Patterns’. There’s a 'Producer/Consumer' and 'Master/Slave'. These both use a queue to pass data from one loop to the other. There's even an Example using queues to pass data from one VI to another.

Ed


Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Message 4 of 12
(3,413 Views)
Ed,

I will have to respectfully disagree with you on this one. My understanding is that the UI tread only needs to run for something that needs to repaint the control (data writing). Data reading should just access the values from memory, make a copy into the new wire and off you go. Anyways, It is probable that you are right on a theoretical basis; however I have built large applications with 100s of controls and indicators as my data containers and do not notice any speed degradation as a result. Also, there are many many times when you need to access properties. And since this cannot be done with local variables, you are stuck wtih the propery nodes. Therefore, if you are going to access a property anyways, why create an additional local variable?

As far as your comment on bad programming, it is my opinion that messy (i.e. too many wires) constitutes a poor program.

The problem with passing data in as a parameter to the queue is that it becomes not flexible. This is the primary advantages of LabVIEW over C++ that we do not allways have to declare things, like data types, explicitly. Queues and events, to me, are for process flow only. I prefer to allow access to whatever data I feel I need, dynamically (i.e. can change it on demand) anywhere in the block diagram.

Kasey, you will have to try both out. If you notice that your programs are sluggish as a result, then the NI engineer was right. However, I think that you will be satisfied at the performance while noticing a huge boost in productivity both in terms of development and iterative maintanance.

-EF
0 Kudos
Message 5 of 12
(3,411 Views)
Ed is absolutely right about property nodes. If you doubt him, see this explanation here from Greg McKaskle. Wires may look messy if you let them, but they are the most efficient way to transfer data. Shift registers are a close second. Sometimes you do need a property node but only when you truly can't do it with a wire.
Message 6 of 12
(3,400 Views)
Ok, everyone can be the judge for themselves. Attached are two vi's with 6 graphs inside a for loop that runs 100 times, updating each of them with a slightly different display of 1000 points.

One .vi does this with wires and the other one does it with property nodes.

I have also included milisecond timers to do the timing analysis. And the results are....

Wired: between 700-1000 ms on average
Property-Nodes: 580-680 ms on average

For benchmarking purposes I am using a PIII with 256MB RAM

Looks like the property nodes win in this case.

-EF
0 Kudos
Message 7 of 12
(3,391 Views)
here is the other .vi
0 Kudos
Message 8 of 12
(3,391 Views)
Faraclas wrote:

> Ed,<br><br>I will have to respectfully disagree with you on this one.
> My understanding is that the UI tread only needs to run for something that
> needs to repaint the control (data writing). Data reading should just access
> the values from memory, make a copy into the new wire and off you go.

But this needs to be synchronized with the UI thread nevertheless.
LabVIEW chooses to optimize terminal access and local variables and
penalize reference value access due to the fact that the first can be
easily analyzed in true dataflow while the last will break dataflow in
many ways. The biggest roadblock however to even try to optimize
reference value access is the fact that the VI server in LabVIEW is a
very complicated entity to manage and all property nodes go eventually
through VI server in some way. Rather than having only an almost perfect
multi-threading capable VI server, the LabVIEW developers choose to be
on the safe side protect any access through VI server and in that way
make sure your applications won't misterically crash on completely
unrelated things due to race conditions.

> Anyways,
> It is probable that you are right on a theoretical basis; however I have
> built large applications with 100s of controls and indicators as my data
> containers and do not notice any speed degradation as a result.

The number is not the problem. The fact that you may try to access
property nodes either in some part of your application which needs to
have almost realtime behaviour or in a place which is called 100 times a
second will make your application misbehave or crawl however.

> Also, there are many many times when you need to access properties.

Yes but this is typically based on user actions and even the fastest
user will not generate more than a few events per second.

> And since this cannot be done with local variables, you are stuck wtih
> the propery nodes. Therefore, if you are going to access a property
> anyways, why create an additional local variable?<br><br>As far as your
> comment on bad programming, it is my opinion that messy (i.e. too many
> wires) constitutes a poor program.

While I agree that to many wires is a messy thing, it is not a question
of to many wires OR using value properties all over the place. It is a
question of applying proper architectures such as while loops with shift
registers, state machines, intelligent global variables and such things
if you get a messy application or not.

Rolf Kalbermatter
Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 12
(3,386 Views)
I'm actually getting almost identical times between the two VIs. Seems a bit strange, and I'm still not sure what's going on there. I want to look at those a bit more to find out what's going on.

I've modified your VI to let you select how to update the terminals. This ensures each method is running exactly the same code. Four methods are available. Wire to the terminal, Linked property node, Strict porperty node and Local variable.

Running this shows (at least on my machine) that both property node methods are slower than either the direct wire or local variable.

That being said, it may not make a difference in your application. It's really going to depend on what it's doing. And with the over abundance of CPU power, you may not need to worry about it much. As long as you be sure and watch for race conditions.

One thing I can tell you for sure, if you decided to take the Certified Developers Exam, you would not pass if you structured the application you have to build using property nodes like that.

Ed


Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
0 Kudos
Message 10 of 12
(3,369 Views)