"MZSens"

1.0

Por

Pietro Zuccar pzuccar [at] elo [dot] utfsm [dot] cl

Ignacio Ferruzola iferruzolas [at] elo [dot] utfsm [dot] cl

 

Descripción del problema

 

Proporcionar un medio para registrar datos y mejorar la seguridad de los experimentos realizados en el banco de motores del laboratorio de termo fluidos del Dpto. de Mecánica de la USM.

 

 

Análisis de problema

 

 

 

 

En la actualidad en el Departamento de Mecánica, en el banco de motores del laboratorio de termofluidos, no se cuentan con los medios para realizar mediciones controlables y sucesivas, así como la mala obtención de datos de cada una de estas pruebas.

Desde este laboratorio, se realizan pruebas de combustibles de empresas ajenas a la Universidad, lo cual genera un ingreso para la misma.

Tras estos antecedentes, se nota la necesidad de generar un medio para la manipulación y adquisición de datos de una forma confiable y que permita reiterar los experimentos para una mejor comparación de los valores obtenidos. Con esto en mente se genera un proyecto que busca solucionar esta gran problemática y cuyo diagrama vemos a continuación.

 

 

 

En el modulo Cliente, es en el cual nos encontramos con la necesidad de generar un software que nos permita llevar acabo todas las necesidades anteriormente requeridas, junto con las peticiones que el usuario final también requiere.

 

 

–        Generar un entorno agradable e intuitivo para el usuario.

–        Desarrollar un ambiente gráfico para la adquisición de datos.

 

Estos propósitos nos llevan a generar el siguiente esquema de interacción entre el Sistema, el Usuario y el resto de los componentes del sistema, que pasaremos a llamar, Caja de Control.

 

 

sistema

 

 

 

 

Caso de Uso 1

 

•         Nombre: Detener el motor con botón de pánico.

•         Propósito: En caso de una emergencia se debe poder detener el motor a través de un botón de emergencia

•         Actores: Usuario

•         Pre-condiciones: MSP encendida y conexión establecida, motor encendido.

•         Evento: Un accidente o una situación inesperada.

•         Tipo: Manual

•         Flujo Normal de Eventos:

 

1.      Se inicializa el programa.

2.      Se ubica el acelerador en posición de “IGNITION”.

3.      Se da contacto.

4.      Comienza la adquisición de datos.

5.      Ocurre una situación fuera de lo normal o un accidente

6.      El usuario activa el botón de emergencia.

7.      Se detiene el funcionamiento del motor.

 

•         Variante en el flujo normal de eventos:

 

5.A.      Una variable se escapa de los rangos normales.

6.A.           Se comprueba que la variable esté dentro de las que están siendo supervisadas por el sistema de emergencia.

 

5.B.      Se pierde conexión con la MSP.

6.B.      Se reintenta establecer la conexión un numero determinado de veces.

7.B.      Se advierte al usuario del problema. 

 

Caso de Uso 2

 

•         Nombre: Acelerar electrónicamente el motor.

•         Propósito: El sistema debe poder controlar la aceleración del motor, permitiendo fijar la posición del acelerador en porcentajes desde un 0% hasta un 100%.

•         Actores: Usuario

•         Pre-condiciones: MSP encendida y conexión establecida, motor encendido.

•         Evento: El usuario mueve el control del acelerador, aumentando o disminuyendo su valor.

•         Tipo: Manual

•         Flujo normal de eventos:

 

1.      Se inicializa el programa.

2.      Se ubica el acelerador en posición de “IGNITION”.

3.      Se da contacto.

4.      Comienza la adquisición de datos.

5.      El usuario mueve el deslizador del acelerador.

6.      El comando se transmite a la MSP.

7.      El motor es acelerado por el servomotor.

 

•         Variante en el flujo normal de eventos

 

6.A. Se pierde la conexión de la MSP

7.A. El servomotor baja a la posición de 0%

8.A. Se advierte al usuario de la perdida de conexión

 

Pruebas

 Se realizaron varias pruebas de conexión y de los sistemas de corte en caso de fallo. Entre las pruebas realizadas están:

1.      Falla de alimentación en la MSP.

2.      Falla de alimentación en el PC principal.

3.      Saturación de la red.

4.      Falla mecánica del servo motor.

Además se realizaron pruebas de medición, contrastándolas con el sistema existente anteriormente.

A partir de los resultados de las pruebas nos dimos cuenta de lo siguiente:

1.      Cuando la red estaba saturada  muchos comandos llegaban de golpe y el motor actuaba erráticamente.

2.      En caso de corte de energía es necesario entrar en la cámara para detener el motor.

3.      El servo puede salirse del rango de trabajo si no se encuentra bien anclado y acelerar en vez de frenar el motor.

4.      No es posible asegurar la confiabilidad de la MSP si no está conectada al computador.

5.      La MSP es afectada por el ruido eléctrico generado por el freno de cargas parasitas del motor.

Luego de un análisis aplicamos las siguientes soluciones.

1.      Aplicamos un “smooth” a los comandos de aceleración para hacer la curva más suave.

2.      Montamos el servo haciendo fuerza contra un resorte, el cual en caso de corte llevara el acelerador a la posición 0.

3.      Aplicamos topes físicos a la palanca sobre la que actual el servo.

4.      Si la MSP pierde la conexión, espera un tiempo determinado y luego detiene el motor.

5.      Los cables fueron blindados y la MSP será puesta dentro de una caja aislada.

Aún hay un problema de rendimiento en la interfaz debido a una implementación sub-optima de los semáforos y threads. Es fácilmente solucionable.

 

Código fuente. Descargue aquí.

Archivo de configuración para DOXIGEN aquí.

 

Generado el Wed Jul 1 11:26:18 2009 para "MZSens" por  1.5.9