Re : If I have custom process model, should I combine client file and process model?

[Trouble]

I have a general question about TestStand.  I understand the process model and how it works and how the client file works with it.  In our application, I created a UI (LabVIEW) and in the process needed to create a couple of custom entry points in the sequential process model.  I removed the 'Single Pass' and added a simple entry point for selecting some utilities and I slightly modified the 'Test UUTs' to have a different name for the GUI.  

Now that I did that, the process model is technically customized.  My coworkers are saying that since it is customized, I should reduce it down to one file instead of both the process model file and the client file.  I see a couple of issues with this. 

-          One, it doesn’t seem that you can run a process model without a client file. 

-          Two, you can’t use entry points if you have a client file without a process model (how would you then interface with the UI?).

Can you confirm/deny this and give me your thoughts?  Personally, I think the two files is still the way to go, but I need some solid arguments as to why, unless you think I can just go to one file?

Here is a little more detail of my client file.  We are actually using the client file as the standard engine for ‘dynamically’ calling small test sequences.  So basically you would use this to call other small individual tests that will only interact with the UUT and the hardware.  This top level architecture will deal with the UI, Database, Results and any setup needed for the test station itself.  This way, a developer just has to worry about their specific test (e.g. calibrate or check interlock) and does not need to know anything, or very little, about the architecture.  The developer will not need to do any overrides to the architecture in any way, they just need to interact with their UUT.

Thanks in advance for your help on this!

[Mathieu_R.]

Hello,

It is possible to overload callbacks of the built-in ProcessModel is test sequence : this is a way to get a unique file (no custom ProcessModel to deploy). This is a good option, if customisation of the ProcessModel can be handled only by overloading callbacks.

My understanding, you customize the EntryPoint. This means these customizations should be generic for your test station. In your case, two files are a better solution (imho).

Calling different sequences (as unit test for instance) from a more generic sequence file is something I have seen: in that case, a generic MainSequence.seq is in charge of chaining the different unit tests (other sequence files). MainSequence call was 'hard coded' in the EntryPoint : ProcessModel was responsible of repport / generic TestStand stuff, the Main sequence of campaing handling (two different roles, two levels of sequence file).

Best regards,

[Trouble]

Yes, my client file is overriding a few of the callbacks as well as some of the engine callbacks (not so much overriding as adding some functions).  Unfortunately, you cannot do this with the Entry Points.

Thanks for your input!