v2.1.0 - not yet released

Execute methods. control/transform/execute and control/reset/execute run a transform or a reset with a single write, and return when it has finished. They answer DL_TOO_MANY_OPERATIONS while another transform or reset of the module runs, and DL_INVALID_OPERATION_MODE without a lookup table or a licence. See Execute methods.

Transforming a stream (experimental). A module subscribes to one Data Layer node, its source, and transforms every update of it as it arrives: address in the stream section of its configuration file names the folder, and the step in the section’s onEntry list the node in it. The node holds either the points themselves (a float array, for example from a PLC), or another application’s result, such as the objects AI Object Matching finds on an image stream. The step says which: none, or plain, for an array; remap for a result, with the list in it (array) and each element’s x and y - or no list, for one point per update. A stream result is read inside its result, as on the application’s regular output. The other keys of the section are those of every LumiScan application’s stream. The points are published on control/subscribe/output/stream/points with their lineage - the camera image an AI result was inferred on, or the PLC node they came from - and as a plain x0,y0,z0,x1,y1,z1,…​ array on control/subscribe/output/stream/plain-points, with NaN for a point outside the lookup table. setting/settings-hash identifies the lookup table and settings they are transformed with, and the module’s tag - its name unless stream.tag gives another - marks them as its own. With keep-latest-output, each update’s points are also written to the regular outputs. Transforming on request keeps working while the stream runs. See Transforming a Stream (Experimental).

What a source may hold. hdvisionsystems/lumiscan-calibration/system/meta/subscription-schema describes it as a JSON Schema: a plain array of numbers, a stream_points or a stream_detections. See What a source may hold.

Subscribing at run time. control/subscribe/execute applies the inputs under control/subscribe/input/…​ - stream mode, the source, the queue size, keep-latest-output - while the application runs, with no restart; control/unsubscribe/execute drops the source. Every module has the stream nodes, so adding a stream section needs a reset only, and a module without one gets one when it subscribes. See Subscribing at run time.

Stream mode and the source kept in the module configuration file. The methods save them in the stream section before they apply them: the module starts with both again after a restart. See Kept in the module configuration file.

Several modules at once. Each module listed in the application settings is served on its own, so a module waiting for its client never holds up another.

Settings on the Data Layer. hdvisionsystems/lumiscan-calibration/system/settings shows the settings the application was started with: the application’s settings file, each module file inlined in its modules list, passwords as ***. Writing it changes the files. The application checks the change as at start, saves it (the previous file as .bak), and then refuses all work until it is restarted: restart-required, status -5. hdvisionsystems/lumiscan-calibration/system/control/restart/execute restarts it. See Settings on the Data Layer.

The example module is example, and it reads AI Object Matching. The example module file is now example.json, so the module is hdvisionsystems/lumiscan-calibration/example, no longer .../lumiscan-calibration-example-module. Its stream section, with a remap step, reads the results of AI Object Matching’s example module, also example, from the start, and writes the points to the regular output too. A settings folder that already has its files keeps them. See Module Configuration File.

reset reloads the module. A reset reads the module configuration file and its TIFF file again, so a corrected file takes effect without a restart. If it cannot be loaded, the module reports -2 and has no lookup table until a reset succeeds, instead of transforming with the old one.

An error status stays until the next request. It used to be replaced by 0 within about 100 ms, before a client could read it.

The bilateralInterpolation interpolation method is now accepted by the settings schema.

Module configuration files may contain comments, as the application settings file may.

A missing TIFF file no longer crashes the application at start. The module is served and reports status -2 (invalidSetting), and control/transform/ready stays false, until its files are corrected and it is reset.

The application no longer waits for ever on a client that does not lower request when it is asked to stop, and a reset requested meanwhile is served.

control/reset/request was never acknowledged. A reset now follows the handshake.

An invalid application settings file is written to the log, and the application stops, instead of crashing.