08-28-2014 05:11 PM
I am deploying a VI executable to several different PXI chassises and I have no control over which slot they put there PXI/PXIe hardware modules. I would like for a VI to auto-select the hardware resources based on the available modules of that type during startup of the executable before all of the hardware gets initialized. It would be nice to see an example of this being done...where the default hardware slot is selected on the chassis that builds the executable, and the "new chassis" that doesn't have the hardware in that slot but in another.
08-28-2014 05:59 PM - edited 08-28-2014 06:12 PM
Try something like this to get names and slots. You can then filter the results.
Cheers,
mcduff
EDIT:
Use the VISA FIND RESOURCE function to get a list of installed components, then use the snippet to find out what slots they are in.
08-29-2014 01:24 PM
With this approach, would I have to create a popup so that the user selects the resource manually before the initialization occurs?
If this is the case, is there a way to set what the user selects to be default each time when the executable is run in the future so that user doesn't have to keep setting it up each time.
08-29-2014 01:40 PM
You could create a configuration file to read on startup. If it isn't there, you can let the user configure the devices & slots and write this information to the configuration file to be read the next startup.
08-29-2014 01:41 PM
Here is a snippet where I look in a PXI chassis for a GPS module that can be either a 6682H or 6682. If it is found then the for loop returns a true value.
I assume you know what modules, or at least have a list, of the possible modules that will be in the PXI Chassis. Here if I find the GPS module in the chassis I initiate it, if I do not find it, then I do not use it in my program.
I would suggest you have a list of possible hardware and if it is found then proceed with the initialization, etc. I would recommend doing this automatically and not having a user pick from a list.
Once you perform an initialization and know what is in the hardware it is possible to create an ini file such that you do not have to cycle through the chassis to determine what is in there. However, I discourage this, as hardware may be added/subtracted from the chassis and thus your ini file would be invalid.
Does any of this make sense or am I unclear.
Cheers,
mcduff
08-29-2014 04:42 PM
I'll give it a try next week after the holiday. I've considered a setup file but when delploying it to people it is hard to manage all of the issues that can go wrong with the app. Thank you both so much. I et you know.
08-29-2014 05:21 PM - edited 08-29-2014 05:24 PM
USE ALIASIS
No, Seriously, COM9 on PXI Slot 1 (Whatever) is junk deployment. Oh, It might work until the first time that MOXA Uport that used to be COM6&7 becomes COM9&10 If you call COM6 "SOBThingA" you can use MAX to make "SOBThingA" COM9 Or even use the import wizard to choose which device to replace on the target based on ---Drum roll.........phyiscal connections You can see those but --The SW CANNOT- I guess that is why the wizard lets you make a choice: Although, silient import might fail if the installer first installs "Config support for...NI- XXX" does not reboot and tries to import config info. (Trust me)
DOWN SIDE: You need to add "MAX Config support for NI-XXX" to your installer and the installer grows fast!------ But, the Maintainence personel can use MAX to test that device's connectivity, or operations, or Tasks or calibrate the Scales. (And itegration gets a lot simpler too)
Now lets go on just a bit:
" I've considered a setup file but when delploying it to people"
Yeah, do that. but, use a file named "*.nce" MAX Export wizard creates those fairly nicely
08-29-2014 05:39 PM
Interesting idea. I've never attempted this, are there any whitepapers?
However, how does this answer the original poster's question?
"I would like for a VI to auto-select the hardware resources based on the available modules of that type during startup of the executable before all of the hardware gets initialized."
If the modules are not in their chassis, does the MAX Config API spit out an error?
Also
"I have no control over which slot they put there PXI/PXIe hardware modules"
I once configure a chassis with three identical A/D boards; the users liked to know the slots of the boards so they knew where they were connecting there signals.
Does the MAX Config API give this information?
Lastly, how does MAX Config API "play" with non-NI boards. In the aforementioned example I gave, I had non-NI boards, MAX did not let me do much with them, except "see" them.
Cheers,
mcduff
08-29-2014 06:16 PM
@ mcduff
The system API can Identify what is connected, what type of device it is and usueally the manufacturer of the device
It cannot detrmine if a specific one of that type of device is in-turn connected to specific hardware.
FirInstance: you have two NI 6905's in your system NI-6509-DEV1 is used for DO that Controls "Motion" the other is used for DI that reads system "Status"
You deploy to the target
XXX will be replaced by "Motion" in the import wizard... You get to select if that is Dev1 (connected to ABC) or Dev2 (Connected to XYZ) since both are devices of the same type. Where they are located logically or phyisically does not matter!
Your code uses tasks calling on lines in the hardware resourses "Motion" and "Status" to read or write Digital lines. If you SWAP the connectors on those devices you only need to swap the device Aliases to use the same tasks.
(And it gets sweeter when you call port0.0 "DoThis" and can move a wire to Port0.1)
08-29-2014 06:30 PM
@ Jeff
Thanks!
I am down on MAX right now as something hosed my system and a complete reinstall still isn't working.
So, I do not completely trust it, nor do I understand it. Most of my dealings with PXI chassis has been non NI Chassis, and non NI Boards. I've had to program using DLLs supplied by the manufacturer, not DAQmx tasks.
Lastly, I tried to keep my program dynamic, or loosely defined may be a better description. There may have been 3 identical boards, but the user could change which board was the master trigger, etc. In this case, I had to know the slot as the PXI TTL Line needed to be routed over the backplane.
In my case I ended up making two similar chassis, one that had a GPS, one that didn't. I did not want two separate programs, so I just searched in the beginning to see if it was there.
Cheers,
mcduff