Is there a way to read VISA addresses from an INI file?

[bemoore]

I'm developing some code for automated testing, and I'd like to be able to specify my instrument addresses in an ini file. I tried setting up an INI read, with a VISA address as the default, but it wouldn't run. Is there a way to convert VISA addresses to/from text?

[santo_13 · Accepted solution]

Please share the code and sample INI files you tried.

For INI files, VISA resources are just string, it does not know anything about what it is, if you are able to read/write strings to ini file, it is no different.

[billko]

If, instead, you use NI-MAX aliases, you can make the ini file "universal", meaning that let's say one of your test stations has ABC instrument on GPIB, but on another station, ABC is hooked up VIA network, you can have each instance of that instrument have the same alias in NI-MAX, and you wouldn't have to have separate ini files for each station.

Doing that, we were able to run the same software on a legacy test station that had an Agilent Power Supply hooked up on GPIB, and an updated station that had it hooked up via network.

[BertMcMahan]

Yes, you can generally just write VISA addresses to string functions and it auto-converts. If it doesn't, you can always use Format Into String or something. IIRC, all functions that take a VISA address can also take a string with no loss of functionality.

@billko- I normally handle VISA and DAQmx addressing using ini files that get set up on each computer during installation, which works great. Do you gain anything by using MAX aliases? And can you do it programmatically with an installer or similar? Is that what the dang .aliases file is that always gets auto-created? 😉 Does that get rid of the "Which COM port is my unit again?" problem? I guess, can MAX aliases give you the same alias for a given instrument no matter which port it's plugged into?

[billko]

---

@BertMcMahan wrote:

Yes, you can generally just write VISA addresses to string functions and it auto-converts. If it doesn't, you can always use Format Into String or something. IIRC, all functions that take a VISA address can also take a string with no loss of functionality.

@billko- I normally handle VISA and DAQmx addressing using ini files that get set up on each computer during installation, which works great. Do you gain anything by using MAX aliases? And can you do it programmatically with an installer or similar? Is that what the dang .aliases file is that always gets auto-created? 😉 Does that get rid of the "Which COM port is my unit again?" problem? I guess, can MAX aliases give you the same alias for a given instrument no matter which port it's plugged into?

---

Let me guess.  You don't like MAX aliases.  I'd rather install a new instrument and assign the alias than release new software because of an ini file change.  It's much cheaper and takes a lot less time than it takes to release said software.  Our instruments get sent out for calibration all the time and need to be swapped out regularly.

So while it won't help with COM port changes from plugging in a USB adapter in a different place (OS at fault here), and MAX will assign a new alias to your new hardware, it makes administering the software much easier.  That is, assuming that your software is CM controlled.  (In my world, a change in an ini file will result in non-conforming software and invalidate all tests run with that software on that machine.  Hence the new software release.)  And of course, as I mentioned earlier, while new iterations of test stations usually have the same instruments, legacy ones are usually GPIB, new ones are networked.  One software release will run on both stations without any changes.

[JÞB]

Getting back to the original question.

Any VISA function will take a String and Coerce it to a VISA IO session by name. DAQmx does the same thing since it has VISA under the hood. RFmx does not because VSTs use RIO not VISA IO

MORE: details you don't care about...
The String will first look for an existing VISA Session with that Name Property.
Then it looks for an existing Alias even if the device is not present. Next it will try to decipher a resource descriptor e.g. GPIB0::4.
Lastly it returns an error if nothing is right.

CONCLUSION: Use a String Value in the ini file containing the Alias of your IO Resource.

ADVANCED: for Mr Ko and Bert Use the System Configuration Palette functions to verify hardware, rename Aliases, and test for calibration dates programmaticly at startup. You can even Import a MAX configuration *.nce file at install OR DURING APPLICATION STARTUP for those systems where multiple applications exist.  For instance two developers want a HP 6632B resource at GPIB0::10 to be "VCC" for test 1 and "TestCurrent" on test 2 on the same station.

[crossrulz]

---

@bemoore wrote:

I'm developing some code for automated testing, and I'd like to be able to specify my instrument addresses in an ini file. I tried setting up an INI read, with a VISA address as the default, but it wouldn't run. Is there a way to convert VISA addresses to/from text?

---

I store my addresses in a JSON file, but the concepts are the same.  Here is how I create my VISA Resources.

[JÞB]

---

@crossrulz wrote:

---

@bemoore wrote:

I'm developing some code for automated testing, and I'd like to be able to specify my instrument addresses in an ini file. I tried setting up an INI read, with a VISA address as the default, but it wouldn't run. Is there a way to convert VISA addresses to/from text?

---

I store my addresses in a JSON file, but the concepts are the same.  Here is how I create my VISA Resources.

---

Hey Tim.  Could you explain the advantages of using JSON over the NI proprietary nce format native to MAX and exposed in LabVIEW with the app builder and the system configuration API? Or even a ini I thought JSON was built on the W3 Document Object Model and DOMUSERDEFREF.DLL Is still not threadsafe.  Since LabVIEW 2009 the ini internals use those blinding fast queues. Or, am I out of touch on that?

[crossrulz]

---

@JÞB wrote:

Hey Tim.  Could you explain the advantages of using JSON over the NI proprietary nce format native to MAX and exposed in LabVIEW with the app builder and the system configuration API? Or even a ini I thought JSON was built on the W3 Document Object Model and DOMUSERDEFREF.DLL Is still not threadsafe.  Since LabVIEW 2009 the ini internals use those blinding fast queues. Or, am I out of touch on that?

---

I just try to avoid having MAX define things.  I really got into this habit when I had a single test system working 15 different projects.  Instead of having 15 sets of definitions in MAX, I just used simple text files (ini at that time) that each project read and did the setup they required.  It has served me even more at my current position where nearly all of the test setups use laptops connecting to who knows what equipment over who knows what communication bus (Ethernet, serial, USB, MXI).

I recently started using JSON instead of ini because I found that I needed a hierarchical definition for many of my instruments.  Config files (ini) are flat.  I got them to work, but they seemed not intuitive in the definition.  I did dabble with XML for a little bit, but debugging with NI's XML API was really hard.  I now use JSON Text by JDP Science, which is a wonderful library that allows me to parse JSON objects very easily.

[bemoore]

This is kinda embarrassing. I THOUGHT I had the "broken start button" when I tried this. But today, I used strings everywhere, and it just converted to VISA addresses where needed. Thanks for the help.