[Nexus] How to model a grating monochromator?

["V. Armando Solé"]

Hi Gerd,

The precursor of the generic NXcollection group was indeed motivated by 
most of your caveats.

With respect to what is OK or not with the NXcollection, everything has 
to be OK because it was created for custom use. Hopefully when several 
people are making a common use, that can lead to a more explicit new 
NXgroup.

Concerning your problem, you can follow the absolutely standard NeXus 
way of organizing the motors inside NXpositioners wherever is allowed 
(probably inside NXinstrument). If you just need the values of a set of 
motors, you can just create one NXcollection group with links named as 
your favourite motor names that are pointing to the motor value(s). If 
you have an application definition that needs a motor value, you can 
just validate the application definition by the existence of the link, 
without forcing it to be to a certain NXpositioner or NXcollection group.

Best regards,

Armando

On 14/12/2010 16:42, Wellenreuther, Gerd wrote:
> 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
>