Best structure for an automated test program

[buddyfares]

here is a quick diagram of the states.  Would it be recommended to use event structure to handle the parts where I am waiting for sensors to close or just loop in those states until true?

[wiebe@CARYA]

I'd let the sequencer handle it.

You'd have a GUI loop controlling the sequencer.

The sequencer handling the sequence.

The DAQ loop reading\writing the things the sequence does.

Come to think of this, this probably qualifies as a traditional Model\View\Controller setup (DAQ+UI in==Controller, Sequence==Model, GUI out==View).

+1 for making and posting the 'design'.

[buddyfares]

So I broke this down a bit.  I will put a quick test program together but attached is what I am thinking the structure will look like.  Does this look correct?

[wiebe@CARYA]

---

@buddyfares wrote:

So I broke this down a bit.  I will put a quick test program together but attached is what I am thinking the structure will look like.  Does this look correct?

---

It's still more a specification than a design or structure. But it looks like a good specification 👍. Making a SM from it won't be that hard.

You still have the opportunity to implement it as a sequencer 😋.

[buddyfares]

So would using an event structure to activate the stops and  move pallets into the test station with the last event being one that initiates the test sequence.  This test sequence could be a state machine of sequence structure (I was just thought to use state machine over sequence).   Once started it will be a continuous process until stop is pressed. 

When you say sequencer are you referring to the sequence structure of something else?  because I also thought about using teststand for this but only have used it for pure testing.   

[wiebe@CARYA]

---

@buddyfares wrote:

So would using an event structure to activate the stops and  move pallets into the test station with the last event being one that initiates the test sequence. 

---

Using an event structure to activate things is pretty much set in stone. I can come up with useful exceptions (make a sequencer that waits for GUI), but an event structure would be the standard.

---

@buddyfares wrote:

This test sequence could be a state machine of sequence structure (I was just thought to use state machine over sequence).   Once started it will be a continuous process until stop is pressed. 

---

Definitely not a sequence structure. A SM is far better.

(How is a sequence structure ever going to react to an emergency stop?)

---

@buddyfares wrote:

When you say sequencer are you referring to the sequence structure of something else?  because I also thought about using teststand for this but only have used it for pure testing.   

---

I'm referring to an (OO) Sequencer. When done, it's not that different form Teststand, but tailor-made in LabVIEW, and specifically for your purposes.

This would basically be a step class that executes a step. It would have children that actually get\set IO. It would also have a child that executes steps in parallel, and a child that executes steps sequential. With those classes, you can execute a sequence.

Each step (e.g. a ramp or wait for something) can either loop until finished, or execute and either continue, or be repeated next iteration. These are just two variations on the same theme. I'd go for the execute and continue Then it's then very easy to load the sequence(s) from file, if required. Pause\continue, start\stop is very convenient.

It's a setup with components of OO Functor, OO State pattern (not state machine) and an OO Composite.

When the sequencer pattern execute just once, it will also execute calculations very well. A function like ( y * sin (x+3) + z * cos ( y^2) ) is just a combination of executing steps in parallel or sequential.

It might be an acquired taste. I used it a few times, with great success. You can get a lot of bang (flexibility, reusability, serialization) for your bucks (a few days for me).

But if OO, composite or state pattern don't sound familiar, it might be something to consider in the future.

[buddyfares]

Thanks for the reply.  I have not used this is labview yet but I am at the beginning of the project and if I could make it work better than a SM then I would try it.  Would you happen to have an example of a OO Sequencer you could share?

[wiebe@CARYA]

---

@buddyfares wrote:

Thanks for the reply.  I have not used this is labview yet but I am at the beginning of the project and if I could make it work better than a SM then I would try it.  Would you happen to have an example of a OO Sequencer you could share?

---

I don't have one at hand, the few I've made are build-in in proprietary projects.

It would be a good idea of course to put one online.

There is a change you won't like it at all. These things tend to have ups and downs, but the downs are usually obfuscated by familiarity, personal preference and bias.

[BertMcMahan]

@wiebe, I haven't done an OO sequencer before but have wanted to do one. Most of my OO stuff has been HAL type stuff. Do you implement a generic "step" class with some associated functions, then reuse it across your programs? My biggest hurdle in this type of thing has always been maintaining state and test data across steps.

Say you want to do thermal testing of PCB's, do you do a "PCB Thermal Test Step" abstract class that contains the list of steps in your sequence? Or do you have a "Step" class that you use for "PCB Thermal Test", which has children of "Load PCB into test rig" then "Heat to X degrees" or whatever?

Or does each step fully contain its own data- like you initialize the list of steps at the beginning, loading things like temperature targets, COM ports, etc, and throw em into an array to cycle through?

I'd be super interested in hearing more about your architecture, as I still have a lot to learn about OO. I'm sure this would help the OP as well.

[Mark_Yedinak]

---

@BertMcMahan wrote:

@wiebe, I haven't done an OO sequencer before but have wanted to do one. Most of my OO stuff has been HAL type stuff. Do you implement a generic "step" class with some associated functions, then reuse it across your programs? My biggest hurdle in this type of thing has always been maintaining state and test data across steps.

Say you want to do thermal testing of PCB's, do you do a "PCB Thermal Test Step" abstract class that contains the list of steps in your sequence? Or do you have a "Step" class that you use for "PCB Thermal Test", which has children of "Load PCB into test rig" then "Heat to X degrees" or whatever?

Or does each step fully contain its own data- like you initialize the list of steps at the beginning, loading things like temperature targets, COM ports, etc, and throw em into an array to cycle through?

I'd be super interested in hearing more about your architecture, as I still have a lot to learn about OO. I'm sure this would help the OP as well.

---

We developed an OO test sequencer as well. In our case we have several classes defined. We have abstract class for a basic test step, abstract classes for the DUT which include a few classes such as a class for DUT parameters, DUT configuration and DUT execution. These abstract classes are used by the generic test step class. For specific projects we create children classes which fill out the details of the abstract classes. We also have an execution engine which actually does runs the test sequences. In our specific case, all of the test cases and data are stored in a DB. At the start of the execution we get a list of test cases to execute. At run time, we load the steps and their data for a specific test case and execute them. Rinse, lather repeat. At the moment we only have one system using this but everything at the lower level has been defined in a very generic manner so it is easy to re-use the basics for new systems.

To further extend this, we use packed project libraries extensively. This way, test steps are loaded at run time making it very easy to add new steps to the system without having to rebuild the application. We simply need to deploy the new packed project library with the new test step. Since we use a DB to define the actual test cases, we can add new step types very easily.