---
title: "Module Management"
description: "Module management in LumiScan Text Reader - create, remove and save modules while the application runs; on ctrlX OS one licence covers ten modules."
product: "LumiScan Text Reader"
component: "lumiscan-text-reader"
version: "1.1.0"
display_version: "1.1.0.7"
latest_version: true
language: "en"
url: "https://docs.hdvisionsystems.com/en/lumiscan-text-reader/lumiscan-text-reader/module-management.html"
---

# Module Management – LumiScan Text Reader

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`.

> [!IMPORTANT]
> **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](https://docs.hdvisionsystems.com/en/lumiscan-keryx/settings-and-modules.html#registry-apps).

## 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.

> [!NOTE]
> 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](https://docs.hdvisionsystems.com/en/lumiscan-text-reader/lumiscan-text-reader/language-models.html).