How To Use Exported Function "CallInstrument" of LabView.exe ?

[CleanerTM]

Hello!

I want to use the function "CallInstrument" to dynamically call VIs with LabView. Did anyone has experiences with this function?

All I kow is following:
The function is used by LabView Internals and its Runtime Library. Its exported by LabView.Exe and lvrt.dll.

Its prototype is maybe:

int CallInstrument(CPStr* VIPath, int controlcount, int indicatorcount, int options, [ Variable List of Control/Indicator Parameters ]... );

( CPStr Type is a StringArray of PStr (Short PascalStrings) as it is used by LabView to store Path datatypes. )

I whould be glad, if anyone has information about this function.

[rolfk]

---

@CleanerTM wrote:
Hello!

I want to use the function "CallInstrument" to dynamically call VIs with LabView. Did anyone has experiences with this function?

All I know is following:
The function is used by LabView Internals and its Runtime Library. Its exported by LabView.Exe and lvrt.dll.

Its prototype is maybe:

int CallInstrument(CPStr* VIPath, int controlcount, int indicatorcount, int options, [ Variable List of Control/Indicator Parameters ]... );

( CPStr Type is a StringArray of PStr (Short PascalStrings) as it is used by LabView to store Path datatypes. )

I whould be glad, if anyone has information about this function.

---

Calling LabVIEW VIs dyamically from within LabVIEW is done a lot easier by using the VI Server functions. Also this function is absolutely undocumented and a bad idea to use, because I know for sure that its prototype was actually somewhat different in older LabVIEW versions and quite likely will change again with some future LabVIEW version. An earlier prototype was MgErr CallInstrument(Path path, Bool modal, int32 nInputs, int32 nOutputs, ...). The control/indicator parameters were a triple of a Pascal string containing the name of the control/indicator followed by the typedef array for the datatype, followed by a pointer to the unflat data to be passed to the control/indicator. Se there were first nInputs * 3 parameters followed by nOutputs * 3 parameters.

The complexity of this (you need to generate the correct typedef arrays and the correct unflat data) and the fact that it has changed in the past (and likely will change again in the future) seems to make this function like a very bad idea to be used.

Also I'm not sure what you believe to gain with this. You can't use this function from anywhere but a DLL called in the context of LabVIEW. But since you are already working from within LabVIEW using VI server is much, much easier and not prone to version incompatibilities.

Rolf Kalbermatter

[CleanerTM]

Dear Rolf Kalbermatter,

Thirst, thanks a lot for your answer! - 🙂
You sure right, It whould be much much more comfortable to use the VI Server.
And you're also right... using a undocumented dll-function is absolutly no longtime solution.

Currently I am using VI Server for my problem, but it doesn't fit my interesst so much.
But I will explain, what I'm trying to do.

I want to call a VI dynamically from LabView, giving Parameters to its Controls and receive Results from its Indicators.
Realy no big job, but VI Server only let you do this that easy if you have a VI Typedef. otherwise... with untyped VIs, its not that simple. Ok.. its not impossible, you can use "GetAllControlValues" and "SetControlValue" (functions from VI server) and the call "RunVi". But this can get slow (>100ms per call 😕 )

I'm looking for a alternative function, which let me call a VI dynamically with userdefined Parameters. Maybe you know the ActiveX Interface IVirtualInstrument and its Function "Call2" - it is a nice example, what kind of function i want.
But this function is not directly available by the VI Server--- i don't know for what reason.
Then i tried to make use of "Call2" from within LabView, and it took me some time to find out the right Parametersyntax but finnaly i got it and it worked fine ... but it was no long time until problems occur. I cannot tell what really went wrong, but sometimes labview simply crashed or hang into a loop reseting some VIs. And its also impossible to stop a running vi, with has made a call to "Call2", if the call doesn't return by itself.

Next step is/was trying to take advantage of CallInstrument. So, yesterday... after hours of analysing assemblercode, i finnally found out the correct use of LabView.exe->CallInstrument 🙂 and i'm very impressed about its speed (0-15ms per call). The prototype seem to be the same as you explained in your reply int CallInstrument(Path path, Bool modal, int32 nInputs, int32 nOutputs, ...)
But It has the same problem as its ActiveX derivat "Call2".. if you call an endless looping VI, LabView cannot stop your caller-vi. The other bad thing is, that this function is using dynamic paramterlist, which are placed directly onto the stack!
That means that the paramter count on the stack is NOT FIXED (printf makes it the same). LabVIews DLL InvokeNode doesn't support this.

At my current position, it looks like i have three possiblities but no one fits into my interesst.
(continued with next answer)

[CleanerTM]

Now to your Question, why the hell do I need this...?
------------------------------------------------------
I want to make many different (dynamic) calls to many different VIs and i'm not able to make VI Typedefs for all VIs i want to call because i sometimes don't even know which Vi gets called. I'm talking about a proxy calling system (if one can call it so).
In more abstract case, i want to develop a VI Server clone but with extended functions.

My overall task is, to develop a system which makes all common functions for measurement devices (VISA, DAQ, and toplevel APIs like the API from NI ELVIS) available other network.
If the user makes a call to a "wrapper-function" of f.e. "VISA OPEN" , the original function will get called across the network on a specific measurement server (the vi server derivat with some more enhanced functions).
A wrapper function will work the following:
It has all the same controls as the original function. It only calls a special "proxycall" function and pass the name of the original vi, which should get called.
The "proxycall" functions will determine its parent vi reference (callchain - works only for non reentrant vis) and read out all controls and its indicatornamelist. after readout, it pack it all into a packet and send it over network to the measurement server, which will check authentification and perform the call... and at this point i need the Call2 or CallInstrument function.

Hm.. for sure, maybe you now lot of other ways, controlling measuremnt devices over network (remotevisa, rda server, or maybe also remotepanel). Here just some reason what my/this 'on-ones-own' solution will give on afforts:
The first great affort of the system should be, that it will give access only for correct authorized people (username/password) and not (as vi server does) give the access depending on adresses.
The second affort should be that it will make no difference, if your measurement application running on a local computer or somewhere in the network - the wrapper functions will pipe your request correctly.
The third afford should be, that it will be very simple to add new wrapper to the system, for every function you need. In some special way it could also be possible to automate the process of creating "wrapper functions".

Well, currently, I found ways, to realize this proxycalling technic via normal use of vi server, but it is much to slow (up to 200 ms per call! >:/ ), thats why i'm searching for alternatives. Next step will be to make some use of CallInstrument and see if it is an acceptable way but i have the feeling, that it will again won't fit into my interesst...

Well... what do you think?

Best regards,
Karlos