Calling a VI in a subpanel with parameters inside an event structure and using an abort button

[.aCe.]

Ok, here is a very quick implementation of what I meant. It may look daunting but using the right architecture will pay dividends in the long run.

Hope this helps.

[Marty_H]

Hi,

I understand what you have done, but you have not executed any subVIs in your events that contain for loops (say for controlling a frequency sweep and reading some powers) and then allowing the main VI to communicate an Abort to it and stopping it.  This is what I have shown in my example code.  Can you see what I am getting at?

Regards

Martin

[.aCe.]

As mentioned, its a generic implementation. What you can do with the architecture is add cases to you consumer in the subpanel to do whatever you want it to do. So send a message from the main vi to the subpanel 1 to "FrequencySweep" and in your subpanel consumer, have a case to do what you want. You can also post a message back to the main that the action is complete.

The stop button on front panel will STOP the others as well.

The difference between yours and mine is that you start the subpanel everytime, where as mine just waits for any commands from the main vi or from its own front panel. Hope this helps.

[Marty_H]

Hi,

I like the architecture, but you run the VI using the Run VI Invoke node.  I want to run the VI using the normal VI Icon with inputs and outputs so I can pass for example a frequency list and return the set of powers.  In my first example I posted, I used the Run VI invoke node and the abort button works great, but as soon as I want to pass parameters and get back data I have drawn a blank.

Would you have to send the data using queues implementing this architecture?  Is there no other way of syncronising VIs using the standard VI Icon on the block diagram.

Thanks for help

Martin

[.aCe. · Accepted solution]

You are queuing messages, you can pass data along with that as well. The message type def has a variant, so you can literally pass anything you want. Using abort to stop a vi is a very bad practice, as you dont know the state of the subvi when you abort it. It is always a good practice to close all references and stop the while loop, which the architecture allows.

[DFGray]

I posted an example of how to do this sort of thing awhile back, although I used user events, not queues.  You can find the example here.  You may want to walk through the rest of the series, as well.

As a side note, user events are better suited for broadcasting messages to many receivers (1:N).  Queues work better in point to point (1:1).