Bien,
Tenemos cámaras y una clase a través de la cual nos conectaremos a “cualquier” cámara.
Tenemos telescopios y una clase  a través de la cual nos conectaremos a “cualquier” telescopio.
Y tenemos relayboxes y (aún no en el nuevo esquema) una clase que nos permitirá conectarnos a “cualquier” relaybox.
 
Además las cámaras cumplen el interfaz GuiderInterfaz pues algunas cámaras permiten autoguiar y lo mismo con los telescopios. Así que tanto los relaybox como las cámaras como los telescopios son Guiders.
 
Estupendo, conceptualmente parece que todo está solucionado, pero ahora nos enfrentamos a un problema:
 
Imaginen que estamos conectados a un telescopio y que luego queremos conectar con una cámara. Hasta aquí bien. Ahora queremos conectarnos con un autoguiado. Puede ser que queramos conectarnos con un relaybox, entonces no hay problema, pero supongamos que queremos conectarnos al relaybox de la cámara a la que estamos conectados.
 
Aquí debe haber un pequeño negocio. Si la cámara que servirá de relaybox está ya conectada, “simplemente” hay que hacer que el guiador apunte a ella (haciendo la conversión de tipos necesaria):
guider = (GuiderInterface)cam;
 
Listo. Pero qué pasa cuando cerremos la sesión de autoguiado, o  qué pasa si cambiamos de cámara. En el primer caso al tratar de hacer un Disconnect() se debería detectar que el dispositivo aún es “útil” pues está sirviendo imágenes y en el segundo caso deberíamos dejar la instancia de cámara abierta e instanciar otra con la nueva cámara... si se hacen cargo, este “pequeño” negocio puede llegar a ser ¡un lío!
 
Se me ocurre una idea. En lugar de conectarnos a una cámara, a un telescopio o a un relaybox o cualqueir otro dispositivo de “hardware astronómico” de forma aislada, podríamos tener una clase de nivel superior, algo así como AstroHard (o yo qué sé) que centralice todos los accesos a cualquier tipo de hardware, por ahora sólo estos tres.
 
Si queremos conectarnos con cualquier dispositivo (cámara, telescopio o relay) podemos decirle a AstroHard que nos de acceso a ese dispositivo. Si detecta que ese dispositivo ya está abierto, pues le da acceso al mismo (con el interfaz que cumpla la petición). Si recibe una petición de desconexión, primero evalúa si no hay otra petición de uso todavía abierta... en fin sería el encargado de realizar todo ese “pequeño” negocio de dispositivos.
 
cameraID = “Atik 16IC”;
camera = AstroHard.ConnectCamera(cameraID);
 
ascomID = ASCOM.DriverAccess.Telescope.Choose("");
scope = AstroHard.ConnectScope(HardwareType.ASCOM, ascomID);
 
guider = AstroHard.ConnectGuider(HardwareType.Camera,  cameraID);
 
.....
AstroHard.Disconnect(guider.GUID)
AstroHard.Disconnect(scope.GUID)
AstroHard.Disconnect(camera.GUID)
 
Acabo de actualizar el proyecto EQAlign2.1, más o menos está funcional.
 
En cámaras (proyecto EQACam) falta implementar el acceso a ASCOM, creo que será bastante fácil (hay una plantilla para crear cámaras CamTemplate.cs) He esbozado lo que podría ser una conexión a las DSI y he “traducido” también el acceso a las Atik/Artemis
 
No encuentro información sobre los parámetros de guiado de las Atik/Artmeis, en la descripción del comando ArtemisPulseGuide(void *cam, int axis, int millisec); no se especifica los valores de axis. Buscaré, si no encuentro nada: prueba y error.
 

En telescopios (proyecto EQAScope) he implementado el acceso a ASCOM (versión 5), compatible con las dos versiones de ascom. He hecho trampas: primero se comprueba si es compatible ASCOM5, si es así perfecto, si no compruebo si la montura conectada es compatible con LX200, en ese caso también se puede enviar un pulso de movimiento (sin tiempo de acción) y si tampoco, pues el pulso dura 1 segundo. Eso dará un poco más de usabilidad a a botonera.
 
En el proyecto TestScope, se permite conectarse a un telescopio y a un guiador. En el guaidor se muestra un combo con las cámaras que permiten autoguiado y ascom. Pero no hay nada de ese “negocio”, si se desconecta un dispositivo que sirve a los dos, desconectado queda.
 
En el proyecto EQAControls sólo hay dos controles: la botonera (usable por autoguiadores y telescopios) y las coordenadas del telescopio. Ahí puede ir un contenedor de imágenes, el control de tratamientos de imagen (histograma, gamma, contraste, desenfoque, apilado), el graficado de mediciones, etc.
 
Cuando esté todo, habrá que ir “cosiendo” EQAlign 2.1 con los “retales”.
 
Bien, mientras no hayan otras ideas continúo en este esquema.
 
Un saludo