How to programmatically get the formula node content

[maxprs]

Hi guys,

new to LAVA forum, this is my first post here.

I'm a long time LabVIEW user, and I'm stuck with a problem... so I thought maybe some one here could help me.

There is a formula node in my application (more than one, but let's find the solution for one), and the developer can change the formula depending on how it want to customize the application. What I need to do is to show the content of the formula node to the user, so he knows exactly what's the formula in use at the moment.

This must work on the deployed application, so with the run time engine. Infact the developer build the application after the customization of the formula.

I have tried the following:

1) I put the formula node in a separate VI, in order to capture the block diagram image and then show that image to the user. I've used the BD.Get Image Scaled method, but it's clearly written in the help that id doesn't work with the run time engine.

2) Using the report generation toolkit I can call the Append VI Block Diagram to Report to an HTML report. I can't find in the help if it is supposed to work in run time engine, but I've had bad experiences in the past with that tool. And it doesn't seem to work.

3) I've tried a different approach using the labview scripting. I'm able to open the object reference to the formula node and then to load its content in a string with the property Formula Expression. But once the application is built it doesn't work, even if I'm not creating any code with the scripting, just reading.

 

In the end I don't care if the formula is captured on an image rather than a string, or whatever... but it must be what is written in the formula node inside the executable.

Just wonder if I've used the above methods in a wrong way, or if there is a different way to do it.

 

Thanks

 

Max

[Rolf Kalbermatter]

Hi guys,

new to LAVA forum, this is my first post here.

I'm a long time LabVIEW user, and I'm stuck with a problem... so I thought maybe some one here could help me.

There is a formula node in my application (more than one, but let's find the solution for one), and the developer can change the formula depending on how it want to customize the application. What I need to do is to show the content of the formula node to the user, so he knows exactly what's the formula in use at the moment.

This must work on the deployed application, so with the run time engine. Infact the developer build the application after the customization of the formula.

I have tried the following:

1) I put the formula node in a separate VI, in order to capture the block diagram image and then show that image to the user. I've used the BD.Get Image Scaled method, but it's clearly written in the help that id doesn't work with the run time engine.

2) Using the report generation toolkit I can call the Append VI Block Diagram to Report to an HTML report. I can't find in the help if it is supposed to work in run time engine, but I've had bad experiences in the past with that tool. And it doesn't seem to work.

3) I've tried a different approach using the labview scripting. I'm able to open the object reference to the formula node and then to load its content in a string with the property Formula Expression. But once the application is built it doesn't work, even if I'm not creating any code with the scripting, just reading.

 

In the end I don't care if the formula is captured on an image rather than a string, or whatever... but it must be what is written in the formula node inside the executable.

Just wonder if I've used the above methods in a wrong way, or if there is a different way to do it.

 

Thanks

 

Max

I don't think any of these methods will work in a build executable. 1) because it is not supported in the runtime engine, 2) because it makes use of the node in 1) and 3) only maybe if you set the VI explicitedly to not remove the diagram when building the executable. The text of the script is part of the diagram like anything else. LabVIEW compiles this in fact into code and then the script text is not really necessary anymore in a build application and therefore gets removed with the diagram. But even if you leave the diagram there it may still not work as a lot of VI scripting operations do not work in the runtime engine since they don't make to much sense anyways when there is usually anyhow no diagram to work on.

 

Also since the formula node is really compiled into the rest of the VI code, you can't change it in a build application anyways as it would need to be recompiled but the runtime engine does not have any compilation possibilities.

 

What you want to do is probably using some external scripting solution like LabPython or Lua for LabVIEW as there you can have the script in the form of a string that you can load from disk or simply contain in your VI and even let the user modify to run the changed code. 

[maxprs]

I don't think any of these methods will work in a build executable. 1) because it is not supported in the runtime engine, 2) because it makes use of the node in 1) and 3) only maybe if you set the VI explicitedly to not remove the diagram when building the executable. The text of the script is part of the diagram like anything else. LabVIEW compiles this in fact into code and then the script text is not really necessary anymore in a build application and therefore gets removed with the diagram. But even if you leave the diagram there it may still not work as a lot of VI scripting operations do not work in the runtime engine since they don't make to much sense anyways when there is usually anyhow no diagram to work on.

Infact, I forgot to tell you that the project is set so the block diagram of the VI where the formula node is contained is not removed.

But it doesn't work anyway.

 

 

Also since the formula node is really compiled into the rest of the VI code, you can't change it in a build application anyways as it would need to be recompiled but the runtime engine does not have any compilation possibilities.

But I don't want to change it with the run time engine.

I want only to read it. Only the developer will be able to change it, and this is the way it has to be.

I want the user to be able only to get how the formula is written.

 

 

What you want to do is probably using some external scripting solution like LabPython or Lua for LabVIEW as there you can have the script in the form of a string that you can load from disk or simply contain in your VI and even let the user modify to run the changed code. 

Never used... I would prefer to find a solution inside LabVIEW, but if there is no way I'll give that a chance.

 

[Rolf Kalbermatter]

But I don't want to change it with the run time engine.

I want only to read it. Only the developer will be able to change it, and this is the way it has to be.

I want the user to be able only to get how the formula is written.

Not ideal but the only possible solution then:

 

Create a string constant and copy the script into it and then put the script in a case structure and the string constant in the other case of the structure. Now you can call the VI with a boolean input control to execute the string or retrieve the contents.

 

Requires some discipline to update the string constant when the developer makes changes to the script but is the most straightforward and simple solution if you do not want to go with an external script solutions.

 

Or alternatively if your required scripting formulas are not to complex you might go with the script parser that comes as example in LabVIEW. It is however limited to basic mathematical operations, doesn't support arrays, and interprets the formula each time you execute it.

[maxprs]

Not ideal but the only possible solution then:

 

Create a string constant and copy the script into it and then put the script in a case structure and the string constant in the other case of the structure. Now you can call the VI with a boolean input control to execute the string or retrieve the contents.

 

Requires some discipline to update the string constant when the developer makes changes to the script but is the most straightforward and simple solution if you do not want to go with an external script solutions.

 

Or alternatively if your required scripting formulas are not to complex you might go with the script parser that comes as example in LabVIEW. It is however limited to basic mathematical operations, doesn't support arrays, and interprets the formula each time you execute it.

Yeah, that what I've thought to do as well; the problem is that there will be many formulas in the application, so discipline required is a lot.

 

On the other hand the limitation of the script parser is not accettable.

 

I just wonder why NI didn't put a read only property for the formula node where you can get what is written inside as a string.

[hooovahh]

Okay so I ran some tests.  Getting the text from a Formula Node in the development environment is easy.  Use Traverse for GObjects to get a reference to the Formula Node then use a property node to read it.  In a built EXE even when the block diagram is still there you won't be able to to use this VI.  So instead I tried using the All Objects property on the block diagram.  But that too won't work because that doesn't work in the run time environment.  But even if it did, the Formula Expression node won't work in the runtime engine either.  One possible alternative (that I'm still looking into) is if you can open a reference to the VI within the EXE, but in the development environment.  This would mean you can only get the expression from within the full development environment and not just from the EXE sorry.

 

If you are considering using some string constant I would recommend looking into some scripting that can run in a pre-build of the EXE that could copy the text from the formula node into the string constant.  That way at least you don't need to rely on the engineer to manually update it for every build.

[hooovahh]

Okay so I have a working test of what I was talking about with the Pre Build action.  Attached is a project with a VI in it that gets the text of a Formula Node in the development environment.  It also has a string constant that is blank, but before building the EXE it will take the value from the expression node and put it in the string constant.

 

Build the EXE and you'll see that the value of the string constant will change to the value in the expression node.  Not ideal but it can be done with minimal engineering effort, and using all built in tools.

Formula Node Test.zip

[ShaunR]

Doesn't the Vision Assistant or vision Builder have the ability to show diagrams? I have a vague recollection of someone using the same technique in their application (something to do with subpanels?) On the other hand. Maybe I just dreamt it

Edited April 21, 2014 by ShaunR

[maxprs]

Okay so I have a working test of what I was talking about with the Pre Build action.  Attached is a project with a VI in it that gets the text of a Formula Node in the development environment.  It also has a string constant that is blank, but before building the EXE it will take the value from the expression node and put it in the string constant.

 

Build the EXE and you'll see that the value of the string constant will change to the value in the expression node.  Not ideal but it can be done with minimal engineering effort, and using all built in tools.

I think that the use of the pre build action is a way to get the info that I need very interesting.

I will do some test to see if it can fit my needs...

Thank you very much for your effort.

[hooovahh]

Doesn't the Vision Assistant or vision Builder have the ability to show diagrams? I have a vague recollection of someone using the same technique in their application (something to do with subpanels?) On the other hand. Maybe I just dreamt it

So the tests I did seems to suggest you were dreaming.  Getting the block diagram reference is not allowed in the run-time engine.  And using the "Insert Block Diagram" on a sub panel, for a VI that didn't have the block diagram removed returns "Cannot Load Block Diagram" when in an EXE.

[drakhri]

Can use the invoke function on the VI reference to get an image of the block diagram. This could be made into a reusable sub-vi that works off it's parent reference.

Not sure of a good way to automatically determine the size/location of the formula node, however, so it's not ideal.

 

ShowBlockDiagram.vi

[hooovahh]

Can use the invoke function on the VI reference to get an image of the block diagram. This could be made into a reusable sub-vi that works off it's parent reference.

Not sure of a good way to automatically determine the size/location of the formula node, however, so it's not ideal.

 

ShowBlockDiagram.vi

According to the help the Get Image Scaled doesn't work in the run-time engine.

[drakhri]

You are correct. Could set the image default after displaying it. Perhaps a duplicate constant is the simplest & cleanest way.

 

Using the code above, you could save each image in a key-value arrangement using Variant Attributes or other data structure. Setting the key as [VI nameformula-name] and the attribute value as the image itself. Have this sub-vi load it's previous value on execution. Then a simple get function would allow you to see the images in the RTE. 

 

A lot of complexity for a simple multi-line string, but it would work. 

Edited April 21, 2014 by drakhri

[hooovahh]

I'm not saying you can't do what you are suggesting, but if you are choosing to effectively store the data ran when in the development environment, and load it when we are in the run-time, it would be much easier to just deal with the string value which can be pulled out and saved as a constant.  What I am describing is the code that I posted earlier dealing with the string value, and not the image.

[drakhri]

Another possible solution would be to use the Eval Formula Node vi. It's functionally similar as a formula node, but would also have the formula already in string format as an input.

[maxprs]

Another possible solution would be to use the Eval Formula Node vi. It's functionally similar as a formula node, but would also have the formula already in string format as an input.

That's a possibility that I already knew.

I gave up because of the modifications needed to adapt the actual formula nodes, and also because of the limitations about the variables name (a, a0... z, z0...). The content of the formula node instead can use any type of strings, i.e. "Energy", "Mass", that makes the formula self explaining.

[Rolf Kalbermatter]

Doesn't the Vision Assistant or vision Builder have the ability to show diagrams? I have a vague recollection of someone using the same technique in their application (something to do with subpanels?) On the other hand. Maybe I just dreamt it

 

No you haven't dreamed but the Vision Builder makes use of a NI special runtime engine that is located in lvfrt.dll. This is a private build that supposedly works as a runtime engine but with most of the compiling and other full development system still in place. However I have no idea how one would create an installer that deploys this runtime version rather than the standard version.

 

That's a possibility that I already knew.

I gave up because of the modifications needed to adapt the actual formula nodes, and also because of the limitations about the variables name (a, a0... z, z0...). The content of the formula node instead can use any type of strings, i.e. "Energy", "Mass", that makes the formula self explaining.

 

If your only concern would be the variable names, I do have a completely rewritten version of the formula parser that allows for arbitrary (well must start with alpha character and then can contain any alphanumeric character and the underscore) and performs quite a bit better than the NI parser as it does not do all kinds of complicated string reformating on the input string. It also has a clean string to RPN parser so that as long as the string doesn't change one can simply execute the RPN evaluator only, which speeds up the actual calculation of the formula even more. The code was posted long ago here.

[maxprs]

If your only concern would be the variable names, I do have a completely rewritten version of the formula parser that allows for arbitrary (well must start with alpha character and then can contain any alphanumeric character and the underscore) and performs quite a bit better than the NI parser as it does not do all kinds of complicated string reformating on the input string. I also has a clean string to RPN parser so that as long as the string doesn't change one can simply execute the RPN evaluator only, which speeds up the actual calculation of the formula even more. The code was posted long ago here.

Not the only concern, as the application is already written with all the formula nodes.

But sure I'll keep your suggestions under consideration.

 

Thank you very much

[Yair]

No you haven't dreamed but the Vision Builder makes use of a NI special runtime engine that is located in lvfrt.dll. This is a private build that supposedly works as a runtime engine but with most of the compiling and other full development system still in place. However I have no idea how one would create an installer that deploys this runtime version rather than the standard version.

 

I never tried it myself, but I have heard from people at NI (online, so it should be publicly available if people want to search) that there is an installer you can add when you build an installer which will give the RTE some of the missing functionality. I believe it's called Teststand remote execution support or something similar, so it might not be the exact version that the NIVB uses, but I understand it should work. Like I said, I never tried it, so I don't know any further details and I'm assuming it's not officially supported by NI. Maybe it's not an installer, but a build spec option. Maybe you need to install it separately. Maybe it needs a license. Like I said, search for the details if you want this.