Parseq - software for end-of-line testing

Since the first years of its activity in the sector of the testing machines, Microplan invested in the development of a special software language that its programmers could use to produce test procedures quickly and easily.

This happened for the first time in 1998, with the language called TestSeq. In the time, many customers of Microplan decided to learn how to use TestSeq in order to become independent in modifying or creating test sequences on their test benches. For more than 15 years TestSeq enabled our customers to modify their tests without involving us.

Today, a new language has been produced by Microplan, with more enhanced features, called ParSeq. The name itself reminds that one of the most significant features of this new package is to allow creating parallel tests.

In the following, only few features of ParSeq are described. It is impossible, on the other way, to resume in this space the features of a software package that requested more than 2 years of development by engineers extremely skilled in the testing of HVAC appliances. For more details, please contact Microplan.

An example of the operator’s interface of the test procedures created with ParSeq can be seen in the following picture.

The measured quantities are shown in the upper section of the screen, with the shape of watch dials, where the acceptable ranges involved in checks are green/red coloured.

In the lower section, the space is for instructions to the operator, that can include not only text, but also pictures or movies. The messages can be written in the language of the customer, including  Farsi or Chinese.

The below picture shows an alternative way to use part of that space. The right side is dedicated to the monitoring of a direct communication between the bench and the boiler’s control card. A protocol communication is established, allowing the bench to set the boiler in desired conditons or to obtain measured values or status information from the boiler under test.










As the previous TestSeq package, ParSeq is a language used by Microplan to build the test procedures of its benches, but that also customers can use, if they want to modify or write their own tests. In the above pictures the point of view of the operator was considered, so the screenshots were taken during the execution of a test procedure; in the following, the point of view of the user who builds test procedures with ParSeq is considered.

  •  Powerful and easy at the same time

Despite its powerful features, it is much more easy to use than a typical programming language: it is specialized to build test procedures and it is made for people with no programming skills. The user doesn’t write instructions, but he simply fills forms or chooses options from lists.

  • Information to the operator during tests

An important function of a test procedure on an automatic bench is to guide and inform the operator. ParSeq allows to wite in the procedure messages to the operator that can be written by the customer in his own language (provided that Windows is suitably set), not only including languages with western characters, but also others, like Farsi or Chinese.
The messages can include not only text, but also pictures, or even movies: this largely increases the power of communication with the operator. 

The messages are usually shown in a dedicated area, as it can be seen in the first two pictures of this chapter, but, besides them, the user can set pop-up messages, that are windows that he can make appear in any position on the screen and with any dimension. Again, the pop-up windows can include text, pictures or movies, as it is the case in the picture below. 










  • Building a test by filling forms
    The user can build a test defining valves to move, regulations to set up, quantities to measure, acceptable limits, delays, messages to the operator and whatever is needed, simply filling predefined forms or choosing options from menus. No programming instructions need to be written.
    The following pictures shows how ParSeq makes easy to choose the valves to open or close at a certain step of the procedure: the user select the circuit first, so that only the valves of that circuit are listed. Then he selects valves from the list the valves and presses a button to set them ON or OFF.

  • Building sub-sequences

Filling forms like the one in the above picture, the customer can define the actions of every step of his procedure.
Then he can list the tests, built in this way, in a sequence, in any order he needs (the list of sequential tests is called sub-sequence in ParSeq). With simple drag and drop or copy-paste operations, he can easily move one test in any position in the sub-sequence.

The sub-sequences are the elementary units of the test procedures. A test procedure could be formed by a single sub-sequence, or by many sub-sequences one after the other, or even by sub-sequences put in parallel, as it will be explained in the following paragraph, or by combinations of these situations.

  • Parallel execution
    Different sub-sequences, defined as before said, can be put in parallel, so that they are executed at the same time.

Every subsequence is still written and defined as if it was run alone, but once ParSeq runs them, it automatically takes care of their parallel execution and of the consequent problems.
In this way, the user writes the sub-sequences one by one and he doesn’t need to worry about the implications of a parallel execution.
For example, he doesn’t need to worry about  the management of situations where, for example, one or more parallel sub-sequences fail, while others parallel sub-sequences end successfully.
In situations like these, questions arise, like the following: - should the whole procedure be aborted, or should the operator be allowed to try to repeat the faulty tests? - should all the tests be repeatable or not? – when a test is repeated, can it be repeated alone, or some other tests before it should be repeated in order to reproduce the same conditions? - in general, what is, case by case, the right restart point in case of repeated tests?

This level of problems only arise when tests are performed in parallel, so they were unknown to our TestSeq package, as they are unknown to the software packages of companies that propose themselves as competitors of Microplan. A deep study, and all the experience of Microplan were needed to make ParSeq able to manage such situations.
It is easy to understand how powerful can be the parallelism feature of ParSeq in obtaining shorter testing times and in increasing the productivity of the assembly line.

  • Conditional paths in the test procedure

The traditional way to create the association between a certain model of boiler and its testing procedure was to create a specific testing procedure for every model, with a 1:1 match. Once the barcode of a certain model was read by the bench, the corresponding test procedure was loaded; with a different barcode, a different procedure was loaded, and so on. 
This method works, but it produces an unwanted side effect when the number of models increases.
In fact, it often happens that two models, with different barcode, are of the same family, so that they are different only for a detail, like for example the presence of buttons or potentiometers on the front panel of the boiler. In this case, the only difference in their test procedure could be in a message to the operator where he is requested to rotate a potentiometer in one case and to push some buttons in the other case. For all the other aspects, one test procedure would be a duplicate of the other.

This could happen many times, for every detail that could make models of the same family silghtly different. After some years, one manufacturer could find to have dozens of test procedures, with very small differences one from the other.
If, one day, one parameter, like for example the pressure limits for the gas valve adjustment, should be changed for all the models in a family, all the procedures of models of that family should be modified, one by one. The maintenance of many test procedures can therefore become a heavy work.
ParSeq has solved this problem allowing to write test procedure where different paths are followed inside it, according to some features of the models (like the type of HMI in the above example) or conditions that could happen during the execution itself, in real time.
Taking again the above example, in ParSeq the codes of two different boilers would load the same test procedure, but, in some points of it, one code would follow a way where a certain message is shown to the operator, while the other code produces a different message. The test procedure would remain unique, so that, if some parameter should be changed, it could be changed only once.
In practical experiences of our customers, the number of different test procedures from previous situations to ParSeq decreased of a 1:10 ratio.  

  • Parameters of the model and parameters of the family

The testing procedure of a certain model of appliance includes many parameters, like for example the limits for measured quantities to be checked, the setpoint of automatic regulations, delays, timeouts etc. 

Some of these parameters are specific of the model, but others are the same of other models. For example, the time needed to fill the boiler could be typical of that model and different from others because of its internal structure, but the minimum flow rate of the DHW to switch on the flame could be the same of all the other models that mount the same flow switch.
The traditional approach, which also was the one of our previous TestSeq package, was that every model had its own set of parameters. As a consequence, if a certain parameter needs to be changed for many models, it has to be changed in every set of those models.
In the previous example, if one day a new flow switch would be mounted on all the models, the parameter of the minimum flow rate to switch on should be modified in all the parameters set.
ParSeq has a more efficient approach.

The user can decide if a certain parameter is specific of the single model, which is the object of the test procedure, or if it is the same for a group of models. In the first case the parameter is locally saved and is part of the procedure of that specific model, while in the second case it is saved in a database where it is accessible from the procedures of other models.
If a “local” parameter is changed, it only affects the model to which the procedure refers. If a “group” parameter is changed, it affects all the models of the group that use that parameter.
This makes extremely efficient the modification of parameters in ParSeq when many different models are produced.

  • Advanced functions of calculation

At a first glance, it could seem that the only need, during a test procedure, about the check of measured quantities could be to compare each of them with respective acceptable limits and to obtain a “good” or “fail” result from the comparison.

Few examples can show that this is a limited point of view.

Case 1: the bench needs to check when the DHW temperature difference (outlet-inlet) reaches a minimum limit.
In this case the quantity to check against limits is not a measured quantity, but a combination of two of them: the difference between the outlet temperature and the inlet temperature. To satisfy this need, the software of the bench should allow to define a new quantity, the difference between outlet and inlet temperatures, and to check it against limits. This is possible with ParSeq. 

Case 2: the bench needs to check how much the flow temperature at a certain moment increased respect to the flow temperature at the beginning of the test.
In this case the quantity to check against limits is not a measured quantity, but a difference between the same measured quantity taken in two different moments. To satisfy this need, the software of the bench should allow to store in some way a measured quantity and to recall it in the future for a comparison with a new measurement of the same quantity. This is possible with ParSeq.
Case 3: the bench needs to check the instant ratio between power output to the CH circuit and heat input (something like an efficiency value).
Also in this case the quantity to check is not a measured one, but a complex combination of CH water flow rate, flow and return temperatures, gas flow rate, calorific power of the gas. The software of the bench should allow defining formulas that, taking measured quantities and other parameters as inlet, could produce a final result which could be checked agains limits. This is possible with ParSeq.
These are only few examples of the advanced features of ParSeq in data and measurement processing.