LabVIEW
Passing parameters to Labview DLL from VB.NET
That's because it is a LabVIEW project to create a DLL (not a C project file) so that you can communicate using it from a non-LabVIEW code. ".lvproj" is a LabVIEW project file extension. You don't really need it, I always like to create work using projects so it has become a habit to start with a project file. If you decide to use & modify those vi in LabVIEW to create a DLL, the project file will come handy as I have also included a build-specification for a DLL.
-DP
void __cdecl LCDColor(LVRefNum *VISAIN, uint16_t LCDColor2,
TD1 *errorInNoError, LVRefNum *VISAOUT, char OutputString[], TD1 *errorOut,
int32_t len);
LVRefnum is as already mentioned an (U)Int32 value. But it is with an asterix and therefor by reference and not by value so the VB keyword should be accordingly ByRef and NOT ByVal.
However, you should really forget to try to call THIS API from VB. The TD1 errorIn and errorOut look suspicioisly like LabVIEW error clusters. A LabVIEW error cluster is in principle a structure which is possible in VB but the internal LabVIEW string is only possible to be created, handled and managed by calling LabVIEW manager functions from within your VB code. While theoretically possible to do it is in fact more than a pain in the a** and I would never ever go through the trouble of even attempting to do it. One problem but by fat not the only one, is that the location of the LabVIEW manager functions can and does depend on the LabVIEW version the DLL was created with. Locating the correct LabVIEW runtime DLL is more than troublesome, as your VB code would need to know in which LabVIEW version the DLL was created in, locate it from the registry and link to it dynamically. When using Visual C this is normally all done automatically by the labviewv.lib file that you link with your C(++) project, but VB does not use lib files at all.
Well, I'll give you an example using my workstation here. I have COM4 on my computer for RS232 (a USB-to-RS232 dongle is connected to one of the USB ports). I can open that port using VISA_Open.vi in the following example C code (VB.NET would be similar, just needs different syntax):
void main (void)
{
int error;
int i=0;
char RxStr[32];
int Length=0;
int BytesRead=0;
error = VISA_Open("COM4", 0); //Open VISA - once this call is made, the reference is kept in "VISA_ref.vi" which is a part of the DLL but not accessible by a calling application.
While ((error == 0) && i < 5) //Doing it 5 times while continuing to check that there was no error. This logic is just for example - it will stop if there is error.
{
error == VISA_Write("Hello World", 0); //Writing a string "Hello World" out to COM4
if (error == 0)
error = VISA_Read(11, &RxStr, &Length, &BytesRead, 0); //If no error previously, read back 11 bytes
i++;
}
error = VISA_Close(0); //Close VISA
}
Refer to attached VISA_C_DLL.h file for calls - this file is generated (along with a DLL) when you build the LabVIEW project that I had attached earlier.
In the above C example, I got "COM4" from NI MAX (image attached) on my computer. The above call opens a VISA reference and keeps it in the DLL, you don't have to send any references back and forth.
Hope this clarifies...
-DP
@Alex723 wrote:
Rolf,
Since calling Labview DLL with VISA parameters appeared much more complicated that I expected, could it be done a different way? For example, in my DLL I have a parameter COLOR. It is coming from VB as simple integer which LV DLL converts its own way to change LCD color. Now could be similar approach used for VISA parameter or that cluster ERROR variables? For example, instead passing real VISA type parameter, VB sends an integer 1, and the code inside DLL just makes a selection such as if this number =1 then use COM1, if this number =2 then use COM2. Then it uses the selected variable in appropriate format in VISA session. In this case VB would deal with its own standard variables and Labiew would deal with its own data types.
Your mixing here apples and pears in your discussion. The LCD color value is always an integer, Visual Basic or LabVIEW. The LabVIEW frontpanel uses an enum, but technically an enum is still always an integer. You could create enum like datatypes in VB too, so you can write RED instead of 0 in your VB code.
Enum color As UShort RED = 0 GREEN = 1 BLUE = 2 WRITE = 3 End Enum
A VISA refnum is a LabVIEW private datatype. It can be passed to non LabVIEW programming languages and back as integer, but those languages have no way to use it themselves in anyway, other than storing it as integer and passing it to other LabVIEW functions that can operate on this.
Basically something like the included should work, except that the Define Prototype dialog is rather murky for the VISA_Read function. Either I'm not understanding that dialog correctly because of its abominal limited and bad documentation or the person who wrote that dialog messed up for good for output strings at least until LabVIEW 2011 (I didn't check in 2012 yet).
I would expect that I could configure the input length of the RxStr parameter to be BytesToRead and the output length of that parameter to be BytesRead, yet for some reasons those seem to be inversed. Also because of that it seems inpossible to set the BytesToRead to be passed by value, which should be definitely possible, if it is correctly only used for the input length of the string parameter. Something is definitely at least to much limited here in the implementation and absolutely unsatisfactorily documented in the LabVIEW help.
However if you won't need to return strings for your driver, you could still do the rest like in the attached example that I took the liberty to create from a modified version of the example posted by BTC_admin. The use of the LV2 style global buffer/Action engine/(semi)-intelligent global, while correct like this is IMHO to much of a limitation as it will not allow easily to scale suc a driver up for more than one device at the same time.
But the VISA_Read function in the attachement definitely can't be used like it is now, until someone from NI can explain to me the rather weird behaviour about how to setup the RxStr buffer for creating the DLL.
For some reasons I can't seem to append any files here, except the lvproj file for some strange reasons. I attached the archive to the relevant thread on Lava, where I still seem to be able to upload files.
1) Yes you would have to create seperate VISA Ref.vi for each connection, or better yet create a more intellegent VISA Ref.vi that can store multiple refnums with open, lookup and close methods.
2) A VISA refnum is valid in the context it was created. For one this is the process calling the DLL if this is a LabVIEW process with the same version as what the DLL was compiled with. If the DLL runs in a non LabVIEW process and/or was compiled in a different LabVIEW version the VISA refnum will be created and managed in the LabVIEW runtime that matches the version used to create the LabVIEW DLL. So you could end up with several runtimes in a single process if you start to mix and match LabVIEW DLLs created in different LabVIEW versions. As long as you do the VISA Open, VISA Read, VISA Write and VISA Close for a particular VISA refnum all in the same DLL, you won't have troubles, but trying to pass VISA refnums (or any refnums in fact) between different LabVIEW DLLs is setting yourself up for a true disaster sooner or later.
Take a look at the modified library I posted in the Lava thread to see how this can be done.
3) LVRefNum *VISAIN passes the LabVIEW VISA refnum. This is not really a resource name but a resource refnum. That is sligtly different as the refnum contains internally both the resource name and the underlaying ViSession. Depending how you configure the Call Library Node parameter LabVIEW will pass the refnum (Adapt To Type), the resource name (String) or the underlaying ViSession (Integer).
And I would not remove that, but simply make sure that the DLL exports both a "Device Open" and "Device Close" function and whatever else Read and Write your device needs. Device Open receives a simple string, calls VISA Open and any other Initialization code and returns a VISA refnum, all the other functions receive and return a VISA refnum except Close which will just receive it.
