Pass VISA resource to DLL created by CVI

Hi, I want to call a DLL created by Labwindows CVI in Labview.
When I use ' Call Library Function Node', I have to define the parameters output in DLL. However, there is one 'VISA Resource' type parameter and I don't know which shoudl be the right in Labview's definition.
Anyone can help about that? Or maybe there are some easy way to do this?
The type in CVI is: 'ViSession g_hSA'
Thanks in advance.
BR
Gavin
Attachments:
dll.JPG ‏36 KB

There are several issues here. First, a VISA Resource (or other string name resources in LabVIEW) are really a combination of a name and a session ID. If the session ID is invalid, LabVIEW will automatically open a session ID using the string name based on the refnum type. Obviously this won't work in a C function interface anymore as one does not have access to the low level C APIs in the LabVIEW kernel to treat the LVRefnum in such an dual mode way.
What does work is to pass the string to the first function as C String, and do an explicit VISA Open there, then return the VISA session to the caller as LVRefnum and treat it from there as such.
The LabVIEW Call Library Node does a few intrinsic conversions based on the configured datatype.
If you configure the parameter as String, LabVIEW will pass the resource name to the DLL function.
If you configure it as (U)Int32 (and in fact more precisely as pointer sized integer), LabVIEW will extract the underlaying ViSession from the VISA library and pass that one. You should use pointer sized integer instead of 32 bit integer, since a ViSession is really equivalent to a pointer and therefore would be 64 bit large in 64 bit LabVIEW.
If you configure the parameter to adapt to type, LabVIEW will pass its own VISA refnum to the function. This refnum is a LabVIEW intern entity, (and alwasy 32 bit in size and only valid inside the LabVIEW session who created it) and really wraps the ViSession into a LabVIEW refnum for internal bookkeeping reasons.
However the original post also shows TD1 errorIn and errorOut datatypes. This looks suspicially like an error cluster and that would be a thing that you can not easily create in non-LabVIEW land in a way, that LabVIEW will not crash when trying to access it.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Similar Messages

How pass VISA resource string from C++ as uintptr_t* to a LabVIEW generated DLL ?

My coworker build a DLL from LabVIEW that I am trying to call from C++.
void__cdeclMeasureDCvolts(uintptr_t*VISAResourceName, int32_tChannelNumber,LVBoolean*MonitorResult,double*MeasuredVoltage, TD1*errorOut);
Does "extcode.h" define macros or functions for string conversions? Or should I request my coworker rebuild the VI's to make arguments more C/C++ friendly?
Thanks in advance for any tips or direction. Examples are * much * appreciated.
-Ed
TestObjectMeasurement* testObjectMeasurement = m_measurementMap[name];
TestObjectInstrument* testObjectInstrument = m_instrumentMap[selectedInstrumentName];
int slot = 1;
int bank = 1;
int channel = 1;
int channelNumber = 1000 * slot + channel;
char * visaResourceName = testObjectInstrument->visaResourceName().toLatin1().data();
LVBoolean monitorResult = LVBooleanFalse;
double measuredVoltage = -1.0;
TD1 errorOut = {0};
try
// void __cdecl MeasureDCvolts(uintptr_t *VISAResourceName,
// int32_t ChannelNumber, LVBoolean *MonitorResult, double *MeasuredVoltage,
// TD1 *errorOut);
MeasureDCvolts(reinterpret_cast<uintptr_t*>(visaResourceName), channelNumber, &monitorResult, &measuredVoltage, &errorOut);
catch(...)
qDebug() << "Exception thrown by: MeasureDCvolts";
QString errorSource = QString::fromUtf8(reinterpret_cast<const char*>(LHStrBuf(errorOut.source)), LHStrLen(errorOut.source));
qDebug() << errorSource;
LStrHandle errorTextHandle = {0};
bool foundErrorText = NIGetOneErrorCode(errorOut.code, &errorTextHandle);
if(foundErrorText)
QString errorText = QString::fromUtf8(reinterpret_cast<const char*>(LHStrBuf(errorTextHandle)), LHStrLen(errorTextHandle));
MessageHelper::messageError(errorText, errorSource);

Why is it not a solution? It was exactly about what you wanted to do and the solution in the last post is how it can be made to work. There is NO way to ddirectly create a LabVIEW native VISA resource in C code that is not called from within LabVIEW, unless you consider hacking the LabVIEW system and using undocumented functions a solution. But that has very good chances of breaking with future LabVIEW versions.
Your only other option is to export another function from the DLL that accepts a String and uses VISA Open to explicitedly open the VISA session in your LabVIEW DLL and returning that VISA session to your C code. This is functionally equivalent to passing a String to your current function but avoids the lookup and potential recreation of the VISA refnum on each call. Something I would only feel bothered if you intend to call this function many thousend times each second, which for VISA communication seems very unlikely.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How to create a VISA resource without "VISA FIND" or Serial Poll

I'm very new to LabVIEW and my experience so far with GPIB/VISA is to pass a GPIB address (from user control) to a C# function I created. The function will build the correct VISA resource string, and try to connect using a message-based session one at a time to each board address.
I'm trying to do a similar action in Labview but so far, the only method I have seen is to use the drop-down Visa Resource. When I use this, it scans the bus to find all the physically connected devices on the bus but the unfortunate side effect is that all the listeners go into remote mode which typically resets the devices to their default remote connection settings.
ie: This can turn off a the power o/p of a power supply that I didn't want to control at that moment etc.
Can anyone tell me the proper or recommended method? If I had a user control that allowed the user to enter in a GPIB address, would I just create the resource string myself on the block diagram and feed this into a VISA -OPEN .vi?

Connect a string control to the VISA Open VI
LabVIEW Portal

Visa Resource Name in cluster passed to Network Stream writer causes error 42.

If I try and pass this "motor data" cluster with an embedded VISA resource name:
to a Network Stream Writer in this manner:
Then I get this error from the "Write Single Element to Stream" VI
If I change the motor data cluster TypDef so that a string control is used instead of the VISA reference, the error disappears and the data passes over the Network Stream without problem.
Is this expected behavior?
I thought that the "data in" (type = "POLY"?) like the one found on the "Write Single Element to Stream" VI was supposed to accept pretty much anything...
Solved!
Go to Solution.

Doug
I would consider this a bug, as the memory location (more precisely the VISA refnum or session) of a VISA resource means nothing on a potentially remote system. Also I was under the impression that most streaming methods like binary file IO, but also the network streams would use the LabVIEW flattened format for data clusters and for that the VISA resource name would be the only logical choice instead of the underlaying VISA refnum, but I might be wrong in this specific case and the default behaviour for flattening VISA resources might always have been to the VISA refnum.
Considering that the VISA control can resurect the VISA session from a VISA resource name if it is already opened, flattening to the VISA resource name instead would be more logical, but using a string control in the cluster type definition is a reasonable work around of course.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

What determines which inputs you can select from when you're creating a VISA Resource Name Constant?

Hey, I'm trying to write a labview driver an instrument. I have another instrument which came with labview drivers, and I had hoped that by looking at how they did it, I could write my own for this piece of equipment.
However, the problem is they use the old visa open method. That is, they input a string, "GPIB::6", and it outputs a visa session.
The new Visa open requires that you have an input resource name, and the constants only let me pick from "COM1" and "LPT1", but the GPIB interface card in this computer is in a PCMCIA slot.
What determines what choices you get when you select the value of the constant?
Thanks,
-Dobbs

If you created a VISA Resource Name control, right click on the control and select "Allow Undefined Names".
I haven't programmed directly using VISA on LabVIEW 6 but it apppears that if you select from the drop-down menu, it shows the devices that is defined in MAX. Thus, you should be able to select your GPIB resource name if it has been properly installed.
Nevertheless, it still allows you to override the control by selecting "Allow Undefined Names".
I hope that helps.
Shan Pin Koh

Calling a dll created with vision 7.0 from visual basic doesn't work

I created a dll using some vision 7.0 functions and Labview 7.0 environment. I call this dll from visual basic. The dll will work fine as long as I don't stop the visual basic program execution. As soon as I stop the program execution the dll will no longer work. I must reload the visual basic environment and the call to the dll will start working again. I created the exact same dll but I created it with vision 6.0 in Labview 6i environment. It works great and has no issues.
Attachments:
Test.vi ‏36 KB

Roberto N. wrote:
Thank you Jordan, I'm using Labview 7.1.
Anyway I've resolved the problem by adding the "lvanlys.dll" file (present in "..\Labview 7.1\resource\lvanlys.dll" path) as support file in the building process. Now the DLL containing the analysis functions works correctly.
Natalino Roberto
Ok, you probably got lucky since the lvanlys.dll seems to implement that function directly. However most Advanced Analysis functions are just redirected by lvanlys.dll to the Intel Math Kerneal Library that gets installed with LabVIEW 7.1 and higher. The only way to get that properly installed with your LabVIEW executable or DLL is to create a LabVIEW installer in your Application Builder and make sure to select under "Installer Settings->Advanced" the "LabVIEW Run-Time Engine" and the "Analyze VIs Support". Then use that installer to install your DLL on another computer.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

DLL created with LV 7.1 Application Builder doesn,t work when analysis subVIs are present

I'm looking for a solution of the following problem.
The DLL created by the "sum1.vi" source works properly, while the DLL create by "sum2.vi" always gives a zero result.
The "sum2.vi" source contains an additional "Hanning Window" VI (not wired), that seems to be the cause of the problem.
If I delete the Hanning VI and re-build the DLL, the same works fine
Is there a solution or is it not possible to make Labview DLLs when containing analysis VIs as filters, windows, FFTs, and so on?
Thank you for your answers.
N. Roberto
Attachments:
sum1.vi ‏12 KB
sum2.vi ‏14 KB

Roberto N. wrote:
Thank you Jordan, I'm using Labview 7.1.
Anyway I've resolved the problem by adding the "lvanlys.dll" file (present in "..\Labview 7.1\resource\lvanlys.dll" path) as support file in the building process. Now the DLL containing the analysis functions works correctly.
Natalino Roberto
Ok, you probably got lucky since the lvanlys.dll seems to implement that function directly. However most Advanced Analysis functions are just redirected by lvanlys.dll to the Intel Math Kerneal Library that gets installed with LabVIEW 7.1 and higher. The only way to get that properly installed with your LabVIEW executable or DLL is to create a LabVIEW installer in your Application Builder and make sure to select under "Installer Settings->Advanced" the "LabVIEW Run-Time Engine" and the "Analyze VIs Support". Then use that installer to install your DLL on another computer.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Old visa open, error code 1073807343, using VISA with a GPIB device, and VISA resource names

Hi everyone,
I'm trying to get a SRS model SR720 LCR meter (manual on this page) working with LabView, connecting it to my PC with an Agilent 82357A GPIB/USB interface (manual on this page). I'm running MAX version 14.0, and NI-VISA version 14.0. I'm running LabView version 13.0f2, 32 bit.
I followed the directions on this page, and I'm pretty confident I can communicate with my LCR meter, because I can go to NI MAX->GPIB0::17::INSTR under "devices and interfaces", then go to the VISA test panel, go to the I/O tab, and I can enter a few commands from the SR720 manual, like changing the frequency, and I see the light on the LCR meter change to what I just told it to do. Here is a picture, just to illustrate it:
Also, if I do the *IDN? command, it returns "
9: Write Operation (*IDN?)
Return Count: 5 bytes
10: Read Operation
Return Count: 41 bytes
StanfordResearchSystems,SR720,08087,1.03\n
So, that's good too. I also made the alias of this device "MyLCRmeter", but that shouldn't matter for now.
Now I'm trying to get it to work in a more usable way. The SR7xx drivers that LabView found for me came with a couple sample programs, one called "Getting Started.vi". I tried to just simply see if it worked, changing the "instrument descriptor" field to "GPIB0::17::INSTR", since that's the one that seemed to be the right device in MAX. Here is a picture of the front panel of "Getting Started.vi":
Trying to run it like this gave me this error (code -1073807343):
Old VISA Open in SR715/720 Initialize.vi->SR715/720 Getting Started.vi
Doing a bit of searching on these forums, I found these few threads (1 2 3), which seem to tell me that, since this program was written, the way you open VISA has changed. In the 2nd of those links, one guy said:
You just have to replace the Old VISA Open function with the VISA Open that is on the Instrument I/O>VISA>VISA Advanced palette. When you do that, the wire to the string that was used for the resource name will be broken. Delete the string and make the actual VISA Resource Name visible on the front panel. Wire the VISA Resource Name control to the connector pane where the string control was (upper left connection).
So, I went into the sub-VI Initialize.vi, and did that. Here is a picture of what the front panel and block diagram of the sub-VI Initialize2.vi (I changed the name in case I screwed things up, but I'm pretty sure the new one is the one being called by Getting Started.vi) looked like before I changed anything (you can see the Old VISA Open):
and here it is after replacing that with the regular VISA Open, deleting the instrument descriptor string and replacing it with a VISA resource, and connecting that to the VISA Open:
However, as you can see in the image above, and it seems like someone else had this problem in the 2nd thread linked above, I don't see my device listed in the drop-down menu (even if I refresh), only "LPT1" (I don't even know what that is):
No, I wasnt able to select the visa resource from the pull down menu. somehow it seems disabled or something.
If I just enter the VISA resource name from MAX manually, GPIB0::17::INSTR, and save and try running that, I get the error(code -1073807346):
VISA Open in SR715/720 Initialize2.vi->SR715/720 Getting Started.vi
So I'm not sure where to go from there, or why it's not in the drop down menu to begin with. I'm sorry if I've missed something but I've searched about as far as I can go. If I had to guess, maybe one thing could be that in MAX, under Tools->NI-VISA->VISA Options->My System->Conflict manager, I have both Agilent VISA and NI VISA enabled; I know sometimes problems arise from conflicts between different software fighting over the same hardware. Is this okay, or do I need to change it?
Thank you and please let me know if there is any other code/screenshots I could provide that could help!

Hi, I did indeed enable NiVisaTulip.dll under MAX->Tools->NI-VISA->VISA Options->My system->Passports->List of passports. Sorry, I should have mentioned that explicitly.
By install as primary, do you just mean as it is here, where it is selected as the "Preferred VISA"?
Or somewhere else? I installed NI-VISA first I believe, and then the Agilent one, and during the installation of the Agilent one, I'm pretty sure I made it not the primary. Here's what I have in the Agilent (it's called Keysight now) Connection Expert software:
I also have this under the "Keysight 488 options" tab:
Should that be checked? I don't actually know the role of VISA vs 488 here...
What could I try?
Thank you!

No VISA Resources in Labview but all present in MAX

Hi,
I am unable to find any VISA resources from LabVIEW, however, all NI hardware is available and working in MAX. I have just installed a PCI-8433/2 as well as a NI PCI-8512 CAN/HS Card. As part of the installation I believe MAX was upgraded to version 4.6.2. I will attach the max configuration report for those who are interested. I am working with LabView 8.2. I also uninstalled an agilent GPIB card and as a result the NI-GPIB card is the sole controller and is GPIB0... instead of the agilent card.
I have had a similar problem before that was a result of a corrupted database, but I was unable to find this problem on the forums this time and I am not getting any errors. Just an empty VISA Resource control.
Any suggestions would be greatly appreciated.
Nate
MAX Configuration Report
12/27/2010 1:35:05 PM
MAX Summary
My System
Data Neighborhood
CAN Channels
NI-DAQmx Tasks
V1P1V2P2
V3P3
Devices and Interfaces
GPIB0 (PCI-GPIB)
Instrument0
Instrument1
Instrument2
Instrument3
Instrument4
Instrument5
Miscellaneous VISA Resources
GPIB0::INTFC
GPIB0::16::INSTR
GPIB0::2::INSTR
GPIB0::22::INSTR
GPIB0::7::INSTR
GPIB0::10::INSTR
GPIB0::27::INSTR
GPIB0::3::INSTR
Network Devices
NI-DAQmx Devices
NI USB-9481: "Dev2"
NI USB-9481: "Dev1"
NI-XNET Devices
NI PCI-8512 CAN/HS
CAN1
CAN2
PCI-8433/2
Port1
Port2
PXI System (Unidentified)
Serial & Parallel
COM1
COM6
COM9
LPT1
Scales
Software
IVI Compliance Package 3.3
LabVIEW 8.2
LabVIEW Run-Time 7.1
LabVIEW Run-Time 8.0.1
LabVIEW Run-Time 8.2.1
LabVIEW Run-Time 8.5.1
LabVIEW Run-Time 8.6.1
LabWindows/CVI Run-Time 9.0
Measurement & Automation Explorer 4.6.2
Measurement Studio for VS2005
DotNET
Common
NI LabVIEW SignalExpress 3.0
NI Spy 2.7.1
NI-488.2 2.46
NI-CAN 2.7
NI-DAQmx 8.7.2
NI-PAL 2.5.3
NI-Serial 3.6
NI-USI 1.0.2
NI-VISA 4.6.2
NiVisaServer.exe
NIvisaic.exe
NI-VISA Runtime 4.6.2
NI-XNET 1.1
IVI Drivers
Advanced
Instrument Driver Software Modules
Simulation Driver Software Modules
Simulation Driver Sessions
Driver Sessions
Logical Names
-Nate
Solved!
Go to Solution.

Now that IS odd.
Can you show a couple screen shots from MAX?
First expand the software tab and post a png of the screenshot (I'm not yet convinced you do not have SOME driver issue)
Next select MAX>TOOLS>NI VISA>VISA Options- Wait for the new screen then expand Mysystem General settings and select Aliases.
You could also try "Clear all aliases" from there and reboot.
Jeff

How to get GPIB address from VISA resource

Hi All,
Is there a way (CVI API) to get the GPIB address of a GPIB instrument from an alias or a VISA resource name defined in MAX?
Thanks,
Rick.

Thanks mkossmann, I was actually looking for an api that would get the gpib address from the visa resource name defined in MAX which has already scanned in the gpib instruments.
I guess it may not be good that way even if there's such an api because instrument gpib address might get changed and if MAX has not been asked to rescan then the address will be out of sync.

Visa resource control loses value set during config and saved to step properties in TestStand

I'm using a Visa resource control to set the instrument handle in my VI (edit sub-step) and it gets saved into a step property of a custom step I've built at edit time. At run time the control value is intermittantly changed to "temp 0" value and I don't understand why. I have LabVIEW 7.1, TestStand 3.0

Hi kphite,
Are you using the Refnum to Session.vi and Session to Refnum.vi?
You would use the Refnum to Session.vi to convert your Visa session value to a U32. Then you can pass this back to TestStand.
Going back to LabView you use the Session to Refnum.vi to convert a U32 back to the Visa session.
Regards
Ray Farmer
Regards
Ray Farmer

TestStand not passing VISA info to LabVIEW

Hi All,
I am encountering a problem passing a VISA resource name to LabVIEW (2014) from TestStand (2014) which I cannot for the life of me understand or solve. Thus and so, I would be exceptionally grateful for any help.
I have two Thurlby Thandar LXI power supplies in a test rack, each with unique IP and socket addresses, of the form (TCPIP0::192.168.0.3::9221:OCKET). I have a LabVIEW project which contains a number of VIs, each related to the various functions of the PSUs, which are called from TestStand as appropriate.
I'm calling the LabVIEW 'Initialise.vi' in TestStand within a "ForEach" loop to individually extract the PSU's addresses from an array, open a session, then store the SessionNumber, but the resource name data doesn't seem to make it through to the VI's front panel VISA control. I've checked, checked and re-cheked that the correct values are being pulled from the array, I've even tried putting the LabVIEW call in a sub-sequence, just so that I can verify the data is not being corrupted in any way, but all seems to be well. It's as if the link between TestStand and LabVIEW is somehow broken.
To clarify the issue, on the very first run, the VISA information does get through, but subsequent runs retain this value, rather than overwriting it with the next value in the array. Setting the Run Options of the LabVIEW Action step type to Load Dynamically then Unload after step executes overcome this issue, but cause problems when trying to control the PSU later on in the test sequence.
The most maddening thing is that this used to work up until a couple of weeks ago, but unfortunately I can't remember what, if any, changes I may have made.
I've reinstalled TestStand and LabVIEW, but it hasn't solved the problem.
I've made the VI re-entrant, but that doesn't make any difference (in truth it shouldn't, as although the VI is called numerous times, all calls are sequential rather than simultaneous, so re-entrancy shouldn't be an issue).
I've configured the PSUs in MAX and given them aliases and tried the addresses direct, but that makes no difference either.
I've also tried performing the same exercise of passing data to LabVIEW just using strings and that all works fine, it just seems to be an issue with VISA resource names.
I have a suspicion I've checked or un-checked a check-box somewhere in the bowels of TestStand that's causing all of this, but haven't a clue how to find it.
If anyone can shed some light on this why this issue is occurring, or could even just point me in the direction of some utility which could sniff dataflow between TestStand and LabVIEW, I would be very grateful.
Many thanks in advance

Personally, I use Action Engines to handle my instrument resources. You can call the AE directly in TestStand. What I typically do is have a string input for name and then do a quick lookup for the desired VISA Resource to then control the instrument. This keeps all of the VISA stuff (including resource references) in LabVIEW. Have never had a problem with doing it this way.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Passing a struct from TestStand to LabWindows/CVI

I am passing a struct to a dll written in CVI.
Here is the problem: The code is written in CVI (c code) if I use "struct MyStruct *MyData" as the parameter definition in the dll TestStand works fine. But if I define my struct using a typedef (i.e. typdef struct MyStruct) then use MyStruct *MyData as the parameter TestStand throws a warning.
I an using the C\C++ adaptor.
It is too late in the programming effort to go back and remove the typedef.
So, how do I get TestStand to accept the typedef?
Thanks
Carmine
Solved!
Go to Solution.

In ANSI C, the struct names and type names belong to separate namespaces. You can declare structs several different ways:
1) struct structName { int x; };
2) typedef struct { int x; } typedefName;
3) typedef struct structName { int x; } typedefName; // Note: structName can be same as typedefName.
I'm assuming you are using the 2nd example above in which case LabWindows/CVI automatically generates a struct name (something like __unknown_1) that Testand uses.
Although you said it is too late to remove the typedef, can you add a struct name as in example 3 above? You can use the same name as the typedefName and TestStand will recognize it.

Looping through visa resources

I have a PXI Chassis that contains 8 serial cards. For simplicity sake, say they're wired 1-2, 3-4, 5-6, 7-8. So, basically, what ever I write to 1, I want to read at 2 - the same with the others. I have the code that configures the com ports and writes/reads the data to one set of ports. What I want to do, however, is somehow put this is a loop so as to have the com port number (enum) increment. The two questions I have are:
1) If looping this way is the best way to go, how do I increment from COM port 1 to COM port 3.
2) On the PC where I'm developing, I just have COM1 and LPT1 that show up in my VISA Resource control drop down. On the target, however, I know we have about 16 COM ports. I want to test specific ones though. Do I need to create some type of array of valid COM ports. Is this something that I have to hard code or can I do it dynamically.

You can use the for loop but you probably don't want to auto-index. Maybe if you got the array size and divided by 2 and wired this to the 'N' terminal. Inside the for loop, use the index array function to get elements 0 and 1 the first iteration, 2 and three the next, etc. A shift register will retain the index value.
Message Edited by Dennis Knutson on 07-27-2006 11:57 AM
Attachments:
for loop.JPG ‏9 KB

Resource-only DLL does not contain executable code

A resource-only DLL does not contain executable code. Since
LoadLibrary (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175.aspx) attempts to call the entry point before returning, it will fail for resource-only DLLs. Instead, you should call
LoadLibraryEx (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179.aspx) passing a
LOAD_LIBRARY_AS_DATAFILE, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE, or
LOAD_LIBRARY_AS_IMAGE_RESOURCE flag, to load a resource-only DLL. This prevents to loader from attempting to call the entry point.

Hello,
Just check if there is space in the front of these numeric values or some garbage value...if there is... then it may not be able to pad it up with zero and hence the issue...check in R/3 about how these values are stored...you can remove the space from the front and change it in PSA...and then load but first do the analysis of the source system and see why its coming up wrong.
Regards
Ajeeet

Pass VISA resource to DLL created by CVI

Similar Messages

Maybe you are looking for