Labview not recognizing event for changing control.

[iyeager]

I'm having some trouble with an application I'm working on. I'm trying to create a UI that updates some indicators and sends out an analog output. I'm using a queued state machine and can't figure out why the control doesn't update the output.

Anyone able to take a look?

Uploaded a picture, can upload the .vi if need be.

-Ian

[RavensFan]

It would be better if you attached your VI so we can play with it and see if we understand what you are talking about.

At face value, I can't see why your VI wouldn't be working.  Although usually it is a good idea to pass along the value in the queue element as well.  If your queue datatype was a cluster of the enum and a double, you could enqueue the new value and unbundle it in the consumer loop, then it wouldn't be necessary to use a local variable of the control.

[iyeager]

Check out the attached .vi. Using a cluster is actually a much better solution since eventually there will be four or five analog values to send as outputs from the UI and a handful of booleans as well. Probably better to send them along in the queue. Although, if I can't get it to work right, I guess it's a no-go anyway. More than likely something simple here that I'm missing.

To get the controls and indicators to show you hover over certain areas of the front panel. I highlighted (highlit?) the load valve red so that you can see where you need to hover.

-Ian

[RavensFan · Accepted solution]

The problem is that you have the data being sent into the queue on the Valve Position Value change event.  That is a boolean you have on your front panel.  And since it is an indicator, you can never actually have a value change event unless you do it programmatically.

I think you want your value change event to be associated with the "Valve Position Value" control.

Two other comments.

One, you should wire your queue reference wire through all event cases.  If you don't, there is going to be some odd program situation that will occurr, particularly as you add to your program that will cause the data in that wire that leaves the event structure to be stale and set for its default value.

Two, while I know you have some reasons for hiding and showing the controls, having controls appear and disappear like that doesn't seem to be a very friendly user interface considering it is difficult to tell how to make them appear when you want them to.

[RavensFan]

In many of your event cases, you are dealing with pairs of events that have identical code except for whether you are writing a True or a False to the visibility property nodes.  Mouse enter is write a True,  Mouse Up is write a False.

You can combine those event cases into one and do a simple comparison to determine whether the controls should be visible.

[iyeager]

The reason I split it up is because I want to only open certain indicators for each area. The final design has highlighted areas to give some indication as to where to hover to open them. The idea behind it is that this one cell has roughly 50 I/O points, not all of which are neccesary for every test, (i.e. sometimes they don't use intake piping and don't care about intake temps.) Also, many of our temps and pressures are averages of more than one sensor. There's a .vi that detects outliers and illuminates a boolean, allowing you to decide if the outlier is acceptable or to disable the input from that sensor. Operators don't need to see all of that info all of the time, but it's handy to make it easily available to them if they do need it.

Swapping the event structure around for the correct event is what it took. I knew it was going to be something simple that I'd overlooked. Thanks.

-Ian