Introducción

1. Introducción Software de Monsoon La Serena, Mayo de 2010

2. Introducción • Esquema de comunicaciones • Filosofía de diseño: assembler, “atributos” • Interfaces existentes: MEC y Panview La Serena, Mayo de 2010

3. Esquema de comunicaciones Fibraóptica  Protocolo de comunicación • Protocolos de comunicación: • Systran: • daughter board: • systran / curtis • PCI card: • systran / curtis (1 link) • Usado por Newfirm y sistemas en NOAO-norte • S-Link: • daughter board: • HOLA • PCI board: • Filar (4 links) • Usado por DECAM, ctio60’’ echelle y ctio1M decam test camera Monsoon crate host MCB Comms Daughter board PCI card

4. Esquema de comunicaciones • Software para ambos protocolos sólo cambia a un nivel muy bajo; el uso de uno u otro es transparente para el usuario • Torrent usará systran y/o GigE

5. Filosofía de Monsoon General • Fue pensado (NOAO norte) de manera que el “hardware” fuese manejado como software, solamente usando variables y registros • Para cambiar una variable de hardware (por ejemplo, un voltaje) se cambia el valor de un registro (como si fuese una “variable” de software) • El resultado de esto es que se tiene una larga lista de variables que configuran el hardware (valores de dacs, modos de lectura, relojes, etc) • Estas variables se llaman, en el lenguaje de monsoon, “atributos”

6. Filosofía de Monsoon Assembler • La única “inteligencia” del hardware de monsoon reside en la • Tarjeta MCB, en donde corre un “loop” de ejecución de rutinas • Al momento de ser inicializado se hace un “upload” del código que correrá en la MCB (de manera similar a los archivos “.lod” de SDSU o los “.btl” de arcon – el famoso helicóptero de inicio -) • Estos archivos son de extensión “ucd” (xxx.ucd) • El assembler de monsoon fue también desarrollado por el equipo de software de monsoon (Tucson). • Este assembler es bastante limitado, dado que por filosofía la mayor cantidad de inteligencia debe residir en el host.

7. Filosofía de Monsoon Atributos • Lo que resulte de poner un atributo en un cierto valor (las implicaciones) depende de la variable. • Cada atributo tiene un nombre, una dirección de hardware, límites, algoritmos de conversión, etc • Para cada tarjeta de monsoon existirá una lista de atributos. Esta lista depende del tipo de tarjeta (el número y el tipo de variables) • Como cada sistema tiene varias tarjetas, terminamos con una lista bastante larga de atributos para describir un sistema en particular El ser orientado a “atributos” tiene algunas implicaciones:

8. Filosofía de Monsoon Atributos • La lista de atributos se guarda en un archivo con extensión “csv”, y es específico para cada sistema • Un detalle importante es que la dirección del atributo se forma de la dirección interna de la variable en la tarjeta, y del slot en que la tarjeta se encuentra. • Una implicancia importante de esto es que al cambiar una tarjeta de slot, las direcciones de todas sus variables cambian, por lo que el csv file cambia. • De hecho, el assembler tambien debe ser recompilado

9. Filosofía de Monsoon Atributos • Ejemplo de descripción de atributo: CCD1_H1b_gateClk,CLK_OUT_16,0x0040012,1,0x10000000,RDMSKWRT,RDMSKWRT,FLOAT,UINT,65536,0,LINEAR,0,1,Boolean,controls <nombre_software>,<nombre_hardware>,<dirección>,número_de_direcciones, <mascara>,<método_de_lectura>,<método_escritura>,<tipo_de_dato>, etc • Notas: • El nombre de esta variable es CCD1_H1b_gateClk • La dirección esta formada por un OR entre la dirección del slot • Y la dirección del registro: En el ejemplo: <0x004> es la • Dirección del slot (2^(slot-1)) y <0x12> la dirección de la • variable en la tarjeta

10. Filosofía de Monsoon Atributos • Otras implicancias de la orientacion a atributos: • Las únicas acciones son “set”y “get” (lo único que se hace es poner un atributo en un valor, o leerlo para saber su estado) • La consistencia de ese atributo con respecto a otras variables debe ser asegurada por el cliente, que en este caso se comporta como un programador • Ejemplo: • Al cambiar el “binning”, no basta con poner la variable de binning en el valor deseado; también habría que el hacer el cálculo del tamaño final, y escribirlo en la variable que indica el tamaño del detector

11. Interfaces de Software MEC • Los desarrolladores de software del equipo de monsoon • desarrollaron un software que consiste en varios procesos diferentes • interactuando entre ellos. • La interfaz de usuario fue hecha en TCL-TK. La interfaz de • ingenieria se llama MEC, y es usada para el desarrollo en Tucson. • En CTIO la única persona con extensa experiencia en MEC es • Ricardo Schmidt –además de Peter Moore, quién lo utilza para el • desarrollo de Torrent • Newfirm usa los mismos procesos utilizados en el MEC

12. Interfaces de Software Panview • Viene de Pixel Acquisition Node (en labVIEW) • Desarrollado para la adquisicion de datos y el manejo de controladores de detectores. Utiliza C y labview (Linux). A diferencia del MEC, no fue hecho especificamente para monsoon • Es una evolución del “arcview” original, que fué llevado de CTIO a • Caltech, y de vuelta de Caltech a CTIO • Está disenado para manejar diferentes controladores. Se utiliza • extensivamente en Caltech, JPL y Monte Palomar • Monsoon se agregó a la lista de controladores que panview maneja • a fines del 2007

13. Interfaces de Software Panview • EnFermiLabs, Universidad de Illinois, Ohio State, IFAE y Ciemat: • se usa para desarrollo de DECAM. • En CTIO: • presente: • echelle del 60’’ (orange monsoon) • ingenierías de DECAM en el 1m (fermi monsoon) • laboratorio electrónico de L.S.(monsoon, sdsu) • Futuro: • DECAM (fermi monsoon) • Sistemas con Torrent en general (hydra, chiron, etc) • PreCam del Schmidt (fermi monsoon)

14. Interfaces de Software Panview • En SOAR: • presente: • direct imager de SIFS (sbig) • futuro: • BTFI (cccp) • STELLES (sdsu) • Tener un sistem de software genérico provee varias ventajas: • Todos los comandos e interfaces son idénticos, sin importar • el controlador que utilice el instrumento • Scripts y GUIS pueden ser compartidos sin modificaciones • La mantención de facilita mucho.

15. Conclusión / Resumen • Monsoon tiene dos links de comunicaciones diferentes, pero esto • Es transparente para el usuario (la interfaz de software es idéntica) • Monsoon es orientado a “atributos” que definen variables de hardware • Los atributos son descritos en un archivo (extensión “csv”) • Existen dos interfaces de software para el monsoon: MEC (NOAO norte) y Panview (NOAO sur) • En Tucson se usa solamente MEC, en CTIO se usa y usará principalmente panview, a excepción de NewFirm