Read the client steps running from a different thread in a custom process model

[DaliaR]

Hi, 

I built a TS application with a customized sequential model (next step will modify the batch model). The idea is to have one custom process model for several customer's test sequence; no matter which test sequence will be run, it will use the same custom process model. In this specific case, I modified the Sequential.seq to our needs. This image shows in general the architecture: 

The Sequential sequence calls an LV GUI in a new Thread. This LV GUI receives data using Queues. It works well only if I use the Parameter.Name in the SequenceFilePreStep and SequenceFilePostStep Callbacks in the customer test sequence. 

My goal is to pass the running customer steps to the LV GUI without modifying or touching the customer sequence. I would like to receive this information using RunState variables or any other TS API. 

I know I can use the RunState.CallingStep.Name in the Customer sequence, but since the LV GUI is in another thread, this variable is not useful. 

Questions:

1. What is your recommendation to get\receive the running steps in a different thread?

2. In the near future I will modify the Batch.seq and do the same. What is your recommendation to receive the running steps of each socket in the LV GUI (running in a different thread?

Thank you for your help

Dalia

[~jiggawax~]

This is an exact case of over-engineering in TestStand.  I'm sorry to be the bearer of bad news but you've basically reinvented the UI in TestStand but in a bastardized way.  Why not just have a custom UI.  It will be much much better for what you are trying to accomplish.  You will have UI Messages so you can pass information much simpler than a crazy Queued system.  You'll have access to everything you need through the manager controls.  And you'll be using TestStand the way it was meant to be used.  Typically I'm not this blunt with people but you need to be warned.

That being said.....

If you are dead set on going down this fruitless, already dilapidated, way of using TestStand then you really need to pass the execution object into the LV GUI.  From that you can get about anything you want.   This all depends on when you kick off the new thread.  Do you do it first thing?  Where in the model are you spawning it?  

I got it to work by doing this:

I did notice that the VI can't keep up with TestStand though.  Basically I was monitoring at less than 1 millisecond.  The sequence context is the context of my root in the process model.

This will obviously not scale to batch.  That will be a whole new ball game.

Seriously though....consider a custom UI.... just sayin'.  You are embarking on a maintenance nightmare.

Cheers,

[DaliaR]

Hi Jiggawax, 

Thank you for being honest. It's better to know the truth and the best path to follow. 

From the beginning, I suspected it would be impossible or very hard, especially if I want to move to Batch mode. 

In fact, I'm using the TestExec based on the Basic UI TestExec with some modifications, however, I wanted to receive the running steps from a VI running the Sequential Model before the PreUUTLoopCallback. 

Regarding using UI Messages, as far I as I know, it means that I will need to use the Thread.PostUIMessageEx in the Customer Test Sequence, which I would like to avoid. 

Question: 

Can I use UI Message using callback in the Customer Test Sequence? similar to using the SequencePreStepCallback? 

Can I use the UI Message without adding PostUIMessageEx in the client? I suspect the answer is no, but just checking other options that I'm sure you will know better than me.

Thank you for your help. 

Dalia

[~jiggawax~ · Accepted solution]

So there are many types of events and user messages you can trigger off of in order to accomplish what you want. 

One event is the StartExecution event:

From here you can get the client file information using something like this:

Obviously you could get more sophisticated. This will give you the steps of your client file at least. 

There are a lot of user messages that the engine itself sends as well.  You could trigger off of one of those after each step to get info about the step.  Or you could use StationCallbacks to post your own UI Messages.  Both options would be non-intrusive to the client file.

[DaliaR]

Brilliant!!

Thank you so much for your help Jigg, I will try it