Skip to content

align_wafer remote method behaviour is different compared to when ran locally #16

Closed

Description

@brandonaltieri1

This method seems to behave differently compared to when running Auto Wafer Alignment locally on the prober. Namely, running prober.vision.align_wafer seems to change the Home position/die, whereas running locally leaves the home position as is. Also, running wafer auto alignment locally seems to be significantly faster compared to running it remotely. Not sure if that's due to the type of wafer alignment I'm running (I'm using this option for reference)? Which option should I be using to match the behaviour I am seeing when running locally?

I am unable to attach the screen recordings I have here (above the allowable file size limit), but will email them to MPI support for reference.

Activity

  1. beltoforion commented on Feb 21, 2025

    @beltoforion
    Contributor

    Please clarify: By "running locally" do you mean executing the functionality directly in SENTIO?

    The "AutoDieSize" option is the slowest option. The speed when executed remotely should be identic to running it inside SENTIO. When this option is set SENTIO needs to start by stepping slowly, only a couple 100 µm because it first needs to determine the die size. Only when the pattern is found a second time can SENTIO start to do index steps. Since this happens for both x and y it requires additional time. This option is recommended if you do not know anything about the die size.

    If you do have an idea about the die size, even if its just a rough idea you can set the die size first and then use the "Update Die Size" option. This will work if the die size is close enough and the second pattern is in the camera view when doing an index step. If it is not SENTIO may start a spiral search to find the second pattern (if enabled) which may also take some time.

    If you have already created a project file and at least once determined the proper die size it is always recommended to use the "UpdateDieSize" option. This is most likely what you are seeing when executing locally.

  2. brandonaltieri1 commented on Feb 24, 2025

    @brandonaltieri1
    Author

    Please clarify: By "running locally" do you mean executing the functionality directly in SENTIO?

    Yes that's correct - i.e. I ran wafer alignment by pressing the Auto button shown below, with the settings shown.

    Image

    Image

    The "AutoDieSize" option is the slowest option. The speed when executed remotely should be identic to running it inside SENTIO. When this option is set SENTIO needs to start by stepping slowly, only a couple 100 µm because it first needs to determine the die size. Only when the pattern is found a second time can SENTIO start to do index steps. Since this happens for both x and y it requires additional time. This option is recommended if you do not know anything about the die size.

    If you do have an idea about the die size, even if its just a rough idea you can set the die size first and then use the "Update Die Size" option. This will work if the die size is close enough and the second pattern is in the camera view when doing an index step. If it is not SENTIO may start a spiral search to find the second pattern (if enabled) which may also take some time.

    If you have already created a project file and at least once determined the proper die size it is always recommended to use the "UpdateDieSize" option. This is most likely what you are seeing when executing locally.

    I reached out via email to MPI support, and they responded as shown below:

    I confirmed that for the auto alignment there isn’t an enum for current die size which is what you showed when clicking the align button. Both update and auto calculate the die size thus why it takes so long. As a work around you can replace prober.vision with the below string vis:align_wafer and that we replicate clicking the button.

    # perform wafer alignment
    prober.vision.align_wafer(AutoAlignCmd.value)
    #resp = prober.send_cmd("vis:align_wafer")
    

    So presumably we are missing an enum here which uses the current die size, i.e. the size saved in the project file?

  3. beltoforion commented on Feb 26, 2025

    @beltoforion
    Contributor

    Yes it appears that the "CurrentDie" Size is missing. This option should use the existing die size and not try to determine it at all.

  4. added a commit that references this issue on Feb 26, 2025
  5. beltoforion commented on Feb 27, 2025

    @beltoforion
    Contributor

    issue should be fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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