LabVIEW VI scripting: finding out "new VI object" parameters

[yoctopuce]

Ok, I tried and I can confirm that one doesn't have to use a  "Invoke node .NET" to interface with .NET shared library, a simple  "Invoke node" will do just as well 🙂

[yoctopuce]

@Darren: I'm somewhat embarrassed , I do understand what your VI example does, but I'm unable to reproduce it. I couldn't find a way to create that "MethClassName" property. I looked everywhere, aside from  a very short LabView help page , I couldn't find any direct reference to it, even Google seemed to be a bit lost here.

So I have two questions:
1- What is the LabVIEW UI path to set that MethClassName property ?
2- The class I'm invoking is in a C# .NET dll, how am I supposed to tell the invoke node what dll to use ?

Since I am under the impression  that it won't be the end of it, may I impose on you a little more? I prepared and attached a very simple .NET shared library  example which is basically a static Add function:

namespace SimpleStaticClass
{
    public static  class DotNetClassDemo
    {
       public static double  AddExample(double a, double b)
         { return a + b; }
    }
}

And here is the matching VI (also attached)

How would you create such a VI with VI scripting ?

[Darren]

First of all, you need to make sure you have scripting enabled in order to see the properties/methods associated with scripting. Enable the following setting: Tools > Options > VI Server > VI Scripting > Show VI Scripting functions, properties, and methods.

Once you've got that taken care of, the easiest way to figure out the right scripting parameters is to inspect a VI that is already created. For example, you can inspect your DotNetIntegrationExample.vi like this:

This code should give you the information you need to write the class name and method information when scripting a new VI as I showed in my previous reply.

I also suggest that you start with a template to reduce the amount of scripting you have to do. For example, instead of trying to script a new VI from scratch, start with a template that looks like this:

This way, all you need to do is configure the Invoke Node, then create controls and indicators off its terminals once you specify the appropriate method.

P.S. - I wasn't able to try this with the code you sent, because I can't get the Invoke Node to properly link to the SimpleStaticClass.dll. I don't know enough about .NET to troubleshoot why.

[yoctopuce]

@Darren: I do have scripting enabled . thanks for the "inspect trick" it would be very useful if I could find that feature in Labview UI. Once again I looked everywhere and couldn't find any documentation about it. I did however find your  presentation about VI analyser but your tools menu looks nothing like mine. I have Labview  2017 base, and I suspect that I don't have access to VI Analyser.

The template advice is a good one, but I can't use it. The reason I chose VI scripting is because the Yoctopuce API is automatically generated for all the programming  languages we support. The API are regenerated  from scratch each time we make a modification, that way modifications are propagated efficiently, and most of all, consistently on all programming languages. 

Since you obviously works for NI, is there a way we could continue this conversation through email? and in exchange, once this is all sorted out, I could post a tutorial on how to  script a VI that interfaces a .NET dll here.

[Darren]

I double-checked in Base LabVIEW 2017, and the property is there:

If you don't see that item in the list, then something may be wrong with your LabVIEW installation. I can't think of any other reason why you wouldn't see it.

I was suggesting using a template as your starting point when scripting a new VI. When you make a modification and need to regenerate the VIs, you can still start from a template as I described and save yourself a fair bit of wiring.

[yoctopuce]

@Darren: Ha. I think I found the link I missed: I was looking for "MethClassName " property in Labview UI, but this is just a short name , the actual name is "Invoke Node Class Name" and the relation between theses two can be inferred from the help page for that property. Thank you for the clarifying screen shot.

So, I'm one baby step farther. Now I need to  set MethClassName  in a way that Labview will understand that I want to use a class from a specific dll. I made a few tries and it looks like that the correct syntax is

.NET:dll_name_without_extention.class_name

for instance for the SimpleStaticClass.dll example I posted earlier it would be

.NET:SimpleStaticClass.DotNetClassDemo

it's getting late, I'll report further progress.

[yoctopuce]

So.... I eventually managed to create what I wanted, i.e. creating a complete VI from scratch with Labview VI scripting. The generated VI just have to call a static function inside a .NET dll. For reference here is the .NET DLL source code:

namespace SimpleStaticClass
{
  public static class DotNetClassDemo
  {
    public static double AddExample(double a, double b)
    { return a + b;
    }
    public static string getActualDLLpath()
    { return System.Reflection.Assembly.GetExecutingAssembly().Location;
    }
  }
}

It looked like a simple enough proof of concept, but since I implemented  the whole nine yard (error in/out, closing reference, help, icon etc..)   I ended up with a monster. Yes, I know, I was supposed to create sub VIs but I wanted a panoramic view that I could use as a reference later on.

  And here  is the generated VI:

For further reference, and  proper indexing, here is a list of the LabView VI scripting aspects covered in this proof of concept:

• Make a call inside a .NET dll
• Create a error in cluster
• Create a error out cluster
• Create and wiring a Close reference Node
• Create a VI help/documentation
• Choose VI connector pane pattern
• Wiring VI connector pane
• Set VI icon
• Saving the generated VI

A few comments

Before starting to create the VI, the generator makes a random call inside the .NET DLL, that's because I found out that Labview is not using the specified DLL directly. Actually a copy is made somewhere inside the file system (probably in a temp folder), and LV is working on that copy. This mechanism works fine when calling the DLL directly, but I think that the copy is not made when using an Invoke methClassname  Node.

I had to  use some empiricist to find out the right terminal index for the result of my Add function (top  left block)

Programmatic Node placement on the block diagram is an absolute nightmare, I suspect that the window origin moves when some items are placed too close from the edges.

There probably is is a better class name for my "close reference" node creation, but i couldn't find it.

Finally, here is my LabView newbie's opinions about VI scripting: it's a powerful tool, but man, documentation could use some extra work, only the very basic stuff is documented. The official tutorial barely covers loops creation,  anything slightly more complex than that  quickly turns into a time-consuming treasure hunt.

I attached the whole project (labview 2017)

l almost forgot: Many thanks to Darren for the VI scripting hints.

[Darren]

Glad you got it figured out. I still think your life would be a lot simpler if you started with a template VI. Create a VI I described upthread (with error IO and an invoke node already wired), and wire the path to that template to the New VI function. Then all the stuff you have for creating error IO, Close Reference, all the wires between those nodes, and the conpane connection for error IO can already be taken care of. So the only scripting you need to do is setting the method, creating the controls/indicators specific to that method, and putting those controls/indicators on the conpane.

Also, you never need to close references to GObjects in scripting code, so you can remove every single Close Reference function in your scripting code except the one you have that is closing the VI reference at the end.