The "-ux" parameter allows third-party systems, such as MES or test planning software, to launch procella or O-QIS procella in order to transfer and save self-generated test plans in the Q-DAS value database. This functionality is primarily intended for recording measured values automatically via a third-party system. It can also be used to create new test plans and expand the structure of existing ones. Using this parameter for existing data sets does not enable any information on parts or characteristics to be updated.
The "-ux" parameter is recommended for the following cases:
- To transfer a test plan to procella and to record the measured values.
- To indicate to procella that measured values are to be recorded for a specific test plan. For this purpose, test plans without measured values are transmitted.
- To monitor alarms and subsequently record events, causes and measures with procella.
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/DFX 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. Therefore, the listing of the key fields is one of the minimum requirements for the third-party system when creating the test plan file. |
| 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 measured values or new characteristics, these will be added to the existing data set. |
| 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 and procella system configuration settings. |
Note: If short test plans are transferred via the "-ux" parameter, only the characteristics included in the transferred file will be loaded.
Note: The default "Summary/input" window for the logged user is displayed at start-up, regardless of the settings configured for the start dialogue.
Note: The application launches in a state that allows editing and storage. This means that new data can be entered and files from the external system can be accepted.
If a user locks the test plan, it will not be possible to record any subsequent measurements or import measured values from the file.
Note: According to the system configuration settings, the transferred file is either deleted or moved. If the file is set to be deleted, it will be deleted without any notification.
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 "-ux" 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.
File treatment
The settings here determine the handling of test plan files and alarms, and provide options for restricting data when loading.
<File> | <Configurations> | <additional settings> | <System configuration intern> | <Call parameter -UX>
- File treatment
The options here specify how to handle the test plan file once it has been stored in the Q-DAS value database. - Filter
Any test plans that have been transferred will be automatically reloaded from the database. The options here allow restrictions of the information when reloading. - Alarm display
Here, a general setting is used to determine whether alarms should be displayed when the "-ux" parameter is used.
When enabled, alarms can be identified either from the currently selected evaluation strategy or from "Online Alarms", if configured to identify alarms independently of the evaluation strategy.
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. These rights should include the ability to create, modify and delete files.
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/DFX" 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.
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 "-ux=" and include the path to the test plan file
-ux=<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 -ux=..\Shaft.DFQ
O-QIS procella:
..\qs_STAT_V12.EXE -k=pv -I=..\O-QIS.INI -ux=..\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>