What would be a good way to auto-select a VISA resource during the startup of a deployed VI?

[JÞB]

Oh, then your config may need to recreate the XML hell that max installs. It is a daunting task. I have no good advice. Other than try to be flexible. Max exists and works, so it is possible to do. I wouldn't care to estimate the cost of the framework. And I would have no means of showing anything to justify the quote.

I just write code.

[scarter1]

More on the issue:

Let's say I have 2 people that I am deploying the app to. My VISA resources on the front panel point to a specific slot and they are the default configuration. In this app, I require a function generator, a scope, and a power supply. I build the app and deploy to the 2 people. Person A has 2 scopes and the scope that shouldn't be used is in the slot that I have the default set to in the deployed app. Person B has all the right hardware but none of it is in the default slot so when the app is run it starts to do its function and the VISA resources on the front panel are blank because they need to be selected. The people can not set their defaults for their computer after I deploy and I don't want them to have to set up the front panel every time they run the app.

As far as the setup file, the only way that I can see it working is that the people will have to run the app to set it up once and then output a setup file to the hard disk. I don't see how I can do it if I deploy it with a setup file.

I'm not a great LabView programmer but typically manage if I see an example. Does the above detail help describe the issue I'm having better? It would be nice to see some code where there are 2 devices of the same type ... like a scope ... but are different hardware modules and then the code selects. Consider the 2 scopes to be NI PXIe-5122 and NI PCI-5922. I would like my app to select the NI PXIe-5122 and run the rest of the logic in the app.

Thanks again! 🙂

[mcduff]

I cannot argue against or for the merits of using NI-MAX configuration settings. Judging by the forums, Jeff is a LabVIEW programmer whereas I am just a hacker who happens to program in LabVIEW for my job sometimes. (What I am saying is Jeff's advice should be weighed heavier than mine.)

That being said I had this issue:

1.) Two PXI chassis, different manufacturers

2.) Digitizers from the same company, (Not NI), but different models. (Models had different resolutions and sampling rates)

3.) One system had a NI GPS system, the other may be updated in the future with the card.

So in the beginning of my program, I used something similar to what I posted earlier. I detected how many and what type of digitizer I had, I detected whether I had a GPS card, and I detected what chassis I had. I also detected what slots the cards were in. We had issue with heat and sometimes moved the cards around. We needed to keep track of the slots for data analysis and triggering purposes.

In my program where changes were necessary depending on the hardware, I just used case structures, for example, the following cases, Model 441, Model 461, etc. I did not see any major issues regarding speed or execution. I imagine this would be a good case for Object Oriented programming, but that is above my pay grade.

Lastly, it also depends on what environment you are using the cards. My systems were developed for research purposes, that is, cards could change, be moved in or out of the system, etc. For a production environment where nothing is changing, then I imagine you could be a little more rigid with the requirements.

Hope this helps.

Regards,

mcduff

[AKA_TG]

PErhaps you could have a preemptive UI come to the surface (only at startup)  that allow the user to check things before continuing on. The advantage (while a bit klunky)  is that an ini file could be read in to show the last user selection made and then continue on with processing or give user a chance to assign slots and resources for a hardware change.

The disadvantage is that the user would have to know what cards are in what slots.

Perhaps the setup UI coluld be triggered upon particular hardware access errors so that it normally does not show up except by user request.

This would give the user a chance to check what the program 'thinks it has installed' and make suitable corrections.

In a research environment (hacker hehe I like the term) this would be fine and I normally do this kind of thing with our "in house" stuff.

Having all of it figured out programatically could be very difficult and convoluted, especially if things are switched around often.