"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.
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