align_wafer remote method behaviour is different compared to when ran locally

[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.

[beltoforion]

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.

[brandonaltieri1]

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.

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?

[beltoforion]

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.

[beltoforion]

issue should be fixed