[Nexus] How to model a grating monochromator?
Wellenreuther, Gerd
gerd.wellenreuther at desy.de
Tue Dec 14 15:42:45 GMT 2010
Dear Pete, dear all,
I am still a little bit confused about how I should use NXpositioners.
It is okay to collect them in one or a few NXcollections, and I am also
fine with linking them to something meaningful. But some things have to
be discussed/solved in my opinion:
* Most probably people would like to connect motors with already defined
fields (e.g. with a geometrical value from an application definition).
This could lead to having a link to an NXpositioners at this position
instead of a plain float. And that NXpositioner could also contain
either one position, or an array if that motor was used during a scan,
right?
* Further, it must not be clear whether the motor was properly
calibrated. And what about a stepper motor with an encoder - how should
one know whether to read "position" or "encodered_position" (just making
up those names on the fly...)? So there could be a couple of reasons why
just reading the "position" could not be accurate enough ... :( or at
least some ambiguity could be introduced if one is allowed to link a
predefined field from an application definition directly to a motor.
Maybe on should just "associate" motors with different values, and not
replace the values completely?
* According to Mark, motors moving the sample should be linked in
NXsample, while other motors (e.g. moving detectors) should most
probably go into NXinstruments. Is it okay to have them all together in
one NXcollection? Should the NXcollection be found in the NXinstrument?
What about devices like diffractometers, which are moving both detectors
and samples? I would like to represent them so the relationship between
different stages is clear ... and not putting some diffractometer-motors
here, and others there ... but I guess/hope the neutron-community
already came up with a good solution to this?
Cheers, Gerd
On 02.12.2010 00:09, Pete Jemian wrote:
>
> Gerd:
>
> Discussion was resolved today on NXpositioner. Additional fields need to
> be added to document common parameters and various types of positioners
> (stepper motors, servo motors, piezo-electric transducers, inch-worm
> motions, ...). Usage is intended to be one or more subgroups of
> NXcollection like this:
> beamline has "n" motors
> create an NXcollection group with name of (for example) "positioners"
> create "n" NXpositioner groups inside "positioners:NXcollection"
> store positioner data
>
> Now, when considering other base classes that might also use the same
> positioner information, make a link to the particular positioner as
> appropriate.
>
> Consider a hypothetical SAXS camera for an example, the sample-detector
> distance might come directly from the value of positioner "az":
> /NXsas/NXinstrument/NXdetector/distance
> --> positioners:NXcollection/az:NXpositioner/value
>
>
> As for NXgrating, I will seek experts for content suggestions. Please,
> forward your suggestions. I'll add them to the TRAC ticket.
>
> http://trac.nexusformat.org/definitions/ticket/158
>
> Pete
>
>
> On 12/1/2010 3:11 AM, Wellenreuther, Gerd wrote:
>> Hi Pete,
>>
>> thanks for answering!
>>
>> About the grating: I can ask Jens Viefhaus, who will be using gratings
>> for his beamline at PETRA III, to help me compiling a list of parameters
>> required to describe a grating used in monochromators. Or maybe there is
>> some expert from Bessy / HZB who could do this as well or better?
>>
>> About the motors/NXpositioner: I think we definitely need a defined way
>> of saving not only the position of a motor, but all its settings ( think
>> of soft- and hard-limits, slew_rate, acceleration, stepping_mode,
>> currents, home, conversion, encoders & calibration, units, ...) . This
>> should be handled by a base class, IMHO.
>>
>> What is not clear to me yet is given a device like a crystal in a
>> monochromator, and given a couple of devices like motors moving/tilting
>> such a crystal - how should I define what a certain motor is actually
>> doing? Just trying to deduce the motors function from a name sounds
>> dangerous ...
>>
>> Cheers, Gerd
>>
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus
--
Dr. Gerd Wellenreuther
beamline scientist P06 "Hard X-Ray Micro/Nano-Probe"
Petra III project
HASYLAB at DESY
Notkestr. 85
22607 Hamburg
Tel.: + 49 40 8998 5701
More information about the NeXus
mailing list