Can I use 'System Exec VI' under RT?

[Dave_Bell]

I am moving an application under development, from Windows to the target RT system (PXI chassis, 8176 controller.) Under Windows, I was using 'System Exec VI' to start the main instrument loop, after completing an initialization sequence. Under RT, the initial sequence and System Exec VI run without error, but the second VI never starts. This may be due to not knowing exactly where or how to dwnload the second VI onto the target's hard drive...

[dafna]

Hi Dave,

I've used the System Exec call in RT before so it should work - I think your suspicion regarding the path of the VI is correct. You could ftp the VI you want to launch to a specific location... although the most obvious way to solve this problem is to use VI Server.

I would recommend that you ftp your VI to some predetermined location on your RT 8176 harddrive, then use VI server to launch that VI. This method is thoroughly tested and commonly used, and it gives you much more flexibility in how you launch your VI. It also has the added benefit of existing examples. In fact, on the Developers Zone there is an example that does exactly what you need - launch a VI stored on the PXI hard drive. Have a look: there is an example called Using VI Server to launch VIs stored on the hard drive.

Thanks,
Dafna

[Dave_Bell]

Thanks, Dafna! This helped me along towards what looks like the "right" way to do it, with VI Server.

Now... I grabbed the Server setup code from one of the examples, and put it in place of my System Exec VI call. Worked perfectly under Windows, so I changed the VI Path to point to the target VI, which I ftp'ed to the root directory of the PXI controller's HD.

Top level ran, but could find no evidence that the second VI was running. Probed and stepped through the top level VI, and found the Invoke Node returns "Error 1003: VI Not executable".

If I load the VI (SCANLOOP.VI) by itself, it runs fine under RT. (This does load it from the Host, though, not the RT hard drive.) I played with the values of the two Booleans supplied to Invoke, but
nothing changed. Any thoughts?

By the way - do you know of a straight-forward way for a VI to determine whether it is running under RT vs. Windows? The "Shared Mmeory Size" call I used is obviously a kludge!!

Thanks!!

[dafna]

Hi Dave,

I found this in a KB... "You need to create a library for your VI that includes all of the VIs that it uses, including VIs in the VI.lib directory." Follow this link for the full description of the problem and solution.

Thanks,
Dafna

[Dave_Bell]

OK!! This did make things work better. I was able to build a distribution llb of the second VI, and ftp it to the RT controller. I then targeted the top level VI to the RT box, and ran it, with execution highlighting on. This time, the complete sequence of steps, through the Invoke and Close Reference, executed, and each returned 'OK' in the error status. The target VI started up, as evidenced by its writing to a log file I added for the purpose.

Then, it stopped. Completely. It got through one iteration of its infinite loop, writing a trace to the log file, and quit... I considered the possibility that it failed due to the front panel not being open, per the one Boolean parameter passed to the Property Node. However, Property Nod
e always returns an error (-1), if the OpenFP param is set to True.

Today, I'm adding further trace log outputs, to try to see just where in the sub-VI tree it is halting...

[dafna]

Hi Dave,

I looked at your code and noticed a couple of things - first, as you suspected, FP.Open on VI server while targeted to RT will not work. From looking at your code it seems as though you are writing it such that it will be runnable both on Windows and on RT - is that right? Is that why you have the RT shared memory size error output connected to the case structure? In that case you might have to "comment out" the FP.Open call as well (on RT the front panel doesn't open anyway.)

One other small note - the RT shared memory VI is only written for the RT series plug in cards - not PXI controllers like the one you're using - although it's a pretty clever method for detecting if you're runnign on RT. I'll try to find a more int
uitive programmatic method.

Thanks,
Dafna

[Dave_Bell]

I found the problem, I guess:

When the "parent" VI terminates, it kills the child, also!

I hadn't changed the setting of the "Wait until done" Boolean to the Invoke Node, since getting the proper setup under VI Server. I just tried setting it to True, and the child process took right off, as planned. As soon as I (manually) stopped the parent, the child stopped.

Thanks for all the help and suggestions!

And yes, the Shared Memory Size VI was just a kludge to determine at run time, whether I was running under RT...Once this is running, I will pull all the Windows options out.

[dafna]

Hi Dave,

I made a neat discovery. It turns out that there is an application property you can poll to determine if you are running on RT or not. I've attached a VI that shows you how to do it but in general just plop down an property node and select Application>>Kind. If you connect a constant input to the terminal you will see the valid options. One of them is "embedded." Just compare the property to that and you're done!

Thanks,
Dafna

[Dave_Bell]

Perfect!! Exactly what I was looking for...

Now - two possibly dumb questions:

How do you create the constant you were comparing to? There must be an immense variety of possible Property values, so this appears to be directly related to the specific Application>>Kind selection, but how does one get it into a constant?
A frustration more common to many applications, not at al restricted to LabView, but how in the world do you FIND a tool like this, starting from needing to know what OS the app is running under? I searched all the available Helps, browsed all the VI functions that made any kind of sense (obviously, missing this one!), etc.

Thank God for support Forums!

Thanks!

Dave

[dafna]

Hi Dave,

I'm glad that helped. To answer your two (very valid IMO) questions:

1. There are many times when an input takes an enum (or a set of predefined constants) and what you need to figure out is what the valid set of constants is, or get a copy of the enum. The quickest way to get to that is to right click on the control and choose Create>>Constant. So in this case, start in a new VI. Drop down a property node. Right click on it and go to Properties>>Application>>Kind. Next, right click again on the newly defined property node and choose Create>>Constant. A constant will be created with all the valid Application "Kinds."

Another way to figure out what the possible values of this proper
ty node are to view its online help (just click Ctrl-H.)

2. This is a great point. I agree with you that this was a pretty hidden (though cool!) feature. If you know what you're looking for, it's possible to find - for example, use "embedded" as a search word in context help. Of course, if you don't know the right search words it can get tricky. The places you looked under are the right ones - online help, the web, etc. We just need to make this one easier to find... Please let us know whenever you come across such difficulties so we know to fix them!

Thanks,
Dafna