How can a user enter a value for an indicator%3F

[Mark_Yedinak · Accepted solution]

What you should do is make your tests a class. Give the users the base class to inherit from and then let them fill in the specifics. Your test sequencer will be much more flexible since all tests will be handled the same. Some methods that I can think of for your class would be "Set Limits", "Execute Test", "Verify Results", "Report Result" and of course "Configure test". As mentioned you could also have some guidelines for the size of the subpanel to be used for the Ui portion of the test. You would also specify an API for communicating back to the test sequencer the test result. You are trying to implement a common system framework without a concrete protocol on how it should be done. You need to define an API that tests should conform to.

[cbfsystems]

---

@Bob_Schor wrote:

Thank you for explaining What you want the user to do.  If you read what you wrote, you might see the silliness in the "problem" you are hoping to solve.  Here's an example:

1. "Enter the Limits for an Acceptable Test Value".
2. "Choose the Test you want to run".

Does this sequence make sense?  Of course not -- how can you specify limits if you don't know the test you are going to run?  If you simply invert the order, i.e. ask the User What he or she wants to do, you can then tailor the question about limits knowing the test, and hence the format for the limits.  So if the Limits are a numeric range, you can ask for "Low" and "High" values.  If the limits are a specific set of values, you can ask for acceptable values.  If the limits are "Last names starting with a specific letter", you can ask for that letter.

Once you know what you want to do, figuring out how to do it becomes much simpler.

Bob Schor

---

The user first selects the test to be configured.  This allows the test sequencer to know what the "Output value" looks like, then the user enters the limits.  

[cbfsystems]

---

@Mark_Yedinak wrote:

What you should do is make your tests a class. Give the users the base class to inherit from and then let them fill in the specifics. Your test sequencer will be much more flexible since all tests will be handled the same. Some methods that I can think of for your class would be "Set Limits", "Execute Test", "Verify Results", "Report Result" and of course "Configure test". As mentioned you could also have some guidelines for the size of the subpanel to be used for the Ui portion of the test. You would also specify an API for communicating back to the test sequencer the test result. You are trying to implement a common system framework without a concrete protocol on how it should be done. You need to define an API that tests should conform to.

---

I will have to give this some thought (forcing the user to inherit from a base class and use a number of API methods).  It would certainly make certain parts of the test sequencer code, such as limit configuration and performing the limit check, easier and more flexible.  I was doing something like this a while ago with a previous version of the test sequencer but wasn't happy with certain aspects of how it was turning out.

In the current version of the test sequencer, I have been trying to reduce the constraints on the user test VIs and not make the user create a lot of methods.  As it stands right now, the user only has to create a single VI for their test.  I have been trying to make creating user test VIs as simple as possible with the tradeoff of the test sequencer handling as much of the work of configuring and running tests as possible.  For example, rather than having the user write their own methods to configure and run limit checks, I have been trying to have the test sequencer handle this by using the "Output value" of the user test VI basically as a template for the user to enter the limit bounds.  This can get complicated though if an elaborate limit check condition statement is wanted (not just lower bound < "Output value" < upper bound).

I will give this some more thought.  The increased constraints/work for the user if I use the type of API you have suggested might be out weighted by the benefits of added simplicity and flexibility of the test sequencer.  It might give a better user experience also since the UI to enter limit bounds can be better matched to the particular test being configured.

[Mark_Yedinak]

This is exactly the approach we took with the only different is that our base class is for a test step, not a complete test. Users enter test sequences into a DB via a web interface. They are provided with a list of test steps. Each test step has a form which is used to enter the data for that step. Our test sequencer at execution time reads the list of selected tests and get the list of test steps. The execution iterates over the list of test steps. Our test step class has methods similar to the ones I suggested. The sequences simply invokes the methods of the test steps and they execute. The sequence is actually pretty straight forward since the steps themselves do the heavy lifting. Trying to create a self adapting, self learning test sequencer that executes tests without any defined API will be nightmare to develop, test and maintain.

[cbfsystems]

---

@Mark_Yedinak wrote:

What you should do is make your tests a class. Give the users the base class to inherit from and then let them fill in the specifics. Your test sequencer will be much more flexible since all tests will be handled the same. Some methods that I can think of for your class would be "Set Limits", "Execute Test", "Verify Results", "Report Result" and of course "Configure test". As mentioned you could also have some guidelines for the size of the subpanel to be used for the Ui portion of the test. You would also specify an API for communicating back to the test sequencer the test result. You are trying to implement a common system framework without a concrete protocol on how it should be done. You need to define an API that tests should conform to.

---

What I have ended up doing is a combination of using test classes with methods to configure the limits as suggested by Mark and also allow the user to enter a validation expression to configure the limit checking.  The validation expression works as follows:  The user enters a logical expression (a string), which includes one or more elements of the "Output Value" cluster.  When the test runs, the expression is evaluated to determine whether the test passes or fail.  Consider, for example, a test that reads a weather station and returns an "Output Value" comprising four elements:  Date (String), Temperature (degC) (Dbl), Relative humidity (%) (Dbl), and Barometric pressure (kPa) (Dbl).  The validation expression might be something like (((Date = "2018/7/15") AND (Temperature > 35)  AND (Relative humidity > 95)) OR ((30 < Barometric pressure < 35) AND (Temperature < -20))).  The test would pass if the measurement was taken on a very hot, muggy day (July 15 of this year), or on the top of Mount Everest.

I decided to go with the use of a validation expression because of the flexibility that it allows for the validation test (limit test).  With an appropriate expression parser and code to execute the expression, it is possible to apply different conditions for different elements of the "Output Value", ignore some elements, and even include test inputs or other inputs/outputs of other tests in the validation expression.