11-12-2025 07:31 PM
What magical powers does this "NI-VISA Interactive control" program have?
Trying to use a 3rd party GPIB-USB controller (ADLink 3488a USB) and the only place it is ever recognized is the NI-VISA Interactive Control (let's call it NI-V IC) program.
If this NI-V IC program is launched from NI-MAX, the controller will show up in NI-MAX after being discovered by the NI-V IC program, but is then lost as soon as NI-MAX is closed and re-opened.
Within the LabView development environment, the controller is never visible in the VISA resource constants (yes I filtered for the correct VISA class --> GPIB controllers, works fine for NI branded GPIB-USB units). The stock visa "Find Resource" VI also does not return it (or any instruments connected to it).
I then got curious and turned on NI IO trace while the magical NI-V IC program was launching and it seemed to execute the following sequence:
viOpenDefaultRM (an interesting function which has no implementation in the standard LabView VISA palette)
viGetAttribute (getting resource finding search mode)
viSetAttribute (setting resource finding search mode)
viFindRsrc (ostensibly equivalent to Find Resource palette VI)
Then I got curious and did an import of the visa64.dll in order to gain access to these functions from the labview IDE, then ran the exact same sequence, and still it did not return the GPIB controller 😂
What magic is going on there?
11-14-2025 02:52 AM
@vdod1717 wrote:
What magical powers does this "NI-VISA Interactive control" program have?
Trying to use a 3rd party GPIB-USB controller (ADLink 3488a USB) and the only place it is ever recognized is the NI-VISA Interactive Control (let's call it NI-V IC) program.
If this NI-V IC program is launched from NI-MAX, the controller will show up in NI-MAX after being discovered by the NI-V IC program, but is then lost as soon as NI-MAX is closed and re-opened.
Within the LabView development environment, the controller is never visible in the VISA resource constants (yes I filtered for the correct VISA class --> GPIB controllers, works fine for NI branded GPIB-USB units). The stock visa "Find Resource" VI also does not return it (or any instruments connected to it).
I then got curious and turned on NI IO trace while the magical NI-V IC program was launching and it seemed to execute the following sequence:
viOpenDefaultRM (an interesting function which has no implementation in the standard LabView VISA palette)
viGetAttribute (getting resource finding search mode)
viSetAttribute (setting resource finding search mode)
viFindRsrc (ostensibly equivalent to Find Resource palette VI)
Then I got curious and did an import of the visa64.dll in order to gain access to these functions from the labview IDE, then ran the exact same sequence, and still it did not return the GPIB controller 😂
What magic is going on there?
The "magic" of the NI-VISA Interactive Control (NI-V IC) lies in its ability to force a comprehensive re-initialization of the NI-VISA resource manager, explicitly loading the necessary third-party vendor drivers (like the one for your ADLink controller) that the standard LabVIEW environment or NI-MAX often fail to load during their typical startup sequence. Your custom DLL calls failed to replicate this because the NI-V IC runs with internal, privileged logic (likely part of the detailed viOpenDefaultRM execution) that successfully forces the ADLink DLL to be recognized by the NI-VISA kernel, ensuring the controller is visible for that session only.
11-14-2025 10:04 AM
That seems reasonable although to be clear, I did call the viOpenDefaultRM when making my own calls to the VISA API. So that suggests to me there is something beyond the content of that function. What I am also wondering is if NI considers this intended behavior, or if it unintended behavior that I could expect to see fixed in future versions of LabView / VISA?
Also I am not clear if you are an NI employee who knows this for a fact or an outsider like me? Or an AI 🙂 never know these days
11-18-2025 05:38 AM - edited 11-18-2025 06:09 AM
@vdod1717 wrote:
That seems reasonable although to be clear, I did call the viOpenDefaultRM when making my own calls to the VISA API. So that suggests to me there is something beyond the content of that function. What I am also wondering is if NI considers this intended behavior, or if it unintended behavior that I could expect to see fixed in future versions of LabView / VISA?
It's most likely neither intended behavior nor anything NI will try to fix on its own. NI VISA is the defacto implementation for the VXIpnp VISA standard. This standard is published and you get access to a lot of documents and example codes to implement your own drivers if you are a VXIpnp consortium member. Not sure about the fee to be a member of this consortium but it is likely a considerable yearly amount.
Adlink seems to have access or having had access to this standard documents and implemented a VISA driver for their hardware. But it seems to not behave in a way that NI VISA will simply recognize it as a valid VISA passport and initialize it. The buck is obviously with Adlink here. they have to investigate what goes wrong and either fix their problem or report a bug to NI for not implementing the VXIpnp standard to the letter. Of course that assumes that they are still a member of the VXIpnp consortium. If they are not, I'm afraid all you can do is accept that that board never will work with NI VISA. NI is not going to spend even one engineering hour to fix a problem that affects another manufacturers and competitors hardware unless that manufacturer can proof to them with hard facts that their implementation is not according to the published standard.
Also I am not clear if you are an NI employee who knows this for a fact or an outsider like me? Or an AI 🙂 never know these days
Active NI employees usually have a blue color in the activity bar with the three rectangles to the right of the avatar icon. As to the post being from an AI, it absolutely does not look like a typical AI answer. They are normally neither as explicit and detailed as that response was and usually tend to be super well formulated but with little substance telling you with complete confidence half truths and fantasies as facts. The fact that it is a 1 hit wonder (a person having done exactly 1 post only) and seemingly having specifically signed up for this answer could be several things. It usually is a sign of a spammer, signing up, posting some seemingly useful information before going onto a spam run. But it could be also someone not wanting to post this under his normal account. Doesn't seem very likely, the information isn't exactly very sensitive, just a little bit outside of the normal advices.
Adlinks solution seems to be to suggest to instead install the Keysight IO Driver software suite.
My guess is that their VISA passport has certain problems that the Keysight VISA implementation is not so picky about.
11-18-2025 02:57 PM
Thanks for the detailed response! It still seems strange that NI recognizes it perfectly well in certain programs (the interactive controller) but not in MAX or the regular IDE, but I won't worry much about why.
But I disagree that Mary's response was not AI typical, to my eye it was quite typical 😄
Great find on the ADLink driver documentation, I will check that out as well.
Take care