VI Execution Control?

[NeilA]

Hi,

I need to be able to control a VI execution programmatically from my executive VI.

Basically I have multiple tests that can be selected and I need to be able to have pause, stop, abort and continue control over the "Test VI's" programmatically. I found an example through google on the NI site for pause and resume but it would not load as it was made in labVIEW 5 or something. Is there a way of doing this? could I be right in thinking that it is possible using VI Server or active X?

I would also like to be able to programmatically select if the toolbar is visible in the "Test VI's" based on if someone is logged in as a debugger or operator. Is this possible through VI property node?

I have had a quick look and done a few searches on here and the net and come up blank. Knowing my luck its my ability to use google that at fault lol!

Thanks in advance.

[crelf]

QUOTE (NeilA @ Jan 28 2009, 11:45 AM)

Basically I have multiple tests that can be selected and I need to be able to have pause, stop, abort and continue control over the "Test VI's" programmatically.

I know this doesn't answer you question directly, but I'd use TestStand.

[Neville D]

I think your application is a good candidate for using TestStand.

Neville.

[NeilA]

Yeah I know, thanks!

There has been a decision by people who dont necessarily know what they are talking about to move to LabVIEW from HT Basic which the executive was written in prevously. At the same time the previous system as a whole used to use Test Stand to control all of the ancillery equipment and the test execution using the HTBasic exec as an interface in remote mode. The company were not necessarily using test stand the way it is meant to be used and therefore have a dim veiw of its function in a properly set up test system.

Long story short I am being paid to reinvent the wheel in terms of the executive.

I do really need to find out how to programmatically control the sub VI's (test VI's) if I can. I understand you can run a VI in VI server but is there a way to get remote/run time control of the toolbar (where the run stop pause buttons are) and be able to show hide it at run time?

Thanks.

[Francois Normandin]

QUOTE (NeilA @ Jan 28 2009, 12:39 PM)

I do really need to find out how to programmatically control the sub VI's (test VI's) if I can. I understand you can run a VI in VI server but is there a way to get remote/run time control of the toolbar (where the run stop pause buttons are) and be able to show hide it at run time?

There are many properties and methods to allow you to control exactly what you're describing.

Check out these to start:

VI.FrontPanel.Open (Property node)

VI.RunVI (Method)

And I suggest you command the spawned VI with Queues or Notifiers (to instruct it to close for example...)

[LAVA 1.0 Content]

QUOTE (NeilA @ Jan 28 2009, 06:39 PM)

I do really need to find out how to programmatically control the sub VI's (test VI's) if I can. I understand you can run a VI in VI server but is there a way to get remote/run time control of the toolbar (where the run stop pause buttons are) and be able to show hide it at run time?

QUOTE (normandinf @ Jan 28 2009, 06:56 PM)

There are many properties and methods to allow you to control exactly what you're describing.

Check out these to start:

VI.FrontPanel.Open (Property node)

VI.RunVI (Method)

And I suggest you command the spawned VI with Queues or Notifiers (to instruct it to close for example...)

And VI.Abort (method).

Pausing a VI is afaik not possible.

Ton

[Neville D]

You can also open the required VI in a subpanel, allowing you full control of its front panel.

N.

[crelf]

QUOTE (NeilA @ Jan 28 2009, 12:39 PM)

Long story short I am being paid to reinvent the wheel in terms of the executive.

That's a shame - I'm sorry to hear that.

Anyway, you can run (use the VI.RunVI method) and abort (use the VI.AbortVI method, not that I think there is a reason that you'll need to do that). I'm pretty sure that pausing dynamically isn't an exposed method.

[Val Brown]

QUOTE (crelf @ Jan 28 2009, 11:25 AM)

That's a shame - I'm sorry to hear that.

Anyway, you can run (use the VI.RunVI method) and abort (use the VI.AbortVI method, not that I think there is a reason that you'll need to do that). I'm pretty sure that pausing dynamically isn't an exposed method.

I may be misunderstanding the application context but I believe that by using the same VI ref as for the VI.RunVI method you can also then use Invoke Method of VI.Control Value.Set to programmatically set the values of controls in the called VI. If there is, for instance, a Pause control (with that name) in the called VI, then specifying that name to VI.Control Value.Set would allow the caller to Pause the called VI.

[crelf]

QUOTE (Val Brown @ Jan 28 2009, 05:16 PM)

...by using the same VI ref as for the VI.RunVI method you can also then use Invoke Method of VI.Control Value.Set to programmatically set the values of controls in the called VI. If there is, for instance, a Pause control (with that name) in the called VI, then specifying that name to VI.Control Value.Set would allow the caller to Pause the called VI.

True, but then you'd need to design each little tester VI with the capability that, frankly, it shouldn't be exposed to - that's what the test scheduler is for. That said, the solution that Val has come up with might be your only hope.

[Mark Yedinak]

I would consider designing a simple messaging interface that and use that in all of your VIs you want to call and run. This messaging interface would have the actions of Start, Stop, Pause, Resume, etc. and be passed in to the subVIs via a queue or a notifier. The main application could create the queue and all the subVIs would connect to it when they ran. This assumes that there is only one running VI at any one time. If you need to control multiple subVIs at the same time I would consider using network queues. There is a nice example in a discussion from a couple of months ago (sorry, I didn't put the link in for you) that would allow each subVI to have its own queue. The main application would have to keep track of which queue went with each subVI but it could be down. If you define your queue data to be cluster of a message ID (integer) and a variant you allow yourself to do just about anything. This is a very flexible design and it scales nicely.

[Val Brown]

QUOTE (crelf @ Jan 28 2009, 02:57 PM)

True, but then you'd need to design each little tester VI with the capability that, frankly, it shouldn't be exposed to - that's what the test scheduler is for. That said, the solution that Val has come up with might be your only hope.

Understood and, in principle I agree, but I thought that the OP indicated Test Stand was not an option so....

And, yes, queued messaging would be a good way to implement the "accounting" system, esp in terms of scalability. However, it seems that retrofitting is the name of this game and generally scalable solutions don't scale too well to such unique retro situations. At least that's been my experience.

[jdunham]

QUOTE (NeilA @ Jan 28 2009, 09:39 AM)

There has been a decision by people who dont necessarily know what they are talking about...

You can always try the Dear Abby ploy: Go back and tell them, "Well I wasn't sure the best way to proceed, so I asked the experts some of the LabVIEW bulletin boards, and the unanimous reply was that my company is flushing money down the toilet by not using TestStand for this application. Many people find it is working great for this application and several people said that rolling our own would be foolhardy because it would take so much longer to write and then still need to be debugged."

Sometimes people get religious and this won't work, but other times the advice finds its way through the cobwebbed crania when it originates from outside the group.

Good luck!

[NeilA]

Thanks for all your replies.

I agree that my situation is not great, but I have to say that in this current economic climate I am not too fussed to be reinventing the wheel just pleased to be employed lol!

I am using queues to tranfer info and states between the executive and the TestVI's. The test its self is being ordered by building run time logic in to the states of the test VI's and I will pause by selecting the correct state. However, there is a requirement that may not be needed but should be implemented that will enable the user to pause execution of the test from the remote test controller. This could be possible by selecting pause as the next state but if I am in the middle of an important/damaging setup routine and there is something wrong it may not be good enough if you have to wait for the current state to finish. I have been told not to worry too much about this as often the abort or terminate states will be used which means I can implement the properties/methods in the replies above. I have attached the pause vi from the NI forum that I mentioned before, it is in labVIEW 5 format, I dont know if this is what I need or not as I cant open it. If anyone can help me with this in case it is what I need it would be great.

I have also had a quick look again at VI server properties and I have found the Toolbar:visible property which is great for the debug control I can just place this VI server routine inside the debug login sub VI.

Thanks again,

Neil.

[jcarmody]

QUOTE (Val Brown @ Jan 28 2009, 05:16 PM)

[...] use Invoke Method of VI.Control Value.Set to programmatically set the values of controls in the called VI. If there is, for instance, a Pause control (with that name) in the called VI, then specifying that name to VI.Control Value.Set would allow the caller to Pause the called VI.

I don't think that this will work if the Pause control is handled in an Event Structure because setting the value of a control doesn't trigger an event. I discovered this yesterday and ended up putting a Value (Signaling) property node in the Timeout case.

Jim

[Val Brown]

QUOTE (jcarmody @ Jan 29 2009, 03:27 AM)

I don't think that this will work if the Pause control is handled in an Event Structure because setting the value of a control doesn't trigger an event. I discovered this yesterday and ended up putting a Value (Signaling) property node in the Timeout case.

Jim

That depends on whether you want to trigger the event structure (Value (Signalling)) or just set the value and let the logic of that subs dataflow determine the action to take. Both are available and there can be reasons to use each, in different instances. For instance going into Pause=True one might want to make Run=False or something equivalent and that might mean Pause is Signalling whereas Run is just Value.

[jdunham]

QUOTE (jcarmody @ Jan 29 2009, 03:27 AM)

I don't think that this will work if the Pause control is handled in an Event Structure because setting the value of a control doesn't trigger an event. I discovered this yesterday and ended up putting a Value (Signaling) property node in the Timeout case.

Jim

You can set the value(signalling) property remotely. You have to get the control reference from the VI reference and the control name, but once you have the reference to the specific control, you can call any of the control's properties or methods.