We now have the sample changer proposal from Marcus. and the sample changer (among other things) from Martin. It would be nice to get the discussion started. I would summarise agreements and questions as follows (questions in bold):

Minimum requirement

• mount(location)

• unmount() # MO has unmount(location) - is the location mandatory/optional/unnecessary?

• get_state()

• get_sample_list() # MS calls it 'get_present_samples'

• get_loaded_sample() # **NB MS does not have this, but surely this functionality is necessary? **

Command handling

MO has get_available_commands, get_command_state, execute_command. This has the advantage of being infinitely extendable, but the problem that no functionality can be assumed to be present (or consistently named) across sites.
Is there a need (and possibility) for some commands (e.g. abort) to be universally supported?

The commands proposed here, between MS and MO, are: on, off, abort, park, calibrate, dry, home, defreeze, reset_sample_number, change_gripper

Procedure dependent?

The MO and MS lists have commands that do not match and that may depend on what kind of procedures are envisaged - as a non-crystallographer I cannot have an opinion.
How do these fit into a universal UI?

• get_error_message() # MS

• prepare_sample_loading() # MS

• select_location(location) # MO

• scan_location(location) # MO

• get_full_state() # MO

It looks like the last refactoring removed some RST instructions for formatting, please see the beamline.rst file.

The code and text is not well formatted so its difficult to read the file

Hi all,

I created a mini brick to test the sample changer interface:

In the header of file I have:

from api import sample_changer

api is a directory containing file sample_changer.py:

from HardwareRepository import HardwareRepository

hw_repository_client = HardwareRepository.HardwareRepository()
bl_setup_hwobj = hw_repository_client.getHardwareObject("beamline-setup")

def mount_sample(location, device_name=None, wait=False):

    Mounts sample from location
    Some sample delivery devices like yets could not have a difined locations,
    so location argument could be None.

    :param LocationStr location: location
    :returns: True if mount successful otherwise False
    :rtype: bool

    if not device_name:
        device = bl_setup_hwobj.sample_changer_hwobj
    else:
        device = getattr(bl_setup_hwobj, device_name + "_hwobj")

    device.load_sample(holder_length=None, sample_location=location)

def unmount_current_sample(device_name=None, location=None):

    Un-mounts mounted sample to location, un mounts the sample
    to where it was last mounted from if nothing is passed

    :param LocationStr location: location
    :returns: True if un-mount successful otherwise False
    :rtype: bool

    pass

We could use beamline-setup as container of all hardware objects. By default mount_sample method looks for sample_changer_hwobj and call related method. I added argument device_name because it may happen that several sample mount devices are available.

What do you think about this?

Pull request #7 has a lot of interesting discussion we should keep, but it would be easier to reject it and submit a new one, rather than to merge it and then totally change it by a new pull request.

Is there a way to keep the discussion without accepting the PR?

Rasmus

Discussion around the queue api

A couple of issues to discuss:

• 1 Do we agree that all actuators belong to the beamline as such?

• 2 Are we OK with the proposed system and set of commands?

• 3 Names of centring and alignment motors.
  One would prefer some names that

     - Were independent of geometry and motor names at individual beamlines
  
     - Could be understood and mapped without explicit config mapping (if possible)
  
     - There are various considerations
  
        - The names should work for minikappa, full kappa, Smargon, and maybe Euler 
           geometries. (so maybe avoid 'kappa_phi' and go towards Omega, Kappa, Phi)?
  
        - The names should work for horizontal and vertical omega both 
           (which limits the use of 'horizontal' and 'vertical' for translation motors)
  
        - One of the alignment motors doubles as one of the centring motors. 
          Which one, and how to determine it? 
          Also, one of the alignment motors doubles as the focus motor on some beamline.