Alicia Rodríguez de la Rosa EL DIRECTOR DEL PROYECTO. Ramón Rodríguez Pecharromán. Rafael Palacios Hielscher. Vº Bº del Coordinador de Proyectos

Transcripción

1 Autorizada la entrega del proyecto al alumno: Alicia Rodríguez de la Rosa EL DIRECTOR DEL PROYECTO Ramón Rodríguez Pecharromán Rafael Palacios Hielscher Fdo: Fecha: Vº Bº del Coordinador de Proyectos Álvaro Sánchez Miralles Fdo: Fecha:

2 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL PROYECTO FIN DE CARRERA WLAB SISTEMA DE CONTROL REMOTO EN TIEMPO REAL DE EQUIPOS DE LABORATORIO AUTORA: ALICIA RODRÍGUEZ DE LA ROSA MADRID, Junio 2006

3 Resumen iii Resumen La idea de la que parte este proyecto es la de permitir acceder al Laboratorio de Control de la Escuela desde Internet. Las posibilidades que ofrece son enormes, ya que una vez implantado sería exportable a otros laboratorios con este mismo formato (un ordenador, que mediante algún programa controla un equipo). De esta forma se convierte el laboratorio en un laboratorio remoto, que es aquel que permite a los usuarios interactuar con los dispositivos reales a través de Internet, a diferencia de un laboratorio virtual que sólo permite las simulaciones. Así, mediante el interfaz de una página web, se pueden cambiar parámetros, realizar experimentos, ver y descargar los resultados tal y como se realiza de manera presencial. El proyecto consta de una web hospedada en el servidor del IIT ( a través de la que se puede acceder a los formularios para fijar los parámetros de los elementos que se controlan, en este caso son: la velocidad de un servomotor y el nivel una cuba. También están disponibles en la misma web documentación sobre las prácticas y los equipos. Figura 1 - Página principal de la web

4 Resumen iv Además, se cuenta con uno de los equipos del laboratorio, un ordenador con Windows XP reservado para el proyecto y permanentemente encendido. Desde la web se le transmiten los parámetros dados a un directorio compartido y se ejecuta Matlab mediante acceso remoto y utilizando instrucciones rsh (usando Services for Unix). Una vez finalizado el ensayo, los resultados y las gráficas se devuelven a la web. Figura 2 Esquema general del proceso del laboratorio remoto De este modo se pueden realizar, tanto las simulaciones, como los ensayos de las prácticas de forma remota, ampliando las posibilidades del laboratorio y permitiendo usarlo de formas inexploradas hasta el momento, como por ejemplo, fuera del horario de la Universidad, o los fines de semana y sobre todo, sin la necesidad de estar personalmente en unas prácticas en las que no es necesario conectar cables o montar circuitos como en otros laboratorios de Electrónica. Los ensayos propuestos se diferencian por su duración. En el servo el ensayo es corto, apenas dura cinco segundos y ese pequeño tiempo permite que se realice entero antes de devolver los resultados. En las cubas el ensayo es muy largo, y es necesario ir mostrando al usuario las gráficas de la evolución de la práctica actualizadas cada cierto tiempo. Otra ventaja es que no es necesario que el usuario tenga Matlab instalado, basta con tener un navegador y conexión a Internet. Un problema que presenta es la imposibilidad de realizar más de un ensayo simultáneo, al sólo disponer de una tarjeta de adquisición de datos. En cambio,

5 Resumen v simulaciones sí pueden hacerse cuantas se quieran, abriéndose tantas sesiones de Matlab como sean necesarias. Figura 3 Resultados de un ensayo con un PID De forma más general sus características son: Disponibilidad: 24 horas al día Accesibilidad: a través de un navegador web y una conexión a Internet Facilidad de uso: sólo son necesarios conocimientos básicos de navegación por Internet y del propio contenido de la asignatura Interfaz de usuario intuitiva: es una página en php con un formulario para introducir los parámetros que no requiere tener que descargar ningún software No es necesario tener Matlab instalado en el ordenador del usuario Permite un único usuario para el ensayo, y múltiples para la simulación Tiene ventajas frente a los métodos tradicionales al no estar limitado por factores espaciales y temporales

6 Resumen vi Summary This project is based on the idea of providing access to the University Control Lab via Internet. It opens new possibilities since it could be exported to other labs sharing a common framework (a software package offering remote control of whatever equipment over Internet) Since the University Lab becomes a remote access Lab (allowing users to interact with real equipment via the Internet), this solution is better than a virtual lab which only provides simulation and not real experimentation. From a Web based interface, users can setup parameters for their experiments, execute them and obtain results in their monitors or even download a file with the resulting data. The Project Web Page is hosted in the ITT s server ( providing access to the application forms that are used to setup the experiments parameters, for this particular project: the speed of the servo and the level of the cube. There are also docs and tutorials available for lab practices and the equipment used. Figura 4 Index of the web page Moreover, the Project has one of the Lab s computers (a PC running Windows XP) fully devoted to this project on a 24 hours basis. The Web Page of the project offers a

7 Resumen vii user interface to gather the information needed and transfer such data to a share disc which is used by Matlab to run remotely (using rsh instructions provided by Unix Remote Services). The results and graphics are finally display in the web page. Figura 5 General view of the remote lab This allows remote simulation and execution of practices, increasing labs possibilities and allowing rationalization and reducing idle lab time, for example after timetable hours or weekends. Most important is the fact that it is not required to be there in person since there is no need to connect cables like in other Labs of Electronics. The proposed experiments are of different duration, the one with the servo is a short one and takes roughly five seconds, allowing the experiment completion and presentation of results immediately. On the other hand, since the cube s experiment takes much more time, the results are displayed from time to time to provide feed-back of its progress. Another advantage is that the user does not need to have Matlab installed in his computer, only a Web Browser and an Internet Connection is required. One major drawback is that it is only possible to execute one experiment at a time, since there is only one data acquisition card installed on the computer; but there is no limit for the number of simulations possible since users can open as many Matlab sessions as required.

8 Resumen viii Figura 6 Results of a practice with a PID control General Features: 24x7 availability Accessibility: via the Internet with a Web browser User Friendly: only basic Internet browsing knowledge and the own subject content Intuitive User Interface: provided by a web page programmed in php which uses forms to obtain data from users. There is no need for any software download Do not need to have Matlab installed in the user computer Only single-user for practice execution and multi-user for simulation Several advantages compared to traditional Lab practices since there are no limits of time or location

9 Índice ix Índice PARTE I - MEMORIA... 1 PRÓLOGO INTRODUCCIÓN Estado del arte Motivación del proyecto Objetivos Recursos empleados PROYECTO WLAB Pasos del proceso Ensayo remoto Control con un timer. Problemas encontrados Control con Booleanas. La solución implementada SERVOMOTOR Ensayo (e_servo) Código de ejecución del ensayo Cambio en los parámetros Simulación (s_servo) CUBAS Ensayo (e_nivel) Simulación (s_nivel) Modelos de simulación Simulación de un control proporcional P o diferencial PD Simulación de un control integral PI y proporcional integral PID 54 5 WLAB, LA WEB DEL PROYECTO El menú Hoja de estilos Secciones de la web SFU SERVICES FOR UNIX Los comandos r... 75

10 Índice x Rsh Rcp WinRsh Control de acceso. Archivo.rhosts Interix Control de acceso. Archivo hosts.equiv Transferencia de archivos por unidades compartidas Otras posibilidades RESULTADOS CONCLUSIONES Futuros desarrollos BIBLIOGRAFÍA PARTE II ESTUDIO ECONÓMICO PARTE III MANUAL DE USUARIO A. CÓDIGO DE MATLAB a. Código del ensayo con el servo (e_servo) b. Código de la simulación en el servo (s_servo) c. Código del ensayo con las cubas (e_nivel) d. Código de la simulación en las cubas con control P y PD e. Código de la simulación en las cubas con control PI y PID f. Hoja de estilos B. INSTALACIÓN DE WINDOWS SERVICES FOR UNIX C. INSTALACIÓN APACHE

11 Índice de Figuras xi Índice de Figuras Fig. 1 Captura del laboratorio remoto de la Universidad Italiana... 4 Fig. 2 Esquema de funcionamiento del proceso... 8 Fig. 3 Esquema de una llamada remota hecha de forma local Fig. 4 Parámetros fundamentales para el funcionamiento de un timer Fig. 5 Imagen guardada con r Fig. 6 Captura del cambio del tamaño del texto al guardar la imagen como jpg Fig. 7 Configuración del Trigger Fig. 8 Captura del figure durante el ensayo Fig. 9 - Servo del proyecto Fig Captura de Simulink del esquema para ensayo Fig Captura de la pantalla de los parámetros del escalón Fig Captura del parámetro de la ganancia...28 Fig Captura de la configuración de un scope Fig Captura de Data archiving Fig Captura del Signal & Triggering Fig Resultado del ensayo Fig A mayor ganancia menor error y mayor sobrepaso Fig A menor ganancia más error pero menos oscilación Fig Cambio de dos parámetros Fig. 20 Ensayo detenido antes de su final Fig. 21 Entrada con pulsos en lugar de un escalón Fig. 22 Esquema de Simulink Fig. 23 Respuesta de la simulación con los parámetros anteriores Fig. 24 Efecto de aumentar la Kp Fig. 25 Imagen de las cubas Fig. 26 Esquema de funcionamiento Fig. 27 Esquema general del ensayo de las cubas Fig. 28 Actualización incorrecta de la gráfica Fig. 29 Simulink del ensayo Fig. 30 Simulink de un control P o PD Fig. 31 Captura del esquema del modelo no lineal Fig. 32 Simulación para un Control P Fig. 33 Simulación para un Control PD Fig. 34 Simulación de un control PD más rápido Fig. 35 Captura de los archivos guardados como resol_cubas 1 y

12 Índice de Figuras xii Fig. 36 Simulink del control PI y PID Fig Control PI Fig. 38 Detalle del error Fig. 39 Control PI con parámetros inadecuados Fig. 40 Control PID Fig. 41 Cola en el control PID Fig. 42 Control PID bajando la I Fig Captura de la página principal en Firefox Fig Captura de pantalla de la página principal con el Explorer Fig Partes en que se estructura la página Fig Efecto del mouse over Fig Diferencias de presentación entre los dos navegadores Fig. 48 Captura de la descripción del servo Fig. 49 Captura de la página de archivos del servo Fig. 50 Formulario de entrada de parámetros Fig. 51 Página con los resultados del ensayo Fig. 52 Comparación de las dos opciones de mostrar imagen Fig Ventana Pop up para mostrar la evolución del ensayo Fig. 54 Captura del final del ensayo de las cubas Fig. 55 Captura de la configuración de SFU Fig. 56 Captura de la configuración de los Simple maps en sfu Fig. 57 Captura de la página web Fig. 58 Captura del formulario de la simulación en las cubas Fig. 59 Captura de los resultados Fig. 60 Captura del formulario Fig. 61 Pantalla de resultados en la web Fig. 62 Posible uso de los resultados Fig. 63 Captura de la ventana pop up de evolución del ensayo Fig. 64 Capturas de la evolución del ensayo Fig. 65 Captura del final del ensayo Fig. 66 Captura de uno de los formularios de la web Fig. 67 Captura de la página de resultados de la web Fig Primera pantalla de instalación Fig. 69 Se selecciona la opción de instalación personalizada Fig. 70 Únicamente hay que instalar la parte de Windows Fig. 71 Selección de Password y group files Fig Configuración de los archivos Password y group Fig. 73 Final de la instalación

13 Índice de Figuras xiii Fig. 74 Primera ventana de instalación Fig. 75 Selección de los dominios Fig. 76 Durante la instalación Fig. 77 Final del proceso

14 PARTE I - MEMORIA

15 Prólogo PRÓLOGO El objetivo de este proyecto es establecer un laboratorio remoto basándonos en el formato de trabajo del Laboratorio de Control, con la singularidad de que los equipos se controlan de forma remota a través de Internet. Esta memoria comienza analizando los pormenores de la configuración de dicho Laboratorio en el Capítulo 2, con el desarrollo de la forma de trabajar con los archivos de Matlab, el control del ensayo mediante una variable booleana y su ejecución de forma local mediante un archivo batch. Se explica también la estructura básica de todos los archivos, tanto los de ensayo como los de simulación. Una vez definido lo anterior se estudia el servomotor: en el Capítulo 3 se tratan sus características y se estudia su ensayo y simulación mediante la respuesta a un escalón. En el capítulo 4 se trata el tema de las cubas, también con su ensayo y simulación, y ofreciendo la posibilidad de probar los distintos tipos de reguladores (P, PD, PI y PID), y al ser ensayo largo, con actualización de los resultados cada cierto tiempo en la web. Con todo eso ya montado y funcionando de forma local se desarrolló la llamada remota para ser capaces de enviar el archivo de parámetros y recibir los resultados de los ensayos. Para ello se recurrió a los Services for Unix (sfu, en el capítulo 6) y tras multitud de pruebas entre las versiones de WinRsh e Interix, se acabó optando por la primera, combinada con el uso de un directorio compartido, visible únicamente desde el ordenador del laboratorio y accesible desde la página web. En el capítulo 5 se explica cómo está desarrollada y estructurada la página web, hospedada en el IIT y que contiene los formularios para realizar los ensayos. Se analiza cómo se trató la integración de la llamada remota en php. Por último, en los Anexos se muestra el código de Matlab de los ensayos y simulaciones y la información sobre las instalaciones de los programas necesarios para el proyecto: los Services for Unix y Apache. Cabe destacar que los capítulos más importantes son el 2 y el 6, al ser los más característicos del proyecto y los que más esfuerzo y tiempo requirieron. En el capítulo 7 aparecen los resultados y para finalizar, en el 8 las conclusiones.

16 Introducción 1

17 Introducción Introducción En este capítulo se van a tratar los aspectos generales de presentación del proyecto para ilustrar lo que ya existe en este campo y los motivos por los que se ha realizado este proyecto. 1.1 Estado del arte La idea de un Laboratorio Remoto (también denominado laboratorio a distancia o telelaboratorio) no es nueva. Desde principios de los 90 se lleva desarrollando, pero ha sido con el auge de Internet cuando se ha visto su auténtico potencial. Este proyecto parte de la idea inicial de los directores de este proyecto: Ramón Rodríguez Pecharromán y Rafael Palacios Hielscher, que pusieron las bases para su desarrollo el año pasado. Sin embargo, existen por tanto otros proyectos similares a éste en su concepto, como son: El ACT, Automatic Control Telelab [5], de la Università degli Studi di Siena, que es el más desarrollado que se ha encontrado al hacer la documentación del proyecto, y de los pocos que está activo y permite ensayar libremente. Fig. 1 Captura del laboratorio remoto de la Universidad Italiana

18 Introducción Los artículos de Dormido [1], constituyen una importante referencia, tanto por sus contenidos como por su prestigio en el campo del Control. Otra referencia destacada [2] explica lo que se debe y no se debe hacer respecto a una web dedicada a la enseñanza. 1.2 Motivación del proyecto La motivación principal de este proyecto es la de desarrollar un modo efectivo de ejecución remota. Los equipos físicos son necesarios para comprobar el funcionamiento de los reguladores diseñados teóricamente, sin embargo, el alumno no hace nada más que darle al botón de ejecutar en Matlab, y en ocasiones tiene que esperar más de una hora como en los ensayos de las cubas- para recoger los datos. Además, en caso de error, o de haber diseñado mal el regulador es necesario volver a empezar con la consiguiente pérdida del tiempo invertido. La posibilidad de prepararlo antes y aprovechar el laboratorio para preguntar al profesor, o la de repetir la práctica después en caso de error, supone una interesante posibilidad. En conclusión, este proyecto abre nuevas vías en el campo de la enseñanza: Sirve de apoyo en las explicaciones teóricas, permitiendo asimilar mejor los conocimientos adquiridos Permite preparar mejor las prácticas o, incluso repetirlas, una vez hechas en el caso de laboratorios presenciales. Posibilita realizar laboratorios remotos es en el caso de cursos a distancia Optimiza el rendimiento y aprovechamiento de las instalaciones existentes

19 Introducción Objetivos El objetivo global del proyecto es el de poner en marcha un laboratorio remoto para permitir el acceso a los equipos físicos a través de Internet. Los objetivos específicos son: La realización de la simulación de un control de velocidad con un motor de corriente continua (servo) El ensayo real (ensayo rápido) del servo La realización de la simulación del control de nivel de agua en un depósito (cubas) El ensayo real (ensayo lento) de las cubas, con la posibilidad de actualizar las gráficas durante el proceso, e incluso cambiar parámetros del ensayo El desarrollo de la llamada remota para ejecutar las prácticas propuestas Todo ello se realizará a través de una página web, y sin necesidad de instalar ningún software específico en el ordenador del usuario. 1.4 Recursos empleados En este proyecto se ha usado fundamentalmente el Laboratorio de Control de la Escuela, con el servo y las cubas. Además, la página web ha sido hospedada en el servidor del IIT. Así mismo, se ha utilizado el software Matlab en su versión (service pack 2) con las toolboxes de control y RWT (Real Time Windows Target), y para el desarrollo de la página web se ha usado el programa Dreamweaver. Ha sido necesario instalar el software de Services For Unix (SFU) y las herramientas de WinRsh para permitir el acceso remoto desde Internet al ordenador del laboratorio. Se ha contado con un disco compartido dentro del servidor web del IIT, que funciona como vínculo entre la página web y el ordenador del laboratorio permitiendo intercambiar archivos entre ellos.

20 Proyecto WLAB 2

21 Proyecto WLAB Proyecto WLAB En este capítulo se van a explicar los principios de funcionamiento de este proyecto a nivel global, es decir, desde que el usuario se conecta a la web hasta que recibe los resultados. A continuación, se ampliará la explicación de la solución desarrollada para la ejecución local, y en posteriores capítulos se tratarán los aspectos de la página web y del acceso remoto al ordenador. 2.1 Pasos del proceso Para poder realizar una práctica es necesario dar una serie de pasos como los esquematizados en la Fig. 2 Fig. 2 Esquema de funcionamiento del proceso Es decir, el usuario desde su ordenador se conecta a Internet y accede a la web del proyecto a través de la dirección Una vez allí accede a la práctica que desea e introduce los parámetros necesarios en el formulario y pulsa Enviar. A partir de ese punto el proceso ya es independiente del usuario.

22 Proyecto WLAB Desde el servidor del IIT se realiza una llamada remota mediante rsh (remote shell) al ordenador del laboratorio, que tiene una IP fija y que le permite el paso por tratarse del único ordenador remoto autorizado a lanzar ejecuciones. El ordenador del laboratorio no está accesible desde Internet de ninguna otra manera. Se ha optado por que sea este el único punto de acceso a la red local de la Universidad por motivos de seguridad, ya que así es el servidor del IIT quien establece la conexión con el equipo del laboratorio. Se transfiere el archivo creado desde la web con los parámetros a un disco compartido, y se ejecuta un archivo.bat que arranca Matlab y el Simulink correspondiente, que se conecta con la tarjeta de adquisición de datos y ésta a su vez con el equipo, que realiza el ensayo. Matlab genera la gráfica y guarda los resultados, que se muestran en la web. Allí el usuario recibe la respuesta a su ensayo pasado un tiempo corto. Si es en el ensayo rápido recibe los resultados finales. Sin embargo, si se trata del largo la gráfica con la respuesta se irá actualizando y, una vez acabado, recibirá todos los datos. Se define como ensayo a la prueba realizada conectando con el equipo y simulación a la realizada únicamente en Matlab. El modelo rápido es aquel que dura unos pocos segundos, y el largo es aquel que dura minutos u horas. 2.2 Ensayo remoto El ensayo remoto consiste en ejecutar un ensayo en Matlab mediante una única orden, y sin la necesidad de estar físicamente delante del ordenador en el laboratorio. Para desarrollarlo se hizo primero de forma local, es decir, creando un archivo.bat con los comandos necesarios para arrancar Matlab, y realizar todo el ensayo automáticamente. Posteriormente se desarrolló la forma de llamar a ese archivo.bat desde la web para arrancar el ensayo, como se explicará más adelante. Para ejecutar Matlab desde línea de comandos basta con escribir matlab estando en la carpeta adecuada, o directamente en el menú Ejecutar del menú de Inicio. Pero existen unos parámetros que permiten determinan el modo en que se arranca: -r: permite especificar el archivo o la función a ejecutar en el directorio de arranque de Matlab o en el que se encuentre al abrirse

23 Proyecto WLAB nosplash: no muestra la pantalla de bienvenida del programa -nodisplay: no muestra la ventana de comandos ni arranca el desktop -nodesktop: no arranca el desktop, usa la ventana actual para poner los comandos y no los guarda en el histórico -nojvm: no arranca el java virtual machine, es decir, no arranca nada que requiera java. Tampoco arranca el desktop Una vez probados dichos parámetros se llega a la conclusión que la opción que necesitamos para arrancar de forma local es la de r, que nos permite llamar al archivo que queremos, en este caso un script de Matlab que contiene todo el código para ejecutar el ensayo o la simulación. La mejor forma de hacer esta llamada es crear un archivo.bat o archivo batch, que contiene una serie de comandos a ejecutar juntos. Por ejemplo el archivo e_servo.bat consiste únicamente en: matlab -r e_servo Lógicamente, para que al ejecutarlo funcione es necesario que el archivo.bat esté en el mismo directorio que el archivo al que llama, ya que esta forma de arrancar Matlab no permite poner rutas. En la Fig. 3 se muestra un esquema de una llamada local hecha de forma externa. Fig. 3 Esquema de una llamada remota hecha de forma local

24 Proyecto WLAB Control con un timer. Problemas encontrados Una vez realizada la llamada remota es necesario crear un script con todo el código de Matlab para gestionar los parámetros dados, arrancar Simulink, hacer el ensayo y guardar el resultado. Existen unas instrucciones específicas en Matlab para conectar con una tarjeta externa y realizar un ensayo, y son [6]: set_param('model_name','simulationmode','external') % Es necesario cambiar el modo a external frente al clásico normal para conectar con la tarjeta set_param('model_name','simulationcommand','connect'); % Una vez que el Simulink está preparado y compilado hay que conectarlo con la tarjeta set_param('model_name','simulationcommand','start'); % Así se inicia el ensayo set_param('model_name','simulationcommand','stop'); % Para detenerlo en caso de que no haya llegado al final set_param('model_name','simulationcommand','disconnect'); % Desconectar de la tarjeta externa El problema que presenta esa secuencia de tareas es que es necesario esperar a que termine el ensayo antes de ejecutar el código referente a los resultados, ya que, lógicamente, no podemos cargar el archivo de datos antes de crearlo. Es decir, es necesario programar alguna forma de espera entre la orden de ensayar y la de pintar las gráficas. La primera idea fue utilizar un timer, que con un tiempo de espera un poco superior al del ensayo, mantuviera el código a la espera hasta concluir el experimento. Esta idea, buena en teoría, resultó ser ineficaz en la práctica, porque daba problemas con el tiempo de simulación del Simulink, que no siempre corría, con el consiguiente bloqueo del programa o error al terminar el tiempo del timer y no encontrar los datos del archivo data_0.mat Los parámetros fundamentales de un timer son: t = timer; get(t) AveragePeriod: NaN BusyMode: 'drop' ErrorFcn: '' ExecutionMode: 'singleshot' InstantPeriod: NaN Name: 'timer-1'

25 Proyecto WLAB ObjectVisibility: 'on' Period: 1 Running: 'off' StartDelay: 1 StartFcn: '' StopFcn: '' Tag: '' TasksExecuted: 0 TasksToExecute: Inf TimerFcn: '' Type: 'timer' UserData: [] get(t, {'StartDelay','Period'}) ans = [0] [1] Fig. 4 Parámetros fundamentales para el funcionamiento de un timer La Fig. 4 muestra el esquema de funcionamiento de un timer y sus eventos principales. Así, cabía la posibilidad de definir un retardo en su arranque (Start Delay), o bien llamar a una función (TimerFcn) que ejecutara un determinado código.

26 Proyecto WLAB Sin embargo, y cómo se ha comentado, no resultó una buena solución. Daba varios tipos de errores, siendo el más habitual que se bloqueara Simulink al no llegar nunca a su tiempo de final de ensayo. Otro error que ocurría era que al detenerlo a veces Matlab lo consideraba todavía en funcionamiento y daba un error como el que sigue, ante el que era necesario reiniciar y recompilar: Error ocurred while executing External Mode MEX-file rtwinext Real Time execution is already running. It is not allowed to start multiple real-time models Vistos estos problemas, se planteó la solución de retrasar el Start delay del timer, o aumentar su retardo, así el resultado fue que devolvía errores antes de que saltara el timer: Error while evaluating TimerFcn for timer time -1 Otra propuesta de solución fue probar a compilar siempre con el comando rtwbuild( servo_lab ), pero lo único que se consiguió era retardar más el ensayo en conjunto, pero con los mismos problemas. Existía la posibilidad de que no se estuvieran cerrando bien los archivos, porque generalmente la primera vez que se arrancaba Matlab en ensayo sí funcionaba, así que se probó a cambiar el bdclose con el que se cerraba el Simulink por un close_system, y también se probó con dos copias del mismo fichero con distintos nombres, para ejecutarlos uno a continuación del otro. Se comprobó que el problema no era que tardara más en cerrarse o se quedaran elementos funcionando por debajo, ya que aún así no funcionaba siempre. Otra instrucción relacionada con los timers y que podía ser de utilidad aquí es la función wait, que permite retener la ejecución del programa. Si se colocara dentro de la función a la que llama el timer, se le podría dar la condición de que no devolviera el control hasta terminar el ensayo. El problema que apareció es que así el timer no devolvía nunca el control.

27 Proyecto WLAB Con el siguiente script Matlab se llama al timer: T = timer('timerfcn',@init_sim, %inicializo start(t) %arranco el timer %%aquí debería volver el timer load data_0 plot(ref(:,1),[ref(:,2) vel(:,2)]) print -djpeg -r50 result disp('fin') bdclose quit El timer llama a la función init_sim, que es la siguiente: function init_sim(obj,event) %timer object callback function disp('hola') servo_lab %set_param('servo_lab','simulationmode','external') %rtwbuild('servo_lab') set_param('servo_lab','simulationcommand','connect') set_param('servo_lab','simulationcommand','start') %set_param('servo_lab','simulationcommand','stop') %set_param('servo_lab','simulationcommand','disconnect') wait(obj) %wait for timer object to stop running (occurs when simulation is finished) evalin('caller', 'stop(obj)') %evalua la expresión en el workspace end Sin embargo, como ya se ha comentado, la ejecución se quedaba bloqueada en el timer y no devolvía el control. Se trató de implantar una función de stop del timer, que se ejecutara mediante la función Evalin dentro de la función de final del timer (StopFcn callback), pero tampoco funcionó.

28 Proyecto WLAB Control con Booleanas. La solución implementada. El siguiente paso que se planteó para solucionar el problema fue estudiar los parámetros de evolución del ensayo que tiene Simulink. Los fundamentales son: SimulationStatus y SimulationTime. Se puede conocer su valor a partir de la instrucción get_param: get_param( servo_lab, ObjectParameters ) get_param( servo_lab, Simulation Status ) get_param( servo_lab, Simulation Time ) El problema era que al ejecutarse todo el código seguido sólo se podían ver los valores finales de ambos parámetros, lo cual no aportaba nada nuevo. Ahí cobró importancia la instrucción pause, ya que dándole como parámetro un valor numérico, permitía obtener una serie de valores dentro de un bucle infinito. Es decir, no detenía la ejecución, si no que al ser declarada como pause(1) ejecutaba el contenido del bucle infinito una vez cada segundo, sin interferir en su ejecución. Un ejemplo claro de esto aparece a continuación: t = timer('timerfcn', 'stat=false; disp(''timer!'')', 'StartDelay',10); start(t) stat=true; while(stat==true) disp('.') pause(1) end delete(t) %se recomienda borrar el timer por si quedan procesos residuales La respuesta de este código es: Timer! >>