Passing result of a sub VI to a top level VI using Value Signalling node

[QuantumPenguin]

Hi All,

I have two sub VIs inside - both using event structures of a top level VI, the first generates a value when a button is pressed. I then want to pass this result to the second VI's input, updating the control with a signalling node. The second VI then generates a result being triggered by a value change on its input control. 

The problem is the result is never passed to the second sub VI through the top level VI. The easiest solution is to combine the two VIs into one and have a second case structure -- I have done this and it works, without updating the top level VI control. But for various reasons I need to keep actual routines separate and specifically use Value Signalling to update controls on the top level (that is in particular important).

I have attached some model VIs 

[crossrulz]

You are going down a path that will just lead to lots and lots of headaches.  I recommend a rearchitecture.

In general, all GUI interfaces should be done by the GUI VI.  So you should have a loop on the top level VI that has an event structure for handling all of your button presses, update values, etc.  You then use Queues to send messages to your subVIs (that are running in parallel) for when the buttons/values were updated.  You can use User Events to send data back to the top level GUI loop.

[QuantumPenguin]

Thanks for the reply crossrulz. i am starting to get headaches from this now, I just ran into a problem where I have a subVI which reads an oscilloscope in real-time, however I can't pass the XY graph back to the topVI...essentially the same problem.

I realise that the architecture isn't the smartest, but redesigning it is annoyingly not an option. I don't suppose you could make a small example demonstrating what you have told me? 

[Ben]

---

@crossrulz wrote:

You are going down a path that will just lead to lots and lots of headaches.  I recommend a rearchitecture.

In general, all GUI interfaces should be done by the GUI VI. ...

---

For simple VIs yes for complex I experience as sense of deja vu with flash backs to LV 5 when we had to use attribute nodes that had to be in the VI that owned the control/indicator. Complex applications quickly became obscured with the GUI fiddling and the flow of the application wa shard to follow. I suspect most the "horror story" VI images that NI will use are actually VIs developed in LV 5 or prior and updated without changes.

I take a different tack and use sub-VI that are dedicated to distinct parts of the application and let them do the manipulation of the GUI that is required for their assigned responsibilities in the application.

Example:

Configuration - related work is done by a sub-VI that monitors the controls and indicators of the configuration part of the application.

Test Control - runs the test and keeps the associated controls and indicators updated.

Review - does the work related to reviewing data after the fact.

Using that approach makes it easy to find a starting point to fix a problem ... "Problem with configuration? Start with the Config sub-VI". "test does not run right? go to the Test Control sub-VI.".

The images in my gallery named "GUI_Controller" has images of how the use of sub-VIs can be used to clean-up the code. Look over those images and ssee if the threads where they were used offers some insight.

Now to the original question of this thread...

The GUI can be viewed as an I/O device that allows you to gather information from the user and return results for display to the user. It is not a communication mechanism!

It sound like what you really want are the new Channel wires that will let you pass information directly from one place to another, broadcast to many listeners, etc. depending on which flavor of channel wire you choose.

Just my 2 cents,

Ben

[QuantumPenguin]

Hi Ben.

Thanks for the perspective. This is what I am trying to achieve I wanted more modular code that I could bug check or modify in a more sensible way. Presently, the group I am in has extremely large VIs which make the BD unstable and crash. Aside from that it is just a total pain to read.

I think I am using the wrong approach, the problem for me is I often want to update the controls at the top level VI and I don't know how to do this in a sensible way. 

Could you elaborate a bit more on your suggestion about adding new channel wires and listeners? This isn't a technique I have seen or used before!

Thanks very much!

[Ben]

LV 2016 has help files for Channel wires.

First Q... are you using 2016 or better?

Ben

[QuantumPenguin]

Presently running 64 bit LabVIEW 2014, if you know a method for that version that is fantastic. I can however upgrade if it is essential.

[Ben]

Channel wires are worth the effort to upgrade but keep in mind that channel wires (I believe) will not back-save to 2014.

If you are working with 2014 then take the time to study the functions available under the "synchronization" palette. You a selection to choose from each has their own personality while some can over-lap.

Then look at the nature of this "connection" you are trying to implement. Ask yourself question to characterize the connection that will help you determine which of the "synchronization" methods to use.

Example:

I need to pass more than one message from X to Y and make sure that Y gets all of those messages in the order they were sent." That would be queue.

Getting a good handle on the synchronization palette will also help with understand the channel wires. In many ways Channel wires have the features of the other synchronization methods but are much easier to use and ... once you get use to the fact that they do not force data flow... are much easier to SEE.

A multi-stage Producer/Consumer could look like this;

A Channeled Message Handler (new form of Queued Message Handler) could look like this;

See this thread to find those two examples in LV 2016.

Bottom line, get to know the tools that LV has built-in and when to use each. Using the right one will make your code easier to develop and support and the wrong one will complicate your life and those that follow in your foot-steps.

Using the "Value Signaling" to communicate between sub-VIs is an example of the classic phrase;

"If you only know how to use a hammer, everything looks like a nail."

So as Crosrulz suggested you may want a queue but that is a decision that you should learn to make and figure which tool to reach for when the time comes.

Ben

[crossrulz]

---

@QuantumPenguin wrote:

I don't suppose you could make a small example demonstrating what you have told me? 

---

Have a look at the Continuous Measurement And Logging template.  It is is a decent template that will show how to handle multiple processes using Queued Message Handlers.