Repositorio Institucional de Documentos

Desarrollo de una capa de abstracci´ on de hardware y clases FESA para la renovaci´ on del sistema de control de los aceleradores del CERN Autor: Rub´ en Poll´ an Bella Escuela de Ingenier´ ıa y Arquitectura Universidad de Zaragoza Directora: Anastasiya Radeva Depto. Beams Grupo Controls CERN Ponente: Jos´ e Luis Briz Depto. de Inform´ atica e Ingenier´ ıa de Sistemas Escuela de Ingenier´ ıa y Arquitectura Universidad de Zaragoza 16 de agosto de 2011 2 ´ Indice general 1. Introducci´ on 5 1.1. El CERN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Contexto tecnol´ ogico del PFC . . . . . . . . . . . . . . . . . . . 6 1.3. Contexto organizativo del PFC . . . . . . . . . . . . . . . . . . . 8 1.4. Naturaleza de este PFC . . . . . . . . . . . . . . . . . . . . . . . 8 2. Contexto 11 2.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.1. VME crates . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.2. PCI crates . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.3. Gesti´ on........................... 12 2.1.4. VMOD . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Sistemas operativos . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.1. LynxOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3. FESA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. COntrols Hardware Abstraction Layer 19 3.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.1. Jerarqu´ ıa de m´ odulos . . . . . . . . . . . . . . . . . . . . 20 3.1.2. Inicializaci´ on del m´ odulo . . . . . . . . . . . . . . . . . . 20 3.1.3. Acceso a m´ odulos . . . . . . . . . . . . . . . . . . . . . 22 3.1.4. Gesti´ on de errores . . . . . . . . . . . . . . . . . . . . . 22 3.2. Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Generic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3.1. HWAddress . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3.2. ToolBox . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3 4 ´ INDICE GENERAL 3.3.3. ModuleFactory . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.4. ModuleException . . . . . . . . . . . . . . . . . . . . . . 24 3.4. Digital Input Output . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4.1. ChannelAddress . . . . . . . . . . . . . . . . . . . . . . 27 3.4.2. ICV196 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.4.3. VMOD-TTL . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4.4. VMOD-DOR . . . . . . . . . . . . . . . . . . . . . . . . 29 3.5. Analog Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.5.1. VMOD-12E16 . . . . . . . . . . . . . . . . . . . . . . . 31 3.6. Analog Output . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.6.1. VMOD-12A2 . . . . . . . . . . . . . . . . . . . . . . . . 32 3.6.2. VMOD-16A2 . . . . . . . . . . . . . . . . . . . . . . . . 32 3.7. Otras familias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4. Clases FESA 35 4.1. CGAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2. CGDIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3. SISL2Watchdog . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.4. OasisCursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.5. OasisRdaClient . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5. Conclusiones 41 A. COHAL Reference Manual I A.1. COHAL Hierarchical Index . . . . . . . . . . . . . . . . . . . . . I A.1.1. COHAL Class Hierarchy . . . . . . . . . . . . . . . . . . I A.2. COHAL Class Index . . . . . . . . . . . . . . . . . . . . . . . . II A.2.1. COHAL Class List . . . . . . . . . . . . . . . . . . . . . II A.3. COHAL Class Documentation . . . . . . . . . . . . . . . . . . . II A.3.1. COHAL::AIModule Class Reference . . . . . . . . . . . II A.3.2. COHAL::AOModule Class Reference . . . . . . . . . . . VI A.3.3. COHAL::DIOChannelAddress Class Reference . . . . . . X A.3.4. COHAL::DIOChannelConfig Class Reference . . . . . . XII A.3.5. COHAL::DIOModule Class Reference . . . . . . . . . . XVI A.3.6. COHAL::ICV196 Class Reference . . . . . . . . . . . . . XXII A.3.7. COHAL::VMOD 12A2 Class Reference . . . . . . . . . XXIX A.3.8. COHAL::VMOD 12A2ModuleConfig Class Reference . . XXXV A.3.9. COHAL::VMOD 12E16 Class Reference . . . . . . . . . XXXVIII ´ INDICE GENERAL 5 A.3.10. COHAL::VMOD 12E16ModuleConfig Class Reference . XLIII A.3.11. COHAL::VMOD 16A2 Class Reference . . . . . . . . . XLVI A.3.12. COHAL::VMOD 16A2ModuleConfig Class Reference . . LII A.3.13. COHAL::VMOD DOR Class Reference . . . . . . . . . . LIV A.3.14. COHAL::VMOD TTL Class Reference . . . . . . . . . . LXI B. Fesa Overview LXIX 6 ´ INDICE GENERAL Cap´ ıtulo 1 Introducci´ on En este cap´ ıtulo introducir´ e el entorno en el que se desarrolla este Proyecto de Fin de Carrera. Para ello explicar´ e como se organiza el CERN y sus aceleradores, exponiendo el proyecto en el que se engloba este PFC y las tecnolog´ ıas utilizadas para su desarrollo. Para terminar describir´ e las peculiaridades de este PFC y los objetivos sobre los que se ha trabajado. 1.1. El CERN Este proyecto se realiza en el CERN1, la Organizaci´ on Europea para la Investigaci´ on Nuclear. En ´ el he desarrollado un trabajo de renovaci´ on del sistema de control de los aceleradores, dentro de un proyecto global de renovaci´ on de software y hardware en partes que llevan d´ ecadas funcionando. Para ello he dado soporte a m´ odulos de hardware dentro una interfaz com´ un y he desarrollado aplicaciones para los mismos usando las plataformas desarrolladas en el CERN. El CERN dispone de gran variedad de instalaciones dedicadas a realizar experimentos en f´ ısica de part´ ıculas. La de mayor importancia actualmente es el LHC (Large Hadron Collider), un acelerador de part´ ıculas de 27 kil´ ometros de di´ ametro. En el, tras un a˜ no de funcionamiento, en la actualidad se est´ an realizando 1Siglas en franc´ es de Conseil Europ´ een pour la Recherche Nucl´ e(Consejo Europeo para la Investigaci´ on Nuclear), nombre del consejo provisional creado en 1952 para establecer el laboratorio. Este laboratorio de f´ ısica de part´ ıculas esta situado en la frontera entre Suiza y Francia, a las afueras de Ginebra. El CERN es uno de los centros de investigaci´ on cient´ ıfica mas importantes del mundo, gracias a la colaboraci´ on de sus 20 pa´ ıses miembros, 8 observadores y decenas de colaboradores. 7 8 CAP´ ITULO 1. INTRODUCCI ´ ON experimentos sobre dos haces de protones a 3.5 TeV2, que colisionan a energ´ ıas de unos 7 TeV, lo que convierte al LHC en el acelerador de mayor energ´ ıa del mundo. En los diversos experimentos que se llevan a cabo dentro de este acelerador se espera encontrar el Boson de Higgs3y extender el conocimiento sobre el Big Bang y la cosmolog´ ıa. A parte del LHC en el CERN hay todo un complejo de aceleradores (Figura 1.1) de diferentes tama˜ nos y diferentes energ´ ıas. En ellos se hacen experimentos sobre antimateria, neutr´ ınos, haces de iones etc. Muchos de los aceleradores est´ an interconectados entre si, pues los haces acelerados en unos se usan como entrada para otros aceleradores que requieren las part´ ıculas de entrada con cierta energ´ ıa inicial para poder funcionar. Por lo que los aceleradores conforman una cadena al principio de la cual se encuentran los menos potentes y estos alimentan a aceleradores mas potentes. Por ejemplo para llegar al LHC un haz de part´ ıculas ha atravesado antes cuatro aceleradores distintos. 1.2. Contexto tecnol´ ogico del PFC Una vez puesto en marcha el LHC, que ha focalizado los mayores esfuerzos del CERN en los ´ ultimos a˜ nos, se ha decidido renovar el hardware ysoftware del resto de aceleradores, algunos instalados y en funcionamiento hace d´ ecadas. Para ello se ha creado el proyecto ACCOR (ACcelerator COntrol system Renovation). El proyecto ACCOR se compone de muchos grupos trabajando en diferentes aspectos. Como el grupo de hardware que se encarga de desarrollar drivers y m´ odulos hardware nuevos, o el grupo de aplicaciones que construye aplicaciones para ser usadas por los operadores de los aceleradores. Entre estos dos grupos est´ a el grupo de Front-Ends, que se encarga de crear el software que accede a estos m´ odulos y se comunica con las aplicaciones. En el sistema de control de los aceleradores del CERN hay una gran variedad de m´ odulos, como m´ odulos con entradas y/o salidas anal´ ogicas o digitales, con generadores de se˜ nales etc. Cada m´ odulo tiene caracter´ ısticas y drivers completamente diferentes. Dentro del proyecto ACCOR uno de los desarrollos que se esta realizando consiste en la creaci´ on de una capa de abstracci´ on de hardware llama- 2Tera electronvoltio, unidad de enrg´ ıa equivalente a un electr´ on acelerado por una diferencia de potencial de 1 voltio. 3Part´ ıcula elemental hipot´ etica masiva cuya existencia es predicha por el modelo est´ andar de la f´ ısica de part´ ıculas. Desempe˜ na un papel importante en la explicaci´ on del origen de la masa en otras part´ ıculas elementales. 1.2. CONTEXTO TECNOL ´ OGICO DEL PFC 9 Figura 1.1: Complejo de Aceleradores del CERN Extra´ ıdo del archivo gr´ afico del CERN (http://cdsweb.cern.ch/record/1260465) da COHAL (COntrols Hardware Abstraction Layer). COHAL b´ asicamente es una jerarqu´ ıa de clases C++ que organiza los m´ odulos por familias con similares caracter´ ısticas (como Analog Input o Digital Input Output) mostrando una interfaz uniforme para m´ odulos con caracter´ ısticas parecidas, ocultando las diferencias de drivers, sistemas operativos o arquitecturas. Para la comunicaci´ on con las aplicaciones la secci´ on de Front-Ends desarrolla una plataforma, llamada FESA (Secci´ on 2.3). Con ´ el se crean clases FESA, programas que se ejecutan sobre PCs industriales y que exportan informaci´ on a las aplicaciones a trav´ es de la red interna usando CORBA. FESA autogenera c´ odigo C++ encargado de la comunicaci´ on por CORBA, de la gesti´ on de tareas en tiempo real, coordinaci´ on de procesos paralelos etc. Dentro del proyecto ACCOR se est´ an desarrollando diversas clases FESA, usando COHAL para acceder al hardware. Por cada familia se crea una clase FESA gen´ erica, que permite acceder a la mayor´ ıa de funcionalidades del hardware con la que la mayor´ ıa de los usuarios pueden crear aplicaciones que usen el hardware sin necesidad de desarrollar ninguna clase FESA. A dem´ as de las clases 16 CAP´ ITULO 2. CONTEXTO A lo largo de los a˜ nos de uso se han ido encontrando muchos problemas relacionados con este sistema operativo. Es un sistema privativo, por lo que no se pueden hacer modificaciones en ´ el. Ello obliga al CERN a depender de la empresa que lo soporta para que arregle los problemas que surgen con el, arreglos que en muchos casos nunca llegan a realizarse o cuyas soluciones son parciales. Muchas de las herramientas b´ asicas del sistema, como el compilador de C o las bibliotecas stl de C++ est´ an desfasadas y llenas de errores. Esto obliga a dise˜ nar pensando en c´ omo evitar los problemas que surgen de ellos, teniendo que escribir c´ odigo espec´ ıfico para evitarlos. Adem´ as muchos programas no se puedan compilar sin un gran esfuerzo para portarlos. 2.2.2. Linux Dados los problemas encontrados en LynxOS se ha decidido montar los nuevos sistemas de control basados en Linux6. Este sistema operativo, junto con sus parches de Real Time7, se adapta mucho mejor a las necesidades del CERN. Linux, al ser software libre, permite al CERN adaptarlo si alguna parte no funciona como se espera. Adem´ as es un sistema en activo desarrollo, sus errores se solucionan en poco tiempo. El CERN, junto con el Fermilab8, desarrolla Scientific Linux9una distribuci´ on de GNU/Linux basada en RedHat10. El sistema de control de los aceleradores est´ a basado en esta distribuci´ on, con algunas partes cambiadas, como el n´ ucleo, que se compila con algunas modificaciones como los parches de tiempo real. 2.3. FESA FESA es una plataforma para el sistema de control de aceleradores. El desarrollo lo empez´ o el CERN para su uso interno, pero en la actualidad es usado y desarrollado por GSI11 adem´ as del CERN. 6http://www.kernel.org/ 7http://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html 8Laboratorio de investigaci´ on en f´ ısica de part´ ıculas estadounidense (http://www.fnal.gov/) 9https://www.scientificlinux.org/ 10http://www.redhat.com/ 11Gesellschaft f¨ ur Schwerionenforschung, laboratorio Alem´ an de investigaci´ on de iones pesados. http://www.gsi.de/ 2.3. FESA 17 FESA esta dise˜ nado para crear clases (programas FESA) que se ejecutan en los Front-Ends, accediendo a los m´ odulos de hardware instalados en ´ el, y se comunican mediante CORBA12 con las aplicaciones de control que se ejecutan en otras computadoras. Est´ a compuesto de una serie de herramientas que autogeneran c´ odigo C++ y se encargan de la instalaci´ on de las clases en los Front-Ends. El flujo de trabajo con FESA (Figura 2.1) se compone de cinco fases: Figura 2.1: Flujo de trabajo de FESA Extra´ ıdo de la documentaci´ on de FESA Design. Definici´ on de los diferentes componentes de la clase FESA, como el tipo de eventos que va a tener o la informaci´ on que exporta a las aplicaciones a trav´ es de CORBA. Code. Una vez autogenerado el c´ odigo a partir del dise˜ no hay que programar algunas partes de el mismo. FESA crea clases C++ dejando esqueletos de m´ etodos sin c´ odigo para que el usuario introduzca la l´ ogica en ellos. 12Common Object Request Broker Architecture, plataforma est´ andar de desarrollo de sistemas distribuidos facilitando la invocaci´ on de m´ etodos remotos bajo un paradigma orientado a objetos. 18 CAP´ ITULO 2. CONTEXTO Deliver. En esta fase se almacena el c´ odigo en un CVS13 centralizado disponible para todo el CERN. Adem´ as se compila el c´ odigo guardando los binarios objeto, qu´ e luego ser´ an utilizados para generar las instalaciones en los Front-Ends a trav´ es de la informaci´ on almacenada en la base de datos (Secci´ on 2.1.3). Deploy. A FESA hay que indicarle en que Front-Ends se van a instalar la clase desarrollada y qu´ e tipo de instalaciones se va a hacer. Aqu´ ı FESA se comunica con la base de datos de hardware. Instantiate. El ´ ultimo paso es indicarle a FESA que tipo de dispositivos va a usar la clase FESA. A trav´ es de este paso se le pueden pasar par´ ametros a la clase FESA definidos en su dise˜ no, permitiendo configurar las caracter´ ısticas especificas de cada Front-End. M´ as informaci´ on sobre cada fase del flujo de trabajo de FESA en el Ap´ endice B. 2.4. OASIS OASIS14 (Open Analogue Signal Information System) es un sistema para la adquisici´ on y visualizaci´ on de se˜ nales anal´ ogicas en el dominio de los aceleradores. Las se˜ nales, distribuidas todo alrededor de los aceleradores, son digitalizadas por osciloscopios instalados en Front-Ends. La informaci´ on recogida es enviada a trav´ es de redes Ethernet y mostrada en los puestos de trabajo que ejecutan las aplicaciones dedicadas de OASIS. Cuando el ancho de banda lo permite, las se˜ nales anal´ ogicas son multiplexadas en los canales de los osciloscopios. Teniendo en cuenta que no todas las se˜ nales disponibles son observadas al mismo tiempo, con esta arquitectura se consigue ahorrar digitalizadores, el dispositivo m´ as caro del sistema. Los Front-End son instalados al lado de las fuentes de las se˜ nales, con intenci´ on de preservar la integridad de las se˜ nales en todo lo posible. OASIS proporciona una abstracci´ on de osciloscopio virtual (Vscope). Un Vscope es un osciloscopio por software que recoge la informaci´ on desde diferentes osciloscopios hardware y la muestra como si viniera del mismo m´ odulo. Gracias a esta arquitectura se pueden observar diferentes se˜ nales como si estuvieran unas 13Concurrent Versions System, un sistema de control de versiones. 14http://project-oasis.web.cern.ch/project-oasis/ 2.4. OASIS 19 junto a las otras, mientras que en la realidad pueden estar a distancias de cientos de metros. Por supuesto, para que esto funcione, es necesario tener el mismo pulso de trigger y OASIS debe mantener en sincronizaci´ on los par´ ametros de configuraci´ on usados en las diferentes conexiones dependientes del Vscope. OASIS tiene una arquitectura en tres capas (Figura 2.2). Una capa hardware de osciloscopios y Front-Ends recoge la informaci´ on usando FESA para ello. Por encima se montan los servidores de aplicaci´ on que manejan la informaci´ on que proviene de los Front-Ends. Y conect´ andose a estos servidores de aplicaci´ on la tercera capa est´ an las aplicaciones de OASIS, que se ejecutan en los escritorios de los operadores. OASIS maneja mas de 1800 se˜ nales en todo el complejo de aceleradores del CERN. Permite acceder a ellas de forma uniforme desde cualquier lado de la red del CERN a trav´ es de sus aplicaciones o de las bibliotecas de acceso de OASIS. 20 CAP´ ITULO 2. CONTEXTO Figura 2.2: Arquitectura de oasis Extra´ ıdo de la web de OASIS (http://project-oasis.web.cern.ch/project-oasis/) Cap´ ıtulo 3 COntrols Hardware Abstraction Layer En el sistema de control de los aceleradores del CERN se usa gran variedad de m´ odulos (tarjetas) de hardware. A trav´ es de ellas recibe el estado de las diferentes partes de cada acelerador mediante sensores o se modifica su estado a trav´ es de actuadores. Para dar soporte de forma coherente a los m´ odulos de hardware que se usan en los sistemas de control se ha desarrollado COHAL (COntrols Hardware Abstraction Layer). Es una capa de abstracci´ on de hardware en C++, que agrupa los m´ odulos seg´ un sus caracter´ ısticas en familias, dotando de una interfaz com´ un a m´ odulos con caracter´ ısticas comunes. Cadam´ odulosecomponedeunoovarios canales de entrada y/o salida. COHAL muestra los canales de una forma uniforme entre m´ odulos, usando un direccionamiento com´ un entre m´ odulos, aunque en cada m´ odulo el direccionamiento suele ser diferente. COHAL ademas implementa algunas caracter´ ısticas no presentes en algunos m´ odulos, como por ejemplo readBack1. 3.1. Arquitectura COHAL esta dise˜ nado usando las caracter´ ısticas de orientaci´ on a objetos y meta-programaci´ on con patrones que ofrece C++. Con clases virtuales y herencia se agrupan los diferentes m´ odulos en familias. 1Leer el dato que se ha escrito anteriormente en un canal de salida de un m´ odulo. 21 22 CAP´ ITULO 3. CONTROLS HARDWARE ABSTRACTION LAYER COHAL se compone de un serie de clases gen´ ericas, con herramientas comunes para todas las familias, y cuatro familias de hardware: Digital Input Output. M´ odulos de entrada y salida digital. Analog Input. Conversores de se˜ nales anal´ ogicas a digital. Analog Output. Conversores de digital a anal´ ogico. Function Generator. Generadores de ondas. La mayor parte del dise˜ no de alto nivel (jeraqu´ ıa de m´ odulos y clases) estaba ya definido al comienzo de este Proyecto de Fin de Carrera, pero durante el mismo se ha adaptado la arquitectura de COHAL a las necesidades del proyecto ACCOR, en colaboraci´ on con otros dos desarrolladores de COHAL. Las tres primeras clases que acabamos de listar las he desarrollado completamente desde cero como parte del PFC, y las he mantenido hasta finalizar mi estancia en el CERN. El Ap´ endice A proporciona una referencia del contenido de las tres familias desarrolladas. Cuando se dise˜ n´ o inicialmente se desconoc´ ıan en profundidad los usos que iba a tener la capa de abstracci´ on de hardware. Por este motivo se recurri´ o a un dise˜ no gen´ erico susceptible evolucionar al ir descubriendo necesidades concretas. El Proyecto de Fin de Carrera ha permitido acelerar la evoluci´ on de los interfaces, observando las aplicaciones reales que las iban a utilizar, y las caracter´ ısticas espec´ ıficas de los m´ odulos hardware soportados. En la ´ ultima fase del PFC se ha trabajado en estabilizar las clases, ya que hay varias instalaciones en el complejo de aceleradores y cada cambio supone realizar actualizaciones. 3.1.1. Jerarqu´ ıa de m´ odulos Por cada m´ odulo hardware soportado hay una clase a trav´ es de la cual se puede acceder a toda la funcionalidad del mismo. Estas clases est´ an integradas en una jerarqu´ ıa, siendo todas derivadas de la clase gen´ erica de su familia, la cual es derivada de la clase Module. La Figura 3.1 muestra la jerarqu´ ıa m´ odulos de todas las familias que he desarrollado en el PFC. 3.1.2. Inicializaci´ on del m´ odulo Para inicializar los m´ odulos hay dos jerarqu´ ıas de clases definidas en COHAL: ModuleConfigyChannelConfig.Dependiendo de sus caracter´ ısticascadam´ odu- 3.1. ARQUITECTURA 23 Figura 3.1: Jerarqu´ ıa de clases para los M´ odulos COHAL lo puede no usar ninguna, usar una de las dos o ambas simult´ aneamente. En la inicializaci´ on del m´ odulo se le da informaci´ on a COHAL de c´ omo se va a usar un m´ odulo especifico. Por ejemplo qu´ e canales se van a usar como entrada o como salida, qu´ e voltajes o impedancias va a tener en la entrada. Algunos de estos par´ ametros se configuran por software desde COHAL en el m´ odulo, otros los usuarios tienen que configurarlos a trav´ es de pines en el hardware y luego informar a COHAL de la configuraci´ on que han realizado. La configuraci´ on global del m´ odulo, com´ un para todos sus canales, se hace a trav´ es de clases derivadas de ModuleConfig, que se pasa al m´ odulo a trav´ es del constructor. Puede haber una clase derivada de ModuleConfig por m´ odulo y/o uno gen´ erico de la familia, dependiendo de las caracter´ ısticas comunes o diferentes de cada m´ odulo dentro de la familia. No es obligatorio el uso de ModuleConfig, hay muchos m´ odulos que no necesitan ninguna configuraci´ on, por lo que hay familias y m´ odulos que no tienen definido ninguno. La otra forma de configurar un m´ odulo de las clases derivadas de Channel- Config, las cuales se encargan de la configuraci´ on de los canales del m´ odulo. Por cada canal a configurar se hace una llamada al m´ etodo initChannel con un Chan- 24 CAP´ ITULO 3. CONTROLS HARDWARE ABSTRACTION LAYER nelConfig. Al igual que con ModuleConfig cada familia o m´ odulo puede tener una clase derivada de ChannelConfig o ninguna, dependiendo de si necesita configuraci´ on espec´ ıfica por canal y si esta es com´ un para toda la familia o cada m´ odulo necesita una espec´ ıfica. Como se ha mencionado, la estructura general de estas clases estaba ya definida, y el trabajo en el marco del PFC ha consistido en definir que familias o m´ odulos necesitaban de ellas y que par´ ametros deber´ ıan contener cada una. 3.1.3. Acceso a m´ odulos Para poder acceder a los m´ odulos de forma global se ha aplicado la metodolog´ ıa de dise˜ no Abstract Factory[gamma95], creando una factor´ ıa gen´ erica ModuleFactory (ver Secci´ on 3.3.3) que est´ a instanciada como un miembro est´ atico dentro de la clase de cada familia. Para instanciar o acceder a un m´ odulo se hace a trav´ es la factor´ ıa de su familia, de esta forma que hay un punto ´ unico de entrada a los m´ odulos de una familia. Por este motivo un mismo m´ odulo no se puede instanciar dos veces, si tiene el mismo HWAddress (ver Secci´ on 3.3.1). Cada m´ odulo dispone de un mutex, que lo bloquea en caso de estar accediendo al hardware, por lo que no se puede dar dos accesos concurrentes al mismo m´ odulo hardware. La infraestructura gen´ erica para el acceso a los m´ odulos estaba definida antes delPFC, cuyo cometido ha sido dotar a las clases de funcionalidad en cadafamilia. 3.1.4. Gesti´ on de errores Encasodeerroreslosm´ oduloslanzanexcepciones (descritas en laSecci´ on3.3.4), con informaci´ on sobre el problema encontrado. En caso de que el error afecte al funcionamiento del m´ odulo, de tal forma que ´ este no se pueda usar tras el error, adem´ as de la excepci´ on se activa un indicador interno de la clase Module llamado operationalState.´ Este indica si el m´ odulo esta operativo o no, y en caso de no estarlo conserva una cadena de texto con informaci´ on sobre el error que ha producido. De esta forma en caso de error irreparable se desactiva el m´ odulo a trav´ es del m´ etodo setOperational(). En cada intento de acceso al m´ odulo se comprueba el indicador a traves del m´ etodo isOperational() y en caso de estar activado no se ejecuta la acci´ on, sino que se devuelve un error. 3.2. TEST 25 3.2. Test Cada familia contiene un programa de test. ´ Este es usado para comprobar el funcionamiento de cada m´ odulo y como ejemplo de c´ omo usar la familia COHAL. Los programas de test que se han creado en el PFC para las clases correspondientes son gen´ ericos, permitiendo acceder a toda la funcionalidad de cada uno de los m´ odulos de la familia a trav´ es de opciones pasadas a trav´ es de la linea de comandos. Esto ha permitido en algunos casos usar m´ odulos de salida para generar datos ´ utiles para comprobar las entradas de otros m´ odulos. 3.3. Generic COHAL dispone de una serie de clases gen´ ericas usadas por todos los m´ odulos. En ellas residen funciones para el manejo de cadenas, gesti´ on de excepciones, clases virtuales de las que hereda el resto (Module, ModuleConfig, ChannelConfig, ...), clases de abstracci´ on de hardware etc. Todo esto se compila como una librer´ ıa est´ atica, que se luego se enlazar´ a con el programa que vaya a usar COHAL. Esta librer´ ıa se llama libcohal gen.a. Estapartenohasido objeto del PFC, pero el desarrollo de las clases espec´ ıficas de las que nos hemos ocupado ha puesto en evidencia nuevas necesidades para la librer´ ıa de clases gen´ ericas, y esto ha dado lugar a un estrecho trabajo en equipo para la redefinici´ on de algunas partes. 3.3.1. HWAddress Tal y como se describ´ ıa en la Secci´ on 2.1 en el sistema de control de los aceleradores del CERN hay una gran variedad de hardware. Diferentes tipos de hardware pueden tener diferentes formas de direccionamiento, aunque principalmente se usan el LUN o el Slot (los sistemas de direccionamiento usados en el CERN, explicados en la Secci´ on 2.1.3). Con la intenci´ on de poder acceder a los m´ odu los de una forma uniforme, independientemente del direccionamiento que usen ´ estos, COHAL ha creado HWAddress. Esta clase identifica un m´ odulo hardware tenga el direccionamiento que tenga. 32 CAP´ ITULO 3. CONTROLS HARDWARE ABSTRACTION LAYER bits. 3.5. Analog Input La familia de m´ odulos de entrada anal´ ogica, gestiona conversores de se˜ nales anal´ ogicas a digital. Leen la se˜ nal conectada a la entrada de sus canales, indicando su voltaje o intensidad. Esta familia por el momento solo integra un tipo de m´ odulo, el VMOD-12E16. Est´ a previsto integrar otros m´ odulos en ella por lo que se ha desarrollado de forma gen´ erica para que se pueda adaptar a las necesidades de otros m´ odulos. Figura 3.5: Familia DIO COHAL Las caracter´ ısticas implementadas en toda la familia son: Leer dato. Lee el valor en Voltios/Amperios a la entrada del canal dando un valor num´ erico como resultado. Hace las conversiones pertinentes del valor en bruto proporcionado por la tarjeta al valor real de Voltios o Amperios presente en la entrada. Adem´ as del dato procesado informa del dato en bruto devuelto por el hardware. Ver Ap´ endice A.3.1 para una descripci´ on m´ as detallada. 3.6. ANALOG OUTPUT 33 3.5.1. VMOD-12E16 El VMOD-12E167es un m´ odulo con diecis´ eis canales, configurables como ocho canales diferenciales, con 12 bits de resoluci´ on, configurable para leer rangos de ±5,±10,0−10 V o 0−20 mA. Este m´ odulo se conecta a trav´ es de un conector VMOD (Secci´ on 2.1.4). En caso de configurarse como canales diferenciales mide la diferencia de ten- si´ on o intesidad entre dos canales, sin ninguna intervenci´ on del software. Es programable para que amplifique las entradas pudiendo medir valores muy inferiores. Pero el ruido, descubierto durante las pruebas, destruye gran parte de los datos, por lo que hemos decidido no darle soporte a esta funcionalidad dentro de COHAL. Este m´ odulo es producido por una empresa externa (Janz8), pero sus drivers y bibliotecas han sido desarrollados en el CERN. Los drivers son nuevos y desarrollados solo para Linux. El desarrollo fue bastante sencillo, pues los drivers son estables y sus desarrolladores me han ayudado mucho con todas las dudas y problemas que he ido encontrando. Las pruebas de este m´ odulo las he realizado en conjunci´ on con las del VMOD-12A2 (Secci´ on 3.6.1) y las del VMOD-16A2 (Secci´ on 3.6.2), usando ´ estos para producir se˜ nales senoidales y el VMOD-12E16 para recibirlas, comprobando que cada parte hac´ ıa su trabajo y funcionaba correctamente. 3.6. Analog Output Esta familia de m´ odulos de salida anal´ ogica gestiona conversores de digital a anal´ ogico. Escriben en sus canales la tensi´ on o intensidad indicada. He integrado dos m´ odulos a esta familia: VMOD-12a2 y VMOD-16a2. Las caracter´ ısticas implementadas en toda la familia son: Escribir un dato. Escribir un valor en Voltios/Amperios en la salida del canal. A partir del valor num´ erico de la tensi´ on o intensidad real se calcula el valor en bruto que necesita la tarjeta para generar la salida requerida. Read back. Da la posibilidad de leer el ´ ultimo dato escrito en un canal de salida. Ver Ap´ endice A.3.2 para una descripci´ on mas detallada. 7http://www.janz.de/as/en/modulbus/vmod-12e16.html 8http://www.janz.de/ 34 CAP´ ITULO 3. CONTROLS HARDWARE ABSTRACTION LAYER Figura 3.6: Familia DIO COHAL 3.6.1. VMOD-12A2 El VMOD-12A29es un m´ odulo con dos canales de salida. Con 12 bits de resoluci´ on, configurable para leer rangos de ±5,±10,0−10 Voltios o 0−20, 0−40 miliAmperios. Se conecta a trav´ es de un conector VMOD. Este m´ odulo es producido por una empresa externa (Janz10), pero sus drivers y bibliotecas han sido desarrollados en el CERN ´ unicamente para el sistema operativo Linux. En COHAL no se ha implementado el soporte para salidas en miliAmperios, sino solo para Voltios. Los drivers de este modulo son muy parecidos a los del VMOD-12E16 (Secci´ on 3.5.1), lo que me permiti´ o r´ apidamente estar us´ andolos con fluidez. 3.6.2. VMOD-16A2 El VMOD-16A211 es un m´ odulo con dos canales de salida, similar al VMOD- 12A2. Su principal diferencia es que el VMOD-16A2 dispone de 16 bits de resoluci´ on mientras que el VMOD-12A2 dispone de 12 bits de resoluci´ on. La integraci´ on del VMOD-16A2 en COHAL la he realizado en paralelo con el VMOD-12A2. Al ser dos m´ odulos muy parecidos y tener los dos una biblioteca de acceso similar, el c´ odigo en ambos tiene pocas diferencias. 9http://www.janz.de/as/en/modulbus/vmod-12a2-vmod-12a4.html 10http://www.janz.de/ 11http://www.janz.de/as/en/modulbus/vmod-16a1-vmod-16a2.html 3.7. OTRAS FAMILIAS 35 3.7. Otras familias Aparte de las anteriormente mencionadas en COHAL est´ a la familia Function Generator, encargada de dar soporte a generadores de se˜ nales. Yo no he tomado parte en su desarrollo por lo que no menciono aqu´ ı su contenido. En un futuro se espera ampliar COHAL a˜ nadiendo m´ as familias, que en estos momentos est´ an soportadas por otros tipos de m´ odulos que actualmente se usan a trav´ es de otras herramientas. 36 CAP´ ITULO 3. CONTROLS HARDWARE ABSTRACTION LAYER Cap´ ıtulo 4 Clases FESA FESA, tal y como se describe en la Secci´ on 2.3, es una plataforma para la creaci´ on de programas (clases FESA) para ser ejecutados dentro de los Front- Ends del sistema de control de los aceleradores. Dentro del proyecto ACCOR se est´ an desarrollando diversas clases FESA para sustituir los sistemas de control de los aceleradores m´ as antiguos. Principalmente se desarrollan clases gen´ ericas, que permitan acceder a las funcionalidades de los m´ odulos dadas por COHAL. Para algunas instalaciones con necesidades especiales se desarrollan clases especificas. Como parte de mi aportaci´ on al proyecto ACCOR he desarrollado 3 clases FESA: CGAI, SISL2Watchdog y OasisCursor. Tambi´ en he colaborado en otras 2 clases: CGDIO y OasisRdaClient. 4.1. CGAI Clase FESA gen´ erica de la familia Analog Input (Secci´ on 3.5), que permite acceder a los m´ odulos de dicha familia y a toda su funcionalidad. Con ella cambiando un solo par´ ametro de instanciaci´ on se puede acceder de forma igual a unos u otros m´ odulos de la familia. El desarrollo de esta clase permiti´ o probar la familia AI, y redise˜ nar su interfaz para que tuviera m´ as coherencia con las necesidades de FESA. Esto provoc´ o algunos cambios en la familia mientras se dise˜ naba la clase FESA, como por ejemplo el a˜ nadir soporte para leer el dato de la tarjeta en bruto. Una vez estabilizada la clase CGAI su primera instalaci´ on se ha realizado en un laboratorio de mediciones ambientales. En este laboratorio se est´ an probando 37 38 CAP´ ITULO 4. CLASES FESA sensores y diferentes arquitecturas usando CGAI para sustituir los sensores ambientales de algunos aceleradores. 4.2. CGDIO Clase gen´ erica de la familia Digital Input Output (Secci´ on 3.4). Esta clase se desarroll´ o s´ olo parcialmente, porque aparecieron otras prioridades. El dise˜ no y c´ odigo realizados han quedado en el CERN para ser completados en el futuro. 4.3. SISL2Watchdog SISL2Watchdog es parte de la renovaci´ on del Software Interlock System (SIS) para el LINAC21. SIS requiere un registro persistente para algunos par´ ametros de configuraci´ on, como umbrales, contadores, estados, rangos de tolerancia para los trafos o las fuentes de alimentaci´ on. Es necesario tener estos par´ ametros accesibles para escritura y lectura de forma paralela por las aplicaciones especificas y otras herramientas del sistema de control. Para solucionar esto se ha optado por implementar una clase FESA que implemente este almacenamiento. Adem´ as del registro de par´ ametros de configuraci´ on, hay dos conexiones hardware con el Interlock crate2del LINAC2. Una dedicada a informar del estado del Interlock a las aplicaciones y otra del SIS al Interlock, la se˜ nal keep alive, inform´ andole de que SIS sigue activo. Esta es una se˜ nal peri´ odica. En caso de no presentarse, el Interlock supone que el SIS ha dejado de funcionar y toma las decisiones por s´ ı mismo. Para gestionar la se˜ nal del SIS al Interlock informando que sigue vivo se usa una clase FESA gen´ erica dise˜ nada anteriormente llamada LTIM, haciendo una instalaci´ on de la misma configurada para generar la se˜ nal tal como se requiere. Para el resto, el registro persistente y la recepci´ on de se˜ nales del Interlock crate, se ha decidido implementar una clase FESA especifica. 1El primer acelerador en la cadena, en el que se usan ´ atomos de hidr´ ogeno, y separ´ andolos, se empieza a acelerar sus protones. Ver Figura 1.1 para mas informaci´ on sobre el complejo de aceleradores 2Elemento hardware que se encarga de controlar la salida del LINAC2 a otros aceleradores, en caso de que el haz sea defectuoso lo elimina. 4.3. SISL2WATCHDOG 39 He implementado esta clase FESA especifica partiendo un dise˜ no del sistema dado (Figura 4.1) usando la familia DIO de COHAL (Secci´ on 3.4) para las conexiones hardware. Figura 4.1: Arquitectura del nuevo sistema Originalmente parec´ ıa que iba a ser una clase muy simple y f´ acil de implementar, pero el sistema que se esta reemplazando con esta clase era muy antiguo y sin documentaci´ on. Entender el funcionamiento de las se˜ nales del Interlock crate ha requerido mucho trabajo, y ha supuesto cambiar varias veces el dise˜ no y las especificaciones sobre las que estaba trabajando y rehacer la clase. 40 CAP´ ITULO 4. CLASES FESA Nuestro primer objetivo no era dise˜ nar la clase para usar el LTIM, sino que pretend´ ıamos usar una ´ unica clase para todo usando los m´ odulos de la familia DIO para ello. Tras varias pruebas realizadas mediante un osciloscopio y programas de test que program´ e espec´ ıficamente para ello, descubr´ ı que estos m´ odulos no eran capaces de trabajar a las velocidades requeridas por este sistema, por lo que para producir la se˜ nal de keep alive decidimos optar por un hardware diferente dedicado a producir se˜ nales sincronizadas, y utilizar la clase LTIM para controlarlo. A mi salida del CERN este sistema estaba funcionando en paralelo con el sistema antiguo, en proceso de prueba para verificar que todo funciona bien y decidir si se puede reemplazar el sistema antiguo por el desarrollado en el PFC. 4.4. OasisCursor Mi primera funci´ on en el CERN fue desarrollar la clase OasisCursor, para as´ ı familiarizarme con FESA. Esta clase se enmarca dentro del proyecto OASIS (Secci´ on 2.4), el cual no usa COHAL para acceder al hardware, sino una librer´ ıa propia dise˜ nada con anterioridad. Esta clase recibe datos de OASIS a trav´ es de sus bibliotecas de dispositivos tales como osciloscopios instalados en el mismo Front-End o en otros. Sobre las se˜ nales recibidas calcula varios datos: valor m´ aximo, valor m´ ınimo, media e integral. Puede elegirse la ventana sobre las se˜ nales en las que se quieren calcular estos datos y configurar si se quiere calcular cada cierto n´ umero de se˜ nales recibidas o si se quiere que se calcule cada vez que llega una se˜ nal de sincronizaci´ on del timing del acelerador. Adem´ as cada vez que se reciben datos se puede recibir una o varias se˜ nales en el mismo paquete, dependiendo de c´ omo este configurada la adquisici´ on de datos del m´ odulo. Para los casos en que se reciban varias se˜ nales se han implementado dos algoritmos, uno que primero hace la media de las se˜ nales y luego calcula los datos, y otro que calcula dos datos para cada se˜ nal y hace el promedio. Aunque part´ ı de una clase ya dise˜ nada, tuve que realizar varias modificaciones tanto a lo largo del desarrollo como en su despliegue durante los meses posteriores. Al comunicarme con los futuros usuarios de esta clase fui descubriendo las partes del dise˜ no original que hab´ ıa que retocar para que esta clase se adaptara correctamente a sus necesidades. Al principio se implement´ o un prototipo r´ apido, sin pensar en optimizaciones y usando arrays de C. Esto supon´ ıa un uso excesivo de memoria debido al 4.5. OASISRDACLIENT 41 tama˜ no variable de las se˜ nales, y unos algoritmos poco eficientes. En una de las instalaciones de la clase se descubri´ o que ´ esta no era capaz de recoger datos a la velocidad a la que le llegaban. Por ello desarroll´ e unos programas de prueba que med´ ıan el tiempo consumido para procesar cada se˜ nal y optimic´ e el c´ odigo. La optimizaci´ on consisti´ o en sustituir los arrays por std::vector intentando pasar en todos los lugares posibles el vector como referencia, con lo que consegu´ ı una disminuci´ on dr´ astica en el consumo de memoria. Tambi´ en redise˜ n´ e los algoritmos para minimizar los c´ alculos, con lo que consegu´ ı reducir el tiempo a la quinta parte. 4.5. OasisRdaClient La clase OasisRdaClient es un ejemplo de c´ omo programar un cliente de RDA, protocolo usado por OASIS (Secci´ on 2.4) para intercomunicar los productores de las se˜ nales (osciloscopios) con los receptores de las mismas (clases FESA). Esta clase ya exist´ ıa cuando se comenz´ o el PFC, pero ten´ ıa serios problemas de rendimiento. Mi trabajo con ella consisti´ o en optimizarla, aplicando las mismas t´ ecnicas que hab´ ıa usado con OasisCursor, como medir rendimientos con los programas de prueba, usar estructuras de datos din´ amicas y mejorar los algoritmos. A.3 COHAL Class Documentation III COHAL::AIModule COHAL::VMOD_12E16 Public Member Functions AIModule (const HWAddress &hwAddress) Constructor of the class. virtual ∼AIModule () Destructor of the class. virtual void init (const ModuleConfig &initParams)=0 Initialize the module. virtual std::string getHwVersion () const =0 Get hardware version. virtual void reset ()=0 reset the module virtual void getInputRange (double &min, double &max)=0 Get the input range of the module. virtual double getData (unsigned long channel, long &rawData)=0 Read data on the input of the module. virtual unsigned long getBitResolution (unsigned long channel)=0 bit resolution of the analog input IV AP´ ENDICE A. COHAL REFERENCE MANUAL Static Public Attributes static ModuleFactory<AIModule >Factory Analog Input Factory. A.3.1.1. Detailed Description Common interface for Analog Input modules. A.3.1.2. Constructor & Destructor Documentation COHAL::AIModule::AIModule (const HWAddress & hwAddress) [inline] Constructor of the class. It won’t initialize the module, the method init must be call before use the module. Parameters: hwAddress hardware address class of the module A.3.1.3. Member Function Documentation virtual unsigned long COHAL::AIModule::getBitResolution (unsigned long channel)[pure virtual] bit resolution of the analog input Parameters: channel number of the channel to use, the lowest one is 1 A.3 COHAL Class Documentation V Returns: number of bits of resolution Implemented in COHAL::VMOD 12E16. virtual double COHAL::AIModule::getData (unsigned long channel, long & rawData)[pure virtual] Read data on the input of the module. It is procesed with the input range to return a meaningful value. Parameters: channel number of the channel to use, the lowest one is 1 rawData the data as is readed from the channel Exceptions: ModuleException if there is any problem reading the data Returns: the meaningful data on the input of the module (after apply the input range) Implemented in COHAL::VMOD 12E16. virtual void COHAL::AIModule::getInputRange (double & min, double & max)[pure virtual] Get the input range of the module. Parameters: min minimum value of voltage/ampere that the module can handle max maximum value of voltage/ampere that the module can handle Implemented in COHAL::VMOD 12E16. VI AP´ ENDICE A. COHAL REFERENCE MANUAL virtual void COHAL::AIModule::init (const ModuleConfig & initParams) [pure virtual] Initialize the module. If the constructor was invoked without ModuleConfig this method must be call before use the module. In other case the constructor will initialize the module and this method should not be use. Parameters: initParams configuration of the module Exceptions: ModuleException if there is any problem initializing the module Implemented in COHAL::VMOD 12E16. The documentation for this class was generated from the following files: ai/src/AIModule.h ai/src/AIModule.cpp A.3.2. COHAL::AOModule Class Reference Common interface for Analog Output modules. #include <AOModule.h> Inheritance diagram for COHAL::AOModule:: COHAL::AOModule COHAL::VMOD_12A2 COHAL::VMOD_16A2 A.3 COHAL Class Documentation VII Public Member Functions AOModule (const HWAddress &hwAddress) Constructor of the class. virtual ∼AOModule () Destructor of the class. virtual void init (const ModuleConfig &initParams)=0 Initialize the module. virtual std::string getHwVersion () const =0 Get hardware version. virtual void reset ()=0 reset the module virtual void getInputRange (double &min, double &max)=0 Get the input range of the module. virtual void setData (double data, unsigned long channel)=0 Set data. virtual double readBackData (unsigned long channel)=0 Read back data. virtual unsigned long getBitResolution (unsigned long channel)=0 bit resolution of the analog output Static Public Attributes static ModuleFactory<AOModule >Factory Analog Output Factory. VIII AP´ ENDICE A. COHAL REFERENCE MANUAL A.3.2.1. Detailed Description Common interface for Analog Output modules. A.3.2.2. Constructor & Destructor Documentation COHAL::AOModule::AOModule (const HWAddress & hwAddress) [inline] Constructor of the class. It won’t initialize the module, the method init must be call before use the module. Parameters: hwAddress hardware address class of the module A.3.2.3. Member Function Documentation virtual unsigned long COHAL::AOModule::getBitResolution (unsigned long channel)[pure virtual] bit resolution of the analog output Parameters: channel number of the channel to use, the lowest one is 1 Returns: number of bits of resolution Implemented in COHAL::VMOD 12A2, and COHAL::VMOD 16A2. A.3 COHAL Class Documentation IX virtual void COHAL::AOModule::getInputRange (double & min, double & max)[pure virtual] Get the input range of the module. Parameters: min minimum value of voltage/ampere that the module can handle max maximum value of voltage/ampere that the module can handle Implemented in COHAL::VMOD 12A2, and COHAL::VMOD 16A2. virtual void COHAL::AOModule::init (const ModuleConfig & initParams) [pure virtual] Initialize the module. If the constructor was invoked without ModuleConfig this method must be call before use the module. In other case the constructor will initialize the module and this method should not be use. Parameters: initParams configuration of the module Exceptions: ModuleException if there is any problem initializing the module Implemented in COHAL::VMOD 12A2, and COHAL::VMOD 16A2. virtual double COHAL::AOModule::readBackData (unsigned long channel) [pure virtual] Read back data. Read back the data set on the module. Some modules don’t support this action and will throw an exception. Parameters: channel number of the channel to use, the lowest one is 1 X AP´ ENDICE A. COHAL REFERENCE MANUAL Exceptions: ModuleException if the module can not read data Returns: the voltage set on the module Implemented in COHAL::VMOD 12A2, and COHAL::VMOD 16A2. virtual void COHAL::AOModule::setData (double data, unsigned long channel)[pure virtual] Set data. Set data on the output of the module Parameters: data voltage to set channel number of the channel to use, the lowest one is 1 Exceptions: ModuleException if there is any problem setting the data Implemented in COHAL::VMOD 12A2, and COHAL::VMOD 16A2. The documentation for this class was generated from the following files: ao/src/AOModule.h ao/src/AOModule.cpp A.3.3. COHAL::DIOChannelAddress Class Reference Channel Address. #include <DIOModule.h> A.3 COHAL Class Documentation XI Public Member Functions DIOChannelAddress (unsigned long startChannel, unsigned long end- Channel) Constructor of the class. DIOChannelAddress (unsigned long channel) Constructor of the class. DIOChannelAddress (const DIOChannelAddress &address) Copy constructor. A.3.3.1. Detailed Description Channel Address. Defines a range of channels. If start == end then only one channel is use. The lower valid channel number is 1. A.3.3.2. Constructor & Destructor Documentation DIOChannelAddress::DIOChannelAddress(unsigned long startChannel,unsigned long endChannel) Constructor of the class. Parameters: startChannel the first channel used endChannel the last channel used XII AP´ ENDICE A. COHAL REFERENCE MANUAL DIOChannelAddress::DIOChannelAddress (unsigned long channel) Constructor of the class. Create a Channel Address with a single channel Parameters: channel the channel used DIOChannelAddress::DIOChannelAddress (const DIOChannelAddress & address) Copy constructor. Initialice the class with another channel address Parameters: address DIOChannelAddress The documentation for this class was generated from the following files: dio/src/DIOModule.h dio/src/DIOModule.cpp A.3.4. COHAL::DIOChannelConfig Class Reference Channel configuration of DIO family. #include <DIOModule.h> Public Types type none = 0 channel not configured A.3 COHAL Class Documentation XIX Returns: number of bits of resolution Implemented in COHAL::ICV196, COHAL::VMOD DOR, and COHAL::VMOD TTL. virtual unsigned long COHAL::DIOModule::getData (const DIOChannelAddress & chAddress)[pure virtual] Receive data. Read data from the input of the module Parameters: chAddress channels to use Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type in Returns: the digital value on the input channel Implemented in COHAL::ICV196, COHAL::VMOD DOR, and COHAL::VMOD TTL. virtual void COHAL::DIOModule::initChannel (const DIOChannelAddress &chAddress, const ChannelConfig & initParams)[pure virtual] Initialize channel. Before use it every channel needs to be initialized. If the resolution configured needs more than one physical channel it will start from the channel and use the following channels. Parameters: chAddress to configure XX AP´ ENDICE A. COHAL REFERENCE MANUAL initParams configuration of the channel Exceptions: ModuleException if there is any problem initializing the channel ModuleException if the channel was already configured with diferent ChannelConfig Implemented in COHAL::ICV196, COHAL::VMOD DOR, and COHAL::VMOD TTL. virtual unsigned long COHAL::DIOModule::readBackData (const DIOChannelAddress & chAddress)[pure virtual] Read back data. Read back the last data put on the output of the module Parameters: chAddress channel to use Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out Returns: the digital value on the output channel Implemented in COHAL::ICV196, COHAL::VMOD DOR, and COHAL::VMOD TTL. virtual void COHAL::DIOModule::setBits (const DIOChannelAddress & chAddress, bool data, unsigned long bitMask)[pure virtual] Set bits. Set certain bits on the output of the module A.3 COHAL Class Documentation XXI Parameters: chAddress channels to use data value to set on each bit of the mask bitMask mask of bits to be set Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out ModuleException if bitMask is bigger than the chAddress capacity Implemented in COHAL::ICV196, COHAL::VMOD DOR, and COHAL::VMOD TTL. virtual void COHAL::DIOModule::setData (const DIOChannelAddress & chAddress, unsigned long data)[pure virtual] Set data. Set data on the output of the module Parameters: chAddress channels to use data digital value to set Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out ModuleException if data is bigger than the chAddress capacity Implemented in COHAL::ICV196, COHAL::VMOD DOR, and COHAL::VMOD TTL. XXII AP´ ENDICE A. COHAL REFERENCE MANUAL virtual void COHAL::DIOModule::triggerPulse (const DIOChannelAddress &chAddress, unsigned long bitMask, unsigned long long pulseWidth)[pure virtual] trigger pulse Create a pulse of about pulseWidth length in microseconds. The pulse will never be shorter than pulseWidth, but could be longer than that. From experimental observation: On L865 the maximum error expected is less than 6 microseconds On ppc4 the maximum error expected is less than 15000 microseconds Parameters: chAddress channels to use bitMask mask of bits to be set pulseWidth the time length of the pulse in microseconds Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out ModuleException if bitMask is bigger than the chAddress capacity Implemented in COHAL::ICV196, COHAL::VMOD DOR, and COHAL::VMOD TTL. The documentation for this class was generated from the following files: dio/src/DIOModule.h dio/src/DIOModule.cpp A.3.6. COHAL::ICV196 Class Reference ICV196 class. #include <ICV196.h> A.3 COHAL Class Documentation XXIII Inheritance diagram for COHAL::ICV196:: COHAL::ICV196 COHAL::DIOModule Public Member Functions ICV196 (unsigned long lun, const ModuleConfig &initParams=Module- Config()) Constructor of the class. ICV196 (const HWAddress &hwAddress, const ModuleConfig &init- Params=ModuleConfig()) Constructor of the class. ∼ICV196 () Destructor of the class. void initChannel (const DIOChannelAddress &chAddress, const Channel- Config &initParams) Initialize channel. std::string getHwVersion () const Get hardware version. void reset () reset the module void setData (const DIOChannelAddress &chAddress, unsigned long data) Set data. XXIV AP´ ENDICE A. COHAL REFERENCE MANUAL void setBits (const DIOChannelAddress &chAddress, bool data, unsigned long bitMask) Set bits. void triggerPulse (const DIOChannelAddress &chAddress, unsigned long bitMask, unsigned long long pulseWidth) trigger pulse unsigned long getData (const DIOChannelAddress &chAddress) Receive data. unsigned long readBackData (const DIOChannelAddress &chAddress) Read back data. unsignedlonggetBitResolution(const DIOChannelAddress &chAddress) bit resolution of the analog input A.3.6.1. Detailed Description ICV196 class. The ICV196 is a 12 channels with 8 bit digital input/output board. The channels can be configured as 8, 16 or 32 bits. They are addressed by the first physical channel used. The channels are inverted logic (1=0V, 0=5V) on the hardware, cohal hides that so all the devices of the DIO family will use high voltage for 1 and low voltage for 0. A.3.6.2. Constructor & Destructor Documentation A.3 COHAL Class Documentation XXV ICV196::ICV196 (unsigned long lun, const ModuleConfig & initParams = ModuleConfig()) Constructor of the class. It will initialize the module. Parameters: initParams configuration of the module lun logic unit number of the module Exceptions: ModuleException if there is any problem initializing the module ICV196::ICV196 (const HWAddress & hwAddress, const ModuleConfig & initParams =ModuleConfig()) Constructor of the class. It will initialize the module. Parameters: initParams configuration of the module hwAddress hardware address class of the module Exceptions: ModuleException if the type don’t match ModuleException if there is any problem initializing the module A.3.6.3. Member Function Documentation XXVI AP´ ENDICE A. COHAL REFERENCE MANUAL unsigned long ICV196::getBitResolution (const DIOChannelAddress & ch- Address)[virtual] bit resolution of the analog input Parameters: chAddress channel to use Returns: number of bits of resolution Implements COHAL::DIOModule. unsigned long ICV196::getData (const DIOChannelAddress & chAddress) [virtual] Receive data. Read data from the input of the module Parameters: chAddress channels to use Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type in Returns: the digital value on the input channel Implements COHAL::DIOModule. void ICV196::initChannel (const DIOChannelAddress & chAddress, const ChannelConfig & initParams)[virtual] Initialize channel. A.3 COHAL Class Documentation XXVII Before use it every channel needs to be initialized. If the resolution configured needs more than one physical channel it will start from the channel and use the following channels. Parameters: chAddress to configure initParams configuration of the channel Exceptions: ModuleException if there is any problem initializing the channel ModuleException if the channel was already configured with diferent ChannelConfig Implements COHAL::DIOModule. unsigned long ICV196::readBackData (const DIOChannelAddress & ch- Address)[virtual] Read back data. Read back the last data put on the output of the module Parameters: chAddress channel to use Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out Returns: the digital value on the output channel Implements COHAL::DIOModule. XXVIII AP´ ENDICE A. COHAL REFERENCE MANUAL void ICV196::setBits (const DIOChannelAddress & chAddress, bool data, unsigned long bitMask)[virtual] Set bits. Set certain bits on the output of the module Parameters: chAddress channels to use data value to set on each bit of the mask bitMask mask of bits to be set Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out ModuleException if bitMask is bigger than the chAddress capacity Implements COHAL::DIOModule. void ICV196::setData (const DIOChannelAddress & chAddress, unsigned long data)[virtual] Set data. Set data on the output of the module Parameters: chAddress channels to use data digital value to set Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out ModuleException if data is bigger than the chAddress capacity Implements COHAL::DIOModule. A.3 COHAL Class Documentation XXXV void VMOD 12A2::setData (double data, unsigned long channel) [virtual] Set data. Set data on the output of the module Parameters: data voltage to set channel number of the channel to use, the lowest one is 1 Exceptions: ModuleException if there is any problem setting the data Implements COHAL::AOModule. The documentation for this class was generated from the following files: ao/src/VMOD 12A2.h ao/src/VMOD 12A2.cpp A.3.8. COHAL::VMOD 12A2ModuleConfig Class Reference Configuration of VMOD-12A2 modules. #include <VMOD 12A2.h> Public Types input range neg10 10 = 0 voltage range from -10 to 10 input range 0 10 voltage range from 0 to 10 XXXVI AP´ ENDICE A. COHAL REFERENCE MANUAL input range neg5 5 voltage range from -5 to 5 enum input range {input range neg10 10 = 0, input range 0 10, input range neg5 5 } Input range on the channels of the module. Public Member Functions VMOD 12A2ModuleConfig (input range ran=input range neg10 10) Constructor of the class. VMOD 12A2ModuleConfig (const VMOD 12A2ModuleConfig &config) Constructor of the class. Public Attributes input range range input range of the module A.3.8.1. Detailed Description Configuration of VMOD-12A2 modules. A.3.8.2. Member Enumeration Documentation A.3 COHAL Class Documentation XXXVII enum COHAL::VMOD 12A2ModuleConfig::input range Input range on the channels of the module. Different hardware have different voltages as input configured by the jumpers. Enumerator: input range neg10 10 voltage range from -10 to 10 input range 0 10 voltage range from 0 to 10 input range neg5 5 voltage range from -5 to 5 A.3.8.3. Constructor & Destructor Documentation COHAL::VMOD 12A2ModuleConfig::VMOD 12A2ModuleConfig (input range ran =input range neg10 10)[inline] Constructor of the class. The default value of voltage range if is not set is input range neg10 10, Parameters: ran is the input range that this module uses COHAL::VMOD 12A2ModuleConfig::VMOD 12A2ModuleConfig (const VMOD 12A2ModuleConfig & config)[inline] Constructor of the class. Initialice the class with another config Parameters: config a VMOD 12A2ModuleConfig The documentation for this class was generated from the following files: XXXVIII AP´ ENDICE A. COHAL REFERENCE MANUAL ao/src/VMOD 12A2.h ao/src/VMOD 12A2.cpp A.3.9. COHAL::VMOD 12E16 Class Reference VMOD 12E16 class. #include <VMOD 12E16.h> Inheritance diagram for COHAL::VMOD 12E16:: COHAL::VMOD_12E16 COHAL::AIModule Public Member Functions VMOD 12E16 (unsigned long lun, const ModuleConfig &initParams) Constructor of the class. VMOD 12E16 (const HWAddress &hwAddress, const ModuleConfig &initParams) Constructor of the class. VMOD 12E16 (unsigned long lun) Constructor of the class. VMOD 12E16 (const HWAddress &hwAddress) Constructor of the class. ∼VMOD 12E16 () Destructor of the class. A.3 COHAL Class Documentation XXXIX void init (const ModuleConfig &initParams) Initialize the module. std::string getHwVersion () const Get hardware version. void reset () reset the module void getInputRange (double &min, double &max) Get the input range of the module. double getData (unsigned long channel, long &rawData) Read data on the input of the module. unsigned long getBitResolution (unsigned long channel) bit resolution of the analog input A.3.9.1. Detailed Description VMOD 12E16 class. The VMOD-12E16 is a 16 channel (8 channel if configured as differential), 12 bit analog to digital converters, input board. A.3.9.2. Constructor & Destructor Documentation VMOD 12E16::VMOD 12E16 (unsigned long lun, const ModuleConfig & initParams) Constructor of the class. XL AP´ ENDICE A. COHAL REFERENCE MANUAL It will initialize the module. Parameters: initParams configuration of the module lun logic unit number of the module Exceptions: ModuleException if there is any problem initializing the module VMOD 12E16::VMOD 12E16 (const HWAddress & hwAddress, const ModuleConfig & initParams) Constructor of the class. It will initialize the module. Parameters: initParams configuration of the module hwAddress hardware address class of the module Exceptions: ModuleException if the type don’t match ModuleException if there is any problem initializing the module VMOD 12E16::VMOD 12E16 (unsigned long lun) Constructor of the class. It won’t initialize the module, the method init must be call before use the module. Parameters: lun logic unit number of the module A.3 COHAL Class Documentation XLI VMOD 12E16::VMOD 12E16 (const HWAddress & hwAddress) Constructor of the class. It won’t initialize the module, the method init must be call before use the module. Parameters: hwAddress hardware address class of the module Exceptions: ModuleException if the type don’t match A.3.9.3. Member Function Documentation unsigned long VMOD 12E16::getBitResolution (unsigned long channel) [virtual] bit resolution of the analog input Parameters: channel number of the channel to use, the lowest one is 1 Returns: number of bits of resolution Implements COHAL::AIModule. double VMOD 12E16::getData (unsigned long channel, long & rawData) [virtual] Read data on the input of the module. It is procesed with the input range to return a meaningful value. XLII AP´ ENDICE A. COHAL REFERENCE MANUAL Parameters: channel number of the channel to use, the lowest one is 1 rawData the data as is readed from the channel Exceptions: ModuleException if there is any problem reading the data Returns: the meaningful data on the input of the module (after apply the input range) Implements COHAL::AIModule. void VMOD 12E16::getInputRange (double & min, double & max) [virtual] Get the input range of the module. Parameters: min minimum value of voltage/ampere that the module can handle max maximum value of voltage/ampere that the module can handle Implements COHAL::AIModule. void VMOD 12E16::init (const ModuleConfig & initParams)[virtual] Initialize the module. If the constructor was invoked without ModuleConfig this method must be call before use the module. In other case the constructor will initialize the module and this method should not be use. Parameters: initParams configuration of the module A.3 COHAL Class Documentation XLIII Exceptions: ModuleException if there is any problem initializing the module Implements COHAL::AIModule. The documentation for this class was generated from the following files: ai/src/VMOD 12E16.h ai/src/VMOD 12E16.cpp A.3.10. COHAL::VMOD 12E16ModuleConfig Class Reference Configuration of VMOD-12E16. #include <VMOD 12E16.h> Public Types input range neg10 10 = 0 voltage range from -10 to 10 input range 0 10 voltage range from 0 to 10 input range neg5 5 voltage range from -5 to 5 enum input range {input range neg10 10 = 0, input range 0 10, input range neg5 5 } Input range on the channels of the module. XLIV AP´ ENDICE A. COHAL REFERENCE MANUAL Public Member Functions VMOD 12E16ModuleConfig (input range ran=input range neg10 10, bool isDiff=false) Constructor of the class. VMOD 12E16ModuleConfig (const VMOD 12E16ModuleConfig &config) Constructor of the class. Public Attributes input range range input range of the module bool differential are the channels differential A.3.10.1. Detailed Description Configuration of VMOD-12E16. It handles information about the channel setup, if they are differential or not. A.3.10.2. Member Enumeration Documentation enum COHAL::VMOD 12E16ModuleConfig::input range Input range on the channels of the module. Different hardware have different voltages as input configured by the jumpers. A.3 COHAL Class Documentation LI double VMOD 16A2::readBackData (unsigned long channel)[virtual] Read back data. Read back the data set on the module. Some modules don’t support this action and will throw an exception. Parameters: channel number of the channel to use, the lowest one is 1 Exceptions: ModuleException if the module can not read data Returns: the voltage set on the module Implements COHAL::AOModule. void VMOD 16A2::setData (double data, unsigned long channel) [virtual] Set data. Set data on the output of the module Parameters: data voltage to set channel number of the channel to use, the lowest one is 1 Exceptions: ModuleException if there is any problem setting the data Implements COHAL::AOModule. The documentation for this class was generated from the following files: ao/src/VMOD 16A2.h ao/src/VMOD 16A2.cpp LII AP´ ENDICE A. COHAL REFERENCE MANUAL A.3.12. COHAL::VMOD 16A2ModuleConfigClass Reference Configuration of VMOD-16A2 modules. #include <VMOD 16A2.h> Public Types input range neg10 10 = 0 voltage range from -10 to 10 input range 0 10 voltage range from 0 to 10 input range neg5 5 voltage range from -5 to 5 enum input range {input range neg10 10 = 0, input range 0 10, input range neg5 5 } Input range on the channels of the module. Public Member Functions VMOD 16A2ModuleConfig (input range ran=input range neg10 10) Constructor of the class. VMOD 16A2ModuleConfig (const VMOD 16A2ModuleConfig &config) Constructor of the class. Public Attributes input range range A.3 COHAL Class Documentation LIII input range of the module A.3.12.1. Detailed Description Configuration of VMOD-16A2 modules. A.3.12.2. Member Enumeration Documentation enum COHAL::VMOD 16A2ModuleConfig::input range Input range on the channels of the module. Different hardware have different voltages as input configured by the jumpers. Enumerator: input range neg10 10 voltage range from -10 to 10 input range 0 10 voltage range from 0 to 10 input range neg5 5 voltage range from -5 to 5 A.3.12.3. Constructor & Destructor Documentation COHAL::VMOD 16A2ModuleConfig::VMOD 16A2ModuleConfig (input range ran =input range neg10 10)[inline] Constructor of the class. The default value of voltage range if is not set is input range neg10 10, Parameters: ran is the input range that this module uses LIV AP´ ENDICE A. COHAL REFERENCE MANUAL COHAL::VMOD 16A2ModuleConfig::VMOD 16A2ModuleConfig (const VMOD 16A2ModuleConfig & config)[inline] Constructor of the class. Initialice the class with another config Parameters: config a VMOD 16A2ModuleConfig The documentation for this class was generated from the following files: ao/src/VMOD 16A2.h ao/src/VMOD 16A2.cpp A.3.13. COHAL::VMOD DOR Class Reference VMOD DOR class. #include <VMOD DOR.h> Inheritance diagram for COHAL::VMOD DOR:: COHAL::VMOD_DOR COHAL::DIOModule Public Member Functions VMOD DOR (unsigned long lun, const ModuleConfig &init- Params=ModuleConfig()) Constructor of the class. A.3 COHAL Class Documentation LV VMOD DOR (const HWAddress &hwAddress, const ModuleConfig &init- Params=ModuleConfig()) Constructor of the class. ∼VMOD DOR () Destructor of the class. void initChannel (const DIOChannelAddress &chAddress, const Channel- Config &initParams) Initialize channel. std::string getHwVersion () const Get hardware version. void reset () reset the module void setData (const DIOChannelAddress &chAddress, unsigned long data) Set data. void setBits (const DIOChannelAddress &chAddress, bool data, unsigned long bitMask) Set bits. void triggerPulse (const DIOChannelAddress &chAddress, unsigned long bitMask, unsigned long long pulseWidth) trigger pulse unsigned long getData (const DIOChannelAddress &chAddress) Receive data. unsigned long readBackData (const DIOChannelAddress &chAddress) Read back data. LVI AP´ ENDICE A. COHAL REFERENCE MANUAL unsignedlonggetBitResolution(const DIOChannelAddress &chAddress) bit resolution of the analog input A.3.13.1. Detailed Description VMOD DOR class. The VMOD-DOR is a 2 channel with 8 bit digital output board. Note: VMOD DOR has support for 4 channels of 4 bits, but here is not implemented. The readBack function is implemented by a buffer on memory, VMOD DOR don’t have support for read back. A.3.13.2. Constructor & Destructor Documentation VMOD DOR::VMOD DOR (unsigned long lun, const ModuleConfig & init- Params =ModuleConfig()) Constructor of the class. It will initialize the module. Parameters: initParams configuration of the module lun logic unit number of the module Exceptions: ModuleException if there is any problem initializing the module A.3 COHAL Class Documentation LVII VMOD DOR::VMOD DOR (const HWAddress & hwAddress, const Module- Config & initParams =ModuleConfig()) Constructor of the class. It will initialize the module. Parameters: initParams configuration of the module hwAddress hardware address class of the module Exceptions: ModuleException if the type don’t match ModuleException if there is any problem initializing the module A.3.13.3. Member Function Documentation unsigned long VMOD DOR::getBitResolution (const DIOChannelAddress &chAddress)[virtual] bit resolution of the analog input Parameters: chAddress channel to use Returns: number of bits of resolution Implements COHAL::DIOModule. unsigned long VMOD DOR::getData (const DIOChannelAddress & ch- Address)[virtual] Receive data. Read data from the input of the module LVIII AP´ ENDICE A. COHAL REFERENCE MANUAL Parameters: chAddress channels to use Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type in Returns: the digital value on the input channel Implements COHAL::DIOModule. void VMOD DOR::initChannel (const DIOChannelAddress & chAddress, const ChannelConfig & initParams)[virtual] Initialize channel. Before use it every channel needs to be initialized. If the resolution configured needs more than one physical channel it will start from the channel and use the following channels. Parameters: chAddress to configure initParams configuration of the channel Exceptions: ModuleException if there is any problem initializing the channel ModuleException if the channel was already configured with diferent ChannelConfig Implements COHAL::DIOModule. A.3 COHAL Class Documentation LIX unsigned long VMOD DOR::readBackData (const DIOChannelAddress & chAddress)[virtual] Read back data. Read back the last data put on the output of the module Parameters: chAddress channel to use Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out Returns: the digital value on the output channel Implements COHAL::DIOModule. voidVMOD DOR::setBits (const DIOChannelAddress & chAddress,bool data, unsigned long bitMask)[virtual] Set bits. Set certain bits on the output of the module Parameters: chAddress channels to use data value to set on each bit of the mask bitMask mask of bits to be set Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out ModuleException if bitMask is bigger than the chAddress capacity Implements COHAL::DIOModule. LX AP´ ENDICE A. COHAL REFERENCE MANUAL void VMOD DOR::setData (const DIOChannelAddress & chAddress, unsigned long data)[virtual] Set data. Set data on the output of the module Parameters: chAddress channels to use data digital value to set Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out ModuleException if data is bigger than the chAddress capacity Implements COHAL::DIOModule. void VMOD DOR::triggerPulse (const DIOChannelAddress & chAddress, unsigned long bitMask, unsigned long long pulseWidth)[virtual] trigger pulse Create a pulse of about pulseWidth length in microseconds. The pulse will never be shorter than pulseWidth, but could be longer than that. From experimental observation: On L865 the maximum error expected is less than 6 microseconds On ppc4 the maximum error expected is less than 15000 microseconds Parameters: chAddress channels to use bitMask mask of bits to be set pulseWidth the time length of the pulse in microseconds Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out A.3 COHAL Class Documentation LXVII Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out ModuleException if data is bigger than the chAddress capacity Implements COHAL::DIOModule. void VMOD TTL::triggerPulse (const DIOChannelAddress & chAddress, unsigned long bitMask, unsigned long long pulseWidth)[virtual] trigger pulse Create a pulse of about pulseWidth length in microseconds. The pulse will never be shorter than pulseWidth, but could be longer than that. From experimental observation: On L865 the maximum error expected is less than 6 microseconds On ppc4 the maximum error expected is less than 15000 microseconds Parameters: chAddress channels to use bitMask mask of bits to be set pulseWidth the time length of the pulse in microseconds Exceptions: ModuleException if the channel is not COHAL::DIOChannelConfig::type out ModuleException if bitMask is bigger than the chAddress capacity Implements COHAL::DIOModule. The documentation for this class was generated from the following files: dio/src/VMOD TTL.h dio/src/VMOD TTL.cpp LXVIII AP´ ENDICE A. COHAL REFERENCE MANUAL Ap´ endice B Fesa Overview LXIX LXX AP´ ENDICE B. FESA OVERVIEW LXXI LXXII AP´ ENDICE B. FESA OVERVIEW LXXIII LXXIV AP´ ENDICE B. FESA OVERVIEW