Multi-axis stage handling #34
Description
Apology: I've not yet written a device adapter so this is just based on my reading of the docs. I have started implementing the relevant API functions though, as we're trying to follow the MMCore API in another project, with the eventual goal of creating a device adapter.
I can see single-axis stages and two-axis stages are nicely supported, but I am confused how a 3-axis stage (or XY stage with integrated Z drive, such as the Prior and ASI systems I've used in the past) is supported. Implementing separate XY and Z move commands means that making a move in all 3 axes ends up being split into two sequential moves, one in X/Y and one in Z. Most of the stages I use could accept a command along the lines of move <x> <y> <z> but I don't see an MMCore command that would correspond to this.
The only way I can see to do this in a device adapter would be to implement some sort of delayed-execution scheme, so that two function calls (e.g. to setXYPosition and setPosition) get combined, probably involving two separate objects (one for the XY stage and one for Z) plus a third object to coordinate between them. That significantly complicates the task of implementing a device adapter, and probably results in sub-optimal performance (e.g. because I'll just implement sequential moves as it's easier). Looking at the existing device adapter for Prior stages, it seems that's exactly what happens; I think the code could be simplified if it was implemented as a 3-axis stage (which MMCore can then break down into XY and Z with little to no additional work from the device adapter).
Would it make sense to have a more general class that handles n-axis stages, and then implement nice ways to wrap that to extract single-axis stages? Doing things that way round feels like it should be simpler to me - but no doubt there are reasons for the way it's currently implemented...