Tango @ ESRF Beamlines - PowerPoint PPT Presentation

1 / 19
About This Presentation
Title:

Tango @ ESRF Beamlines

Description:

Electrometers (soleil), Datasocket, Opcds, Lakeshore(py) ... Paragon. VpapMotor. EletaEncoder. Elettra. Septumsled (LeoMotor) Desy. OMS58 (Galil) Alba ... – PowerPoint PPT presentation

Number of Views:102
Avg rating:3.0/5.0
Slides: 20
Provided by: rey90
Category:

less

Transcript and Presenter's Notes

Title: Tango @ ESRF Beamlines


1
Tango _at_ ESRF Beamlines
  • Vicente Rey Bakaikoa
  • BLISS / ESRF
  • Tango Workshop at Elettra / 18 April 2008

2
  • Tango at ESRF beamlines
  • Spec and Tango integration
  • Standard tango motor interface

3
Tango usage statistics
Beamlines
Total Tango DB Running 1 server
ESRF 29 26 (21) 20 (13)
CRGs 11 7 (5) 4 (3)
In braquets (sep.07)
Mlayer Hdb e-giga
4
Tango usage statistics at ESRF beamlines
Servers
Vacuum et al. VacGauge, PlcVacuumValve, Libera, OmronPLC(py)
Video CCD Ccd1394, Falcon, Prosilica, Pixium, DirectShow, Pvcam
MX SampleChanger (embl) and Microdiff (embl), mxautocentring
GPIB, Serial GPIB (soleil), Serial, WinSerial, socket(py)
Other Electrometers (soleil), Datasocket, Opcds, Lakeshore(py), RBRTemperature, Ltr90, Agilent, SLS218, Hdb, TangoMaxe, Matlab, TextTalker, WiiMote
All 31 (21)
Device instances 234 (88)

ID14 - EH3 20 servers / 130 devices
In braquets (sept.2007) -- New server since sept
2007
5
Tango and spec / goals
  • Propose most tango functionality for experiments
    integrated from spec
  • (Tango already available through Taco library in
    a limited way)
  • Advantages
  • Full access to devices / attributes / data types
  • Handling of exceptions
  • Events subscription / attached variables /
    callbacks
  • Create spec controllers for standard instrument
    tango classes

6
Tango and SPEC
  • Status
  • First spec version with tango support about to
    be released
  • Only general features included
  • Commands tango_io()
  • Attributes tango_get() / tango_put()
  • All Tango Data types (ok not DevEncoded yet)
  • Error Handling

7
Commands
8
Attributes
9
Exceptions
10
Tango and spec todo list
  • Events
  • Waiting for tango-7 and event queues
  • Controller (motors / ccds)
  • Next step
  • Must be based on agreed standards
  • Accessing services
  • DB, HDB

11
Motor Interface
  • Motivation
  • So many classes out there
  • Difficult to find two of the same kind
  • Need standards for
  • Exchanging servers between institutes
  • Make client applications live easy
  • Client examples
  • Spec, new ATK motor widget, device pool proxy
    controller
  • Generic clients are also taken into account in
    the proposal
  • (position handling, stepup/stepdown, limit
    switches)

12
Existing Motor classes
  • SourceForge
  • AbstractAxis
  • ESRF
  • AdcMotor
  • Paragon
  • VpapMotor
  • EletaEncoder
  • Elettra
  • Septumsled (LeoMotor)
  • Desy
  • OMS58 (Galil)
  • Alba
  • Device Pool
  • Soleil
  • Galil
  • XPS

13
Motor interface vs. Abstract Class
Abstract class Forces the minimal interface that
a class must implement. Helps in standardization
imposes command names and input/ouput data
types Motor Interface Proposes a standard naming
and data types for commands, attributes and
input/output data types (not all of them
mandatory) Describes mechanisms and the meaning
of states, commands and attributes Lists
mandatory and optional interface
implementations Abstract class(es) will help
greatly to implement mandatory interface and some
typical configurations. New Pogo features to
support standard interfaces ?
14
The Position
  • 1. The commands of the motor controller hardware
    interface are step-based
  • Steps will report the hardware register. The
    value of the Position attribute will be the
    result of a calibration to units (mm,deg, etc)
    in the user space. The simplest calibration
    would be
  • Position HardwarePosition Steps /
    StepsPerUnit.
  • The proposed calibration scheme is
  • Position (Sign Steps /
    StepsPerUnit) Offset
  • HardwarePosition Steps / StepsPerUnit
  • 2. The commands of the motor controller hardware
    interface are position-based
  • Steps will be based in the resolution of the
    motor. In its simplest way calibration will be as
    in case 1. HardwarePosition will be the value
    read from the controller
  • Steps HardwarePosition StepsPerUnit
  • Position HardwarePosition
  • The proposed calibration scheme is
  • Position ( Sign HardwarePosition) Offset

15
Mandatory Attributes
State / Status
Position / Steps read_write start movement when written
HardwarePosition / Sign / Offset / StepsPerUnit Used for calibration / conversion. Can be read only (set by properties) or read_write. Can also be affected by Protected
SlewRate / FirstStepRate / Acceleration read_write In steps per second
LimitLow / LimitHigh Read only. Show status of limit switches
StepSize Used for commands StepUp / StepDown
16
Optional Attributes
Protected read_write protects some attributes from being written
EncoderPosition / EncoderSteps Read only position
EncStepsPerUnit Calibration value for encoder
HomeSide / HomePosition / HomeSlewRate Deals with different aspects of reference switch
Backlash / Deceleration
WindowSize, SettleTime, PID gains, ServoLoop Parameters for servoloop control
17
States
On Waiting for command
Off Power off
Moving Ongoing action, can be simple or composed movement
Fault A fatal error, disallowing any movement occurs
Alarm Movement (maybe limited) can be started. But a warning condition is reported
18
Commands
Reset Starts action to get out of FAULT state
Abort Cancels any movement ongoing or programmed
DefinePosition / DefineEncoderPos Change position (encoder position) register
GoHome Starts movement to look for ref. Switch. Sets position to HomePosition
Forward / Backward Starts continuous movement
StepUp / StepDown Starts relative movement of StepSize
SearchHome Search for Home, do not reset position
19
Thank you
Write a Comment
User Comments (0)
About PowerShow.com