Download
1 / 19
210 likes | 561 Views
Tango @ ESRF Beamlines. Vicente Rey Bakaikoa BLISS / ESRF Tango Workshop at Elettra / 18 April 2008. Tango at ESRF beamlines Spec and Tango integration Standard tango motor interface. Tango usage statistics. Beamlines:. In braquets (sep.07). Mlayer – Hdb + e-giga.
E N D
Tango @ ESRF Beamlines Vicente Rey Bakaikoa BLISS / ESRF Tango Workshop at Elettra / 18 April 2008
Tango at ESRF beamlines • Spec and Tango integration • Standard tango motor interface
Tango usage statistics Beamlines: In braquets (sep.07) Mlayer – Hdb + e-giga
Tango usage statistics at ESRF beamlines In braquets (sept.2007) -- New server since sept 2007
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
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 Tango and SPEC
Tango and spec: todo list Events • Waiting for tango-7 and event queues Controller (motors / ccd’s…) • Next step • Must be based on agreed standards Accessing services • DB, HDB
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…)
Existing Motor classes SourceForge: AbstractAxis ESRF AdcMotor Paragon VpapMotor EletaEncoder Elettra Septumsled (LeoMotor) Desy OMS58 (Galil) Alba Device Pool Soleil Galil XPS […]
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 ?
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 Steps = HardwarePostion * StepsPerUnit
