DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTICS (OBD-II) ALUMNO: OSCAR RAYO MANSILLA DIRECTOR: JORDI SELLARÈS GONZÁLEZ

Tamaño: px
Comenzar la demostración a partir de la página:

Download "DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTICS (OBD-II) ALUMNO: OSCAR RAYO MANSILLA DIRECTOR: JORDI SELLARÈS GONZÁLEZ"

Transcripción

1 DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTICS (OBD-II) ALUMNO: OSCAR RAYO MANSILLA DIRECTOR: JORDI SELLARÈS GONZÁLEZ 4 DE JUNIO DE 2009

2 2

3 ÍNDICE 1. Introducción Justificación del proyecto Antecedentes Objetivos Alcance del proyecto Descripción general del proyecto Descripción básica del hardware Descripción básica del software Diseños realizados Metodología utilizada Recursos utilizados Descripción del diseño del modem interface Descripción del diseño del programador JDM Modificaciones del diseño del modem Diseño de la aplicación de prueba en C Diseño de la aplicación de prueba en JAVA Diseño de la aplicación gráfica diseñada en JAVA

4 3. Resultados Ámbito de utilización Validación de los diseños Descripción del funcionamiento Aplicaciones del proyecto Comentarios finales Plan de trabajo Lista de materiales Presupuesto Objetivos logrados Conclusiones Mejoras futuras Bibliografía Anexo 74 4

5 1. Introducción 1.1. Justificación del proyecto La motivación principal de este proyecto es llegar a poder diseñar un sistema con el que poder diagnosticar las posibles averías de cualquier vehículo sin tener que recurrir a los costosos servicios oficiales. Normalmente cuando se nos avería el coche siempre tenemos que acabar recurriendo a los talleres de reparación de los cuales dispone el fabricante de nuestro vehículo, y aunque desconocemos cuales son los medios de los que disponen para diagnosticar la avería, si sabemos que existe un herramienta que conectándola al vehículo averigua el problema al instante. Esto se debe a que estas marcas tan famosas equipan nuestros coches con sistemas electrónicos capaces de gestionar toda la mecánica y electricidad de que dispone, sin más ayuda que la de un modulo electrónico. En realidad estos módulos no son más que una pequeña computadora a la cual si se conoce su funcionamiento se puede acceder aunque su fabricante intente taparlo, cosa que no les es posible ya que desde hace ya bastantes años están obligados a implementar un estándar de autodiagnóstico llamado OBD-II, que se hizo público a consecuencia de las grandes emisiones contaminantes a las que estamos expuestos, implantando así un mecanismo de control de estas. Estos módulos son el objetivo de este proyecto, ya que en el momento que podamos comunicarnos con ellos podremos saber que le ocurre a nuestro coche y por tanto cuando tengamos que acudir al taller nosotros sabremos, en parte, si nos están estafando, cosa que lamentablemente a veces pasa. 5

6 1.2. Antecedentes OBD (On Board Diagnostics) es un sistema de diagnóstico a bordo en vehículos (coches y camiones). Actualmente se emplea OBD-II (Estados Unidos), EOBD (Europa), y JOBD (Japón) estándar que aportan un control casi completo del motor y otros dispositivos del vehículo. OBD II es la abreviatura de On Board Diagnostics (Diagnóstico de Abordo) II, la segunda generación de los requerimientos del equipamiento autodiagnosticable de abordo de los Estados Unidos de América. Las características de autodiagnóstico de a bordo están incorporadas en el hardware y el software de la computadora de abordo de un vehículo para monitorear prácticamente todos los componentes que pueden afectar las emisiones. Cada componente es monitoreado por una rutina de diagnóstico para verificar si está funcionando perfectamente. Si se detecta un problema o una falla, el sistema de OBD II ilumina una lámpara de advertencia en el cuadro de instrumentos para avisarle al conductor. La lámpara de advertencia normalmente lleva la inscripción "Check Engine" o "Service Engine Soon". El sistema también guarda informaciones importantes sobre la falla detectada para que un mecánico pueda encontrar y resolver el problema. En los Estados Unidos de América, todos los vehículos de pasajeros y los camiones de gasolina y combustibles alternos a partir de 1996 deben contar con sistemas de OBD II, al igual que todos los vehículos de pasajeros y camiones de diesel a partir de 1997, en Europa a partir del año 2001 se obliga implantar el estándar EOBD. Además, un pequeño número de vehículos de gas fueron equipados con sistemas de OBD II. Por tanto la pregunta ahora es, qué fue OBD I? OBD I fue la primera regulación de OBD que obligaba a los productores a instalar un sistema de monitoreo de algunos de los componentes controladores de emisiones en automóviles. Obligatorios en todos los vehículos a partir de 1991, los sistemas de OBD I no eran tan efectivos porque solamente monitoreaban algunos de los componentes relacionados con las emisiones, y no eran calibrados para un nivel específico de emisiones. Y además, qué es EOBD? EOBD es la abreviatura de European On Board Diagnostics (Diagnóstico de a Bordo Europeo), la variación europea de OBD II. Una de las diferencias es que no se monitorean las evaporaciones del depósito. Sin embargo, EOBD es un sistema mucho más sofisticado que OBD II ya que usa "mapas" de las entradas a 6

7 los sensores expectadas basados en las condiciones de operación del motor, y los componentes se adaptan al sistema calibrándose empíricamente. Esto significa que los repuestos necesitan ser de alta calidad y específicos para el vehículo y modelo. Todos los estándares antes mencionados implementan varios modos de trabajo, es decir, según la parte de información a la que queramos acceder necesitamos utilizar un modo diferente, dentro de cada uno de ellos podemos usar un abanico de parámetros muy amplio. Los modos de trabajo más extendidos son los siguientes: Modo 01: Se utiliza para determinar qué información del modulo electrónico (ECU) está a disposición de la herramienta de exploración. Modo 02: Muestra los llamados en este contexto Freeze Frame Data, es decir, capturas puntuales de información que ha ido almacenado la ECU. Modo 03: Lista los posibles fallos producidos en la mecánica mediante códigos de error identificativos (DTC). Modo 04: Se utiliza para borrar los códigos de error almacenados (DTC) y los datos Freeze Frame Data. Modo 05: Muestra los valores tomados a los sensores de oxigeno y los resultados de los test que les ha realizado de forma autónoma la ECU. Modo 06: Se usa para obtener los resultados de los test realizados por la ECU al sistema de monitoreo no continuo. Existe normalmente un valor mínimo, máximo y actual de cada uno de los test. Modo 07: Se usa para solicitar resultados al sistema de control permanente. Este modo lo suelen utilizar los técnicos después de una reparación del vehículo, y después de borrar la información de diagnóstico para ver los resultados de las pruebas después de un solo ciclo de conducción, determinando si la reparación ha solucionado el problema. Sólo hay tres monitores continuos identificados: combustible, fallo de encendido, e integridad de los componentes. En este proyecto solo se va ha hacer uso del modo 01, 03 y 04, aunque teniendo en cuenta que el modo 01 dispone de más de 60 PID s diferentes, no es poco el trabajo a desarrollar. 7

8 Actualmente ya existen muchas herramientas y software disponible para poder llevar a cabo la inspección de un vehículo dotado de OBD-II. Existen muchos tipos de herramientas distintas, pero principalmente la gran diferencia entre ellas es si pueden o no trabajar de forma autónoma, es decir, si necesitan o no ser ejecutadas en un ordenador personal bajo un sistema operativo. Como ejemplo podemos encontrarnos el software llamado ScanMaster, el cual se puede utilizar de forma completa previo pago de una pequeña cantidad de dinero: 8

9 También podemos encontrar el software ScanTool.net, el cual ha sido de mucha utilidad para este proyecto ya que en una de sus versiones ofrece el código fuente con el que fue diseñado: Estos programas están diseñados para trabajar junto con el microcontrolador ELM327, es decir, necesitan de este elemento intermedio entre el PC y el vehículo. Existen en el mercado muchos modelos de interface disponibles en el mercado, pero todas se basan en este micro. A continuación podemos ver algunos ejemplos: Interface ELM327 9

10 Interface ELM327 Interface ELM327 con Bluetooth En las imágenes vemos que los modelos tienen diferentes formas y diferentes métodos de conexión, ya que en uno de los casos se realiza por bluetooth, pero su funcionamiento respecto al estándar OBD-II es idéntico Objetivos Este proyecto abarca una pequeña parte del complejo campo de la autodiagnosis en la automoción, y por tanto no pretende crear un sistema que pueda substituir a las avanzadas herramientas de las que dispone cualquier servicio de manteniendo, ya que el estándar OBD-II, aun siendo de libre acceso, comprende modos de trabajo de los cuales no se tiene información en este proyecto. Mucha de la documentación que engloba al OBD-II está disponible previo pago a las respectivas empresas que lo han diseñado y estandarizado, como es el caso de la Sociedad Americana de Ingenieros (SAE) o la Organización Internacional para la Estandarización (ISO). Aun no disponiendo de toda la información deseada los objetivos de este proyecto son bastante ambiciosos y se pueden listar como sigue: Conseguir una comunicación estable con cualquier centralita electrónica (ECU) de cualquier vehículo equipado con OBD-II. Conseguir desarrollar una aplicación portable a cualquier sistema operativo y plataforma utilizando lenguaje JAVA y la estructura de programación por capas. 10

11 Realizar mejoras en el hardware ya existente en el mercado a partir del cual se construirá nuestra interface. Demostrar que con la información disponible en la red, es posible acceder a los sistemas de control que implementan los fabricantes de automóviles en sus vehículos Alcance del proyecto El alcance de este proyecto incluye la creación de un sistema que implementa una parte de las grandes posibilidades que ofrece el OBD-II, pudiéndose usar como una herramienta orientativa a la hora de diagnosticar una posible avería. Este sistema utiliza por un lado un modem interface que adecua las señales procedentes de la centralita electrónica que se encuentra en el vehículo (ECU), a las señales que necesita un puerto USB de cualquier ordenador. A partir de aquí, un software de control gestionara toda la información recibida. Muchos de los métodos de diagnostico existentes utilizan este planteamiento pero ninguno de ellos, por lo menos oficialmente, utiliza una aplicación desarrollada en JAVA que, por lo tanto, permita ejecutarse en la mayoría de los sistemas operativos existentes, incluyendo el famoso Linux y además en diferentes tipos de plataformas. Para desarrollar el hardware se utilizaran diseños de interfaces ya existentes a partir de los cuales se creará la que se utilizara en este proyecto, es decir, se recapitularan los esquemas eléctricos de los que se dispongan y sobre el PCB elegido se añadirán las posibles mejoras que pudieran aportar otros diseños. Esta parte del trabajo también conlleva la construcción y puesta en marcha de un programador de microcontroladores, necesario para implementar el firmware a partir del cual el micro utilizado en la interface funcionará. Po otro lado el software ha desarrollar tiene un papel igual o más importante, ya que para conseguir diseñar la aplicación de control sobre el modem interface, se necesitan realizar los primeros programas de prueba que servirán para constatar las bases del funcionamiento de la última y definitiva aplicación que interactuará con el modem. Este último programa constará de diferentes apartados y opciones en un entorno visual que mostrará los resultados de una forma fácilmente comprensible dejando así todo el proceso de cálculo en segundo plano. 11

12 1.5. Descripción general del proyecto En este proyecto como se ha ido comentado a lo largo de este documento se pretende elaborar un sistema capaz de comunicarse con la electrónica que gestiona cualquiera de los vehículos dotados con el estándar OBD-II, y para llevarlo acabo ha sido necesario trabajar sobre diferentes aspectos que están involucrados en el proceso de comunicación. Por tanto principalmente existen dos partes importantes a diferenciar en el desarrollo de este proyecto: La parte que engloba el hardware necesario, que nos es más que un modem interface que hace de intérprete entre la centralita electrónica del automóvil (ECU), y el puerto USB de un ordenador personal. La parte que engloba el software, que se refiere a la aplicación que funcionará en el PC y que gestionará el modem interface a partir de los datos que se vallan recibiendo y enviando atreves del puerto USB Descripción básica del hardware (Modem interface) Para diseñar el modem interface se recurrió a diseños ya existentes y de libre disposición en la red, con el fin de conseguir construir una interface que aportase las mejoras que de forma individual cada diseño implementa. Esta interface contiene como elemento principal un microcontrolador (PIC18F2550) que es el encargado de gestionar la comunicación entre los dos periféricos en cuestión, es decir, recoge la información que obtiene del puerto USB y la interpreta según el protocolo en que se esté comunicando con la ECU. Esto se debe a que el estándar OBD-II implementa 4 posibles protocolos en su capa física, SAEJ1850PWM, ISO 9141/14230, J1850 VPW, ISO (CAN). Para que el micro pueda realizar estas funciones se dispone además de un firmware que implementa las capacidades antes descritas, lo que lleva por tanto a realizar su grabación en el micro, y además a la construcción de un programador con el cual realizar este proceso. Otro aspecto importante a resaltar es la necesidad de construir un cable específico para realizar la conexión entre la ECU y la interface durante las primeras pruebas, ya que las centralitas electrónicas disponen de un conector exclusivo para este uso, y por tanto es muy difícil de encontrar en el mercado material compatible. 12

13 1.5.2 Descripción básica del software (Interface Visual) Para realizar la aplicación que gestionará el modem y todos los datos que serán enviados y recibidos a través de él, se deben realizar primero unos pasos previos para poder familiarizarse con las rutinas que deberemos utilizar. Como inicio de este proceso se debe comenzar por averiguar cuál es el mecanismo que siguen otras aplicaciones que ya implementan este mecanismo, y para poder hacerlo existe una aplicación, mencionada anteriormente (ScanTool), que ofrece el código fuente mediante lenguaje C++. A través de este código es posible extraer las rutinas básicas con las que se realiza la comunicación con el micro y la ECU, esto permite que nosotros mismos realicemos un programa de prueba con el que observar cual es la estructura básica que debemos seguir. Debido a que el objetivo es realizar el software utilizando JAVA, ya que nos permitirá hacer portable nuestro trabajo a diferentes plataformas, el programa anterior no es aun suficiente para poder afrontar la implementación de la aplicación definitiva, y por tanto es necesario realizar otro programa de prueba que contenga la misma estructura que el anterior pero con código JAVA. Para poder llevar a cabo este objetivo es necesario utilizar la librería RXTXcomm como librería nativa para realizar las comunicaciones por los puertos serie, ya que los medios que ofrece la API de Java respecto a este tipo de comunicaciones están obsoletos. Una vez sabemos utilizar los recursos existentes de Java, se puede empezar a desarrollar el software que nos ofrecerá las opciones y características que queremos implementar en la aplicación definitiva. El objetivo es que el programa pueda permitirnos, a través de una interface visual, realizar las siguientes tareas: Opciones para poder configurar los parámetros del puerto serie según convenga. Opciones para poder seleccionar los protocolos de comunicación que sean necesarios según el vehículo. Realizar lectura de códigos de error que pueda tener almacenados la centralita electrónica del automóvil. Realizar lecturas a tiempo real de los datos que aportan los diferentes sensores del motor del vehículo, rpm, velocidad, carga del motor, etc. Disponer de una consola de texto que monitoree el puerto serie refrescando su contenido según el estado del tráfico de datos entre el PC y el modem interface. 13

14 2. Diseños 2.1. Metodología utilizada Durante el desarrollo de este proyecto se ha seguido en parte la filosofía de la ingeniería inversa para alcanzar algunos de los objetivos, aunque también se han seguido las pautas de diseños anteriores de disponibilidad libre que realizan las mismas funciones, ya que encontrar cual es el camino que se sigue para realizar los procesos adecuadamente en un sector tan cerrado tecnológicamente como el del automóvil puede llegar a ser muy desesperante. Este proyecto consta principalmente de un parte de software y otra de hardware. En lo que hace referencia a la parte física, es decir, el hardware, se ha utilizado un diseño de libre uso disponible en la red, a partir del cual se construye básicamente la interface. Este aparato también se comercializa actualmente con el nombre de ALLProAdapter por la empresa OBDDiag.net y es una versión compatible de otra interface llamada ELM327, que originalmente es utilizada por muchos software disponibles de pago, y del cual también se disponen de los diseños electrónicos, los cuales también se han aprovechado para realizar el diseño final de la circuitería del modem interface basado en el PIC18F2550. El primer paso ha sido comprobar que los programas que existen como antecedentes funcionen correctamente sobre el hardware montado. De esta manera se tiene la garantía de que el hardware (interface con PIC18F2550 con conexión USB), funciona correctamente y de que los programas en los que nos basaremos para la realización del proyecto son funcionales. De no ser así, podríamos basarnos en herramientas que no serian útiles. Una vez verificados estos puntos, el primer objetivo siempre ha sido conseguir efectuar algún tipo de comunicación con el dispositivo (PIC18F2550) desde el PC, ya que uno de los problemas comunes a todos los dispositivos de este tipo es conocer la forma de comunicarse desde el nivel más básico, es decir, constatar que el micro controlador reacciona o contesta de alguna manera delante de un estimulo producido mediante una línea de comunicaciones digital. Existe un software para el diagnostico de vehículos llamado ScanTool.net, que en una de sus versiones ofrece el código fuente, muy útil para el propósito de este proyecto. Este programa ha sido, para este proyecto, la base para poder iniciar la búsqueda de los pasos que se siguen a la hora de realizar una comunicación desde el PC hasta la centralita electrónica del vehículo, atreves del puerto de comunicaciones serie. 14

15 Además del software de control y el hardware a controlar hay que tener en cuenta que los microcontroladores necesitan un driver para que el sistema operativo que lo gestiona pueda controlarlo. Dado que el PIC18F2550 lo fabrica la compañía Microchip, se pensó en que posiblemente esta proporcionara su driver, y aunque así es, lo proporciona mediante la instalación de un paquete de herramientas llamado USB Framework package, el cual obliga a instalar además del driver muchas otras utilidades que en principio no son necesarias para este caso. La empresa que ofrece libremente la información para montar la interface, OBDDiag.net, también proporciona el driver que se necesita, en forma de fichero INF, y es suficiente para que Windows XP o Vista la detecte sin problemas. También se pudo averiguar que en otros sistemas operativos, como por ejemplo Linux, este microcontrolador está contemplado y en las mismas distribuciones de Linux ya se incorpora el driver necesario. Por tanto, después de montar la interface y verificar su funcionamiento mediante el software ya existente, se procedió a intentar una comunicación utilizando recursos propios, es decir, sin recurrir a la funcionalidad de los programas anteriores. Utilizando el código fuente antes mencionado, el cual se basa en C++, se diseño un programa de prueba que conseguía comunicarse de forma básica con el microcontrolador, pero que aportó mucha información para realizar el proyecto. Una vez lograda la comunicación se procedió a intentar obtener el mismo resultado pero utilizando la plataforma Java. Básicamente el programa de prueba en este caso tiene la misma estructura que en C++, pero utilizando los recursos de los que dispone Java. El paso más importante aquí fue encontrar que métodos utiliza Java para comunicarse con el puerto Serie, y aunque los que proporciona Sun Microsystems, empresa diseñadora de esta plataforma de programación, están obsoletos, no fue difícil encontrar otros actualizados y perfectamente compatibles con su máquina virtual. Esta funcionalidad la proporciona el paquete RXTXcomm junto con la instalación de la maquina virtual de Java. Como último objetivo se planteó realizar un software que ofreciese muchas más funcionalidades de configuración sobre la interface, utilizando un entorno grafico y mucho mas intuitivo. Este software engloba toda la capacidad de comunicación de los programas anteriores pero añadiendo todo el potencial que ofrece un entorno visual diseñado con java, lo cual dota al programa de muchas opciones de configuración y operatibilidad sobre la interface y por tanto sobre la centralita electrónica de cualquier vehículo, que, al fin y al cabo, es lo que se pretende controlar. 15

16 2.1 Recursos utilizados Para realizar este proyecto se han utilizado recursos de diferente tipo según si nos referimos a la parte de software o a la de hardware, pero siempre recurriendo como fuente principal de información a la que se dispone en la red. Para montar la interface se recurrió a la web OBDDiag.net, donde se describen todos los materiales, software, firmware del micro y diseño del PCB necesarios para construirla. Paralelamente también se sacó información de la web ELM Electronics, donde mediante los datasheet que ofrecen (ELM327DS.pdf y ELM320DS.pdf), describen como fabricar un interface para conectarse a la centralita electrónica (ECU) de cualquier vehículo utilizando los microcontroladores que ellos suministran. El datasheet ELM327DS, es el documento que expone todas las posibles ordenes y respuestas que se reciben y envían al modem interface ELM327 y por tanto también al microcontrolador que se utiliza en este proyecto, ya que este incorpora un firmware compatible que contiene la misma estructura básica que el original, el ELM327. En el siguiente listado se pueden ver todos los posibles comandos que el ELM327 implementa, y por tanto, aunque no todos los comandos que utiliza la interface utilizada en este proyecto: 16

17 17

18 A continuación podemos ver uno de los esquemas eléctricos que aporta ELM Electronics, utilizando su microcontrolador más famoso, el antes mencionado ELM327, el cual utilizan muchas interfaces del mercado, ya que es capaz de manejar y gestionar los protocolos de comunicación más utilizados en el estándar OBD-II: Detalle del esquema eléctrico de un intérprete de OBD a RS232 18

19 Para realizar el software de control se utilizo como base de inicio el software que proporciona la empresa ScanTool.net, la cual ofrece en una de sus versiones su código fuente. Este código fuente se trató con el tan extendido programa de desarrollo DEV-C++, y posteriormente también se desarrollaron con él los primeros diseños de prueba con los se empezó la comunicación con la interface. Una vez se empezó a programar utilizando la plataforma JAVA y su máquina virtual, la cual está disponible en la web de Sun Microsystems y se puede descargar mediante el paquete JDK 6 Update 13, se pasó a utilizar otra herramienta para programar con este lenguaje llamada Eclipse en su versión 3.2.2, y fue muy útil para desarrollar el entorno gráfico del que dispone el software de control que se ha creado en este proyecto. Un recurso muy importante también fue toda la información que se aporta en RXTX.org, donde se explica el funcionamiento de la librería RXTXcomm.jar, que es la que se utiliza en JAVA para manejar los puertos serie. En esta web se ofrecen claros ejemplos de cómo utilizar y configurar los métodos de los que se dispone, en especial haciendo hincapié en uno de ellos que será adjuntado en el anexo del proyecto. 19

20 Por otro lado para poder entender cómo funcionan los protocolos de comunicación que utiliza el estándar OBDII (On Borad Diagnostics II), se extrajo mucha información de la enciclopedia libre Wikipedia, donde en uno de sus documentos (OBD-II PIDs), explica cuales y como son los formatos de trama de datos que utiliza este estándar, además de documentos como (ASCII), que detalla las equivalencias del código ascii entre valores decimales y hexadecimal. Detalle de equivalencias código ASCII Detalle de la información aportada en el documento OBD PID s 20

21 2.3. Descripción del diseño del modem interface La primera parte del proyecto que se empezó a diseñar y construir es el modem interface que se utiliza como aparato para interconectar el PC con la centralita electrónica del vehículo. Este aparato consta de tres partes a diferenciar, el cable USB que comunica el PC con el modem, el cable OBD-II que comunica la centralita electrónica del vehículo con el modem y el modem propiamente dicho. En los cables no hubo ningún proceso de montaje, se podían comprar ya hechos, pero si se intento fabricar el del conector OBD-II, ya que es difícil encontrarlos en los comercios especializados, pero se acabó desechando por su poca durabilidad ya que después de unas pocas pruebas empezó a deteriorarse. Cable OBD-II a DB9 hembra Cable USB tipo A-B En la siguiente tabla se puede apreciar la correspondencia entre los pines del conector OBD-II y el DB9: OBD-II 16 PIN(Macho) DB9 PIN(Hembra) (J2850 BUS+) 2 7 (Chassis Ground) (Signal Ground) (CAN High J-2284) 6 3 (ISO K Line) 7 4 (J2850 BUS- ) 10 6 (CAN Low J-2284) 14 5 (ISO L Line) 15 8 (Battery Power)

22 Por tanto el trabajo importante aquí estaba en la fabricación del modem. Para poder construirlo se acudió a una tienda especializada donde disponían de todos los componentes electrónicos necesarios, los cuales se procedieron a instalar en el PCB creado a partir del siguiente layout de doble cara: 22

23 Este aparato contempla la posibilidad de utilizar 4 protocolos de comunicación distintos a nivel de capa física, ya que a lo largo de los años las diferentes centralitas electrónicas que montan los fabricantes de vehículos así lo han dispuesto, aunque a partir del año 2004, en Europa, la mayoría de fabricantes empezaron a implementar solo el protocolo CAN Bus. Cualquiera de los vehículos fabricados en EE.UU. a partir del 1996, fueron obligados a disponer de un puerto OBD2, y en Europa a partir del año 2001, también se obligo a implantar este tipo de conexión. La norma OBD2 comprende cuatro protocolos de comunicación distintos: ISO 9141/14230 J1850 PWM J1850 VPW ISO (CAN) VPW (Variable Pulse Width) fue originalmente introducido por General Motors, mientras que PWM (Pulse Width Modulation) pertenece al grupo Ford. ISO 9141 y la posterior encarnación ISO (AKA Keyword 2000) es el que la mayoría de vehículos europeos y asiáticos utilizaban. Todos los nuevos modelos a partir 2007/2008 sólo pueden implementar el protocolo CAN Bus. La siguiente imagen es la de un conector típico OBD2 de 16 pines instalado en cualquier vehículo: Según el protocolo de comunicación que utilice el vehículo los pines habilitados en el conector serán diferentes. El protocolo ISO 9141/14230 utiliza los pines 6 y 15, el protocolo J1850 PWM utiliza el 2 y el 10, el protocolo J1850 VPW utiliza solo el pin 2, y el protocolo ISO (CAN), el pin 6 y 14. Todos los protocolos utilizan como fuente de alimentación los pines 4 y 5 (masa chasis y masa señal respectivamente), y el pin 16 (+12V). 23

24 Para entender el funcionamiento interno del modem habría que empezar por describir las partes de las que se compone su circuitería. En la siguiente imagen se puede observar el esquema eléctrico de la interface: En el esquema se observa que el microcontrolador utilizado es el PIC18F2455, pero por dificultades a la hora de adquirirlo se optó por el PIC18F2550, que es perfectamente compatible además de aportar un poco mas de memoria. Este micro es el encargado de gestionar todo los componentes periféricos del circuito y de mantener la comunicación entre ellos, es decir, recibe la información procedente del puerto USB al que está conectado, la transfiere a los elementos del circuito que proceda y viceversa, ya que la comunicación es bidireccional. La parte del circuito que se ocupa de manejar el protocolo CAN BUS, son los integrados MCP2515 y MCP2551, el integrado MC33290 maneja el protocolo ISO9141/14230 junto con Q3, J1850 VPW está controlado por MC33390 y el par de Mosfets (Q2 P-channel y Q1 N-channel) controlan el bus J1850PWM junto un comparador interno del PIC18F2550 y las resistencias R4 y R5 que crean la señal diferencial de la entrada del PWM. 24

25 2.4 Descripción del diseño del programador JDM2 Después de la explicación anterior es obvio deducir que el elemento más importante aquí es el microcontrolador PIC18F2550, pero por si solo no tiene ninguna funcionalidad a no ser que se le introduzca el firmware adecuado, por esta razón se tuvo que construir exclusivamente para este fin un programador compatible con el protocolo ICSP (In-Circuit Serial Programming). Este tipo de programador, llamado JDM2, es muy famoso en la red ya que se construye con pocos componentes e implementa el estándar ICSP que es el que ofrece la empresa Microchip para poder introducir los firmwares en los microcontroladores que ellos fabrican. El esquema eléctrico del programador es de fácil adquisición en cualquier web de electrónica y se representa con el siguiente esquema: 25

26 El circuito se montó en una placa de baquelita específica para realizar prototipos, y se siguió el siguiente layout : Detalle del programador JDM2 en su parte superior Detalle del programador JDM2 en su parte inferior (lado soldadura) 26

27 Además del programador necesitamos poder conectarlo a una PC que disponga de puerto serie, ya que a través de este puerto se comunicará con el software que enviará el firmware al micro. La aplicación que se utilizó para programar el microcontrolador fue PICPgm Develop. Programer que es un software gratuito y de fácil manejo; solo hay que seleccionar el archivo que contenga el firmware y una vez cargado cliquear en la opción de gravado. Siguiendo el datasheet del microcontrolador se conectó al programador según el siguiente detalle: Los pines detallados en la imagen son los que utiliza el programador JDM2 y por tanto el estándar ICSP, para comunicarse con el PIC. Vemos que además de los pines de comunicación (MCLR, PGC y PGD), también utiliza el puerto serie para alimentarse mediante los pines 8 y 19 para masa, y el 20 para los +5 V necesarios. El pin 26 (PGM), no está implementado en el programador ya que este solo se utiliza en el caso que se realice una programación en modo Low- Voltage ICSP, y en este caso se realiza en modo High-Voltage ICSP. 27

28 La conexión realizada para proceder a programar el micro fue la siguiente: En la imagen podemos ver como el cableado procedente del programador está etiquetado con el nombre de los pines a los cuales debe ser conectado. Alrededor del micro hay un cable que puentea dos pines, esto se debe a que el microcontrolador necesita dos puntos de masa. Por otro lado vemos como el cable procedente del puerto serie está conectado en su el respectivo conector DB9. También vemos que el programador está dotado de un diodo led de color rojo, el cual es de suma utilidad a la hora de detectar alguna anomalía en el proceso de gravado. 28

29 2.5 Modificaciones del diseño del modem Una vez se había montado la interface y se procedió a comprobar su correcto funcionamiento con software ya existente, se observó que funcionaba correctamente en todos los vehículos chequeados los cuales utilizaban diferentes protocolos de comunicación, exceptuando uno de los casos que no se obtenía respuesta de su centralita electrónica. Se sospechó que posiblemente la interface no funcionaba correctamente y se procedió a analizar con un osciloscopio las señales que producía respecto al protocolo J1850PWM. Para realizar las mediciones se tuvo recurrir a un osciloscopio digital con una capacidad de muestro de hasta 1GHz, herramienta que aseguraba el visionado más que correcto de la señal, ya que además esta era de tipo no periódica y por tanto con un osciloscopio analógico es prácticamente imposible capturarla. El resultado fue el siguiente: Resultado de la trama enviada a través del pin 2 (BUS+) del conector OBD-II Resultado del trama enviada a través del pin 10 (BUS-) del conector OBD-II 29

30 Para entender el resultado de estas graficas es preciso hacer una descripción del comportamiento de la capa física del protocolo j1850pwm. Este protocolo dispone de dos líneas de comunicación, el BUS+ y BUS-, y se caracteriza por utilizar la modulación del ancho de pulso (PWM) como mecanismo de codificación de bits. El periodo de cada bit tiene una duración de 24 µs y su estado se expresa de la siguiente forma: Un bit=1, se representa con un estado activo de 8us dentro de un periodo. Un bit=0, se representa con un estado activo de 16us dentro de un periodo. El BUS+ está activo cuando toma el valor de 5v. El BUS- está activo cuando toma el valor de 0v. Por tanto se deduce que en estado de reposo el BUS+ se encuentra a 0 V y el BUS- a 5 V, a medida que se van enviando los bits los buses van cambiando de estado quedando siempre entre ellos con tensiones invertidas, lo que se traduce en un mecanismo de protección contra interferencias exteriores. Hecha esta explicación podemos darnos cuenta de que la gráfica que representa el BUS+ desvela un pequeño problema eléctrico, ya que mientras que el BUSreacciona rápidamente colocándose a 0 V, el BUS+ nunca llega a lograr los 5 V, quedándose siempre en los 4,4 V aproximadamente. Aunque este no sería un problema para realizar la comunicación satisfactoriamente según las especificaciones del protocolo SAEJ1850PWM, ya que se encuentra dentro de los márgenes eléctricos permitidos, se procedió a modificar la electrónica que se ocupa de implementar esta codificación. 30

31 En el esquema eléctrico observamos que los encargados de ajustar estas tensiones son los Mosfets Q1 y Q2 (Q2 P-channel y Q1 N-channel) junto con las resistencias R7 y R6. Partiendo de otro diseño disponible en la red que implementa el mismo protocolo, se cambiaron los Mosfets por transistores PNP y NPN (PNP->2N3906 y NPN->2N3904) y las resistencias R6 y R7 de 22kΩ por resistencias de 2K7 Ω. Además se incorporaron resistencias de protección a las bases de los transistores de 1KΩ. Por tanto la modificación resultaría según el siguiente esquema: 31

32 Debido a que se constató que el problema no venia causado por el hardware se empezó a investigar si podía venir dado por errores en las tramas enviadas. Según el estándar J1850 PWM el formato de trama es el siguiente: A partir de los documentos que explican las características de este protocolo se averiguo que las diferentes partes de la trama tienen las siguientes funciones: SOF: Start of frame Header Field: Son los encargados de especificar mediante 3 bytes los siguientes parámetros: El primer byte especifica el modo en que se van a comunicar la centralita con la interface, y según el documento SAE J2178 este byte de cabecera se denomina de tipo mapeado, eso significa que cada bit tiene un significado. Los 8 bit se identifican así: BIT ID P P P H K Y Z Z Los tres más significativos (7, 6 y 5) indican la prioridad del mensaje y puede tomar los siguientes valores: Bit 7 Bit 6 Bit Prioridad máxima Prioridad mínima 32

33 El bit 4 (H) indica si la cabecera es de 3 bytes o uno: H=0 Tres bytes H=1 Un byte El bit 3 (K) indica si se utiliza "In-Frame response"? : K=0 Requerido K=1 No requerido El bit 2 (Y) indica si la dirección usada es física o funcional: Y=0 Funcional Y=1 Física Los bit 0 y 1 (Z, Z) se usan junto con K e Y para definir el tipo de mensaje: Msg. KKYZ Respuesta(K) Dirección(Y) Tipo de mensaje Requerido Funcional Function Requerido Funcional Broadcast Requerido Funcional Function Query Requerido Funcional Function Read Requerido Física Nodo a Nodo Requerido Física Reservado-MFG Requerido Física Reservado-SAE No requerido Física Reservado-MFG No requerido Funcional Function Command/Status No requerido Funcional Funcion Request/Query No requerido Funcional FunctionExt.Command/Status No requerido Funcional Function Ext. Request/Query No requerido Física Nodo a Nodo No requerido Física Reservado-MFG No requerido Física No disponible No requerido Física Reservado-MFG 33

34 El segundo byte representa a la dirección de memoria elegida que identifica a la centralita (ECU). El tercer byte representa a la dirección de memoria elegida que identifica a la interface o herramienta de chequeo. Data Field: Es la información que se quiere hacer llegar al micro de la ECU. CRC: Chequeo de redundancia cíclica de la trama. Conociendo ya la estructura de este protocolo se pensó que una solución al problema sería modificar los Header Field ya que posiblemente no serian los adecuados. A partir de aquí se procedió a averiguar cuáles eran los que utilizaba nuestra interface, y esto se consiguió mediante el comando ATH1, el cual le indica al modem que muestre las cabeceras (Headers) de todas las tramas, después observando una de las tramas se vio que la cabecera utilizada por defecto era 6A 61 F1. En el documento antes mencionado (J2178), se indicaba que esta cabecera es generalmente la más utilizada en muchas de las centralitas que implementan el protocolo J1850PWM, pero también hacía referencia a otra posible cabecera a utilizar, que era E4 10 F1. La cabecera 6A 61 F1 especifica el uso de 0x61 ( ) como primer byte que significa prioridad 3, tres bytes de cabecera, tipo de mensaje 2, usando dirección funcional que es el segundo byte de la cabecera, es decir, 0x6A. La cabecera E4 10 F1 especifica el uso de 0xE4 ( ) como primer byte que indica prioridad 7 (mínima), tres bytes de cabecera, tipo de mensaje 4, con dirección física y nodo a nodo. En principio para proceder a cambiar las cabeceras se dispone del comando ATSH, pero por causas aún desconocidas no era reconocido por nuestra interface, a pesar de que en el firmware del microcontrolador se vio que estaba implementado, mediante un software para editar ficheros de este tipo. Utilizando este mismo software (Hex Workshop Hex Editor), se intento averiguar donde se encontraban los bytes que definían las cabeceras en cuestión, y después de una búsqueda muy extensa se encontraron y modificaron con los nuevos valores. 34

35 En la siguiente captura podemos observar el fragmento de código donde se encontraban estos datos, fue un tarea laboriosa ya que este fichero solo contiene tramas hexadecimales, y es el resultado de la compilación de un código fuente al que no se tenía acceso. :103C E66EE66A BC6F000E0120CA :103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2 :103C E0120BF6FBEC0E6FFBFC0E6FFDDEC37 :103CA0001EF046E90028E96E000E0120EA6E6A0E59 :103CB000EF6E020E0024E96E000E0120EA6E610E26 :103CC000EF6E030E0024E96E000E0120EA6EF10E85 :103CD000EF6E EBC6F00EBE9FF01EBEAFFA2 :103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A Además de reemplazar estos bytes también se tuvo que recalcular el checksum de cada línea modificada ya que este cambiaba, y el resultado fue el siguiente: :103C E66EE66A BC6F000E0120CA :103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2 :103C E0120BF6FBEC0E6FFBFC0E6FFDDEC37 :103CA0001EF046E90028E96E000E0120EA6EE40EBA :103CB000EF6E020E0024E96E000E0120EA6E100E77 :103CC000EF6E030E0024E96E000E0120EA6EF10E85 :103CD000EF6E EBC6F00EBE9FF01EBEAFFA2 :103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A Con el firmware ya modificado se procedió a volver reescribirlo en el microcontrolador utilizando el programador antes descrito. Una vez preparada la interface se volvió a intentar la comunicación con la centralita en cuestión que nos daba problemas. El resultado fue muy interesante ya que esta vez si nos contestó pero de la forma no esperada. La trama enviada fue la siguiente: E4 10 F A Y su respuesta: C4 F1 10 7F El dato a resaltar es el 7F 01, que indica respuesta negativa, es decir, según el documento J2178 una respuesta negativa significa que la centralita electrónica no dispone de información sobre el modo de trabajo requerido, que es el Modo

36 El estándar OBD-II contempla varios modos de trabajo, entre ellos el modo 01, modo 03, modo 07, modo 04, modo 09, modo 22 y bastantes más. Cada uno de ellos se ocupa de una parte de la información que puede aportar la ECU. El modo más extendido entre todas las centralitas es el modo 01. Cada modo además especifica sus parámetros PID (Parameter ID), en caso del modo 01 uno puede ser el parámetro 00, que es el que se utiliza en nuestro caso. Este parámetro sirve para decirle a la ECU que nos muestre cuales son los PID que pueden ser utilizados en este modo de entre los PID que se encuentran numerados del 1 al 20. Después de consultar nuevamente el documento J2178 se averiguó que cuando el modo 01 no está disponible en la centralita lo más probable es que se implementara en su lugar el modo 22. Este fue el final de la investigación ya que el modo 22 utiliza una longitud de trama más larga que el 01, cosa para la cual nuestro hardware (el microcontrolador de la interface), no está preparado, ya que no se implemento en su firmware esta funcionalidad. 36

37 2.6 Diseño de la aplicación de prueba en C++ Hasta ahora se ha explicado el diseño utilizado para crear la parte de hardware de la que se compone el proyecto, pero anteriormente se ha hecho referencia también a la parte de software que es la que tiene más peso y elaboración. El desarrollo del software se empezó a elaborar a partir del software libre ScanTool.net, que en una de sus versiones ofrece el código fuente. Utilizando la herramienta Dev-C++ y este código, el cual se basa en C++, se localizaron los métodos y funciones que se sospechaban eran los responsables de mantener la comunicación mediante el puerto serie. El primer paso fue averiguar cuál era la función que realizaba las operaciones necesarias para realizar las comunicaciones con el PIC. Tras encontrarla y incorporarla a un programa de prueba, se procedió a compilar la función, tras esto el mismo compilador mencionaba cuales eran las funciones y variables que llamaba este método para poder comunicarse, y por lo tanto poder buscarlas en el código anterior para reunirlas en el programa de prueba. Una vez que se tenían todas las funciones y variables en el mismo fichero se podía compilar el código sin obtener errores, averiguando así cómo se comportaba el hilo de ejecución. Después de saber cuál era la rutina de ejecución, se sacaron todas las órdenes o variables que no son imprescindibles por realizar una comunicación básica, dejando la clase reducida al máximo para tener una visión simple del proceso comunicación dejando a la vista claramente las funciones necesarias. Finalmente el programa de prueba podía realizar la comunicación enviando órdenes al PIC (atz, 0100, etc...) obteniendo los mensajes enviados y los recibos con una visualización por consola. A continuación aparece el código del programa de prueba: 37

38 38

39 Este programa utiliza la librería allegro como base, un librería muy utilizada para desarrollar videojuegos, y por tanto era necesario indicarle al compilador que la cargase con -lalleg, aunque también necesita cargar la librería iostream y la winalleg, necesaria si se trabaja en Windows. Las funciones implementadas son: main(): Arranca el hilo de ejecución. init(): Carga las librerías y abre el puerto. deinit(): Descarga las librerías y cierra el puerto. read_comport(): Lee el puerto serie. open_comport(): Abre el puerto serie. 39

40 close_commport(): Cierra el puerto serie. send_command(): Escribe en el puerto serie Diseño de la aplicación de prueba en JAVA El segundo diseño se centra en la elaboración de otro programa de prueba a partir de lenguaje JAVA, ya que era necesario averiguar las capacidades de este lenguaje a la hora de comunicarse con el puerto serie. Como primer apunte se ha de decir que se utilizó el IDE para programar en Java Eclipse. Para poder comunicarse con el puerto serie es necesario incluir las librerías adecuadas en el paquete de la API de java instalada en el PC, es decir, en el paquete autoinstalable JDK-JRE que ofrece gratuitamente Sun Microsystems, ya que este no incluye librerías con esta funcionalidad. Para este fin existe una librería llamada RXTXcomm, disponible en que mediante métodos nativos dota a Java de la capacidad para comunicarse con el puerto serie y paralelo, y además puede utilizarse en cualquier sistema operativo, haciendo hincapié en Windows, ya que aunque Sun ofrece una API para este fin (Javacomm), no da soporte para este sistema operativo, quedándose ya esta API obsoleta y aconsejando RXTXcomm. Descargando y descomprimiendo el zip donde se incluyen los ficheros necesarios de RXTX, debemos de copiar RXTXcomm.jar en la ruta c:\archivos de programa\java\jre\lib\ext, rxtxserial.dll y rxtxparallel.dll en c:\archivos de programa\java\jre\bin. Si en lugar de Windows nos encontramos en Linux las rutas donde situar los ficheros es diferente. En Linux debemos de copiar RXTXcomm.jar en /usr/lib/jvm/jre/lib/ext, los archivos librxtparallel.so y librxtxserial.so hay que copiarlos en /usr/lib/jvm/jre/lib/i386 si el sistema es de 32 bits. Con esto el compilador ya tendrá las librerías disponibles y podremos utilizarla en el código que programemos. RXTX.org dispone de una web donde se explica el funcionamiento de la librería y sus métodos, además ofrece ejemplos claros de cómo ponerla en marcha. 40

41 El programa de prueba que se elaboró en esta fase del proyecto fue el siguiente: import gnu.io.commportidentifier; import gnu.io.nosuchportexception; import gnu.io.portinuseexception; import gnu.io.serialport; import gnu.io.unsupportedcommoperationexception; import java.io.ioexception; import java.io.inputstream; import java.io.outputstream; import java.util.date; import java.util.enumeration; public class Principal { CommPortIdentifier idpuerto; String NombrePuerto; String ordre="atz"; String stringrebut; SerialPort port; OutputStream DadesEscriu; InputStream FluxDades; Date temps,temps2; StringBuffer respuesta; public Principal(){ public void conectar(){ int j=0; for(enumeration i=commportidentifier.getportidentifiers();i.hasmoreelements();){ idpuerto = (CommPortIdentifier) i.nextelement(); System.out.print(j++ +". " + idpuerto.getname()+"\n"); //Se examinan todos los puertos disponibles try { idpuerto.getportidentifier("com2"); port = ( SerialPort )idpuerto.open("visualobd",2000); port.setserialportparams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //Se abre el puerto seleccionado catch (PortInUseException e) { e.printstacktrace(); System.out.println("Puerto en uso."); catch (NoSuchPortException e) { e.printstacktrace(); System.out.println(e); catch (UnsupportedCommOperationException e) { e.printstacktrace(); System.out.println(e); 41

42 public void enviar(){ temps=new Date(); int data; try { DadesEscriu = port.getoutputstream(); for(int i=0;i<ordre.length();i++){ data= ordre.codepointat(i); System.out.println(data); DadesEscriu.write(data);//Se escribe en el Puerto serie if((i+1) == ordre.length()){ DadesEscriu.write(13); //Solamente necessita el retorno de carro, //sin el salto de linea. System.out.println("Enviat atz:"); catch (IOException e) { e.printstacktrace(); System.out.println(e); public void recibir(){ respuesta=new StringBuffer(); while((timer()-temps.gettime())<3000){ char z; int reb=0; try { FluxDades = port.getinputstream(); while(reb>-1){ reb=fluxdades.read();//se lee el Puerto serie z=(char) reb; respuesta.append(z); System.out.println(respuesta);//Se imprime la respuesta por consola port.close(); catch (IOException e) { e.printstacktrace(); System.out.println(e); public static void main(string[] args) { Principal prin=new Principal(); prin.conectar(); prin.enviar(); prin.recibir(); public long timer(){ temps2 = new Date(); return temps2.gettime(); 42

43 Estructuralmente el programa se asemeja al diseño en C++, y por tanto implementa métodos funcionalmente muy parecidos: public static void main(): Método que inicia la ejecución del programa. public void Conectar(): Establece la conexión con el puerto serie indicado. public void Enviar(): Escribe la trama de datos a enviar en el puerto serie. public void recibir(): Lee la trama de datos recibida del puerto serie. Public long timer(): Método que realiza la espera necesaria a la respuesta del puerto. Tanto en JAVA como en C++, el tratamiento de las tramas digitales recibidas y enviadas en el puerto serie se traducen en valores decimales según el código ASCII, a partir de su equivalente en binario y posteriormente en hexadecimal. Unos ejemplos de trama de datos y su tratamiento sería el siguiente: Comando a enviar: atz -> equivalencia código ASCII: 97,116,122 Este comando sirve para hacer un reset del micro. Se le añade a la trama el retorno de carro para indicar fin de trama: atz\r ->código ASCII: 97,116,122,13 y el método write() de la clase SerialPort la envía al puerto serie. Trama recibida del puerto serie atreves del método read() de la clase SerialPort: 97,116,122,13,10,69,76,77,51,50,55,32,118,49,46,49,32,99,111,109,112, 97,116,105,98,108,101,13,10,62,-1 Equivalencia de la trama según el código ASCII: atz ELM327 v1.1 compatible El último número (-1), indica que no se está recibiendo ningún dato, y sirve como referencia para saber que la trama ha finalizado, además el micro marca el fin de la trama con el numero 62 ( equivalente a > ). 43

44 Comando a enviar: 01 0C -> equivalencia código ASCII: 48,49,48,67 Este comando sirve para pedirle a la centralita electrónica del vehículo (ECU), a cuantas revoluciones por minuto (rpm), está girando el motor. Se le añade a la trama el retorno de carro para indicar fin de trama: 01 0C\r ->código ASCII: 48,49,48,67,13 y el método write() de la clase SerialPort la envía al puerto serie. Posteriormente cuando la interface la ha recibido esta la envía a la ECU según el siguiente formato de trama si el protocolo a utilizar es J1850 PWM: SOF: Start Of Frame Header Field: 6A 61 F1 Data Field: 01 0C (Comando que se ha especificado antes) CRC: 0A EOF: End Of Frame La ECU contesta con la siguiente trama y la interface la recoge para enviarla al puerto serie: 6A F C 0B 88 0A -> Respuesta ECU 01 0C -> Respuesta 6A F C 0B 88 0A Interface Se puede observar que la interface le añade a la trama el comando solicitado Trama recibida del puerto serie atreves del método read() de la clase SerialPort: 48,49,48,67,13,10,54,65,70,49,54,49,52,49,48,67,48,66,56,56,48,65,13,1 0,62,-1 44

45 Por tanto en la respuesta obtenida podemos diferenciar que: 010C: Comando requerido 6A F1 61: Cabecera de la trama(especifica direcciones de memoria, prioridades, tipo de conexión, etc..) 410C: Confirmación de que se ha contestado al comando requerido sumando 40 a 01, quedando 410C. 0B 88: El dato que interesa para calcular las rpm. Según el documento OBD Pid s anteriormente mencionado, si pasamos a decimal estos valores quedando en 11 y 136, y aplicamos esta fórmula (( A 256) + B) ( ) = = 738, obtenemos las revoluciones por 4 4 minuto del motor a tiempo real. 0A: Chequeo de redundancia cíclica de la trama (CRC). 45

46 2.5. Diseño de la aplicación grafica diseñada en JAVA El diseño final y definitivo de este proyecto consistía en realizar un software multiplataforma diseñado mediante la conocida estructura de programación por capas, para poder unir de forma correcta toda la capacidad de comunicación que se había conseguido en los programas de prueba anteriores con la necesidad de ofrecer muchas más opciones, entorno grafico y el potencial que aporta un entorno visual diseñado con JAVA, lo cual dota al programa de muchas posibilidades de configuración y operatibilidad sobre la interface y por tanto sobre la centralita electrónica de cualquier vehículo. Este software intenta ser compatible con cualquier plataforma que disponga de una conexión USB o RS-232, de ahí su implementación mediante JAVA, pero debido a que para realizar las comunicaciones con dichos puertos se ha utilizado un librería nativa (RXTXcomm.jar), es posible que existan algunas incompatibilidades de un plataforma a otra, cosa que se debería consultar en la web de RXTXcomm. Básicamente el programa ofrece cinco apartados bien diferenciados: La pantalla principal de inicio: Es la ventana que vemos cuando inicia el programa, en ella realizamos y vemos las operaciones principales, como son realizar la conexión/desconexión con la interface y siempre viendo en una consola de texto los datos que se están enviando y recibiendo a tiempo real. La opción de configuración del puerto: En esta sección del programa podemos configurar todos los parámetros necesarios del puerto serie, para poder realizar una conexión. La opción de selección del protocolo de comunicación: Esta funcionalidad del programa permite que el usuario pueda elegir manualmente el protocolo con el que se quiere comunicar con la ECU de su vehículo. La opción de Lectura de códigos de error: Esta opción ofrece la posibilidad de poder averiguar si nuestro vehículo ha sufrido o sufre algún fallo técnico, a través de la obtención de un código identificativo que especifica la avería y que proporciona la ECU. La opción de mediciones a tiempo real: Esta parte del programa proporciona información de los diferentes sensores de los que dispone el motor de nuestro vehículo, mostrando datos como la temperatura, velocidad, revoluciones por minuto, cantidad de aire absorbido, etc. 46

47 Para realizar el software se utilizó la estructura de programación por capas: capa de datos, capa de dominio y capa de presentación. Cada capa tiene una función dentro del programa y una serie de clases que cumplen con la función que se les ha asignado. A continuación se explica la función y clases que contiene cada capa: 1. Capa de Datos: Es la encargada de gestionar todas las tramas de datos que se intercambian la computadora y la interface. Su objetivo es recoger ya sean datos recibidos o enviados, adecuarlos y tratarlos para poder o bien mandárselos a la interface a través del puerto serie o recibirlos y mandárselos a las capas superiores. En esta capa podemos encontrar las siguientes clases: Clase Conexión: Es la encargada de encapsular todos los atributos de los que se compone una conexión que se realiza atreves del puerto serie: velocidad, databits, stopbits, paridad, nombrepuerto, protocolo. Clase ControladorConexión: Contiene todos los métodos necesarios para realizar la conexión, contiene mucha de la estructura conseguida en los programas de prueba. Clase lecturatxterrores: Clase que permite acceder a archivos de tipo TXT, con el objetivo de que el programa disponga de una memoria permanente. Alguna de las funcionalidades de las que dispone el software necesita cotejar la información que recibe con la que dispone para poder reconocerla, como es el caso de la lectura de los códigos de error. Clase MuestraIDs: Captura los identificadores de trama del protocolo CAN Bus. 2. Capa de Dominio: Es la encargada de hacer de intermediario entre la capa de datos y la inmediatamente superior a la de dominio, que en este caso es la de presentación. Ofrece la capacidad de trabajo de la capa de datos, de una forma mucho más accesible para sus capas superiores. En esta capa encontramos la clase ControladorDominioConexión, la cual contiene todos los métodos necesarios para manejar todas las clases que se encuentran en la capa de datos. 47

48 Capa de Presentación: Esta capa se encarga de gestionar toda la parte visual del programa y contiene todas las clases y controladores necesarios para poder llevar a cabo esta tarea. Concretamente estas son las clases que contiene: ControladorPrincipal y VistaPrincipal: Gestionan la carga de todas las demás clases de la capa de presentación y proporcionan las operaciones básicas del programa, como son poder iniciar o detener un conexión con la interface y seleccionar las diferentes opciones del programa. ControladorErrores y VistaCodigosError: Estas clases se ocupan de gestionar la presentación en pantalla de los códigos de error proporcionados por la ECU. ControladorMediciones y VistaMediciones: Se ocupan de gestionar la presentación en pantalla de los datos referentes a valores que proporcionan los sensores del vehículo, tales como temperatura, velocidad, revoluciones por minuto, cantidad de aire absorbido, etc. ControladorProtocolo y VistaProtocolo: Gestionan la presentación en pantalla de las opciones disponibles a la hora de seleccionar un protocolo de comunicación. ControladorPSerie y VistaConfiguración: Presentan en pantalla todas las opciones que requiere el puerto serie para ser configurado. Además permiten realizar una búsqueda de estos. Por lo extenso del código de este último programa, se incorporará al final del proyecto como documento adjunto. En esta aplicación la clase más importante y difícil de desarrollar es la clase ControladorConexion, ya que es la que capacita al software de la capacidad de utilizar varios hilos de ejecución. Esta clase implementa la interface Runnable con su respectivo método Run(), el cual está en permanente escucha a los mensajes que se envían desde el puerto serie, y por tanto permite liberar al hilo principal para poder realizar otras funciones simultáneamente. Otra de las clases que implementa un nuevo hilo de ejecución es la clase ControladorMediciones, la cual se encarga de mostrar los datos de la lectura a tiempo real de los diferentes sensores de los que dispone la centralita en el vehículo. Por tanto en la aplicación trabajan 3 hilos de ejecución: Hilo principal: Se mantiene a la espera para realizar las funciones que reclame el usuario. Hilo de la clase ControladorConexion: Escucha permanentemente el puerto serie consiguiendo así no perder ningún posible dato y una velocidad de respuesta mucho más alta. Hilo de la clase ControladorMediciones: Refresca constantemente en pantalla los datos que va recibiendo el método run() de la clase ControladorConexión. 48

49 Cuando se procedió a probar el software sobre diferentes sistemas operativos con la intención de asegurar su funcionalidad, ventaja que tiene JAVA sobre otros lenguajes ya que utiliza una maquina virtual, se observó que en Windows funcionaba correctamente ya que sobre este se había realizado la programación, pero sobre Linux se obtuvo un resultado inesperado. Se observó que en Linux el programa arrancaba y funcionaba de forma correcta, pero en el momento que se procedía a desconectarlo del puerto serie el programa quedaba totalmente bloqueado. Después de muchas pruebas se averiguó que las librerías nativas RXTXcomm.jar que utiliza esta aplicación se comportaban de diferente forma según el sistema operativo en el que estuviéramos trabajando. El problema se encontraba en el método run() de la clase ControladorConexión(), ya que este utiliza la clase SerialPort constantemente para escuchar el puerto serie. Observando el siguiente fragmento de código podemos hacernos una idea de la situación: public void run(){ boolean datos=false; String tramarecibida; Thread thisthread = Thread.currentThread(); while(hilo == thisthread){ char z; int longitudtrama=0; int reb=0; try { datosrecibidos = port.getinputstream(); while((reb=datosrecibidos.read())>-1){ z=(char) reb; if(reb==62){ break; if(reb!=-1){ tramarecibidainicial.append(z); DestruirHilo=true; catch (IOException e1) { estado("no response."); Vemos que la línea subrayada, datosrecibidos.read(), es la orden que se encarga de acceder al puerto y cuando el hilo de ejecución llega a ella en Windows la lee una vez y sigue su transcurso dentro del método run() hasta el siguiente ciclo de bucle donde lo volvería a leer, pero en Linux no sucede los mismo, el hilo de ejecución se detiene en esta línea esperando un nuevo mensaje del puerto y por tanto bloqueando su posible cierre desde el hilo principal, es decir, como el hilo que se ejecuta en run() nunca libera al objeto port, cuando accedemos al mismo objeto desde el hilo principal de la clase este provoca un bloqueo de la aplicación ya que nunca tendrá permiso para cerrarlo. Esto se solucionó enviando un mensaje cualquiera al puerto y cambiando en el mismo instante la condición del bucle while (hilo=null), para que el hilo de run() saliese de su estado de escucha y acabara extinguiéndose ya que la condición del bucle ya no se cumplía. 49

50 Como aporte final a esta aplicación se procedió a empaquetarla en un archivo.jar, lo que facilita mucho su puesta en marcha y portabilidad a cualquier otra plataforma o sistema operativo. Pero uno de los inconvenientes que presentaba esta aplicación era que para poder comunicarse con los puertos de comunicación necesitaba la librería nativa RXTXcomm, y por tanto, esta no viene incluida en las librerías de la maquina virtual que se instala por defecto, lo que obliga a tener que instalarla manualmente. Para cualquier persona que esté familiarizada con la programación no resulta ser un problema, pero si para alguien que solo quiera hacer unas cuantas pruebas. La solución fue crear una carpeta donde se introduciría el archivo JAR, los archivos adjuntos necesarios como los JPG y TXT, y otra carpeta donde incluiríamos la librería nativa RXTXcomm. Además de lo anterior se crearon dos archivos ejecutables (RunLinux.sh y RunWindows.bat), que se utilizan según en el sistema operativo en el que estemos. La carpeta se llama VisualOBDJar y contiene los siguientes archivos: VisualOBD.jar: Archivo comprimido que contiene todo el código de la aplicación. RunLinux.sh: Archivo ejecutable para Linux. RunWindows.bat: Archivo ejecutable para Windows. VisualOBD4_1 y AboutVisualOBD: Archivos de tipo JPG. CodigodErrores.txt: Archivo de texto utilizado como base de datos. Leeme.txt: Archivo de texto que contiene una breve explicación de cómo arrancar el software. lib: Carpeta que contiene la librería nativa RXTXcomm con los respectivos archivos rxtxparallel.dll, rxtxserial.dll, librxtxserial.so, y librxtxparallel.so necesarios para realizar su carga en el sistema operativo través de la máquina virtual. 50

51 Para poder realizar la carga de la librería nativa correctamente se tuvo que modificar el archivo MANIFEST que contiene el paquete VisualOBD.jar quedando de la siguiente forma: Y a los archivos RunWindows.bat y RunLinux.sh se les introdujo los siguientes comandos: 51

DISEÑO E IMPLEMENTACIÓN DE UN PROTOTIPO DE MONITOREO DE AUTOMÓVILES EMPLEANDO EL ESTANDAR OBD-II

DISEÑO E IMPLEMENTACIÓN DE UN PROTOTIPO DE MONITOREO DE AUTOMÓVILES EMPLEANDO EL ESTANDAR OBD-II DISEÑO E IMPLEMENTACIÓN DE UN PROTOTIPO DE MONITOREO DE AUTOMÓVILES EMPLEANDO EL ESTANDAR OBD-II María Fernanda Caizatoa Chulca, Ximena del Rosario Méndez Flores Resumen La construcción del prototipo da

Más detalles

Ic-Prog PARA PROGRAMAR MICROCONTROLADORES PIC 16F84 y 16F876.

Ic-Prog PARA PROGRAMAR MICROCONTROLADORES PIC 16F84 y 16F876. Ic-Prog PARA PROGRAMAR MICROCONTROLADORES PIC 16F84 y 16F876. Prof: Bolaños D. En unión del hardware adecuado, el software IC-PROG permite programar gran cantidad de dispositivos electrónicos. Esta guía

Más detalles

Proyecto PLUMA Plataforma Universal Microcontrolada Aplicaciones didácticas e industriales

Proyecto PLUMA Plataforma Universal Microcontrolada Aplicaciones didácticas e industriales Proyecto PLUMA Plataforma Universal Microcontrolada Aplicaciones didácticas e industriales INS LA GARROTXA PEB12: TONI MORENO ÍNDEX: 1. INTRODUCCIÓN... 3 1.1 VISIÓN ARTIFICIAL... 3 1.2 INTERFACE PLUMABOT-PICAXE...

Más detalles

Sensor de Temperatura utilizando el Starter Kit Javelin Stamp. Realizado por: Bertha Palomeque A. Rodrigo Barzola J.

Sensor de Temperatura utilizando el Starter Kit Javelin Stamp. Realizado por: Bertha Palomeque A. Rodrigo Barzola J. Sensor de Temperatura utilizando el Starter Kit Javelin Stamp Realizado por: Bertha Palomeque A. Rodrigo Barzola J. INTRODUCCION DIFERENCIAS EJEMPLOS JAVA Orientado a Objetos Multiplataforma Programar

Más detalles

5.2 Plataforma de Desarrollo Para la Interfaz de Usuario

5.2 Plataforma de Desarrollo Para la Interfaz de Usuario 5.1 Introducción Para la comunicación entre SATEDU y su estación terrena se necesita ajustar ciertos parámetros de comunicación de la Tarjeta de Comunicaciones como la tasa de transmisión, el número de

Más detalles

MANUAL PARA LA INSTALACION DE UN BLOQUEO PARA EL CONECTOR OBD EN EL SEAT LEON.

MANUAL PARA LA INSTALACION DE UN BLOQUEO PARA EL CONECTOR OBD EN EL SEAT LEON. MANUAL PARA LA INSTALACION DE UN BLOQUEO PARA EL CONECTOR OBD EN EL SEAT LEON. Todos los Seat León (realmente todos los vehículos del grupo VAG) tienen un conector debajo del cenicero (generalmente). Este

Más detalles

Utilización de los puertos serial y paralelo de una PC usando LabView

Utilización de los puertos serial y paralelo de una PC usando LabView Universidad del Táchira Departamento de Ingeniería Electrónica Instrumentación Electrónica Utilización de los puertos serial y paralelo de una PC usando LabView Hecho Por: Ing. Rafael Chacón Ing. José

Más detalles

Introducción a Arduino. 2. Para qué puedo utilizar Arduino?

Introducción a Arduino. 2. Para qué puedo utilizar Arduino? 1. Qué es Arduino? Arduino es una plataforma open-hardware basada en una sencilla placa con entradas y salidas (E/S), analógicas y digitales, y en un entorno de desarrollo que implementa el lenguaje Processing/Wiring.

Más detalles

Anexo B. Comunicaciones entre mc y PC

Anexo B. Comunicaciones entre mc y PC Anexo B Comunicaciones entre mc y PC En este apartado se hará hincapié en los comandos para el manejo del módulo de comunicaciones desde el PC. Conociendo estos comando se podrá realizar una aplicación

Más detalles

Siempre un paso adelante

Siempre un paso adelante Siempre un paso adelante Copyright: El material sobre OBD-II incluido en este manual es de dominio público y puede encontrarse en las recomendaciones SAE y anexos. Parte del mismo es también interpretación

Más detalles

CAPITULO 3 Herramientas de desarrollo CAN

CAPITULO 3 Herramientas de desarrollo CAN CAPITULO 3 Herramientas de desarrollo CAN En este capítulo se describirán herramientas para el desarrollo y diseño de proyectos CAN: CANKing, CANalyzer, MPLAB IDE y el KIT de desarrollo PICDEM CAN-LIN

Más detalles

Arduino I. José Manuel Ruiz Gutiérrez

Arduino I. José Manuel Ruiz Gutiérrez Arduino I Qué es Arduino? Arduino = Plataforma para physical computing de código abierto Plataforma = Tarjeta I/O + entorno de programación + Componentes Physical computing: computación ubicua, interfaces

Más detalles

MODBUS INDICE. Centro Integrado Politécnico ETI Departamento de Electricidad Fernando Pascual Moisés Pérez MODBUS 1. CARACTERÍSTICAS DEL BUS

MODBUS INDICE. Centro Integrado Politécnico ETI Departamento de Electricidad Fernando Pascual Moisés Pérez MODBUS 1. CARACTERÍSTICAS DEL BUS INDICE 1. CARACTERÍSTICAS DEL BUS 2. PROTOCOLOS 3. CARACTERÍSTICAS DE LOS MENSAJES ENVIADOS 4. INSTRUCCIÓN PMCR 5. EJEMPLO DE APLICACIÓN a. Configuración puerto SCU41 b. Configuración variador V1000 c.

Más detalles

Hecho por Víctor Orozco (tuxtor@shekalug.org) Puerto paralelo

Hecho por Víctor Orozco (tuxtor@shekalug.org) Puerto paralelo Hecho por Víctor Orozco (tuxtor@shekalug.org) Puerto paralelo Un puerto paralelo es una interfaz entre un ordenador y un periférico cuya principal característica es que los bits de datos viajan juntos

Más detalles

Módulo 1 El lenguaje Java

Módulo 1 El lenguaje Java Módulo 1 El lenguaje 1.1 Presentación de es un lenguaje de programación desarrollado por la empresa Sun Microsystems en 1991 como parte de un proyecto secreto de investigación llamado Green Proyect, con

Más detalles

IntesisBox. Modbus Server - M-Bus (EN 13757-3) Pasarela para la integración de medidores M-BUS en sistemas de control basados en Modbus RTU y TCP.

IntesisBox. Modbus Server - M-Bus (EN 13757-3) Pasarela para la integración de medidores M-BUS en sistemas de control basados en Modbus RTU y TCP. IntesisBox Server - M-Bus (EN 13757-3) Pasarela para la integración de medidores M-BUS en sistemas de control basados en y TCP. Integre medidores M-Bus en su dispositivo o sistema master (BMS, SCADA, PLC,

Más detalles

CEADENSoft Visual DataLogger 1.0

CEADENSoft Visual DataLogger 1.0 CENTRO DE APLICACIONES TECNOLÓGICAS Y DESARROLLO NUCLEAR CEADENSoft Visual DataLogger 1.0 Software de aplicación para datalogger DL-1a Índice 1 - Introducción...1 2 - Requerimientos....1 3 - Instalación

Más detalles

PLATAFORMA DE CONTROL DIGITAL DE SISTEMAS ELECTRÓNICOS DE POTENCIA

PLATAFORMA DE CONTROL DIGITAL DE SISTEMAS ELECTRÓNICOS DE POTENCIA PLATAFORMA DE CONTROL DIGITAL DE SISTEMAS ELECTRÓNICOS DE POTENCIA V. MIÑAMBRES-MARCOS, E. ROMERO-CADAVAL Y F. BARRERO-GONZÁLEZ Departamento de Electrónica e Ingeniería Electromecánica. Escuela de Ingenierías

Más detalles

UNIVERSIDAD DEL PAIS VASCO - EUSKAL HERRIKO UNIBERTSITATEA

UNIVERSIDAD DEL PAIS VASCO - EUSKAL HERRIKO UNIBERTSITATEA DEPARTAMENTO DE ELECTRONICA Y TELECOMUNICACIONES ESCUELA UNIVERSITARIA DE INGENIERIA VITORIA GASTEIZ UNIVERSIDAD DEL PAIS VASCO EUSKAL HERRIKO UNIBERTSITATEA Ampliación de Sistemas Digitales Manual de

Más detalles

Seminario WEB Monitores OBDII. Sistemas Mexicanos de Diagnóstico Automotriz 2012

Seminario WEB Monitores OBDII. Sistemas Mexicanos de Diagnóstico Automotriz 2012 1 Objetivos Mostrar la importancia del buen entendimiento de los monitores continuos y no continuos de sistemas OBDII 2 Contenido Introducción OBDII Conector Protocolos Modos de diagnóstico Modo 01 (datos)

Más detalles

Programación de microcontroladores en tarjetas: Soluciones para el mercado del automóvil

Programación de microcontroladores en tarjetas: Soluciones para el mercado del automóvil Programación de microcontroladores en tarjetas: Soluciones para el mercado del automóvil Artículo cedido por Agilent Technologies www.agilent.com Dado que los µcs modernos llevan Flash a bordo, la programación

Más detalles

Instrucciones de instalación y guía del usuario del DS550E. Dangerfield June 2008 V2.0 Delphi PSS

Instrucciones de instalación y guía del usuario del DS550E. Dangerfield June 2008 V2.0 Delphi PSS Instrucciones de instalación y guía del usuario del DS550E 1 CONTENIDO Componentes principales...3 Instrucciones de instalación...7 Configuración de Bluetooth...30 Programa de diagnóstico...41 Inserción

Más detalles

Manual de programación de los microcontroladores PIC para su uso en el Proyecto IOCards

Manual de programación de los microcontroladores PIC para su uso en el Proyecto IOCards Manual de programación de los microcontroladores PIC para su uso en el Índice 1. Introducción 2. Material necesario a. Hardware b. Software 3. Conexiónes Hardware 4. Configuración Hardware 5. Instalación

Más detalles

Corporacion Universitaria Autonoma del Cauca EJEMPLARIZACION DE COMUNICACIÓN ENTRE DOS MODOULOS XBEE SERIE 2.

Corporacion Universitaria Autonoma del Cauca EJEMPLARIZACION DE COMUNICACIÓN ENTRE DOS MODOULOS XBEE SERIE 2. EJEMPLARIZACION DE COMUNICACIÓN ENTRE DOS MODOULOS XBEE SERIE 2. RESUMEN Hoy en día son muchos los dispositivos que cumplen la función de comunicarse uno con el otro, siendo útiles y cumpliendo objetivos

Más detalles

2 1.1 2 1.2 2 2. SOFTWARE +... 3 3. COMUNICACIÓN - CONEXIÓN DEL DISPOSITIVO...

2 1.1 2 1.2 2 2. SOFTWARE +... 3 3. COMUNICACIÓN - CONEXIÓN DEL DISPOSITIVO... Manual de software Dynamic Plus Fecha: 03/04/2014 Manual Software Dynamic Plus v2.0.5 ÍNDICE GENERAL 1. INTRODUCCIÓN... 2 1.1 Configuración mínima del PC... 2 1.2 Instalación del Software Dynamic Plus...

Más detalles

TUTORIAL PARA PROGRAMAR UN ATMEGA8

TUTORIAL PARA PROGRAMAR UN ATMEGA8 TUTORIAL PARA PROGRAMAR UN ATMEGA8 Este tutorial está diseñado para las personas que nunca han utilizado un microcontrolador de Atmel, y quieren empezar a desarrollar sus proyectos con esta tecnología.

Más detalles

Placa de control MCC03

Placa de control MCC03 Placa de control MCC03 Placa de control MCC03 La placa de control basada en el micro controlador PIC 16F874A de Microchip, es la encargada del procesar los datos que se introducen en el sistema y actuar

Más detalles

ZKit: Kit de evaluación XBee ZB (ZigBee-PRO)

ZKit: Kit de evaluación XBee ZB (ZigBee-PRO) Contenido del kit ZKit: Kit de evaluación XBee ZB (ZigBee-PRO) 3 placas XBoard conteniendo cada una un módulo XBee ZB con antena integrada o whip 1 placa USB2UART que permite obtener un puerto serie a

Más detalles

Tema: Introducción a la Plataforma Arduino

Tema: Introducción a la Plataforma Arduino Facultad: Ingeniería Escuela: Electrónica Asignatura: Interfaces y Periféricos Tema: Introducción a la Plataforma Arduino Objetivos Específicos. Conocer la plataforma de hardware libre Arduino 2. Desarrollar

Más detalles

Figura 3.1. Imagen del ambiente de programación llamado NXT G.

Figura 3.1. Imagen del ambiente de programación llamado NXT G. Capitulo III. Hardware y software utilizado. Kit LEGO Mindstorms NXT. El Kit consta de una serie de piezas de plástico que se ensamblan entre si, sensores; como lo son de tacto, de sonido, de ultrasonido,

Más detalles

Programador de microcontroladores PICs ENIGMA

Programador de microcontroladores PICs ENIGMA Programador de microcontroladores PICs ENIGMA Este tutorial te permitirá construir el hardware del programador USB, la ventaja de construir este hardware; es la de poder utilizarlo con el software de programación

Más detalles

Práctica 3. Control de un PLC mediante tramas Host-Link generadas por un PC

Práctica 3. Control de un PLC mediante tramas Host-Link generadas por un PC Sistemas de Control Automático Práctica 3. Control de un PLC mediante tramas Host-Link Jorge Pomares Baeza Carlos Alberto Jara Bravo Grupo de Innovación Educativa en Automática 2011 GITE IEA - 1 - Introducción

Más detalles

PROCESO DE SIMULACIÓN EN PROTEUS

PROCESO DE SIMULACIÓN EN PROTEUS USB PROCESO DE SIMULACIÓN EN PROTEUS Departamento de Electrónica Fundación San Valero Microchip PIC18F4550 1 Microchip Firmware PIC18F4550 La velocidad de transferencia a ido aumentando rápidamente a lo

Más detalles

Adaptador USB a LPT para la recuperación de equipos de rehabilitación

Adaptador USB a LPT para la recuperación de equipos de rehabilitación Adaptador USB a LPT para la recuperación de equipos de rehabilitación Javier Barragan; Fernando Anaut, Jorge Osio* 1 ; José Rapallini 1 ; Flavio Ferrari 2 ; Facultad de Ingeniería - Universidad Nacional

Más detalles

Guía de Usuario Programador USB

Guía de Usuario Programador USB Guía de Usuario Programador USB Tecnología Digital del Bajío Av. Vicente Guerrero 1003, Int. A Irapuato, Gto. Mex. C.P. 36690 Teléfono: (462) 145 35 22 www.tecdigitaldelbajio.com i Guía de Usuario, Programador

Más detalles

Lo que necesitaremos para programar en Java, será un editor de texto o IDE y la JDK.

Lo que necesitaremos para programar en Java, será un editor de texto o IDE y la JDK. Introducción Java surgió en 1991 dentro de la empresa Sun Microsystems como un lenguaje de programación sencillo y universal destinado a electrodomésticos. La reducida potencia de cálculo y memoria de

Más detalles

CONFIGURACIÓN TCP/IP DE TARJETA ETHERNET EN LINUX (tipo Debian) y VERIFICACIÓN BÁSICA DE FUNCIONAMIENTO.

CONFIGURACIÓN TCP/IP DE TARJETA ETHERNET EN LINUX (tipo Debian) y VERIFICACIÓN BÁSICA DE FUNCIONAMIENTO. CONFIGURACIÓN TCP/IP DE TARJETA ETHERNET EN LINUX (tipo Debian) y VERIFICACIÓN BÁSICA DE FUNCIONAMIENTO. Recuerde que para la asignatura de Redes de Área Local cada pareja de alumnos es responsable del

Más detalles

Revista Espectro Tecnológico / Instituto de Ingeniería y Tecnología / Universidad Autónoma de Ciudad Juárez 1

Revista Espectro Tecnológico / Instituto de Ingeniería y Tecnología / Universidad Autónoma de Ciudad Juárez 1 Revista Espectro Tecnológico / Instituto de Ingeniería y Tecnología / Universidad Autónoma de Ciudad Juárez 1 PROTOTIPO DE LECTOR DE CODIGOS DE ERROR EN EL SISTEMA AUTOMOTRIZ Jesús Armando Holguín López,

Más detalles

En el presente capítulo se describe la programación del instrumento virtual y cómo

En el presente capítulo se describe la programación del instrumento virtual y cómo Capítulo 6. Instrumentación virtual En el presente capítulo se describe la programación del instrumento virtual y cómo éste controla el circuito de captura de señales, la llamada telefónica y escribe los

Más detalles

INSTRUMENTACIÓN AVANZADA Departamento de Ingeniería Eléctrica y Electromecánica Facultad de Ingeniería Universidad Nacional de Mar del Plata

INSTRUMENTACIÓN AVANZADA Departamento de Ingeniería Eléctrica y Electromecánica Facultad de Ingeniería Universidad Nacional de Mar del Plata Problema a resolver Ejercicio 2.1 Tomando el ejercicio 1.4 realizar los ajustes necesarios para que además de encenderse un LED en pantalla se encienda un LED físicamente sobre la placa PIC suministrada

Más detalles

UTILIZACIÓN DEL OSCILOSCOPIO EN EL AUTOMÓVIL

UTILIZACIÓN DEL OSCILOSCOPIO EN EL AUTOMÓVIL UTILIZACIÓN DEL OSCILOSCOPIO EN EL AUTOMÓVIL AUTORÍA JESÚS DÍAZ FONSECA TEMÁTICA MANTENIMIENTO DE VEHÍCULOS AUTOPROPULSADOS ETAPA FORMACIÓN PROFESIONAL Resumen En el siguiente artículo se expondrá la importancia

Más detalles

PROCEDIMIENTOS PARA LA INSTALACIÓN DEL SOFTWARE SISTEMA RED. Junio 2010 MINISTERIO DE TRABAJO E INMIGRACIÓN TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

PROCEDIMIENTOS PARA LA INSTALACIÓN DEL SOFTWARE SISTEMA RED. Junio 2010 MINISTERIO DE TRABAJO E INMIGRACIÓN TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL SUBDIRECCIÓN GENERAL DE RECAUDACIÓN PROCEDIMIENTOS PARA LA INSTALACIÓN DEL SOFTWARE SISTEMA RED Junio 2010 MINISTERIO DE TRABAJO E INMIGRACIÓN TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL INDICE 1 INTRODUCCIÓN...

Más detalles

LEGO Mindstorms NTX 2.0 Lenguajes de Programación. UCR ECCI CI-2657 Robótica Prof. M.Sc. Kryscia Daviana Ramírez Benavides

LEGO Mindstorms NTX 2.0 Lenguajes de Programación. UCR ECCI CI-2657 Robótica Prof. M.Sc. Kryscia Daviana Ramírez Benavides LEGO Mindstorms NTX 2.0 Lenguajes de Programación UCR ECCI CI-2657 Robótica Prof. M.Sc. Kryscia Daviana Ramírez Benavides Introducción El Software del NXT es un lenguaje visual fácil de usar. Sin embargo,

Más detalles

COMO CREAR UNA RED ENTRE WINDOWS VISTA Y WINDOWS XP

COMO CREAR UNA RED ENTRE WINDOWS VISTA Y WINDOWS XP COMO CREAR UNA RED ENTRE WINDOWS VISTA Y WINDOWS XP 1.- Introducción. 2.- Códigos de color del conector RJ45. 3.- Requisitos del sistema. 4.- Elección de la tarjeta de red. 5.- Instalación del adaptador.

Más detalles

Comunicación NS12 y 3G3MV a través del GateWay

Comunicación NS12 y 3G3MV a través del GateWay Informe Técnico Comunicación Guía entre Rápida NS12 y 3G3MV a través del GateWay 1. Introducción 2. GateWay 3. Conexiones 4. Parametrizaje 3G3MV 5. Software GateWay 6. Configuración del NS 7. Uso de la

Más detalles

Practica de Control y Programación de Robots ROBOT HERMES. Curso 2007-2008

Practica de Control y Programación de Robots ROBOT HERMES. Curso 2007-2008 Practica de Control y Programación de Robots ROBOT HERMES Curso 2007-2008 CAMPUS TECNOLÓGICO DE LA UNIVERSIDAD DE NAVARRA NAFARROAKO UNIBERTSITATEKO CAMPUS TEKNOLOGIKOA Paseo de Manuel Lardizábal 13. 20018

Más detalles

EL POLÍMETRO. HERRAMIENTA BÁSICA Y FUNDAMENTAL PARA EL ELECTROMECÁNICO

EL POLÍMETRO. HERRAMIENTA BÁSICA Y FUNDAMENTAL PARA EL ELECTROMECÁNICO EL POLÍMETRO. HERRAMIENTA BÁSICA Y FUNDAMENTAL PARA EL ELECTROMECÁNICO AUTORÍA JESÚS DÍAZ FONSECA TEMÁTICA MANTENIMIENTO DE VEHÍCULOS AUTOPROPULSADOS ETAPA FORMACIÓN PROFESIONAL Resumen En el siguiente

Más detalles

ANEXO D X-CTU CONFIGURATION & TEST UTILITY SOFTWARE. Technical Support: Online support: http://www.digi.com/support/eservice/login.

ANEXO D X-CTU CONFIGURATION & TEST UTILITY SOFTWARE. Technical Support: Online support: http://www.digi.com/support/eservice/login. ANEXO D X-CTU CONFIGURATION & TEST UTILITY SOFTWARE Technical Support: Online support: http://www.digi.com/support/eservice/login.jsp TABLA DE CONTENIDO 1. INTRODUCCION... 2 2. PC SETTINGS... 3 2.1 COM

Más detalles

FSA. La solución sencilla para el diagnóstico complejo en vehículos. Mejor Bosch.

FSA. La solución sencilla para el diagnóstico complejo en vehículos. Mejor Bosch. Bosch Diagnostics: Nuestro conocimiento es su éxito. FSA. La solución sencilla para el diagnóstico complejo en vehículos. Mejor Bosch. NUEVO! Automotive Diagnosis Bosch Software Equipos de Formación Hotline

Más detalles

U.T.4.EL ENTORNO DE DESARROLLO

U.T.4.EL ENTORNO DE DESARROLLO U.T.4.EL ENTORNO DE DESARROLLO Lenguaje Java Estamos en unos días en los que cada vez más la informática invade más campos de nuestra vida, estando el ciudadano medio cada vez más familiarizado con términos

Más detalles

USB. Teoría. INGENIERIA EN MICROCONTROLADORES Protocolo USB (UNIVERSAL SERIAL BUS) Protocolo

USB. Teoría. INGENIERIA EN MICROCONTROLADORES Protocolo USB (UNIVERSAL SERIAL BUS) Protocolo Protocolo USB INGENIERIA EN MICROCONTROLADORES Protocolo USB (UNIVERSAL SERIAL BUS) Teoría PROTOCOLO USB www.i-micro.com Ingeniería en Microcontroladores Teléfono 044 55 11 29 55 05 E-mail: cursos@i-micro.com

Más detalles

MANUAL DE USUARIO ARDUINO DMX MASTER SHIELD MCI-TDD-01588 REV. 1.0

MANUAL DE USUARIO ARDUINO DMX MASTER SHIELD MCI-TDD-01588 REV. 1.0 MANUAL DE USUARIO ARDUINO DMX MASTER SHIELD MCI-TDD-01588 REV. 1.0 Ingeniería MCI Ltda. Luis Thayer Ojeda 0115 of. 1105, Providencia, Santiago, Chile. MANUAL DE USUARIO ARDUINO DMX MASTER SHIELD Página

Más detalles

ACTUALIZACION MANUAL: MODO OFFLINE (Ejemplo: WINDOWS 7-32 bits):

ACTUALIZACION MANUAL: MODO OFFLINE (Ejemplo: WINDOWS 7-32 bits): ACTUALIZACION MANUAL: MODO OFFLINE (Ejemplo: WINDOWS 7-32 bits): Si el cliente no dispone de conexión a internet en el ordenador conectado a la TRS 5000 EVO, se puede dar de alta en la web de JMA, siempre

Más detalles

Secuenciador de Luces

Secuenciador de Luces Basic para Pics Ing. Wilfrido González Bonilla www.electronicaestudio.com Muchos aficionados a la electrónica aun no se animan a aprender a manejar los microcontroladores PIC debido a la creencia de que

Más detalles

Centro Universitario de Ciencias Exactas e Ingenierías DIVISION DE ELECTRONICA Y COMPUTACION

Centro Universitario de Ciencias Exactas e Ingenierías DIVISION DE ELECTRONICA Y COMPUTACION SISTEMA DE MONITOREO POR INTERNET CON ENVÍO DE IMÁGENES Ricardo Hernández Durán (Ingeniería en Comunicaciones y Electrónica) Gabriela Ramos Rosas (Licenciatura en Informática) Víctor Jiménez García (Ingeniería

Más detalles

IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes

IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes 1 Objetivos Ingeniería Técnica Informática de Sistemas Curso 2003/2004 En la presente sesión se pretende familiarizar al alumno

Más detalles

Desarrollo de una interfaz RS-232 para el manejo de un coche de radiocontrol desde el PC

Desarrollo de una interfaz RS-232 para el manejo de un coche de radiocontrol desde el PC Desarrollo de una interfaz RS-232 para el manejo de un coche de radiocontrol desde el PC A. Muñoz, A. Millan, P. Ruiz-de-Clavijo, J. Viejo, E. Ostua, D. Guerrero Grupo ID2 (Investigación y Desarrollo Digital).

Más detalles

Tema: Introducción a Java y Netbeans

Tema: Introducción a Java y Netbeans 1 Tema: Introducción a Java y Netbeans Objetivo Especifico Conocer el uso básico del JDK para la compilación y ejecución de código java desde la linea de comando Conocer el entorno de desarrollo NetBeans

Más detalles

V5.05 Manual de Usuario CRecorder V1.00.000 20110610

V5.05 Manual de Usuario CRecorder V1.00.000 20110610 V5.05 Manual de Usuario CRecorder V1.00.000 20110610 i Contenido Introducción Breve... 1 Funciones... 1 Composición del producto... 1 Registro, descarga e instalación... 2 Proceso de registro de usuario...

Más detalles

10. - Programación del sistema de supervisión con Vijeo Citect 6.10.

10. - Programación del sistema de supervisión con Vijeo Citect 6.10. 10. - Programación del sistema de supervisión con Vijeo Citect 6.10. 0. Introducción Vijeo Citect es una solución HMI/SCADA (Human Machine Interface / Supervisory Control and Data Acquisition) para la

Más detalles

INFORME DE ESTACIÓN DE MONITOREO DE TEMPERATURA GRUPO LAJUCALE

INFORME DE ESTACIÓN DE MONITOREO DE TEMPERATURA GRUPO LAJUCALE INFORME DE ESTACIÓN DE MONITOREO DE TEMPERATURA GRUPO LAJUCALE LAURA ANDREA (G11NL38laura) LEONARDO CORREA (G11NL08leonardo) JUAN GALVIS (G10NL15juan) CAMILO VALENCIA (G10NL38Camilo) Informe realizado

Más detalles

T3-Rondas V 1.1. Help-Pc, S.L. C/ Pintor Pau Roig, 39 L-5 08330 Premià de Mar Barcelona Tel. (93) 754 90 19 Fax 93 752 35 18 marketing@t2app.

T3-Rondas V 1.1. Help-Pc, S.L. C/ Pintor Pau Roig, 39 L-5 08330 Premià de Mar Barcelona Tel. (93) 754 90 19 Fax 93 752 35 18 marketing@t2app. T3-Rondas V 1.1 1 Indice 1 Requisitos mínimos 3 2 Instalación 3 2.1 Instalación del software 3 2.2 Instalación del terminal 4 3 Configuración Inicial 4 3.1 Crear terminales 5 3.2 Crear puntos de lectura

Más detalles

ACTUALIZACION AUTOMATICA: MODO ONLINE (Ejemplo: WINDOWS 7-32 bits):

ACTUALIZACION AUTOMATICA: MODO ONLINE (Ejemplo: WINDOWS 7-32 bits): ACTUALIZACION AUTOMATICA: MODO ONLINE (Ejemplo: WINDOWS 7-32 bits): Una vez se haya instalado el software de PC de la TRS5000, se arranca el programa bien automáticamente desde el propio instalador (launch

Más detalles

Manual de Instalación de BioClock

Manual de Instalación de BioClock www.biotracksoftware.com 1 TABLA DE CONTENIDOS 1 ANTES DE INSTALAR... 1 1.1 NOTA... 1 1.2 PANEL DE OPERACIÓN DEL DISPOSITIVO... 2 1.3 PUERTOS DE ALIMENTACIÓN ELÉCTRICA Y COMUNICACIÓN... 3 1.4 CONTENIDO

Más detalles

USO DEL SOFTWARE PROVIEW 32

USO DEL SOFTWARE PROVIEW 32 USO DEL SOFTWARE PROVIEW 32 Como primera parte se hace la instalación del software Proview 32, observando: Se da clic en el ejecutable y se inicia la instalación. La clave de software viene en el archivo

Más detalles

LCD. Las pantallas de cristal líquido o módulos LCD, como. Módulo. con interface serial

LCD. Las pantallas de cristal líquido o módulos LCD, como. Módulo. con interface serial Módulo Módulo LCD con interface serial LCD con interface serial EDISON DUQUE C. Este módulo permite mostrar, en una pantalla de cristal líquido, los mensajes que son enviados desde una computadora o un

Más detalles

Red Digital de Servicios Integrados (RDSI/ISDN)

Red Digital de Servicios Integrados (RDSI/ISDN) Universidad Francisco de Paula Santander Departamento de Sistemas e Informática ACADEMIA LOCAL CISCO CURSO CCNA Red Digital de Servicios Integrados (RDSI/ISDN) 1 de Mayo de 2004 Tabla de contenidos INTRODUCCIÓN...

Más detalles

Sistema eléctrico 54.00

Sistema eléctrico 54.00 Sistema eléctrico 54.00 Información general Introducción a la multiplexión El término "multiplexión" describe cómo funciona el sistema eléctrico del vehículo. Se define la multiplexión como el enviar múltiples

Más detalles

Página 1 de 16. Utilización del Osciloscopio para electromecanicos

Página 1 de 16. Utilización del Osciloscopio para electromecanicos Página 1 de 16 Utilización del Osciloscopio para electromecanicos Los multímetros digitales son un instrumento totalmente eficaz para la comprobación estática de circuitos y para casos en que los cambios

Más detalles

Gestor de aplicaciones Java. Esta herramienta es el intérprete de los archivos de clase generados por el javac (compilador).

Gestor de aplicaciones Java. Esta herramienta es el intérprete de los archivos de clase generados por el javac (compilador). CAPÍTULO 4 Requerimientos de software Este capítulo presenta las herramientas necesarias para la construcción y ejecución de programas en el lenguaje de programación JAVA, los requerimientos mínimos de

Más detalles

Autenticación LDAP - ORACLE

Autenticación LDAP - ORACLE I.E.S. Gonzalo Nazareno Autenticación LDAP - ORACLE Sistemas Gestores de Bases de Datos Pier Alessandro Finazzi José Manuel Ferrete Benítez 2011 Índice Oracle Identity Management... 3 Por qué Oracle Identity

Más detalles

Guía Práctica: Como configurar el SYRUS para trabajar con www.visioanairegps.com Rev. 1.0

Guía Práctica: Como configurar el SYRUS para trabajar con www.visioanairegps.com Rev. 1.0 Guía Rápida de Configuración de Equipo SYRUS. Página 1 de 24 Guía Práctica: Como configurar el SYRUS para trabajar con www.visioanairegps.com Rev. 1.0 Guía Rápida de Configuración de Equipo SYRUS. Página

Más detalles

PROGRAMACION ORIENTADA A OBJETOS CON PHP

PROGRAMACION ORIENTADA A OBJETOS CON PHP PROGRAMACION ORIENTADA A OBJETOS CON PHP COMO SE DEFINE EN PHP La programación orientada a objetos es una metodología de programación avanzada y bastante extendida, en la que los sistemas se modelan creando

Más detalles

Qué es Java? Introducción a Java. Lenguajes Orientados a Objetos. Qué es Java? Historia de Java. Objetivos de Java

Qué es Java? Introducción a Java. Lenguajes Orientados a Objetos. Qué es Java? Historia de Java. Objetivos de Java Qué es? Introducción a es Un lenguaje de programación Un entorno de desarrollo Un entorno de ejecución de aplicaciones Un entorno de despliegue de aplicaciones Utilizado para desarrollar, tanto applets

Más detalles

ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA ELÉCTRICA TESIS PREVIA A LA OBTENCIÓN DEL TITULO DE INGENIERO EN ELECTRÓNICA Y CONTROL

ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA ELÉCTRICA TESIS PREVIA A LA OBTENCIÓN DEL TITULO DE INGENIERO EN ELECTRÓNICA Y CONTROL ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA ELÉCTRICA TESIS PREVIA A LA OBTENCIÓN DEL TITULO DE INGENIERO EN ELECTRÓNICA Y CONTROL DISEÑO Y CONSTRUCCIÓN DE UN PROTOTIPO DE UN PROGRAMADOR PARA MICROCONTROLADORES

Más detalles

Hagamos nuestros propios Arduinos

Hagamos nuestros propios Arduinos Hagamos nuestros propios Arduinos Como hemos visto a lo largo de las clases, Arduino es una placa extraordinariamente difundida gracias a sus múltiples virtudes, que todos conocemos. Si bien no es demasiado

Más detalles

Guía del usuario para DS150E con Win7. Dangerfield February. 2010 V1.0 Delphi PSS

Guía del usuario para DS150E con Win7. Dangerfield February. 2010 V1.0 Delphi PSS Guía del usuario para DS150E con Win7 1 ÍNDICE Componentes principales.... 3 Instrucciones de instalación...5 Instalación de Bluetooth...17 Configuración de Bluetooth..29 Programa de diagnóstico...42 Archivo.44

Más detalles

Introducción a la Programación en Java. Page 1

Introducción a la Programación en Java. Page 1 Introducción a la Programación en Java Page 1 Qué es Java? Java es un lenguaje de programación de propósito general, orientado a objetos que fue diseñado específicamente para tener tan pocas dependencias

Más detalles

Programando con SinaProg. Manual de usuario para programar microcontroladores Atmel AVR en Windows con SinaProg

Programando con SinaProg. Manual de usuario para programar microcontroladores Atmel AVR en Windows con SinaProg Programando con SinaProg Manual de usuario para programar microcontroladores Atmel AVR en Windows con SinaProg Este documento se encuentra protegido por una licencia Creative Commons Creative Commons:

Más detalles

VIII. CONTROL USANDO SIMULINK Y ARDUINO

VIII. CONTROL USANDO SIMULINK Y ARDUINO VIII. CONTROL USANDO SIMULINK Y ARDUINO Los entornos de Diseño de Sistemas de Control Asistido por Ordenador (CACSD) están experimentando notables cambios durante los últimos años. Estos avances afectan

Más detalles

MANUAL DE USUARIO CENTRO DE CONTROL DE FLOTAS MU-CCF-021-SN AGOSTO 2000 EDICIÓN: 1 REVISIÓN: 0

MANUAL DE USUARIO CENTRO DE CONTROL DE FLOTAS MU-CCF-021-SN AGOSTO 2000 EDICIÓN: 1 REVISIÓN: 0 CENTRO DE CONTROL DE FLOTAS MANUAL DE USUARIO MU-CCF-021-SN EDICIÓN: 1 ÍNDICE 1 INTRODUCCIÓN... 1.1 2 FUNCIONALIDAD... 2.1 3 REQUISITOS DEL SISTEMA... 3.1 4 INSTALACIÓN DEL PROGRAMA... 4.1 5 MANEJO DEL

Más detalles

ISP (Programación en sistema) de los microcontroladores de NXP (Philips) 89LPC9XX utilizando Flash Magic y la UART (puerto serie) del microcontrolador

ISP (Programación en sistema) de los microcontroladores de NXP (Philips) 89LPC9XX utilizando Flash Magic y la UART (puerto serie) del microcontrolador ISP (Programación en sistema) de los microcontroladores de NXP (Philips) 89LPC9XX utilizando Flash Magic y la UART (puerto serie) del microcontrolador Patricio Coronado, SEGAINVEX ELECTRONICA (Universidad

Más detalles

Módulo CJ1W-ETN11 GUIA RAPIDA ESTE MANUAL CONTIENE: 1.- CARACTERÍSTICAS 2.- INSTALACIÓN Y CONFIGURACIÓN DEL MÓDULO 3.- CONFIGURACIÓN DEL MÓDULO

Módulo CJ1W-ETN11 GUIA RAPIDA ESTE MANUAL CONTIENE: 1.- CARACTERÍSTICAS 2.- INSTALACIÓN Y CONFIGURACIÓN DEL MÓDULO 3.- CONFIGURACIÓN DEL MÓDULO GUIA RAPIDA Módulo CJ1W-ETN11 ESTE MANUAL CONTIENE: 1.- CARACTERÍSTICAS 2.- INSTALACIÓN Y CONFIGURACIÓN DEL MÓDULO 3.- CONFIGURACIÓN DEL MÓDULO CON CX-PROGRAMMER 4.- CORREO 5.- EJEMPLO DE CONFIGURACIÓN

Más detalles

Software EasyKool. Manual de instrucciones

Software EasyKool. Manual de instrucciones Software EasyKool Manual de instrucciones 2 1 Índice 1 Índice 1 Índice... 3 1.1. Indicaciones sobre este manual... 5 2 Especificaciones... 5 2.1. Uso... 5 2.2. Requisitos del sistema... 6 3 Primeros pasos...

Más detalles

SIMULACION DE UN ENTORNO Y MEMORIA VIRTUAL PARA UNA PLATAFORMA KHEPERA. Leonardo Solaque Nelson D. Muñoz Nelson Londoño Ospina

SIMULACION DE UN ENTORNO Y MEMORIA VIRTUAL PARA UNA PLATAFORMA KHEPERA. Leonardo Solaque Nelson D. Muñoz Nelson Londoño Ospina SIMULACION DE UN ENTORNO Y MEMORIA VIRTUAL PARA UNA PLATAFORMA KHEPERA Leonardo Solaque Nelson D. Muñoz Nelson Londoño Ospina GIRA 2 (Grupo de Investigación en Robótica y Areas Afines) Universidad de Antioquia

Más detalles

GUÍA DE INSTALACIÓN Y REFERENCIA ECR8200PROGRAMMING UTILITY. Code: 569800

GUÍA DE INSTALACIÓN Y REFERENCIA ECR8200PROGRAMMING UTILITY. Code: 569800 GUÍA DE INSTALACIÓN Y REFERENCIA ECR8200PROGRAMMING UTILITY E Code: 569800 PUBLICACIÓN EDITADA POR: Olivetti S.p.A. www.olivetti.com Copyright 2011, Olivetti Reservados todos los derechos Llamamos su atención

Más detalles

Herramientas hardware y software para el desarrollo de aplicaciones con Microcontroladores PIC bajo plataformas GNU/Linux

Herramientas hardware y software para el desarrollo de aplicaciones con Microcontroladores PIC bajo plataformas GNU/Linux Herramientas hardware y software para el desarrollo de aplicaciones con Microcontroladores PIC bajo plataformas GNU/Linux Juan González Gómez Escuela Politécnica Superior Universidad Autónoma de Madrid

Más detalles

Un circuito simple y un programa para mostrar las posibilidades de utilizar las salidas del Puerto paralelo.

Un circuito simple y un programa para mostrar las posibilidades de utilizar las salidas del Puerto paralelo. Un circuito simple y un programa para mostrar las posibilidades de utilizar las salidas del Puerto paralelo. Copyright Tomi Engdahl 1996-2000 El Puerto paralelo de una PC puede ser un canal muy útil de

Más detalles

AUTOR : ALEX CALDERÓN DIRECTOR: ING. GERMAN ERAZO CODIRECTOR: ING. MAURICIO CRUZ

AUTOR : ALEX CALDERÓN DIRECTOR: ING. GERMAN ERAZO CODIRECTOR: ING. MAURICIO CRUZ OPTIMIZACIÓN DE LA POTENCIA EN UN MOTOR DE COMBUSTIÓN INTERNA GASOLINA MEDIANTE EL CONTROL DE AJUSTES DE COMBUSTIBLE Y EL MONITOREO DEL SENSOR DE OXÍGENO AUTOR : ALEX CALDERÓN DIRECTOR: ING. GERMAN ERAZO

Más detalles

Fig. 5.143 Driver ATS, Configuración del controlador realizada. Realizados los ajustes, se procederá a definir el acceso al programa (Topic)

Fig. 5.143 Driver ATS, Configuración del controlador realizada. Realizados los ajustes, se procederá a definir el acceso al programa (Topic) 5 Fig. 5.143 Driver ATS, Configuración del controlador realizada Realizados los ajustes, se procederá a definir el acceso al programa (Topic) Fig. 5.144 Driver ATS, Ventana de configuración del acceso

Más detalles

FUNDAMENTOS DE INFORMATICA

FUNDAMENTOS DE INFORMATICA FUNDAMENTOS DE INFORMATICA TEMAS QUE SE TRATARÁN: Arquitectura Interna Sistemas Operativos Programación en Visual Basic Bases de Datos Redes e Internet 1 FUNDAMENTOS DE INFORMATICA Tema 1: Arquitectura

Más detalles

INSTALACION DE ESITRONIC

INSTALACION DE ESITRONIC INSTALACION DE ESITRONIC Indice: Instalacion ESI version 2009/1 - Pag 2 Conexion y Configuracion del equipo KTS - Pag 8 Configuración y conexión del Bluetooth - Pag 17 Solicitar y cargar el codigo de Acceso

Más detalles

MANUAL DE INSTALACIÓN Y OPERACIÓN DE TABLERO DE MONITOREO REMOTO INSPECTOR II. 1. Presentación:

MANUAL DE INSTALACIÓN Y OPERACIÓN DE TABLERO DE MONITOREO REMOTO INSPECTOR II. 1. Presentación: INDICE 1. Presentación:... 2 2. Instalación del tablero de Monitoreo:... 3 3. Operación del Tablero Inspector II... 4 4. Instalación del Software de Monitoreo Remoto:... 7 I. Instalación del.net Framework...

Más detalles

CAPÍTULO 2. La Instrumentación

CAPÍTULO 2. La Instrumentación CAPÍTULO 2 La Instrumentación La implementación en el laboratorio del sistema péndulo-carro que describimos en el capítulo anterior presenta algunos retos de instrumentación cuya solución no es sencilla.

Más detalles

Ejemplo práctico de instalación del programa JCLIC en red

Ejemplo práctico de instalación del programa JCLIC en red Ejemplo práctico de instalación del programa JCLIC en red Una red local permite optimizar los recursos, tanto en relación al espacio (los programas se pueden colocar en el disco duro del servidor y ser

Más detalles

Guía para construir un programador y una mini placa de desarrollo para el microcontrolador PIC

Guía para construir un programador y una mini placa de desarrollo para el microcontrolador PIC Guía para construir un programador y una mini placa de desarrollo para el microcontrolador PIC Rafael Fernández Andrés Aguirre Introducción: Esto de ninguna manera pretende ser una guía completa de como

Más detalles

MANUAL DE INSTALACIÓN

MANUAL DE INSTALACIÓN CADUSB y Programas de Microsoft Excel para lectores de presiómetro ELx MANUAL DE INSTALACIÓN Versión 1.0 - Rev 1 Fecha de Revisión: Abril 2011 Versión 1.0 Rev 1 - Abril 2011 TABLA DE CONTENIDOS INFORMACIÓN

Más detalles

Guía de Usuario Convertidor USB-Serial

Guía de Usuario Convertidor USB-Serial Guía de Usuario Convertidor USB-Serial Tecnología Digital del Bajío Av. Vicente Guerrero 1003 Irapuato, Gto. Mex. C.P. 36690 Teléfono: (462) 145 35 22 www.tecdigitaldelbajio.com ventas@tecdigitaldelbajio.com

Más detalles

SENTINEL REMOTE CONTROL (S.R.C)

SENTINEL REMOTE CONTROL (S.R.C) SENTINEL REMOTE CONTROL (S.R.C) Versión G-0.5 Índice de contenidos 0.Consideraciones acerca de este producto...3 1.Objetivo del SRC...3 2.0 Instalación...3 2.1.Parte cliente (gclient)...4 2.1.Parte servidora

Más detalles