From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Is there a way to read VISA addresses from an INI file?
Solved!
@billko wrote:
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.
No, not at all. I've just never used them before and am wondering if I'm missing something. I'm more in crossrulz' situation where setups change very frequently, so being able to click "Setup" within my program to change an address (which my users can do manually) is much easier than trying to manage MAX on all of the systems as well (which would require some new training). I'm just trying to learn about as many new features as possible. Apologies if I came across as challenging- I'm genuinely curious to learn new methods that I haven't used before.
@BertMcMahan wrote:
@billko wrote:
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.
No, not at all. I've just never used them before and am wondering if I'm missing something. I'm more in crossrulz' situation where setups change very frequently, so being able to click "Setup" within my program to change an address (which my users can do manually) is much easier than trying to manage MAX on all of the systems as well (which would require some new training). I'm just trying to learn about as many new features as possible. Apologies if I came across as challenging- I'm genuinely curious to learn new methods that I haven't used before.
LOL, it's just that most poeple don't like using MAX (including me, at times). It's all good. Sorry that I came across as more defensive than I should have.
@Kevin_Price wrote:
Off topic...
@billko wrote:
...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 machineInteresting policy. Changing the system config via MAX is fine, changing it via ini file is verboten. I'm guessing the powers that be might not be fully aware of the MAX "back door" that still lets you change the test environment...? 😎
-Kevin P
You know how the people making these decisions aren't necessarily the ones with the information to make them...
@Kevin_Price wrote:
Off topic...
@billko wrote:
...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 machineInteresting policy. Changing the system config via MAX is fine, changing it via ini file is verboten. I'm guessing the powers that be might not be fully aware of the MAX "back door" that still lets you change the test environment...?
My solution for the configuration file was to have the software perform a checksum/hash (MD5 at the time) on every file in the project (TestStand sequence files, VIs, configurations) and that was verified by the software before it would run anything. Far from perfect, but it made quality and the customer (NASA) happy.
I store all my instrument VISA information in an XML file.
This is what in looks like in XML Notepad
Raw XML file
I parse the XML and type cast it to a VISA Resource type because I have an aversion to coercion dots 😛
@RTSLVU wrote:
I store all my instrument VISA information in an XML file.
This is what in looks like in XML Notepad
Yep, I did something similar. XML Notepad is a great tool if you are doing XML. But, as I said earlier, I had a lot of trouble debugging the parsing code (kept getting confused about what layer I was in and the reference doesn't give the information I needed). I switched to JSON and the JSON Text library because the library allowed me to see the actual strings being parsed and therefore debug. I also don't need a special tool to do JSON effectively.
