Differentiating between TestStand user interfaces at run time

[Rob_]

Hello,

Up until a new requirement, we have been using the off-the-shelf Full Operator Interface (labview) for the majority of our Deployed tests in production environments.  Unfortunately (especially as the production folks are accustomed to it) we now have a need to further lock-down the execution of some of our tests.  Thankfully the off-the-shelf Simple interface looks like it will remove the functionalities which are in conflict with our new requirements. 

The problem:

Our production group includes some clever people, who *could* decide to just bring back the Full Operator Interface, and I'm tasked with playing Big Brother and ensuring that the end reports reflect HOW the test was run (eg. only the 'simple' runs which are sanctioned by the new requirements are allowed to produce a clean 'pass' report).  The report generation branching side of this isn't a problem, but I'm stumped when it comes to 'knowing' whether the operator used the approved interface or not.  I do plan on giving the production the Full UI for the Engineers to troubleshoot with also, just prevent clean "Pass" when they run that way.

So I've been looking at the source code from a few different angles in an attempt to solve this:

• Looking for the definitions of the menu items which are causing us problems got...complicated quickly, and unfortunately doesn't answer "what if they grab/run another UI?"
• RunState.IsEditor is a great way for me to 'see' the difference between editor and operator, and will help.  But unfortunately isn't enough to differentiate (Dev vs Engineer vs Operator)

My question:
Is there another (similar to IsEditor) property that I can latch onto to determine which interface is executing?

or

What is the easiest way to embed such a flag into both interfaces so that I require that the flag exist and tells me that it's the 'locked down' UI before the report can come up as a clean "Pass"? 

[Norbert_B]

The most simple way i can think of is using User Management. If you can make sure that the user has to log in with HIS/HER account, you can verify that he/she can only perform those actions which are "acceptable" for this account.

hope this helps,

Norbert

[Rodéric]

You can modify report options in combination with user management, you could set a different directory for the reports operator/engineer/etc...

[Rob_]

Thanks for the suggestions re: user management.  I don't think that's an approach I can use for our specific problem, but poking around in there and the relevant portion of the manual I see that it's a good way to do things like that.

Example commands that I can't allow them to access for a 'clean' run are the:

ForcePass

SetNextStepToCursor

I suppose I could define the custom priveleges for those commands/users, but then I run into the problem that the Engineers which we want to enable to troubleshoot (run out of order) would be denied the ability to run as an Operator and perform unmodified runs of the tests (sometimes they help out by playing 'operator').  Also we would be having one of the Engineers on that end acting as admin for the user management portion, which in itself would end up a headache.

If there's no sort of 'which UI application is running this sequence' parameter, perhaps a different angle?  Would it be a herculean effort to insert a new boolean "NonStandardRun" which is set to true when/if unacceptable commands are executed?

[~jiggawax~]

Why don't you change the simple UI name from TestExec.exe to SimpleTestExec.exe.  Then somehow use ActiveX or DLL steps to find out the process.  I wouldn't know what those are off the top of my head but you could probably google.  It would be the owning process. This would be some Windows API stuff.

Then just have one of them be a pass/fail step and make the sequence fail if it's not SimpleTestExec.exe.

[Rob_]

Thanks Jigg.  That's definitely in the ballpark of what I was aiming to do.  I guess I hadn't thought to go that route yet as all my previous delving into windows API was on XP systems (these new platforms are 7)

Playing devils advocate though, is it likely that going this route would be able to tell the difference between my renamed simple interface and a later-renamed (naughty engineers) full interface?  Pretty sure I can defeat that as well through some windows permissions as well as the checksumming we're planning to add into parts of our sequence.

At some point playing big-brother gets a little ridiculous (you can spend LOTS of hours at it) but when it comes to even 'accidentally' having a 'pass' report for bad hardware...

[~jiggawax~]

it's actually easier than i thought.  Even better is the path to the exe.

[~jiggawax~ · Accepted solution]

For those that can't access the example:

simply place down a .NET step.

Assembly: System(X.X.X.X whatever version)

Root Class: System.Diagnostics.Process

.NET Invocation:  GetCurrentProcess().MainModule.FileName

Then in the Parameter list set Value to the variable where you want to store the path.

I agree Rob that it is a pain to play police with those that should ethically care about the well-being of a company.  I've spent countless hours doing it myself.  Good Luck!!

[Rob_]

Thanks a ton Jigg!

Combining that with some simple checksums should be able to ensure that I can branch the results according to who/how the sequence is being run.

Thanks again,

-Rob

[Trek]

Thanks a lot.

I'm creating a user interface in labwiew for calling TestStand tests sequence.

Can you tell if the user interface can start automatically after opening the sequence files?

How can i do this in Labview Vi? Where?