DIFFRACTOMETER WORKING GROUP

[beteva]

This is a place to make suggestions and comments, concerning the AbstractDiffractometer Class and all the inheriting classes. Open to all MXCuBE developers, in particular those interested in the Diffractometer API development.

[beteva]

For all issues and pull request, being a result of this issue, please add the DIFFRACTOMETER WORKING GROUP label

[rhfogh]

@marcus-oscarsson @beteva
I was a little surprised that the AbstractDiffractometer PR was merged while still marked WIP (though admittedly, it had been there for a long time). [OK, that was a simple mistake and has been fixed.]

Anyway, I think there is still an issue to discuss, about the nested roles / dictionaries of roles. Nesting is not problematic, but having defined role names is, I think.

I think it is quite important that you can write code that access e.g. zoom, omega, kappa, phi, centring motors in a generic manner, without having to hardcode the naming system of a specific beamline. So far we have used ESRF names as a de facto standard for everybody. But if e.g. motors are an unconstrained dictionary of role names, how are we to do this?

I am not sure of the best answer.

It is true that my GPhL colleagues said that there is no universal standard for motor names - but we still need some local standard for coding purposes. They (Peter Keller) recommended giving the names of e.g. rotation axes as a list in order from goniostat to sample (or vice versa). The you could get the name of e.g. the Kappa axis as diffractometer.rotation_axis_names[1], with an orientation vector specified in a configuration file. This approach could combine with having motors in a dictionary, would still allow us to add motors freely, and would free us from the problem of finding a motor name that would work for both kappa and chi axes (Smargon). But other axes that one might want to access more broadly (e.g. zoom, centring) would need a standard as well. Also, because we use a dictionary, there would be no way in the code to check that the motor we are accessing actually exists, and is not a typo, or called something else on that particular beamline.

Alternatively we could decide on our own naming standard, accept that the names would be somewhat misleading in some cases, and get a set of official names that anyone could code to, and that could be enforced in the code as role names currently are.

A third option would be that I make my own GPhL-specific naming standard. and ask the beamline scientists as part of the configuration to specify the mapping between their local names and mine.

MODIFIED FROM ORIGINAL:
For rotation and centring motors that is what we are already doing, so for us it is less of a problem. It could be done this way. But any other motor we wanted to use we would have to (re)configure as well (zoom, for instance), and in general it would become impossible for anyone to refer to specific motors in beamline-independent code. Is that the best way?

[marcus-oscarsson]

Sorry I was doing to many things at once, so I MERGED instead of CLOSING it. So we closed it as there were two PR's for the Diffractometer and it was confusing which one was actually the current. So the one to refer to is #663.

[marcus-oscarsson]

I agree that there still are a few things to discuss regarding this. When it comes to naming of motors I would find not find it incorrect if agreed to a set of, within the community, established names as long its clear what those names refer to. Its not the only way of dealing with this "problem" but its easy to work with/understand.

It does not prevent us from having other additional motor names.

[rhfogh]

@marcus-oscarsson Sounds right to me.