[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