Object Storage

One file per object

An object is its picture: one .png at the top of the object directory, named after the object.

<configuration directory>/objects/
├── screw-m6.png
└── bracket.png

which the application publishes as

system/objects = ["bracket", "screw-m6"]

There is no second listing, because there is nothing else to list - the object id and the picture are the same thing. A detector is built around exactly one picture, so a second view of an object has nowhere to go: an object that has to be recognised at two orientations is two objects, screw-m6-front and screw-m6-tilted, searched for in turn.

Anything that is not a .png file at the top of the directory is skipped, subdirectories included.

Only lower case .png is listed. .PNG is ignored deliberately: matching case-insensitively would let screw.png and screw.PNG collapse into one entry, and the listing would no longer say which file a name refers to.

Getting objects onto the device

Either teach them from the camera with create-object, or put .png files into the application’s configuration directory in the layout above: upload them on ctrlX OS, copy them in on a PC. The configuration directory and its default objects folder are created at startup, so there is somewhere to put them straight after installing.

Platform Configuration directory

ctrlX OS

/var/snap/rexroth-solutions/common/solutions/activeConfiguration/lumiscan-object-finder, part of the active solution

PC (Windows)

%APP_RESOURCE_DIR%\etc\lumiscan-object-finder; without APP_RESOURCE_DIR, C:\ProgramData\HD Vision Systems GmbH\LumiScan Vision Suite\lumiscan-obj-find\etc\lumiscan-object-finder

Changing the directory

system/object-dir names the directory in use. It is read-only, and system/set-object-dir is the only thing that changes it:

system/set-object-dir/input/object-dir = production-parts
write system/set-object-dir/execute

The method validates first and publishes object-dir and objects together, so a rejected call leaves both exactly as they were and the listings always describe the directory actually in use. The choice is saved, so it survives a restart.

The directory must already exist inside the configuration directory. It is deliberately not created for you: the default is created at startup, so a missing one means a typo, and silently creating an empty folder would hide it.

The Data Layer does not enforce read-only on an application’s own nodes, so a client that writes system/object-dir directly will change the value shown. It will not change which directory the application reads, and the listings will then describe a different folder than the node claims. Use set-object-dir.

Path rules

object-dir and object-id are both interpreted relative to the configuration directory. Absolute paths, and any path climbing out with .., are refused with status -2. The application can therefore only read and write templates inside its own configuration area, whatever a client asks for.

When changes are noticed

system/objects is refreshed at startup, when set-object-dir switches directory, and when create-object saves a template.

Files added or removed by other means - an upload or an SSH session on ctrlX OS, files copied in or deleted by hand on a PC - are picked up at the next one of those, or at the next restart. Each refresh also makes every module rebuild its detector, so a template removed from disk stops being findable.