Prepare beamline route

[marcus-oscarsson]

There is a route/resource called /prepare_beamline that was requested by MAXIV back in the day,

mxcubeweb/mxcubeweb/routes/beamline.py

Line 29 in 0b0225e

@bp.route("/prepare_beamline", methods=["PUT"])

.

@elmjag, @fabcor-maxiv, @matyson Is this route still in use, and what is it used for ?

[elmjag]

Yes, we use it. This route calls prepare_for_new_sample() method on the collect hardware object.

It prepares beamline hardware for manually(?) mounting a new sample.

That code does things like:

• close detector cover
• put MD3 into transfer phase
• move back detector (to a 'safe' position)
• close safety shutter

As far as I understand, the idea is to put beamline in a state where a user can enter the hutch and exchange the sample on the diffractometer.

[marcus-oscarsson]

I see, I'm wondering if we really need a route for this. I think this can be better done in a another place and not directly triggered from the UI. We at least know in the back end when a new sample is mounted manual or from the sample changer so it could be done in the SamleChanger or Lims components of mxcubeweb. The ideal would be if we could find a way to handle this in mxcubecore.

Perhaps, you already have some ideas where this can be done better ?

[beteva]

@elmjag we have exactly the same sequence when we change the sample, as it is part of the interlock for the sample changer robot. We call the procedure it in the local sample changer hardware object (see prepare_load in the FlexHCD.py), As @marcus-oscarsson said, it is more practical and natural to attach it to the sample changer and and the UI only triggers load/unload, no matter if it is automatic or manual, if is done with the sample changer.
Otherwise, we also have procedures which executes actions when we open/close the hutch. It is automatic and connected to the PSS (personal safety system), so can be triggered with the hutch door opening/closing. We also have in the hutch actions a button to choose if you want to use this or not.
I see that prepare_load is also implemented in other synchrotron’s sample changed HOs, so maybe it could be an idea to put a place holder in the AbstractSampleChanger.

[elmjag]

I agree that it feels a bit weird that UI specifically triggers this 'prepare for manual sample' routine. If it's only used at MAX IV, we should think about refactoring it.

I don't really know exactly sample mounting code works. I don't really have any suggestions. We, at MAX IV, will take a look at this, and see what suggestions we come up with.

[marcus-oscarsson]

A very easy change would perhaps be to move it to:

mxcubeweb/mxcubeweb/core/components/samplechanger.py

Line 239 in d781642

msg = "Mounting sample: %s" % sample["sampleName"]

Its not the cleanest, another solution would an implementation on the SampleChanger HardwareObject. The same or similair that is called for mounting with the sample changer (just without the actual mounting part).

[fabcor-maxiv]

So, I guess this is related: #1859 (comment).