ASI stage homing

[juliomateoslangerak]

The ASI stage is set to homed=False at init time. This means that it thinks it is not initialized anytime we connect to it, while, in reality, the stage is homed. We just don't check if the controller knows. I will look into this.

Another thing is that, when it homes, it does first X and Y and then Z. Very dangerous! I want to make the Z stage go down first (eventually homing there, before the other axis move. How do other stages deal with this? This is obvious for this stage and we know what is the Z axis.

[juliomateoslangerak]

I believe this might depend on the presence or not of linear encoders. In fact the stage I'm trying (thanks @jondaniels) doesn't seem to need homing at all.

There is the command SI (https://asiimaging.com/docs/products/ms2000#commandsi) that seems to do all the homing. It haves a different behavior with or without encoders. I think we can call it with a value of -1 or 1 in both cases. The difference with the current implementation is that it would place the 0 position in the center of the stage.

Anyhow, it seems that the min_limit of the z axis is when the objective is up, I will change the strategy for homing of the z axis

[iandobbie]

With my stage the system has no idea of the active area until the system has been driven to its limits, this is why I wrote the code to start with homed=False and then force a homing cycle which drives stage to the limits and allows us to find the active area and construct a imaging area in cockpit.

We could definitely have some code to see if the stage has encoders and not home if we don't need to. I also think it doesn't matter where the zero position is, and I did think about making it the center, but it was easier to just drive to the negative end and set that to zero.

[juliomateoslangerak]

@iandobbie, can you try the SI command? For example, without linear encoders SI X=-1 should find lower limits. From the docs

If 1, then the stage seeks the upper limit. If -1, then the stage seeks the lower limit.

The stage moves to the hardware limit, backs away 3 mm, then approaches the limit slowly enough to maximize 
repeatability of the result. 
The recommended procedure is as follows, with SI and HERE commands using one or more axis arguments:

    Send SI command.
    Poll with STATUS command until ‘N’ is received.
    Send HERE command with desired real world position.

[iandobbie]

There is the command SI (https://asiimaging.com/docs/products/ms2000#commandsi) that seems to do all the homing. It haves a different behavior with or without encoders. I think we can call it with a value of -1 or 1 in both cases. The difference with the current implementation is that it would place the 0 position in the center of the stage.

This doesn't appear to be present on my controller.

>>> con._conn.command(b'SI')
>>> con._conn.read_multiline()
[b':N-1', b'\n', b'']

So it just returns :N-1 and doesn't move the stage. I wouldn't be surprised if my firmware is just too old. I am not totally adverse to upgrading but I do want to think about it a bit as the system also has an obsolete camera (cascade II) so might not be easy to drive with other software if we muck it up.

Sorry it took a while to test this, been very busy here.

[iandobbie]

@iandobbie, can you try the SI command? For example, without linear encoders SI X=-1 should find lower limits. From the docs

If 1, then the stage seeks the upper limit. If -1, then the stage seeks the lower limit.

Sorry I didn't read carefully enough and did not try this. I am home now but will try again next week.

[iandobbie]

Just reading up some more on this and the manual says...

"This functionality is available by request from ASI. It is not included with standard firmware." (https://asiimaging.com/docs/commands/si)

So it seems that the default non-encoded stage might not have this.

[iandobbie]

I have just conformed that even when I do the right thing it still fails.

>>> con._conn.command(b'SI X=-1')
>>> con._conn.readline()
b'\n:N-1\r'
>>> con._conn.command(b'SI X=1')
>>> con._conn.readline()
b'\n:N-1\r'

So it looks like my controller jyst doesn't implement this. We could easily reimplement the homing loop to try this command and fall back on the exisiting code if it fails. We should also add some logic so a fully encoded stage actually ends up knowing where it is as this seems possible.

[jondaniels]

Indeed it appears that your firmware doesn't support homing. We can get you different firmware if it is important to have this feature.

Taking a step back, why do you want to perform this homing step? I know some other stages do it automatically on power-up, but the ASI controller remembers the stage positions across power cycles. Very rarely is this command used by our customers, mostly if there is the chance that the stage got bumped when powered off (and the typical leadscrew pitches stages take a lot of force to move externally).

[iandobbie]

The homing is only part of the issue, driving the system to the two extremes allows us to know how big the stage area is. This info is used by our GUI to build an interface with the correct stage size and to assess if moves will succed or not.

I didn't realise the stage actually knew where it was, I assumed that it had no idea. We could add the strage size to the config so we don't need to drive the stage to the extremes to find how big it is and then just rely on the stage knowing where it is. I guess we could add some error checking that if the stage hits the limits when it isnt expecing to then we can flag that it needs to be homed and warn the user about this.

[jondaniels]

OK, how about just driving the stage to its limits? (In contrast to doing it in the more fancy way that the SI routine does, but only in supported firmwares). E.g. "M X=-123456789 Y=-123456789" and then wait until both axes stop moving, then register the position. Followed by moving to the other corner "M X=123456789 Y=123456789".

If you haven't found this it can be helpful: http://asiimaging.com/docs/command_quick_start

[iandobbie]

This is exactly what I am doing, in a slightly different way. I am using the spin function rather than setting a very large -ve/+ve position and once I reach the minus limit I am setting the current position to zero so the stage effetcive goes from 0,0 to its size in x and y.

How about seeing if we have a set xy size in the config and using that if it exists and then driving the stage to the limits and reporting it so it can be added to the config if it isn't there.

[iandobbie]

The XYZ position is not preserved over a power cycle on my system. The system powers on with all set to 0, no matter where you powered it down, so the only way to get repeatable positioning is to do some kind of home move. I agree that systems which do preserve this can avoid the whole move to limits step but my system requires the homing on powerup.

[jondaniels]

Maybe somebody (or a previous software package) disabled this feature. Try enabling it by sending serial command "SP X=0" and then "SS Z". See https://asiimaging.com/docs/commands/savepos.

Or else you have an extremely old system.

[iandobbie]

I will try but I also suspect that we have a suitably old system. It came via 3i and talking to them recently I think it is from the 90's originally.

[jondaniels]

So 20+ years old... all bets are off with firmware features, but it's great to hear that it still basically works ;-)

[iandobbie]

I agree, pretty big reach! It does work, very well. I am actually using the system as a TIRF training setup for a grad student course I am running this year. The stage works well, it can get a bit crunchy in places so I think it needs some lubrication but still works fine. I will see if I can grab the firmware version, but to be honest it is performing brilliantly.

I am thiunking of trying to turn it into a STROM system by adding a chunky 640 laser but frankly it just works!