It is possible to save a VI as a buffer (string) using scripting. A reference to this buffer saved VI can then be opend using scripting as well. The problem with this kind of VI is that LabVIEW doesn't know they exist and cannot recompile them when something referred by the VI changes.

I'd like to script a top-level VI for each XNode instance so that the content of the scripted VI depdens on the configuration of the XNode. The important issue here is that the VI must be top-level i.e. I need to be able to call it asynchronously. At execution time XNodes are always called syncrhonously to my knowledge, aren't they? So I was thinking placing a static VI reference on the code generated by the XNode and use this reference to call the VI asynchronously using Run VI method.

The problem is that I don't find good solution to do this. If I script a new VI, it needs to be saved somewhere. From usability point of view, the internal VI needs to be unexisting for the user. So I cannot save it into an external file. I could save it as a buffer that's stored as state parameter of the XNode. However I expect that this method would lead into many problems as LabVIEW cannot compile the VI in the buffer when something changes. For example if a VI containing such XNode is opened in another LabVIEW version, the buffer would not be recompiled properly.

So I guess the only option I can think of is to save the VI within the XNode containing VI or the XNode instance somehow. I know LabVIEW class controls are VIs stored within an lvclass file. I'd like to kind of save my scripted VI within the VI as a kind of internal subVI that would be recompiled when the outer VI is recompiled. But I've no idea if this is possible. Does anyone have any idea if this is possible? I would not like to use explicit linker depdendesies as Aristos Queue so strongly demanded not to use them. That is always the last option left...

Tomi

Tomi,

I have used this VI buffer technique in the past several time (basicaly reading the VI as a text file and saving the end result as default in a string control). I don't understand why you say that LabVIEW will not recompile this VI. As soon you "extract" this VI to disk, it becomes like any other VI. I guess I don't quite understand your use case scenario.

Note: I have seen the scripting buffer function and while I never had to try them, I always though that the App:Open.VI from Buffer method was the equivalent of extracting the VI to a temp location and them opening a ref to it.

PJM

But in my use case I would never be able to save the VI into a file. It would only exist as a string buffer in a state information of an XNode. As LabVIEW doesn't know this particular string is a VI, it doesn't know that it needs to be recompiled every now and then. I was indeed looking for methods to get it recompiled without saving it to an external file. External file would be usability wise so bad an alternative that I cannot consider it as an option. Nobody would accept a situation where LabVIEW would generate several support VIs for every user defined VI on its own. Only if these VIs can be somehow stored within the VI and LabVIEW would load them into memory together with the VI with front panels closed, only then the solution would be acceptable.

So is there a way to store a VI inside another VI and get LabVIEW to load the inner embedded VI into memory when the outer VI loads to memory and compile the inner VI like any other VI and save it together with the outer VI when ever the outer VI is saved?

Ok, I understand now.

This method (although deprecated in 8.5) should do this (I have not test it though).



PJM

 Open_VI_from_Buffer.vi ( 4.79K ) Number of downloads: 245
LV8.5

Ah, wayward traveler! A word I would whisper in thy ear! Know ye the toolkit known as Block Builder? 'Tis a tool of the devil, the one they call "Express." But in yon toolkit ye shall find the secret that you seek -- the magic of hiding one VI within the confines of another. I canna say how such transsubstantiation is accomplished, for I have ne're learned the trick. But a black magician such as yourself should have no trouble ferreting out the diamond in the rough.

Thank you, ah mister, for thy guidance! Thy words of wisdom of great help are! Lord praise you mister, lord praise.

Aristos Queue, it works! But only within development environment There seems to be a bug in builder that drops the instance VIs from the build... I reported it to NI and for their shake I hope they will fix it soon. I'm still going to use this method and if not fixed, I guarantee they are going to get a plenty of bug reports from you all

If a static VI reference is created into an instance VI (Express VI isntance), the instance VI can be referred using a VI reference. If one wishes to use Run VI method, one needs to place the instance VI itself on a disable diagram to avoid reserving the instance VI for subVI exection when the main VI executes. This method works properly in development environment but build applications exit with internal error. It's presumable that builder simply mistakenly excludes the instance VI from the build.



To reproduce:

- Open the attached project
- Open the only VI in the project
- Run VI in the development environment, notice that the instance VI is executed properly
- Now close the VI
- Build an application according to the build specifications
- Execute the application, note that it doesn't execute but stops at internal error

It's not a mistake to exclude the instance VI... you commented out the Express VI node, thus app builder would assume that the instance VI would never be callable. Try using a case structure with constant FALSE instead (use a control, not a block diagram constant or LabVIEW may again get too smart for you). Again, just a guess.

I diagree. I think it is a bug. All VIs referred by static VI references should be included into the build. Instance VIs should not be any different in this respect. When I place any other subVI on the disable diagram and create a static VI reference to this subVI, builder includes the VI into the build, because I have the static VI reference referring to it.

The method suggested using case structure instead of disable diagram doesn't work. LabVIEW reserves all VIs within case structure for subVI execution. Then they cannot be called with RunVI method because they are in a state Run not compatible with top-level exection.

Tomi

Reentrancy?
Jeff Washington once mentioned that all express VIs needed to be reentrant.
Include it explicitly in the build file?

Ton

I don't think this is possible to explicitly include an instance VI into a build. The instance VIs are saved within outer VI and I don't think you can explicitly select them to be included, at least not interactively. Maybe one could edit the build specification manually but that's not very user friendly. I'm working on a user friendly framework and am not ready to accept usability wise poor solutions.

An instance VI path is something like

C:\My Project\My Outer VI.vi\1

where 1 is the name of the instance VI. The qualified name of the instance VI is

My library.lvlib:My Outer VI.vi:Instance:1

Actually I've not tested if instance VI will be included into the same library into which the outer VI belongs to.


Tomi