Addresses and Modules
The address of a node
hdvisionsystems/<app>/<module>/<folder>/... the nodes of one module
hdvisionsystems/<app>/system/... what concerns the whole app, or more than one module
types/hdvisionsystems/<app>/<type> the FlatBuffers types the app publishes
<app>-
The app’s name on the Data Layer, lower case with
-, for examplelumiscan-cam-driver. It is not always the name of the program: the programlumiscan-ai-obj-matserveslumiscan-ai-object-matching, andlumiscan-calibserveslumiscan-calibration. <module>-
One instance inside the app: a camera, a neural network, a calibration plane, a finder module. Its name comes from the app’s settings. The code readers have no module level.
Example: hdvisionsystems/lumiscan-cam-driver/camera1/control/connect-camera/request.
Module names
-
Addresses are lower case. A node you cannot find is nearly always a difference in case or spelling.
-
Module names consist of lower-case letters, digits,
-and_. The Cam Driver and AI Object Matching refuse any other module name: such a module does not appear on the Data Layer. Calibration names a module after its file and uses the name in lower case. -
systemis reserved and is never a module name.
The folders of a module
| Folder | Holds |
|---|---|
|
the functions: |
|
what a client writes before it starts a function |
|
the results of the functions, read-only |
|
a read-only view of what the module applies, for example |
Some apps have folders of their own, for example the Cam Driver’s device-info/,
transport-layer/ and features/.
Where a function keeps its nodes
An execute method keeps everything it owns under its function:
<module>/control/<function>/execute
<module>/control/<function>/input/...
<module>/control/<function>/output/...
A handshake has ready and request under its function, and uses the inputs and outputs of the
module:
<module>/control/<function>/ready
<module>/control/<function>/request
<module>/input/...
<module>/output/...
<module>/control/status/code, text
A function that has both - most functions of the Cam Driver, AI Object Matching and Calibration -
uses the module’s input/ and output/ for both ways of calling it.
The layout of each app
Some apps keep an older layout so that programs written against them keep working.
| App | Module named by | Functions |
|---|---|---|
Cam Driver |
|
|
AI Object Matching |
|
|
Calibration |
the module file’s name without |
|
Template Finder, Object Finder, Area Detector, Text Reader |
the module id given to |
|
DMC, QR, Aztec and Barcode Reader |
no module level |
|
Cockpit |
none: Cockpit only reads the nodes of the other apps |
|
The exact nodes of each app are in its manual’s Data Layer Reference.
The system node
Everything that is not about one module is under hdvisionsystems/<app>/system/: making and removing
modules, the settings files, device discovery, and resources shared by all modules. The code readers
have only system/meta/subscription-schema there. See Settings, Modules and Restart.
Types
| Type | Used for |
|---|---|
bool, int16, int32, uint32, uint64, float32, float64, string |
plain values: inputs, flags, counters, status codes ( |
arrays of these |
for example the coordinate arrays of Calibration |
FlatBuffers |
results and images. Their schemas are on the Data Layer under |
Build PLC logic on the plain values. A FlatBuffers result needs its schema to be decoded; every result a PLC usually needs is also available as plain nodes - see the app’s manual.