[Nexus] Motors

[Mark Koennecke]

Dear Gerd, Armando and Pete,


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?
>

My 2c:

NeXus is intended as a data exchange format and as such cares only 
about  the most exact value of translations
and angles at the appropriate places in the NeXus hierarchy. I 
acknowledge the request to store additional motor
parameters in order to debug the instrument. So this stuff ought to go 
into a NXcollection. NeXus does not really care
where this goes. Or should it? Is this a new requirement? Concerning the 
linking of values to NXpositioners there are
two options, which are equal in respect to an application definition:
1) you store the value at the NXpositioner and link to it from the right 
place in the application definition.
2) you store the value in the application definition compliant part of 
the NeXus hierarchy and create a link in
   your NXpositioner

I have a slight preference for 1) because then the target attribute 
tells you where to go in order to find all the gory
details of the motor right from within the application definition 
hierarchy.

The ideal storage for a motor would be to have a value in the NeXus 
hierarchy which is a group at the same time
which upon opening reveals all the other gory parameters.  Like this:

entry:NXentry
     sample:NXsample
                  rotation_angle
                              zero
                              lowerlimit
                              upperlimit
                              cap_name
                              .......
This is how it looks like within SICS. But HDF does not allow this. A 
data field cannot double as a group. And a group
not as data.The only way we can achieve this in HDF is to use 
attributes. This means converting all the fields of
NXpositioner to attributes of the value stored in the NeXus hierarchy. 
Performancewise this is no problem, we
are talking at max two handful of parameters/attributes per motor here.

Another option would be to make rotation_angle a group of type 
NXpositioner. But I am very reluctant to
do this as it would add yet another layer of hierarchy before getting at 
the values. And it would require rewriting
all the application definitions we already have.

I am also a little bewildered by this discussion: at our place motors 
are units which just work. And if not, we
ask the electronics guys to fix them!

In an attempt to bring this forward some questions to the community:
-  Does NeXus need to care about where NXpositioners go?
-  And make suggestions beyond NXcollection/NXpositioner?
-  What do people think about dropping NXpositioner and storing the 
parameters in there as attributes
  to a data value?
- Gerd, would it help if I send you one of four circle diffractometer 
files in order for you to see how diffractometers
 are dealt with?

Best Regards,

    Mark Koennecke


> 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
>