Module Management

A module is one configured instance of the application. It owns the reading operation, with its own settings and results:

hdvisionsystems/lumiscan-text-reader/<module-id>/read-text/...

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 -11 when no licence on the device covers it.

The management node sits outside the modules:

hdvisionsystems/lumiscan-text-reader/system/

Nodes

Node Type Description

modules

string array

The modules that currently exist

create-module/execute

method

Create a module and its node subtree

create-module/input/module-id

string

Name of the module to create. Lower case letters, digits, - and _ only; must not be system and must not already exist

remove-module/execute

method

Remove a module and its node subtree

remove-module/input/module-id

string

Name of the module to remove

save-current-modules/execute

method

Persist the module list, so the same modules are recreated on the next start

save-module-inputs/execute

method

Persist one module’s settings

save-module-inputs/input/module-id

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

  1. Set system/create-module/input/module-id to the new name

  2. Write to system/create-module/execute

  3. Check system/create-module/output/status-code is 1

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 - save-current-modules deletes the saved inputs of every module the new list no longer names, because until the list is written a removal is not permanent and a restart brings the module back with its settings intact.

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:

  1. Set system/save-module-inputs/input/module-id

  2. Write to system/save-module-inputs/execute

  3. Check system/save-module-inputs/output/status-code is 1

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.

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.

What is shared between modules

Modules are independent in everything except the language models: each has its own camera, its own reading settings, its own recognition engine and its own results. The models are application-wide - system/tessdata-dir names one upload directory for the whole application, and every module reads from the same set, each in its own input/language. See Language Models.