i using an event structure for an input box and also for hardware input

[matrix]

Hi there!

I have many input boxes and display boxes on my user interface and i have a case for it in the event structure. If the user changes the values of the input boxes, the particular event case writes this new value to the hardware. However, in the timeout section of the event structure, we read the inputs from the hardware and we set the value for its related display object.  Within the timeout section i set the value for the related user interface display component, by making use of the property node value.

Furthermore, for most of the display components, i have a event case for a value change associated with it. In that event case, i check for range errors and so forth.

My assumption was that when i read the value in from the hardware and set the property node value, the user interface component's value will change and it would then trigger the event of the value changed for that component. 

My assumption worked to the point of updating the component's value, however, it did not trigger the event  for the value changed for this component.

Please advise me on how to achieve what i wish to.

Thanks.

Regards,

[EdDickens]

The simplest solution would be to write to the "Value (Signaling)" property instead. This will trigger the Value Change Event for that front panel item.

Ed

[altenbach]

While Ed's answer certainly is correct, your programming approach seems a bit convoluted.

Events are mainly designed for UI interaction. It seems very unusual to trigger events from the timeout case of the same event structure. If things are not designed right, you have things constantly trigger each other and you'll get an event avalance.

Events are good for controls and less useful for indicators.

It seems silly to first write the raw value to a signaling property to trigger an event, which in turn does range checking and possibly correct the value. Somehow it would seem more logical to do the range checking first, right there in the timeout case, before the data even reaches the front panel.

Maybe I don't quite understand what you are doing. Do you mind attaching your program?

[EdDickens]

Not to mention the possibility of race conditions.   (I was going to write a bit more, but I got interrupted)

It sounds like there's the possibility of the user entering a new value and that value may get overwritten by the read action in the Timeout event. Then the new value would not get written to the hardware.

Maybe I'm not quite understanding what you are doing either. Maybe the reads in the Timeout are not writing to the same controls that the user is changing?

Ed

[matrix]

Hi again!

Thanks for all the responses, much appreciated!

Ok, let me try and clarify myself. For simplicity, i have analog inputs and digital outputs. So when i for example click on a "valve" component on my gui. I send a command to the hardware to open the valve, however, there are 2 inputs associated with a valve. The "openStatus" value will return true and the "closedStatus" value will return false. This is to ensure that the physical valve has opened. For this the event structure seems fine!

Then comes what i and from what you guys have said, is the problematic section. I need to constantly update the analogue  display values. These are display only, cannot be written to! So the user interface will not be able to change it. I think the reason why i put the "aquisition" of the data in the timeout case is  to sort of isolate the various steps. So i do the aquisition here (Since we cannot have an event case associated with the hardware itself, and the timeout section seems to be the ideal place, since it will always be executed, so we have a constant data aquisition!) and the range checking and alarming goes in the value-changed event case for each gui analog display component!

I hope this clears things up!

Please advise!

Thanks.

Regards,

[matrix]

Hey again!

I tried using the "value(signalling" property instead, and it does do what i want. Question is, is it the best way to do what i want to do?

Thanks.

Regards,

[EdDickens]

Constantly writing to Property nodes is not the best way to do things. Every time a property node is used, LabVIEW must switch the execution system to the User Interface thread (which takes time) and then switch back (more time). Not to mention it causes a copy of the data to be created.

Take a look at the attached VI. Open and run it. All it's doing is generating a random number and writing that value to the indicator through a property node in a For loop that runs 10,000 iterations. On my machine, it takes about 450ms to do this through the property node. Now delete the node and move the indicator into the For loop and wire it directly to the random number function and run it again. My time with this setup is about 5ms.

So depending on how fast your Timeout is executing, this may or may not be a problem. But it's something to keep in mind.

A better setup may to have your DAQ read in a separate While loop. In this loop, read all your data using a single read (or a single read for each device if needed) and parse the data and write directly to the indicators.

Ed

[matrix]

Hi !

Wow, thats amazing, I cant believe that the property node keeps the system so busy!

I guess i should rethink my use of the property nodes. I just found it quite convenient, when for instance you get a value in for example the true section of a case structure, and you also want to use it in the false or in some other section, then this seems like a convenient "pointer" type of thing! Furthermore, it meant that i did not need to have a hundred lines all over the show to link a control to various sections that require its value.. It made things so much cleaner and well as i notice it comes at a huge price!

What would be the best way to reference a value of some indicator or control from various sections which cannot see that pointer.

Thanks.

Regards,

[EdDickens]

Local variables are actually much more efficient than property nodes as far as execution speed goes. Take that same VI and delete the property node and instead write to a local variable inside the loop. You'll see the speed nearly identical to writing directly to the indicator. But note that variables also cause a copy of the data to be created. So if you're just using the "Value" property, you're much better off using a local variable. But don't use both at the same time. If you are reading/writing other properties when you update/read the value, you might as well use the value property.

Sometimes you can't get around using either variables or property nodes. Initializing controls to saved values from an ini file is one example. But in this case, they are only written to once as the application starts so the performance hit is negligible.

One thing you can do is store values in a shift register as they are read and pass this through your application so the last value read can be accessed from anywhere. You can even create a cluster that runs through the shift register to hold several values in a single register. This can be expanded a bit farther to create what's called a Functional Global. This basically a subVI with a While loop that only runs once on each call. It has a shift register to store data and a Case structure to Read or Write data into the register. There's a pretty good example that ships with LabVIEW showing how these work. Open the Example finder and search for "Functional Global Communication". This example shows how to use them to pass data between two independent loops, but they work just as well in a single loop application.

One of the big advantages of these Functional Globals over the standard LabVIEW Globals and local variables is that you can add cases to manipulate the data in addition to just storing it. Also, since it's a subVI, access to the data is protected to one caller at a time whereas variables can have multiple reads and/or writes at the same time. This can cause race conditions.

Hope that helps a bit.

Ed