Module Management
A module is one configured instance of the application. It owns the detection operation, with its own settings and results:
hdvisionsystems/lumiscan-area-detector/<module-id>/detect-area/...
Modules can be created and removed while the application runs. A fresh installation serves one
module, named module-1.
|
On ctrlX OS, one licence covers ten modules. The eleventh module acquires a second licence of the
same key, and a module is refused with status |
The management node sits outside the modules:
hdvisionsystems/lumiscan-area-detector/system/
Nodes
| Node | Type | Description |
|---|---|---|
|
string array |
The modules that currently exist |
|
method |
Create a module and its node subtree |
|
string |
Name of the module to create. Lower case letters, digits, |
|
method |
Remove a module and its node subtree |
|
string |
Name of the module to remove |
|
method |
Persist the module list, so the same modules are recreated on the next start |
|
method |
Persist one module’s settings |
|
string |
Name of the module whose settings to save |
Every method also has output/status-code and output/status-text. How these modules compare with
those of the other LumiScan apps is described in
Settings, Modules and Restart.
Creating a module
-
Set
system/create-module/input/module-idto the new name -
Write to
system/create-module/execute -
Check
system/create-module/output/status-codeis1
The module is live at once, with default settings, and appears in system/modules. It is not
permanent until the module list is saved.
Removing a module is the mirror image, through remove-module. A module is refused with -1 (busy)
while one of its own operations is running, rather than having its nodes destroyed mid-execution.
|
A module created now is a new module: it starts with the default input values, even if a module of
that name existed before and its settings were saved. Those settings stay on disk until the removal
is made permanent - |
Saving
Two things are saved separately, and both must be saved to survive a restart:
-
the module list -
save-current-modules, so the same modules are recreated; -
each module’s settings -
save-module-inputs, once per module.
To save a module’s settings:
-
Set
system/save-module-inputs/input/module-id -
Write to
system/save-module-inputs/execute -
Check
system/save-module-inputs/output/status-codeis1
Every input of that module is written to the application configuration directory and restored on the next start. Results are not saved - they are produced by the next run.
A setting whose node no longer exists after a software update is skipped with a log entry, so an older configuration never prevents the application from starting.