Scribd
Upload
15 views

Dam

The document proposes a Data Acquisition Machine (DAM) software that would manage sensors and motion controllers. The DAM would define a simple interface for acquiring data from hardware in an asynchronous manner. This would replace an existing gantry control module and be reusable for multiple projects and applications without dependencies on specific products or configurations. The DAM would execute lists of commands to move sensors and capture data, calling a handler function once complete.

Uploaded by

keremaktug
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
15 views

Dam

The document proposes a Data Acquisition Machine (DAM) software that would manage sensors and motion controllers. The DAM would define a simple interface for acquiring data from hardware in an asynchronous manner. This would replace an existing gantry control module and be reusable for multiple projects and applications without dependencies on specific products or configurations. The DAM would execute lists of commands to move sensors and capture data, calling a handler function once complete.

Uploaded by

keremaktug
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Our short term goal is to implement simple and reliable replacement of gantryctl in HPE project.

The
replacement should be free of any project specific dependencies like homography or server
configuration. Ideally the new gantry module should be applicable for other projects and also for the
trainer application in live view.

Therefore I propose the design of Data Acquisition Machine, a software managing sensors (2D/3D
cameras, profilometers, line scanners) and motion controllers (FESTO in gantry axis, robot) in order
to acquire the data. The aim of this design is to define a very general and simple interface to be
applied in all related implementation. The design ensures easy extensibility. Initially we can
implement only the functionality and hardware handling needed for HPE and the trainer. Later we
can add new hardware and functionalities needed for other applications, the interface itself however
will not require any updates.

First I will describe the interface of the DAM and it’s usage, then I will propose implementation of the
the DAM.

Data Acquisition Machine is a bare minimum software without any application specific dependencies,
no product configuration, no connection to data sources like DB, ETCD, MQTT etc. It only moves
sensors to specified positions and grabs the data.

All the operations to be performed are defined as instructions. Instruction contains a list of
consecutive hardware commands (goto, take_image, start_streaming, start_scanning, etc.).
Commands in the instruction are specified along with required parameters, for example goto [x,z,y,r],
take_image [gantry_center], start_streaming [camera1, stream1].

Commands are executed by DAM in asynchronous manner. The caller thread is not being blocked.
After all commands in the instruction have been executed (or if the execution broke due to an error)
the DAM calls a handler function and passes the results: command status (cmd_ok, cmd_error) and
grabbed data, for example reference to image.

It’s up to the DAM caller how to organize the commands and instructions.

 For HPE each instruction will most likely contain 2 commands: goto and take_image. The
caller will pass the image to the inference immediately after grabbing.
 In case of profilometer usage the instruction could be: goto [start_pos], start_prfilometer,
goto [end_pos], stop_profilometer.
 In live view in the trainer app, each instruction will probably contain only one command.
When live view is open the command start_streaming is must be called. If user presses
button to move gantry then the only goto command must be executed.

DAM exposes only 3 functions:

1. initialize(configuration)
Connects to sensors and motion controllers defined in passed configuration. The
configuration is what we usually have in sifecfg.rml.
2. execute(instruction, callback)
Executes passed instruction and invokes passed callback function once the execution is
finished or broken
3. abort()
Aborts instruction execution
DAM is a Finite State Machine implementing related state handler for each supported command.

Implementation

DAM can be implemented based on idem4 with usage of existing modules.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy