Introduccin Software de Monsoon La Serena Mayo de

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

Esquema de comunicaciones Fibra óptica Protocolo de comunicación Comms Daughter board MCB Monsoon crate 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, ctio 60’’ echelle y ctio 1 M decam test camera PCI card host

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 Gig. E

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 El ser orientado a “atributos” tiene algunas implicaciones: • 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

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: CCD 1_H 1 b_gate. Clk, CLK_OUT_16, 0 x 0040012, 1, 0 x 10000000, RDMSKWRT, FLO AT, 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 CCD 1_H 1 b_gate. Clk • La dirección esta formada por un OR entre la dirección del slot Y la dirección del registro: En el ejemplo: <0 x 004> es la Dirección del slot (2^(slot-1)) y <0 x 12> 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 lab. VIEW) • 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 Fermi. Labs, 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 1 m (fermi monsoon) • laboratorio electrónico de L. S. (monsoon, sdsu) • Futuro: • DECAM (fermi monsoon) • Sistemas con Torrent en general (hydra, chiron, etc) • Pre. Cam 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 New. Firm