Position updates in mosaic and macrostage window can be behind the stage.

[iandobbie]

In the simulation mode the stage position works great in both the macrostage and the mposaic windows but with the relatively slow Ludl stage the macrosatge and mosaic window can be one move behind when moving the stage by double clicking in either the macrostage or the mosaic windows

[carandraug]

Does the ludl return from the move functions after the move has finished? Cockpit expects those functions to block. I've seen that problem when stages were returning soon after sending the move command to the hardware instead of waiting for the hardware to finish the move.

[iandobbie]

I don't know, I'll have to test tomorrow. I suspect you are correct and it is returning as soon as the move has been commanded. However the mosaic has code to wait for the correct position to be found so why don't we have similar code to keep sending position updates while the stage is moving.

The great advantage of this is that a diagonal move can be twice as fast as both moves happen simultaneously.

[carandraug]

However the mosaic has code to wait for the correct position to be found so why don't we have similar code to keep sending position updates while the stage is moving.

You can make an async call to Microscope's move command which returns immediately. You then should be able to keep querying the position while waiting for the async command to finish.

The great advantage of this is that a diagonal move can be twice as fast as both moves happen simultaneously.

You could still have it in Cockpit by calling _proxy.move_to({"x": x_pos, "y": y_pos}) (instead of calling it in one of the axis, waiting for it to return, then calling it on the other axis).

[iandobbie]

Good thought on the async call, I'll have a look at that.

Not sure the direct call to _proxy.move_to is a good idea as that bypasses the stageMover. I figure probably the async call logic should go into stageMover and then get it for all moves if requested. I think there is already a blocking=True option in the move commands.

[carandraug]

Not sure the direct call to _proxy.move_to is a good idea as that bypasses the stageMover.

You're right. I was not trying to suggest that, I was just noting that Microscope does support it (diagonal moves) even though the move commands block.

I figure probably the async call logic should go into stageMover and then get it for all moves if requested. I think there is already a blocking=True option in the move commands.

It was never clear to me what cockpit expects some of the move callbacks to do. I can't help much there.

[iandobbie]

Ok, Sorry other things got on top of me today so I didn't check this out. It is a rather minor issue but worth thinking about. I will see exactly what the behavior of cockpit and microscope is and think about the best way to fix this issue and hopefully improve the system in general. These is one fundamental issue that some stages will accept moves in multiple axes at once while others just block while one movement is taking place so you can't move another at the same time.

[iandobbie]

I have finally got back to look at this. As suggested the move returns immediately once the move is triggered, not what cockpit expects, which is the move actually completely before the move call returns. The issue is actually in the microscope ludl code. In fact I had written it "properly" to start then comment it out and returned as soon as the move is commanded. I have now fixed it.