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

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

 Protocolo de comunicación  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: 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

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

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”

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.

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:

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

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

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

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

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

Interfaces de Software Panview En FermiLabs, 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)

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.

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