Ability to define more than one prototype/method for a single exported labview .dll

[easperhe]

I very much like being able to export a labview.vi to a .dll or .net interop library .dll. Our higher level automation is in C# and having access to labview.vi via .net .dll is great. However, the current build capability only allows a single prototype/method to be created. Consequently, I have to provide every input/output when invoking this single method. This can work but it's just inconvenient and not as obvious as being able to create multiple methods smaller things, e.g.

write setup values

write DAQ sample rates

start storing samples

stop storing samples

stop DAQs

write summary info

When I create a C# class, I can create any number of methods or properties to manipulate class data members. Exported labview.vi files should enable this too. NI AE said I could create parent.vi files (setup.vi, write_DAQ.vi, etc) that all include the actual vi of interest. These various vis could be added to the exported .vi list. And, this would indeed be a work around. But, this is a hack to get around this problem and the AE agreed. Instead, I would like to be able to define multiple methods/prototypes on a single exported .vi.

[AristosQueue (NI)]

Easperhe:

Although I agree that we *could* do this, I am not sure this is a good idea.

In C#, when you want those additional function signatures, you declare separate functions and then call into the core function. You can do the same in LabVIEW -- create the VIs with the signatures that you want wrapping the main VI and then export them all.

I am suggesting that this is actually better than us augmenting the process of building the DLL. If you put it in the build specification, you are hiding code in a build specification. As much as possible, I think it is better practice to have the code actually in code files and not appear only when you do your build. That way you know to modify those alternate prototypes when you make changes to the back end (as opposed to only discovering them later when you try to do a build of the DLL) and you can have a test harness that actually exercises those entry points.

Does my reticence make sense to you?

-- AQ

[easperhe]

AQ,

I agree that you don't want to hide code in a build specification. But, that's not what I was suggesting. Instead, I was suggesting that NI think of some way to more conveniently allow a user to define methods. When I compare this to what I do in C# (see below), creating a separate .vi (file) for each method seems awkward.

I'll go ahead and use the suggested approach of creating a separate parent .vi for each method I want for now. Maybe after I use this it will seem more appropriate.

public class ViClass {

   public void Init()  { LabviewVI(a: 1); }

   public void Setup() { LabviewVI(b: 1); }

   public void Start() { LabviewVI(c: 1); }

   public void Stop()  { LabviewVI(d: 1); }

   private void LabviewVI(inta=0, intb=0, intc=0, intd=0) { }

}

[AristosQueue (NI)]

> When I compare this to what I do in C# (see below), creating

> a separate .vi (file) for each method seems awkward.

...

> Maybe after I use this it will seem more appropriate.

Maybe. Maybe not. 😉  It's worth kicking the tires on this idea a bit more...

I think that we might be able to do some of what you suggest... LabVIEW conpane terminals can be required or recommended [optional is equal to recommended for the purposes of this discussion]. The recommended terminals, in the current system, become required inputs for the C# subroutines. But C# now has named parameters and optional parameters.

It seems to me that we could move the recommended inputs to be optional parameters in the function signatures to the end of the function signature, and go ahead and assign them the default values of the controls. That would solve one of your defaulting problems.

The other problem might be solved by you using named parameters in the calling code, so if you want a differently organized signature, your caller can assign the parameters in a chosen order.

http://msdn.microsoft.com/en-us/library/dd264739.aspx

I have no idea what kinds of problems that might cause, but it might be worth exploring.

[easperhe]

AQ,

Agree it makes sense to try and leverage and equate the optional paramaters that C# allows to the recommended conpane terminals - they do seem to be the same thing. And using the named parameter capability of C# (or any other language), I think you should be able to provide the functionality that I would prefer above about how to call the LabviewVI with different combination of input parameters.

Note, calling another function with different combination of parameters is different than having a real function/method that does something more significant. In that case, I still agree with you that there should be some .vi code somewhere for that and not be a part of a build description.

I'm going to implement the current solution (multiple parent .vi this week). I'll get back to this thread in a week or so after I've tried this out.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

[NIJB]

Garbage,

The request for multi-mode prototypes is 2nded officially. Here's the Kudo's to the first person who asked. And I truly don't care for folks telling me how to manage my code stack. Open it up and give me all the flexibility I can handle (including enough to crash myself). 

Why make multiple VIs to manage when there is only 1 function? Waste of effort to have to go update all those if I change something in one.

Regards,

Josh