General Concept of Handshake
The communication process in the LumiScan AI Object Matching application is based on the general concept of handshake. The naming convention for handshake parameters usually consists of the functionality and the names -ready or -request.
The handshake works the same on the ctrlX Data Layer and on LumiScan Keryx. Its general rules are described in Handshake; this page describes how AI Object Matching follows it and where it differs.
| Address | Description |
|---|---|
|
Read-Only, controlled by our app to indicate whether the relevant functionality is allowed to be executed. |
|
Writable. It is used by user to trigger our application to execute relevant functionality. |
Functionality Execution
|
To avoid repeating the entire address, in this section the invariant part containing the parent address and the variable functionality name (inference, reset) have been replaced by XXX. Thus, the address: Accordingly, the address: |
In order to execute a functionality, you need to run the following steps (see also image Functionality Execution Steps):
-
Wait until XXX/ready is set to True.
-
Set XXX/request to True.
Make sure there is only one process is accessing XXX/request at a time.
The result of execution is undefined when:
-
ProcessA set XXX/request to True.
-
ProcessB set XXX/request to False without considering ProcessA.
-
Our application might therefore miss XXX/request from ProcessA.
-
-
Wait until XXX/ready changes to False: the application has seen the request.
-
Set XXX/request to False.
-
Wait until XXX/ready is True again: the functionality has finished.
-
Read
control/status/codeand the results.
%% The ready/request handshake. Rendered by Mermaid in the browser; edit and preview at https://mermaid.live sequenceDiagram autonumber participant C as Client (PLC or program) participant M as Module M-->>C: ready = true: the function can be started C->>M: request = true M-->>C: ready = false: the request was seen C->>M: request = false Note over M: runs the function M-->>C: ready = true: the function has finished C->>M: read control/status/code and output/
When a Functionality Runs
Not every functionality waits for XXX/request to fall before it starts:
| Functionality | Runs | status/code at the end |
|---|---|---|
|
At once, as soon as the application sees the request. |
|
|
At once, without waiting for XXX/request to fall. It runs again on every cycle while XXX/request stays True. |
|
|
After XXX/request has fallen. |
|
While the module is in error, it ignores every request but reset. XXX/ready still shows
True, but the request is never acknowledged: XXX/ready does not fall. Request reset.
While the image stream runs, inference/ready is False. An inference requested anyway sets
status/code to 100002 (StreamActive) and is not acknowledged.
Outcome of an Inference
An inference requested through the handshake ends at status/code 3, whatever its outcome.
Tell the outcome by hdvisionsystems/lumiscan-ai-object-matching/<network name>/output/package-identifier:
it grows by one with every successful inference, and only then.
If it did not grow, the inference failed. Either:
-
the image could not be read: there was no image, or it was empty. Provide an image and request the inference again; or
-
the inference itself failed. The module is then in error and ignores every request but
reset(see above). Requestreset, and check the application log for the cause.
To read the outcome directly, start the inference with
control/inference/execute instead. status/code then keeps it: 0, 100001 or -1. See
Execute a Method.