Module Management
A module is one configured instance of the application. It owns the matching operation, with its own settings and results:
hdvisionsystems/lumiscan-object-finder/<module-id>/find-object/...
Creating a template is not per module: it writes into the one directory every module shares, so it
lives on the system node as system/create-object. See
Creating an Object.
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-object-finder/system/
Nodes
| Node | Type | Description |
|---|---|---|
|
string array |
The modules that currently exist |
|
method |
Cut a template out of a live image and save it into |
|
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.
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 module’s image stream settings are saved in the same file, by the stream’s own methods - see Kept in the settings file.
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.
Why the address contains a module even with one module
The <module-id> level is always present, so addresses do not change when a second module is added:
a program written today against module-1 keeps working. It also matches the path convention the
other LumiScan applications document, see Addresses and Modules.
How the finders' modules differ from those of the Cam Driver, AI Object Matching and Calibration is
summarised in Settings, Modules and Restart.
What is shared between modules
Modules are independent in everything except templates. system/object-dir names one directory
for the whole application, system/create-object writes into it, and every module searches it, so
a template only ever has to be created once. See
Object Storage.