Execute Methods

An execute method is for an operation that finishes within about 1 s. The client writes any value to the method’s execute node, and the write returns when the operation has finished. One write, no state to track.

Calling a method

  1. Write the method’s inputs. A method has no arguments of its own: its inputs are separate nodes.

  2. Write to the method’s execute node, for example hdvisionsystems/lumiscan-cam-driver/camera1/control/capture/execute.

  3. Check both results:

    1. The result of the write: could the operation run at all? A refused write is never queued. See Results of a method call.

    2. The outcome: did the operation succeed? Where to read it depends on the app, see below.

  4. Read the outputs.

Where the inputs, outputs and outcome are

Apps Nodes A failed operation shows as

Cam Driver, AI Object Matching, Calibration

<module>/control/<function>/execute; the module’s input/…​ and output/…​, the same the handshake uses

control/status/code and text, while the write itself answers that it ran. Always read the status after the write. A refused write leaves the status as it was

Template Finder, Object Finder, Area Detector, Text Reader

<module>/<method>/execute, <module>/<method>/input/…​, <module>/<method>/output/result, output/status-code, output/status-text

<method>/output/status-code and status-text, and the write fails with the matching result

DMC, QR, Aztec and Barcode Reader

<app>/execute, <app>/input/…​, <app>/output/results

the write fails; the reason is in the application log

The finders' status-code has its own values, see Execution status of the finders.

The functions under system/ of every app are methods of the second kind: system/<function>/execute with input/…​ and output/status-code, status-text. A function of the whole app in the newer layout is system/control/<function>/execute, for example system/control/restart/execute.

When a method runs

A method of the Cam Driver, AI Object Matching or Calibration checks the same control/<function>/ready signal its handshake uses, and is refused while it is false. Most functions depend on something that must happen first - a connected camera, a loaded network, an image to save. The app’s manual says when each ready is true.

When a method is refused, read its ready together with control/status/code and status/text: ready names the missing precondition, and the status text still carries the message of the fault that caused it.

Timeouts

Keep in mind that the caller is blocked until the method returns. On LumiScan Keryx a client gives up after 2 s by default; the OPC UA Connector waits up to 60 s for a method call. A function that can take longer is offered as a handshake only.

One operation at a time

A module runs one operation at a time. A method called while another operation of the same module runs - an execute, a handshake, or in the finders a frame of a stream - is refused as busy (TooManyOperations, ctrlX DL_TOO_MANY_OPERATIONS). Retry it: the same call succeeds once the running operation has finished.

An operation that collides with a running stream is refused differently: the Cam Driver’s capture and AI Object Matching’s inference are not ready while their stream runs (InvalidOperationMode, ctrlX DL_INVALID_OPERATION_MODE). Retrying does not help; stop the stream first, see Streams.