"Does VI have block diagram?" at runtime?

[Steen Schmidt]

Hi,

 

I'm looking for a way to determine if a VI has its block diagram or not in the runtime engine.

 

Assume I have the VI reference. In the dev environment it's no problem, but the runtime engine does not support either of these methods:

 

 

 

The latter should be supported in the RTE, according to NI documentation, but in fact it is not. Any clever ideas short of examining the file bits on disk (which is a flaky approach)?

 

Cheers,

Steen

[JackDunaway]

Unless something has changed since LV2010, determining whether the BD exists in the RTE will be hard: http://labviewwiki.org/Loading_vis

 

It appears that `Metrics: Block Diagram Loaded` "works" in the RTE, but it is hard to test since it is hard to load the BD (as per above link)

 

Have you tried exported LVRTE function `REdLoadResFile()`? That might not be so flaky as the naïve approach to examining the bits. Good luck!

[hooovahh]

Unless something has changed since LV2010, determining whether the BD exists in the RTE will be hard: http://labviewwiki.org/Loading_vis

Oh it's not hard, it's you just need to use unconventional tools.  A while ago I posted a bunch of VIs that open up the VI file structure.  Normally you provide a VI as a path, then it reads it, analyzes it and tells you what blocks are in the VI and at what offsets.  This can then do things like read the VI description, VI icon, and a bunch of other things without opening a reference to the file.  This same code could be used to analyze VI files without LabVIEW too.

 

Anyway so I made a couple VIs one with a block diagram one without, and looked at what blocked were missing then found a couple that start with BD and assume that has to do with the block diagram.

 

So attached is some code.  Open Perform Test which will have two static VI references in it.  One to a VI with a block diagram one without.  It will then perform a save VI as a buffer, then using that buffer will find the blocks, and look for the BD ones.  I also built and EXE and it also worked from there too.

 

One downside is the VI without a block diagram was saved in 2013, so this exact test only runs in 2013, but if you provide your own VI without a BD in whatever version you have it should work.  Couple of undocumented features being used here by the way.

Block Diagram Test.zip

[JackDunaway]

Oh it's not hard, it's you just need to use unconventional tools.  A while ago I posted a bunch of VIs that open up the VI file structure.

 

`YourExample::Get All Block Data.vi` == `lvrt::REdLoadResFile()` 

[hooovahh]

You know I kinda thought it did.  Do you have a pre-made VI that calls that with the right inputs that you could share?  Oh but that only works on a VI path right?  I can load the Block Data from a stream of bytes, not that it wouldn't be hard to save to a temp file.

[Stinus Olsen]

Would this do the trick?

 

Check for BD.zip

[hooovahh]

Would this do the trick?

Thanks you and this is nice, but I'm guessing this only works if the full LabVIEW development environment is installed, because this relies on that ever so important REdLoadResFile call Jack mentioned earlier.  Still this is helpful and I will look into modifying my VI File Structure code in the future to have that option, since it probably is less error prone and more flexible than my manual method.

[Stinus Olsen]

Thanks you and this is nice, but I'm guessing this only works if the full LabVIEW development environment is installed, because this relies on that ever so important REdLoadResFile call Jack mentioned earlier.  Still this is helpful and I will look into modifying my VI File Structure code in the future to have that option, since it probably is less error prone and more flexible than my manual method.

 

Nope - the REdLoadResFile function is a public export from lvrt.dll as well. So you should be good to go with the RTE too..

(at least until NI some day decides to remove it for various reasons)

Oh and by the way - here are the two missing functions to make the subVI folder complete..     (insert and save functions)

Have fun....

Missing SubVIs.zip

[Steen Schmidt]

Thanks Jack, Brian and Stinus :-)

 

Sure, raw VI file examination will work (and thanks for the work you did on this). I'd rather avoid it, as the file format will change and thus we'll have some work cut out for us to keep up with different LabVIEW versions.

 

Stinus, your VI can't grab a  subVI by path inside an executable (I've attached a project that demos this). This might be due to something external to LabVIEW, didn't put too much thought into it just now (I'm on vacation ;-). I'll take a look at it again later.

 

Take care y'all!

 

Cheers,

Steen

 

PanelsPresentTest.zip

[hooovahh]

Sure, raw VI file examination will work (and thanks for the work you did on this). I'd rather avoid it, as the file format will change and thus we'll have some work cut out for us to keep up with different LabVIEW versions.

Well it hasn't changed since version 5 or so.  This block format is likely here to stay.  What may change is what the 4 letter abbreviations are or stand for.  I assume if it starts with BD is is for the block diagram.

[Steen Schmidt]

Well it hasn't changed since version 5 or so.  This block format is likely here to stay.  What may change is what the 4 letter abbreviations are or stand for.  I assume if it starts with BD is is for the block diagram.

 

Yes, and I'll likely use this approach until a better one emerges (e.g. when VI Server gets fixed to support this natively as the doc suggests it should be able to).

 

/Steen

[Stinus Olsen]

Do you have a specific use for it to be able to read the VIs from within a built executable - or was it just a way of showing that the functions won't work with files in a executable image?

Because thats a limitation of the NI function I guess

I agree that the VI Server should be fixed, or the doc revised to correspond to the code - but if it's a matter of creating a 'temporary' workaound, it shouldn't prove that hard!

I.e. you can access the VI files inside a LabVIEW executable image - but the non-NI way is not as easy as a simple property node (nor as pretty).

 

Depending on whether the solution should run on RT/Linux, you could use the Windows API to unpack the main resource from the executable, then work from there, whereas if you

were to do the check on RT or Linux you would have to manually unpack the contained resource.

After that you would then parse the output (de-XOR'ed) archive, find and unpack the Resource Fork (VI File) in question, and finally use the REdLoadResFile approach from there..

As I said - not pretty or tidy, but definitely doable...

 

 

Edit: fixed minor RT / Linux confusion..

Edited July 1, 2015 by Stinus Olsen

[Steen Schmidt]

Do you have a specific use for it to be able to read the VIs from within a built executable - or was it just a way of showing that the functions won't work with files in a executable image?

 

Nope, not a specific use. The thing is that the built-in way works perfectly well in the IDE:

 

and

 

It's only under the RTE that we need an alternative solution. Half the time under the RTE we're accessing wild VIs (dynamically loaded source distribs typically), the other half we're accessing VIs within the exe. Within the exe doesn't work that smoothly. Yes, I could grab those bits and shove them through REdLoadResFile through a proxy...

 

But my current use case is in the IDE (as we're talking about an edit workflow). I just like my classes to work in as many worlds as possible, so it pains me these won't work under the RTE  . NI US is looking into what's wrong with VI Server here. They'll probably end up fixing the documentation instead of the function  .

 

/Steen

[hooovahh]

Hey my solution should work in RT, Windows, and Linux, with or without the IDE, inside or outside of an EXE, by passing in a VI reference. Just saying.

 

(not certain about other platforms due to how the buffer is saved, but there are inputs to force it to Windows in which case I think it should work)

 

But if NI improved those functions that would certainly be a better approach.  Or if NI just saved the VI into a text file, or some kind of open standard, in which case looking for the block diagram using text would be trivial.

[Steen Schmidt]

Hey my solution should work in RT, Windows, and Linux, with or without the IDE, inside or outside of an EXE, by passing in a VI reference. Just saying.

 

Yeah, I know Brian, I was referring to the direct REdLoadResFile approach as that takes a path on which it croaks if that path is within an exe.

 

/Steen