Skip to content

Discussion: Mover-Setup update #137

@maltewae

Description

@maltewae

This is not a problem with LabExT but rather a discussion for a planned update in Mover. I created this ticket to discuss the changes before I invest in work that doesn't solve the problem/use case in the end.

Background:

Change requests have come up for the new SfP interface. Assuming we only use a stage during the Search for Peaks process and in no other case (e.g for move to device), the current mover is too restrictive.
Specifically, each stage that is to be used in LabExT is registered in the Mover. To do this, we create a calibration for each stage containing everything needed to safely move the stage. In particular, we require the mandatory specification of orientation in the chip system (left, right, etc.) and a device port (input or output) for each stage. In addition, we make the restriction that no orientation and port can be assigned twice. This currently limits the number of connected stages to 2.
We also require that each stage is fully calibrated (Kabsch) or partially calibrated (Single Point), which makes sense since these stages should be moved absolutely to new devices.
This especially does not allow Stages that we never move to devices.

Suggested idea:

  • From now on, when a Stage is to be used, there is a checkbox in the Wizard that simply activates the Stage. Calibration is still created, which is registered in the mover.
  • We leave out the configuration point of orientation for each stage. I noticed the following: The orientation is only important for the stage polygon, which is only used if we configure more than one stage. More precisely, we never ask the mover the question: Give me the left or right stage. We only ask it to give me the input or output stage when we move the stage to the device, for example. Proposal: We move the orientation as a parameter to the stage polygon. Advantage: We only require the parameter if the user configures more than one stage.
  • In principle, you can now register an "infinite" number of stages. To be able to move stages to devices, we require one or two stages that have firstly been assigned a device port and secondly are fully or partially calibrated (e.g. they can move absolutely). If there are two Stages, the CollisionFree-Algo is activated, so we require a StagePolygon.
  • For all other stages without DevicePort, you can make calibrations but do not have to. Especially the axes can be adjusted to move them relatively. In Search for Peak, which does not require calibrations to work, all stages are now selectable.

Advantages:

  • We do not break the design that the mover is responsible for all stages and calibrations for their safe movement. The interface remains consistent.
  • We allow more stages and outside of the constraint to fully calibrate them.

Disadvantage:

  • If a stage is not fully/partially calibrated but is physically in the measurement space, the Path Finder cannot take it into account. More precisely, no obstacle can be created for it in the potential field, because we do not know how it is in the chip space. Here we have to issue a warning.

Alternative idea:

  • We allow stage objects outside the mover, skipping the intermediate Calibration representation. This would be easy, but I would advise against allocating stages outside of a mover registry. This can lead to duplicate allocations.

Happy to discuss this idea with you.
@marcoep @delmedico @boris-vukovic

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions