Programmatically check if VI is Desktop, Real-Time and FPGA compatible?

[Steen Schmidt]

Hi,

 

Do you know of a simple way to check programmatically if a VI (any LV file actually) is compatible with different LV targets (Desktop, Real-Time, FPGA)? Currently I plan on scripting an empty project, add Real-Time and FPGA targets, add the VI under each target and check for execution state. Since I expect this approach to be slow as ****, and a broken (e.g. under construction) VI will defeat the check in any case, I'm looking for a better alternative.

 

Is there some private VI Server methods that can tell me if my subject LV file is compatible with this or that target? Preferrably while loading as little as possible of the file into memory. Of course a VI and its dependencies need to be loaded to check for compatibility, but I want the process to stop as soon as a problem is encountered (since by then I know the answer is "not compatible"), and I definetely don't want the "searching..." prompt to appear if a dependency is not found at the expected path.

 

Looking forward to your input here!

 

Cheers,

Steen

[JamesMc86]

I hate to be negative but I suspect this is not possible. My reasoning is that g code is g code. It only breaks once you try and compile it for a particular target which requires opening it in the correct context. I guess the defining characteristic is that the unsupported functions could mostly be summarised in a few rules. E.g. Anything using a dbl data type can't run on FPGA, I bet using scripting you could rule most VIs out of fpga execution pretty quickly. RT is harder as the differences are more subtle. I suspect this may all end up being slower though. Cheers,James

[shoneill]

Is it possible to programatically create a RT or FPGA target and copy the VI there to see if it's broken?

 

Anything else is way too much work.

 

Shane.

[Oakromulo]

Nice question... I'll call NI Support team to check that. The ability to know programatically if the VI is compatible with VxWorks or Pharlap would be really useful for some generic LV classes/libraries.

[Steen Schmidt]

Is it possible to programatically create a RT or FPGA target and copy the VI there to see if it's broken?

 

Anything else is way too much work.

 

Shane.

 

Yes, that's perfectly possible, but it doesn't solve anything - I ruled this option out from the very beginning. By looking for a broken VI on a specific target type you can't determine incompatibility with that target. The VI can be broken for any number of reasons beyond incompatibility with Real-Time or FPGA.

 

There isn't any way but brute force object traversion looking for target-incompatible objects...

 

/Steen 

[shoneill]

Yes, that's perfectly possible, but it doesn't solve anything - I ruled this option out from the very beginning. By looking for a broken VI on a specific target type you can't determine incompatibility with that target. The VI can be broken for any number of reasons beyond incompatibility with Real-Time or FPGA.

 

There isn't any way but brute force object traversion looking for target-incompatible objects...

 

/Steen 

 

Well I would think defining a broken VI as being incompatible with a target would be a valid response.

 

Seeing how it is incomplete it cannot run on the target.  Testing a broken VI for compatibility seems to be a bit wierd if you don't mind me saying so.

 

Is there any way to get the list of errors or warnings for a given VI?  If so, then filtering them would give you the information you need.  If not, it would make for a great idea on the Idea exchange.

 

Shane.

[JamesMc86]

Maybe for efficiency you can use both. First look for some common causes e.g. Floating point maths on FPGA which will rule out most things but it would be difficult to catch everything (for FPGA I bet this could catch 99% between using floating point, using non fixed arrays and not using the call library node.). Then do the test opening it on the target, if it is not broken it is compatible, if it is broken you can flag that file as inconclusive and highlight the VI which is broken. The harder one is actually RT I think because there are not many specific functions that make it broken under RT, it is more of a code style that needs to be considered. in fact the only things I can think of right now is if you are calling a dll and need a .out for VxWorks and if you are using front panel property nodes (but these won't break the VI, they just don't function when built) so this is pretty tough. If I was approaching this I would be tempted to make VI analyser tests for common compatibility issues to make it easy to run. You may not catch everything, but you can rule out a lot.

[Steen Schmidt]

Well I would think defining a broken VI as being incompatible with a target would be a valid response.

 

Seeing how it is incomplete it cannot run on the target.  Testing a broken VI for compatibility seems to be a bit wierd if you don't mind me saying so.

 

I don't mind you saying so .

 

If the questions are these, the project-approach makes perfect sense:

 

a) Is this VI runnable on Desktop?

b) Is this VI runnable on Real-Time?

c) Is this VI runnable on FPGA?

 

In my use case the questions are these however:

 

a) Is this VI incompatible with Desktop?

b) Is this VI incompatible with Real-Time?

c) Is this VI incompatible with FPGA?

 

In the latter case the project target test may be inconclusive for a VI under construction (and thus possibly broken).

 

Is there any way to get the list of errors or warnings for a given VI?  If so, then filtering them would give you the information you need.  If not, it would make for a great idea on the Idea exchange.

 

There's unfortunately no way to get that information, and it has been requested of NI at several occasions.

 

Cheers,

Steen

[Steen Schmidt]

The harder one is actually RT I think because there are not many specific functions that make it broken under RT, it is more of a code style that needs to be considered. in fact the only things I can think of right now is if you are calling a dll and need a .out for VxWorks and if you are using front panel property nodes (but these won't break the VI, they just don't function when built) so this is pretty tough.

 

There are a number of other things too, for instance everything in the Real-Time palette, stuff in conditional disable structures that need consideration on one target but not the other etc. But anyways, I don't actually think it's that big a deal - I'll see if I can come up with some recursive way to check compatibility.

 

If a VI is optimized for Real-Time or not is another situation - that will be quite hard to determine. Almost every VI will fail such a test if it is rigorous in any way. Just completely avoiding dynamic malloc is almost impossible for instance. I think it's more realistic to classify code as Real-Time compatible by aiming for the correct tradeoff that'll let the specific target hardware perform deterministically. Along the lines of 'on powerful hardware you can allow some dynamic malloc, for light hardware you must eliminate dynamic malloc completely' etc. This will be next to impossible to weigh with the current tools, especially with the many ways in LabVIEW to prioritize code execution. And then emerging technologies (like deterministic dynamic malloc) skews the rules of thumb all the time.

 

If I was approaching this I would be tempted to make VI analyser tests for common compatibility issues to make it easy to run. You may not catch everything, but you can rule out a lot.

 

Can't use VI Analyzer as that is not a free toolset, and I'm limited to plain vanilla LabVIEW.

 

I was hoping for an answer along the lines of "the compiler internally calls this method to determine Real-Time compatibility". No dice. Thanks for your feedback anyway.

 

/Steen

[Aristos Queue]

This is easy.

 

Write a VI that has a conditional disable structure on the block diagram for each of the cases you want to identify. "Desktop" or "RT" or "FPGA". Then have each frame output the appropriate value of an enum. When you call that subVI in your code, you can test that enum value.

 

Now, as for why you would want to do that instead of including the conditional disable in the calling code so as to avoid the runtime check, I have no idea. But assuming there is a good reason to do that, the solution above should solve your problem.

[Steen Schmidt]

This is easy.

 

Write a VI that has a conditional disable structure on the block diagram for each of the cases you want to identify. "Desktop" or "RT" or "FPGA". Then have each frame output the appropriate value of an enum. When you call that subVI in your code, you can test that enum value.

 

You should always be suspicious when you think "This is easy" to one of my questions .

 

In this case you've misunderstood my objective. You're right it's easy to determine at runtime which target type you execute under, but my objective is to determine if a given VI is compatible with each target type. So I want to make some G code that takes as input a path to VI A, and then outputs a Boolean that is True if VI A is compatible with FPGA for instance. VI A never gets run, and VI A may not even be runnable at the moment it's checked.

 

The latter case, where VI A is still under construction, makes it insufficient just to add VI A to an FPGA-target in a scripted lvproj and check for runnability for instance - VI A may be broken due to incompatibility with the given target, or it may be broken due to it's still under development. Therefore I seek a different method for determining target compatibility; one way would be to evaluate each and every BD object against a positive (or negative, whichever is fastest) list for each target. In that light a wire stump will not invalidate VI A from FPGA compatibility, while a DBL constant will.

 

/Steen

[ShaunR]

 one way would be to evaluate each and every BD object against a positive (or negative, whichever is fastest) list for each target. In that light a wire stump will not invalidate VI A from FPGA compatibility, while a DBL constant will.

 

/Steen

I think this is the only (reliable) way.

 

The functions and features supported on each platform are documented (example) but not in a single list that I'm aware of so you would have to spend a bit of effort pulling it all together (property nodes have tables in the help that state quite a bit about where they will and won't work).

 

 

 

Once done however, it can be put in a DB along with LV versions etc making examining a VI fairly straight forward with scripting. You would just need to keep the list updated with the latest LV version. You never know. Maybe NI have an internal doc that pulls it all together. Worth asking your local rep.

Edited March 28, 2013 by ShaunR

[Aristos Queue]

Wait... so you want to be able to do this *without* loading the VI on the actual target?

 

I'm fairly certain that *we* could not write something that a priori said whether or not a VI would work on a given target because each target defines what it accepts. It allows us to write new features into core LV and have targets add support for those over time. Functions that work on one FPGA may not work on all FPGAs... functions that exist on one desktop target may not exist on all desktop targets. It is up to the particular target to decide whether to accept the code or not when the VI loads on that target.

 

So, no, I don't think there's any way to do this short of loading the VI on the target and seeing if it is broken and, if it is broken, removing it (if your goal is to only include non-broken VIs). And if you build any sort of caching scheme for that information, you would want to invalidate that cache whenever the LV version bumps.

 

 

I think this is the only (reliable) way.

 

 

 

The documentation is a broad categorization of yes vs no, but any specific target may have differences with the general declarations. I would say the only reliable way is to load a VI on the target and see if it is broken. (Notice that table doesn't say anything about FPGA, for example.)

[ShaunR]

 Functions that work on one FPGA may not work on all FPGAs... functions that exist on one desktop target may not exist on all desktop targets. It is up to the particular target to decide whether to accept the code or not when the VI loads on that target

Right! So that must be documented somewhere (as it was for the Single Precision Functions in the FPGA example I gave). I doubt if the "rules" for the particular target are that esoteric that you can only load this single precision object on this FPGA target when it's Tuesday and you have your left trouser leg rolled up. It's more likely that it will be things like an FPU isn't present on that target (that will be documented internally at NI) and the manual will supply the features that are or are not applicable.

 

The OP says that it may not load on the target because the VI may be broken due to wiring, missing dependencies etc. So he is looking to weed out incompatible features (like the DLL checker that is used to check Pharlap DLLs). This is presumably so they can write it "offline" and verify the developer hasn't used unsupported features,

 

At the simplest level you are trying to end up with a compatibility matrix accross LV versions, targets and features. I would be very surprised if an engineer at NI hasn't got a spreadsheet with it somewhere (probably an applications engineer) Once you have that, you can add simple rules for "odd" anomalies. You don't have to start with all targets or LV versions. However, eventually you will have a complete picture. After all. Most people that use the targets "know" what does and doesn't work. It just needs to be formalised to be able to use it programmatically.

[Aristos Queue]

> So that must be documented somewhere

 

No, it doesn't have to be documented anywhere. And as much as you are willing to bet that it exists as a spreadsheet somewhere, I'm willing to make the counterbet. Why would I make the counterbet? Because I was working on this exact problem last month, and the only definitive way I found to identify whether a given primitive/datatype/control/subroutine/configuration was valid on a given target was to let the target syntax checker run. An individual node may be generally known to work on a target, but not in one of its configurations. Or only if the project is configured a particular way. The edge cases are rare relative to the total number of nodes, but there are still plenty of them.

[ShaunR]

An individual node may be generally known to work on a target

That may sufficient for the OP and it is a lot closer than nothing at all..

[Steen Schmidt]

Ok, so there are many corner cases which makes it quite a task to make such a compatibility matrix, not speaking about maintaining it.

 

What I'd most like to do was make a project (scripting, very easy), configure it with the target in question, and add the subject VI to that target and examine the syntax checker's output. First hurdle is that it takes a long while to execute all this for an exhaustive number of targets/configuration combinations; the scripting part at least takes one second per project + config, often 2-3 seconds. Considering this conformity verification/rectifier tool will typically run on 50 to several hundred files at a time, it all adds up. I can live with this, and there are ways to optimize the execution time and so on.

 

But the second obstacle is impossible to get by; it all gets blocked by the fact that I can't get to the output of said syntax checker. I can invoke the 'Error list' manually by pressing the VI's broken Run arrow, and it'll tell me stuff like "Diagram Constant: Type not supported in current target". NI has been prompted on several occasions to publish an entry point that lets us access this info programmatically, but it's not possible yet (obviously for very good reasons, I don't doubt nor contest that). My hope when submitting this post to Lava was that someone knew a backdoor that'd let me run this syntax checker on my VI and evaluate its output.

 

So far it seems the options stand between an undefendable amount of work or an impossible task. In that case I must opt for a lesser functionality in my verification tool, which isn't completely shocking to me. But thanks for your time anyway .

 

Cheers,

Steen