[Nexus] How to model a grating monochromator?

[Pete Jemian]

Gerd:

I agree with Armando's comments as well.  Continuing, additional 
attributes have been added to NeXus so they could allow NXcollection to 
have any content.  In NXcollection, the attributes are:
	ignoreExtraGroups="true"
	ignoreExtraFields="true"
	ignoreExtraAttributes="true"
and these tell the validation step that any groups, fields or attributes 
are permitted in a NXcollection group and not to attempt to validate 
them.  This may take a little more work to get right but the next step 
is to fold consideration of these attributes into the validation process.

On 12/14/2010 09:42 AM, 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?

You are 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...)?

There are fields for:
value		best known value of positioner
raw_value	raw value of positioner (native units of controller)
target_value	targeted (commanded) value of positioner

Here, the source of information for "value" is purposely ambiguous so 
that it is rather flexible to choose.

In our control systems at APS, we are used to a couple more fields that 
may or may not be used.  These could be added to NXpositioner.  Probably 
better to have some discussion first.  My vote is "add these".
encoder_value	derived from an encoder
readback_value	derived from (non-encoder) other sensor or computation

Thus, "value" itself may be a number of array of numbers or even a link 
to "encoder_value" or "readback_value".

Our APS motor abstraction also makes use of a "dial" coordinate which is 
in the same engineering units as "value" but is aligned with a printed 
label on the device.  Conceptually, it works like this:

	dial = raw_value * units_per_raw
	value = sign * dial + offset
	sign = +1 or -1

units_per_raw is defined by the nature of the motor (full-step, 
half-step, microstepper, ...) and the drive train 
(units/motor_shaft_revolution, worm gear, gear box ratio, ...).
The zero position for "raw_value" coincides with the zero on the dial.
"offset" is used to calibrate the motor to a known position without 
affecting the raw_value".

A "dial_value" is not represented in NXpositioner, nor is a flag for 
"properly_calibrated" or conversely, "uncalibrated".  We use this all 
the time, for example, on Huber diffractometers.  Almost always, the 
printed scale increases opposite to the coordinate system convention. 
And the zero is different (such as 90 degrees off).  However, a 
"dial_value" may be too much for NeXus as it may provoke more questions 
and misinterpretations.

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

The link is not to NXpositioner but to NXpositioner/value or 
NXpositioner/target_value.  Perhaps I miss your point, though.
With the additional fields ("encoder_value" and "readback_value"), this 
ambiguity can be resolved for most cases?

> Maybe one should just "associate" motors with different values, and not
> replace the values completely?

Not sure I understand this.  Can you say it differently?

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

Typical use I see is to have a list of NXpositioner entries within
     /NXentry/NXcollection
This provides a table of values to be referenced (linked to) as needed 
from the /NXentry/NXinstrument (or other) hierarchy.


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

The NXcollection class is a recent addition (and I expect that 
previously each instrument stored all its motors in the appropriate 
place for the device such as aperture, diffractometer, ...). 
NXcollection seems like just the place to store a list of motors.  In my 
view, I am comparing it with the SPEC data file which has a list of the 
positions of all configured motors in the header of every scan. 
NXcollection provides a standard place for me to store that information now.

Pete


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