NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Absolute path to vi in project

"... i recommend you to reconsider using lvproj files for managing code modules if you require the full path to the VI in the step.

I think that packed project libraries are more the technology you are looking for."

 


Trust me, I have reconsidered.....to the point where I have argued back and forth with myself about exactly where to persist my DAQmx tasks.  The Teststand workspace would be one possible location but thats not possible and would require my to depend on TestStand to debug any hardware on test any system resources.  MAX does not allow for any subfolders so thats not doable either and again I have imposed an undesireable external config manager (MAX).  Persisting my DAQmx Tasks and scales into the UUT specific *.lvproj gives me the capabilities I desire and wrapping all calls to these resources in a single FGV makes code development and system integration darn near painless as I can use the individual resource modules to establish any system state.  (Well, except for one device.  For some reason it seams useless to put a I/O session to a 6544R on a USR since some of the lower level class data poofs out of existance the moment the FGV goes idle corrupting the data on the USR.  Nasty surprise there that I'm sure you'll get correctedSmiley Frustrated.  Don't call the cal dll from both the generation and acquisition FVGs either.  Since, even if you close the session, the darned calibration dll doesn't really go away until the caller is idle Smiley Wink)

 

For runtime souce control our legacy homebuilt tool simply creates a MD5 hash of all modules in each step of each sequence.  for modules call with tha LabVIEW adapter the file hashed is TS.SData.VICall.VIPath.  Simple, since from the begining of time this has been a path to a vi on disc.  Not true if the vi is called through a *.lvproj and hence my current predicament.

 

Just call the vi the Project is optional anyway right? Wrong- my DAQmx Tasks are in the Project so I need the Project to bring the tasks into scope and I want the tasks in the project to keep them segregated and prevent MAXtastrophies.


"Should be" isn't "Is" -Jay
0 Kudos
Message 11 of 13
(989 Views)

See Here for a possible work around


"Should be" isn't "Is" -Jay
0 Kudos
Message 12 of 13
(973 Views)

Jeff,

 

The easiest way to get the VI path is the following expression:

 

Step.Module.AsLabVIEWModule.GetVIAbsolutePath(Locals.myVar)

 

Where Locals.myVar is a string variable where the path will be stored. For example, I ran this expression in a Statement step directly before a VI that was being referenced from a .lvproj:

 

RunState.NextStep.Module.AsLabVIEWModule.GetVIAbsolutePath(Locals.myVar)

 

After this statement, Locals.myVar holds the absolute path to the VI on disk.

 

I hope that helps!

Message 13 of 13
(953 Views)