New 2.3 version

[mguijarr]

Let's put here the list of changes we would like for 2.3, and when we are ready we can make a new 2.3 branch from master.

[IvarsKarpics]

1. Rename Qt4_diffractometerMockup to DiffractometerMockup in master. Add deprecation warning in 2.2 branch.

[meguiraun]

what about configurable position changed threshold in MicrodiffMotor? here

In mxcube3 we re-emit all those signals to the client, it would be nice having more control on which motor you want with higher resolution, so we can ~tune the number of sent signals.

The threshold would be defined in the xml and if not use the default one (1E-3).

(I can do a PR if you consider useful)

[IvarsKarpics]

Sounds like a useful feature.
It would be better to implement this in AbstractMotor.
In the AbstractMotor there is self.motor_resolution property which is used in move method. Could this property be used also for motorPositionChanged?

[meguiraun]

Yep, the same property can be used for both.
I will do a PR and we move any discussion there.

[IvarsKarpics]

I can prepare a table to list all hardware objects, branches and actual methods called from gui. It sounds like a challenging task, but for sure everyone would profit from a clearly defined API. Table could look like:

Hardware object	AbstractClass	master	2.1	2.2.	2.3
CollectMockup	AbstractCollect

Maybe a wiki page would be a better place to define 2.3 and API?

[mguijarr]

Ivars,
It would be really nice to make such table. Sure it's going to be useful.
👍

[IvarsKarpics]

Hi all,

I tried to create a table where we could compare all methods, signals, etc, but it is difficult to edit and extensively use tables in the issues and wiki. So I create a a wiki page dedicated to 2.3. https://github.com/mxcube/HardwareObjects/wiki/2016.12.05.-Version-2.3
The idea is to propose a clear API that hopefully could be the base of 2.3. I am not sure if the wiki page is the best place to discuss it (a face-to-face meeting would be the best), but somehow we have to start.

[IvarsKarpics]

I created a new google doc. with status information:
https://docs.google.com/spreadsheets/d/1eFYePJsdDN_NP15jir_0Ug5KLNT30RtCmX6GMjyKe9E/edit?usp=sharing
Please have a look and fill information about current version of HardwareObjects and GUI. It will help to merge branches 2.1, 2.2 and master, and proceed to 2.3.

[mguijarr]

Hey @IvarsKarpics and others,

I filled the document with information about which version is currently running on ESRF beamlines. We can see we are still very close to 2.1 regarding Hardware Objects.

For us, switching to 2.2 means at least:

• extensive use of Abstract classes
• use of newest data collection loop (AbstractCollect instead of AbstractMultiCollect)
• sample centring using Gleb's and Ivars' maths

This require more work than just switching branches, and tests - and we cannot afford instability at the moment, as we are constantly installing new stuff on our beamlines since a few months (like new sample changer robots or diffractometers) + developing our low level control software (spec replacement).

ID30A-3 is where we do most of MXCuBE 3 development, so we are on 2.2 for Hardware Objects to be in sync with MAX IV. But being on a branch doesn't mean the new code is really in operation as long as the old code is not deleted... In 2.2 we have both AbstractMultiCollect and AbstractCollect, for example. So it's possible to be on 2.2 and happily use old code from 2.1.
Maybe we should mark some modules as deprecated (with a DeprecatedWarning) in 2.2, and remove the files in 2.3.

For GUI: all beamlines are running Qt 3. We will switch to MXCuBE 3 (web), hopefully after summer.

Our plan is to concentrate on Hardware Objects once MXCuBE 3 is deployed ; one thing at a time. If we have extra time we would like to move to 2.2, with required changes to do, or directly to 2.3 (if it is out) beforehand of course.

[IvarsKarpics]

Hi @mguijarr !

Thanks for summarizing the current situation at ESRF. It does not sound easy to maintain a single code among such amount of beamlines.
I sent an email to the mailing list hopping people will be active and fill the document.

[vrey01]

Dear Ivars, For what I know about Alba and Soleil beam lines SOLEIL - Proxima-1 - does not use a separate HardwareObjects module. Their plan is not to update until they will eventually jump to mxcube3 with web interface. SOLEIL - Proxima-2 - they are up to date with HardwareObjects/ master branch. They use for now, AbstracMultiCollect. AbstractCollect is being adopted ALBA - Xaloc - they are up to date with HardwareObjects/ master branch. Their first implementation will use AbstractCollect, AbstractDetector… etc. That’s my humble contribution to the discussion

…

El 29 mar 2017, a las 16:02, Ivars Karpics ***@***.***> escribió: Hi @mguijarr <https://github.com/mguijarr> ! Thanks for summarizing the current situation at ESRF. It does not sound easy to maintain a single code among such amount of beamlines. I sent an email to the mailing list hopping people will be active and fill the document. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#82 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFQ4T69KddgMJ4YkKLjFaGjCC1JG-ALdks5rqmRhgaJpZM4JJT8G>.