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.


SOLARsoft - software for lab of solar collectors

This software, written with LabView by National Instruments, is designed to perform the tests of solar panels according to ISO 9459 and EN 12975-2.

Main tests:

  • Determination of the daily system performance

  • Determination of the degree of mixing in the storage vessel during draw off

  • Determination of storage tank heat losses

  • User defined test routines



CALsoft - software for gas flow rate calibrator

Main features:

  • Automatic heat input calculation
  • Automatic gas flow rate measurement

Other features:

  • System synoptic with instant values displayed
  • Graph of the values
  • Custom values to graph and related scales
  • Database of gases with related characteristic values (calorific power, correction factors, density, etc.)
  • Formula displayed
  • Logged data analysis (min, max, average, etc.)
  • Custom help file (on line schematics, pictures, etc.)
  • Editor of calibration points CALed [learn more]



CALed - calibration editor

Main features: 

  • data stored in a database
  • conversion data displayed as table and graph
  • no limit in the number of points you can enter for the conversions
  • interpolating curve (degree chosen by the user)
  • broken line
  • option of fixed offset to sum to each channel
  • real time simulation of the data entered
  • field for damping entering

example 1: broken line on 4 points

Microplan calibration editor 

example 2: polinomial 2nd degree

Microplan polinomial


The perfect tool for diagnosis, troubleshooting, manual use of the test bench.

The diagnostic program is a powerful software tool allowing the manul command of all the functions of Microplan's test benches.

Using the diagnostic program:

  • Checking DI signals (Digital Inputs)
  • Checking DO signals (Digital Outputs)
  • Checking AI signals (Analog Inputs)
  • Checking AO signals (Analog Outputs)
  • Reading measurements in physics values (bar, l/m, ecc.)
  • Reading measurements in electric values (mA, Volt)
  • Checking the eletric safety tests unit
  • Testing the communication with the PCB
  • Testing the PWM signal
  • Operating the test rig in manual mode

Faults finding and fixing (troubleshooting):

When a fault happens on the test rig, the diagnostic program is the perfect troubleshooting tool. Through a sequence of manual operations you will able to locate the fault or to exclude good parts from investigation.



R&Dflex - software for Research & Development

...the flexible software

R&Dflex is a software package developed by Microplan with Labview by National Instruments. R&Dflex has been conceived to give full flexibility in support of the research and development activities of the customers. Its main features are the followings:

| Full flexible tests

The synoptic panel is available for the operator to:

  • activate any component
  • log any measurement
  • graph any measure

| Automatic regulations

The operator can set the parameters to perform:

  • automatic PID regulations of water flow and temperature
  • automatic increasing or decreasing ramps
  • PWM control of fan

| Test sequence editor

  • the operator can perfom a series of operations and save them as a test sequence
  • every sequence created can be recalled for future use

 | Cyclic tests

  • this mode allows the phase editing (phase = group of steps); these phases can then automatically be executed one by one or in a cycle test (ex. life tests, endurance tests).

labSOFT - software for lab activities

labSOFT is the software developed by Microplan for the lab and R&D activities, based on Labview by National Instruments, a very powerful platform laboratory-oriented.

12 good reasons for choosing labSOFT

  1. operational testing conditions automatic reaching and keeping
  2. parameters from database
  3. automatic measurements and calculations
  4. automatic compensation of transducers errors based on calibration curves [learn more]
  5. temperature measurement redundancy
  6. calculation process fully traceable on screen 
  7. formula and partial results visibles 
  8. data logging of all the measurements acquired during the test 
  9. automatic reporting
  10. "free test" function with active synoptic (R&D mode)
  11. easy to learn
  12. easy to use

1. Synoptic feature

This features allows the operator to drive the test bench with a simple click on the mouse as every active component of the bench is available. The operator can also set the parameters for the PID control of the water flow rates. All the instant values are displayed on the screen next to the related transducer.

2. Chart feature

The operator is free to decide which of the available measurement transducers (ex. water flow rate, pressure, etc.) he wants to be displayed. Whenever he wants the operator can start logging the selected measures.

3. X-Y graph feature

This feature allows the operator to select two measures and get them displayed on a X-Y graph. This is different from the previous "2. Chart feature" where on the X axis the time is always displayed. A report, including a graph of the test executed, can be generated.

4. Automatic tests

This sections is about all those tests which refer to a specific standard such as for instance EN 483, EN 677, EN 26, EN 13203, ASHRAE 103 etc. In this case the operator just have to select the test to be permormed and then the bench will automatically reach the steady conditions and after a prompt from the operator will execute the test automatically. All the relevant measures are displayed throughout the test and the operator is free to select those he wants to be displayed. All selected measures are logged and available for statistical elaborations and a test report is finally produced.

5. Data analysis

This feature is very useful during R&D operations as the tester can promptly check the results of the ongoing tests.

6. Utilities and settings

  • Database of the different gases with related characteristic values
  • Editor of calibration points
  • Troubleshooting diagnostic panel
Subscribe to RSS - Software