Choosing a Pattern

Every function of a LumiScan app is called in one of three ways.

	Handshake	Execute method	Stream
For	operations longer than about 1 s, or of unknown length	operations within about 1 s	every item a source produces, as it arrives
The client	writes `request`, polls `ready` and the status; nothing blocks	writes the method once; the write returns when the operation is done	subscribes once; the apps push every result
The outcome	`control/status/code` and the outputs	the result of the write (could it run?), then the status (did it succeed?)	each pushed result
Examples	`connect-camera`, `reset`, `inference`	`capture`, `trigger`, `transform`, `find-template`	camera frames into AI Object Matching, a finder or a code reader

For

operations longer than about 1 s, or of unknown length

operations within about 1 s

every item a source produces, as it arrives

The client

writes request, polls ready and the status; nothing blocks

writes the method once; the write returns when the operation is done

subscribes once; the apps push every result

The outcome

control/status/code and the outputs

the result of the write (could it run?), then the status (did it succeed?)

each pushed result

Examples

connect-camera, reset, inference

capture, trigger, transform, find-template

camera frames into AI Object Matching, a finder or a code reader

Why about 1 s

An execute method holds its caller until the operation has finished: a PLC task, or a client whose request times out. On LumiScan Keryx, a client gives up after 2 s by default. An operation that can take longer is therefore a handshake, which the caller polls instead of waiting. This is why the Cam Driver offers connect-camera, disconnect-camera and reset as handshakes only.

On request or as a stream

	On request (handshake or execute)	Stream
Who starts the work	your program: one call per image or per point	the source: every image the camera delivers starts the next app
How the apps relate	independent; your program carries the data from one to the next	chained; each app subscribes to the one before it
Speed (one camera, one PC, as measured)	about 34 images per second from the Cam Driver	63 to 68 images per second from the Cam Driver

On request (handshake or execute)

Stream

Who starts the work

your program: one call per image or per point

the source: every image the camera delivers starts the next app

How the apps relate

independent; your program carries the data from one to the next

chained; each app subscribes to the one before it

Speed (one camera, one PC, as measured)

about 34 images per second from the Cam Driver

63 to 68 images per second from the Cam Driver

Use on request for single, slow or irregular operations: connect the camera, take one image, transform a few points you already have. Use a stream for continuous work: the camera delivers an image, AI Object Matching finds the objects, Calibration turns them into coordinates, and your program only reads the result.

One implementation, several patterns. Where an app offers the same work in more than one pattern, they share one implementation and one lock per module. The result is the same, and two operations of one module never overlap.

Which app offers what

App	Handshake	Execute	Stream
Cam Driver	yes	yes	produces frames
AI Object Matching	yes	yes	consumes frames, produces detections
Calibration	yes	yes	consumes points or results, produces 3D points
Template Finder, Object Finder, Area Detector, Text Reader	–	yes	consume frames, produce results
DMC, QR, Aztec and Barcode Reader	–	yes	consume frames, produce codes

App

Handshake

Execute

Stream

Cam Driver

yes

produces frames

AI Object Matching

yes

consumes frames, produces detections

Calibration

yes

consumes points or results, produces 3D points

Template Finder, Object Finder, Area Detector, Text Reader

–

yes

consume frames, produce results

DMC, QR, Aztec and Barcode Reader

–

yes

consume frames, produce codes

Each app’s manual lists its functions and which patterns each one offers.