What is the best practice when working with address handles?

[taylorblack]

I have a bunch of instruments that I'm trying to use in a Labview Program that are in a PXI chassis. The address handles seem to be static, so I'm thinking of writing all of my instrument sub-VIs with the instrument handles as constants. I would prefer to do it this way because I am using state machines and don't want to carry the handles out through shift registers in every state. My concern is that I write an entire program doing this and have communication issues in the future and have to go back and rewrite everything. 

What is the best practice for working with instrument handles?

[santo_13]

You maintain the address handles in a config file, this way you can still update it.

Create an action engine (FGV) that reads the config file at startup, use this FGV to retrieve the PXI Alias at every place in the state machine. But the question is why you need the PXI alias? it is required only at initialize, after that you need to use the session handle of respective drivers throughout your execution until it is time to close the session handles when you're done using the instruments.

[taylorblack]

Thank you for the reply. I guess I'm confusing the PXI alias and the session handle. Is there a better way to pass the session handles to different states without shift registers and all of the extra connections? I ask because it gets really busy when you have a lot of states and using many different instruments.

[JÞB]

For each project I will almost certainly create an Action Engine for each Resouce that will be used.  In fact, I started using the term Resource Module long before I read 

Ben's famous Action Engine Nugget is always a good read. http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801

That I still keep in a macro so I don't have to look it up all the time.

In every case with a PXI Chassis I will set a meaningful Alias in MAX and ensure my installer imports the MAX *.nce file.  Meaningful Aliases like DMM1 and VST1 or RF_MUX2 help a lot!  I even use Meaningful names for my DAQmx Tasks like PartInPlace or Temperatures (with Channels AirIn, Exhaust,  Armpit etc...) and store the Task information in the XML file called MyProject.lvproj.

Often, I will even wrap up these Resource Modules inside a separate project containing a lvlib with a private AE "Core.vi" and enum ctl, a public API with Init, Close and Read/Write vis plus Config.vis when needed.  Also in those projects, but outside the lvlib, you find requirements documents, Unit Tests, ReadMe files, Examples or Soft Front Panels and anything else I need for when the client comes back 12mo later with a new requirement.

So, yes!  All of my Resource Modules run with a constant in the Init case and stored on a FBN or SR.  those Modules are designed to do everything the using project needs done to that resource and should not access any other resource.  The caller does not need to know anything about the how or on what the action needed is taken and exposing the session to the caller just begs for some "eye dee ten tee" (ID10T) to mess up my perfectly fine code.

Too much work.you say?  Project Templates I reply.