The "-uf" parameter allows third-party systems, such as MES or test planning software, to launch procella or O-QIS procella in order to create new data set (test plan) and expand the structure of existing ones.
Although it is possible to add measured values to new data sets or characteristics, the "-uf" parameter is not intended for this purpose. Using this parameter for existing data sets does not enable any information on parts or characteristics to be updated. It is designed for creating and expanding data sets and to enable users to manually modify the information on parts and characteristics fields.
Therefore, the input masks are always displayed at start-up, regardless of the settings configured for the start dialogue.
Table of Contents
How procella interacts with the third-party system
| 1 | The third-party system first creates a test plan in Q-DAS ASCII transfer format as DFQ or DFD file. Then launches procella or O-QIS procella and informs procella where to find the test plan file by using defined launch parameters. |
| 2 | The file is analysed by procella to check whether the test plan exists in the Q-DAS value database. The identification is carried out using key fields on part level. |
| 3 | If the data set does not exist, the test plan, including any provided measured values, will be stored as a new data set in the Q-DAS value database. If there is already a data set for the test plan and the file contains new characteristics, these will be added to the existing data set including any provided measured values. |
| 4 | Once the comparison and saving processes have been completed, the test plan will be reloaded from the database according to the defined key fields on part level and the input masks will be displayed. |
Note: The system always loads the full data set corresponding to the key fields at part level.
Note: If there are datasets that match the key fields at part level but differ at characteristic level, the dataset with the lower consecutive number will always be loaded.
Note: The file generated by the external system will neither be deleted nor removed by procella.
Recommended system configuration
Procella launching options
How the procella application behaves when it is already running can be configured in the procella settings. In a default installation, "Do not allow multiple start" is set with the additional option "Block products". This means that each product can be launched once, but different products, e.g., qs-STAT and solara.MP, can be launched in parallel.
<File> | <Configurations> | <additional settings> | <System configuration intern> | <Programme>
Note: Selecting one of the multiple launch options means that an additional licence will be in use each time a procella application is launched from an external system.
Note: When using the "-uf" launch parameter, it is recommended to select the "Switch to running programme" option.
This has the following effect: if the procella application is already running and a test plan (data set) is open when procella is launched from an external system, the open data set will close. The test plan from the file will be added to the Q-DAS value database then reloaded and displayed in the "Summary/Input" window.
Text coding standards
The use of Q-DAS parameters requires awareness of the potential for variation in coding standards across different applications. For example, Word and the Windows "Run" use different coding standards. Using different text encodings when working with the clipboard (e.g. [CTRL+C] and [CTRL+V]) may cause problems when executing the parameters. As an alternative, the "/" notation can be used, e.g. "/ux".
User access rights
To ensure a smooth process, the appropriate access rights need to be defined for the test plan file storage directory.
Requirements for the test plan file for the transfer
The test plan transfer file needs to meet the following requirements:
- Compliance with the Q-DAS ASCII transfer format.
- As a file name suffix, the extensions "DFQ" or "DFD" are required.
- To identify a test plan in the Q-DAS value database, the K-fields at part level are used as key fields (K-fields 1001 - 1999). The K-fields at part level that are not specified as key fields serve to provide additional information.
If a test plan already exists in the Q-DAS database, in other words if the key field matches, any updates to K-fields that are not defined as key fields will not be applied. - To identify characteristics within a test plan, the characteristic fields that have been defined as key fields (K-fields 2001–2999) are used. Only new characteristics are added in this process. Existing characteristics are neither updated nor deleted.
- When a new data set or characteristic is added, any measured values provided will also be stored in the Q-DAS value database.
The transfer file needs to contain only K-fields with header data and no measured values. Using DFD/DFX pairs, only the DFD file shall be available in the directory.
What is a "key field"
Any content in a test plan file is assigned to a K-field. The same applies to the value database.
Unlike test plans stored in files, where the file itself defines the test plan, in the value database the key fields define the test plan.
Key fields are the K-fields which, taken together, uniquely identify a data set (test plan) within the database.
Altering the content of any of the key fields in the test plan file creates a new data set in the database.
Altering the content of any non-key fields will not update the existing entries.
The key fields can be viewed and modified in the Q-DAS application via the database settings.
<File> | <Configurations> | <Databases> | <Options> | <Administration> | <Database type>
Launch parameter
In order to transfer a test plan file via an external system and to store it to the Q-DAS value database, the following requires specification:
- The path to the application including the "exe" file extension
\\<UNC path of server provisioning>\Q-DAS\Share\<PLANT>\<architecture>\<major version>\<minor version>\qs_STAT.exe - When launching Q-DAS products within a specific module, it is also recommended to specify the launch parameters "-k=" for the required module
-k=<Module abbreviation> - The parameters and path for the product INI file
-I=\\<UNC path of server provisioning>\Q-DAS\Share\INI\<PLANT>\<Product INI file> - The launch parameter "-uf=" and include the path to the test plan file
-uf=<Path to the test plan file>
The following examples demonstrate the launch parameters for procella and O-QIS procella
procella:
..\qs_STAT_V12.EXE -I=..\procella.INI -uf=..\Shaft.DFQ
O-QIS procella:
..\qs_STAT_V12.EXE -k=pv -I=..\O-QIS.INI -uf=..\Shaft.DFQ
Launch parameters for minor release update
The application path is part of the launch parameter. It needs to be modified when switching to a different Q-DAS version, such as a major or minor upgrade.
The following example shows three minor versions of major version 14:
The path of the Q-DAS application in the launch parameter needs to be specified according to the required version.
<Path to the Q-DAS application> -I=<Path to the Q-DAS product INI file>
Example
The following example refers to an existing data set (test plan) in the Q-DAS database. The "-uf" parameter is used to expand this data set by adding new characteristics.
The defined key fields are part number (K1001), part description (K1002), characteristic number (K2001) and characteristic description (K2002).
Content of the INI transfer file created by the external system:
The external system launches O-QIS in the procella module with the following parameters:
..\qs_STAT_V12.EXE -k=pv -I=..\O-QIS.INI -uf=..\DATA\OwnData\Part_Shaft_New.DFQ
The "Parts/characteristics list" before using the -uf" launch parameter:
The "Parts/characteristics list" after using the -uf" launch parameter: