NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Pass teststand command line args (/run, /editor, ...) when starting Labview UI as VI and not as EXE

Solved!
Go to solution

Hi!

(Setup: Teststand 2013 and LabView2013 on Windows7)

 

I want to start my UI (which is very close to the FullFeatured Labview UI) using the Development environment and pass the defined teststand command line arguments so that a seqeunce is started (after login). Somehow it does not work.

 

Start UI as EXE (working):

TestExec.exe /editor /run "StartupSequence" "D:\SequenceFile\Startup.seq"

 

Start UI as VI (not working, MyUi.vi does nothing more than calling the TopLevel VI of the FullFeatured UI):

Labview.exe "MyUi.vi" /editor /run "StartupSequence" "D:\SequenceFile\Startup.seq"

 

What did I do up to now?

1. I added code to the FFUI which shows me the cmdline args (App.args property ) of the Labview Application reference --> it shows the following string array (every array item in a new line)

LabView

/editor

/run

StartupSequence

D:\SequenceFile\Startup.seq

--> all arguments are passed like i write them on the command line excep the VI -> this is good because it is similar to the EXE situation.

 

2. I created a callback VI for the Application Manager Event ProcessUserCommandlineArguments --> Here I get an event for the command line item 'MyUi.vi' which means that the teststand AppMgr does not recognize this cmd line item. This is on one hand OK because the VI is not a known cmd line switch for teststand but on the other hand  a little bit strange because the VI is not part of the string array I described under point 1!

 

Situation: sequence in given sequence file is not started, no error dialog appears.

 

Best regards

  Waldemar

 

 

 

 

0 Kudos
Message 1 of 5
(3,954 Views)

I would expect exactly what you are seeing.  LabVIEW has a special built in argument handler for running VIs like that with the LabVIEW.exe.  So it will strip out the VI name from your arguments. 

 

However, TestStand doesn't know to do that.  So the TS engine is treating the .vi argument as an argument.  My guess, and I can't confirm this, is that because it sees such an odd argument it stops parsing through them all and doesn't execute the others?

 

Regards,

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
Message 2 of 5
(3,936 Views)
Solution
Accepted by weltaran

I've never spent time doing this in a VI that wasn't compiled to an .exe, so I'm not sure if LabVIEW will pass the original command line arguments on to the app manager.

 

If you ignore the .vi argument and just increment the currentArgument parameter, do the rest of the arguments get parsed successfully? (note that the event should actually get fired twice for each unrecognized argument)

 

I wrote an example a while back that might be useful, although it was designed to run as an executable.

Hope this helps!

Trent

https://www.linkedin.com/in/trentweaver
0 Kudos
Message 3 of 5
(3,925 Views)

Hi Trent!

 

>  If you ignore the .vi argument and just increment the currentArgument parameter, do the rest of the arguments get parsed successfully? 

 

YES! Now its working perfectly, just by incrementing the currentArgument. Thanks a lot.

 

weltaran

 

 

0 Kudos
Message 4 of 5
(3,887 Views)

Glad that worked!

 

I'm not sure how you wound up implementing this, but if you ever plan on compiling the code into an executable, you should test to make sure the VI is ready to handle both RTE and dev environment. For example, you could add in a check like this, or read the argument to make sure it's the .vi one before you ignore it. Wouldn't want to miss a valid command line argument!

 

-Trent

https://www.linkedin.com/in/trentweaver
0 Kudos
Message 5 of 5
(3,876 Views)