Академический Документы
Профессиональный Документы
Культура Документы
INGENIERÍA ELECTRÓNICA
POR
Erika Febres Urdaneta
Proyecto de Pasantía
Presentado ante la Ilustre Universidad Simón Bolívar
Como requisito Parcial para Optar al Titulo de
Ingeniero Electrónico
i
PROTOCOLO DE COMUNICACION HART
Para los instrumentos de FLOTECH S.A.
por
Erika Febres Urdaneta
Tutor Académico: Guillermo Villegas.
Tutor Industrial: Gerardo Febres.
RESUMEN
ii
A mi Familia
Gabriel, Lia, Yuribé y Deborah
Mi hermano Pedro Rondón
iii
AGRADECIMIENTOS
A mi Tutor Académico Guillermo Villegas, por sus enseñanzas y diferentes propuestas de
solución a mis problemas, no solo durante la pasantía, sino a lo largo de mis años de estudios.
A mi Padre Gabriel Febres, por el apoyo y ayuda en el diseño del circuito e implementación
del proyecto en todo momento, a pesar de la distancia.
A mi familia en general, por darme fuerzas para culminar mis estudios y el proyecto de
pasantía, al recordarme cada día que debía esforzarme y concentrarme en mi trabajo, obviando todo
aquello ajeno a éste.
A mi hermano Pedro, ya que sin él no lo hubiese logrado. Por todo su ingenio, del cual durante
años e aprendido miles de cosas útiles al momento de diseñar y ensamblar tanto programas como
circuitos.
A mi novio Jonathan Bartolotta, por toda su ayuda cuando el programa no quería funcionar, el
apoyo moral en las noches sin fin y su cariño siempre presente.
iv
INDICE GENERAL
1.1.-Objetivo general…………………………………………………………………2
1.2.-Objetivos específicos…………………………………………………………..2
v
2.3- Procedimiento de transacciones, código y estructura del mensaje…...13
vi
3.3.- Programas del microcontrolador ( firmware)……………………………..42
5.1.- Conclusiones……………………………………………………………………59
5.2.- Recomendaciones……………………………………………………………...60
REFERENCIAS BIBLIOGRÁFICAS………………………………………….61
ANEXOS…………………………………………………………………………62
vii
INDICE DE FIGURAS
ix
INDICE DE TABLAS
x
CAPITULO 1.-INTRODUCCIÓN
En las industrias con equipos de campo, como las petroleras y procesadoras, es necesaria la
lectura permanente de variables diversas de sus estanques, tuberías o máquinas para evitar pérdidas
del producto, accidentes o simplemente una falta de eficiencia en la producción. Estas mediciones en
un principio eran manuales, y se requería de un vasto personal para poder controlar toda la fabrica,
planta de producción o campo de extracción. Con el tiempo, y el desarrollo de la tecnología se
crearon sensores electrónicos que permitían la lectura de las variables de un modo más conveniente, e
incluso la transmisión de las mismas a un equipo central. Una de estas formas de comunicación es el
lazo de 4 a 20 mA, un lazo de corriente que al cual dependiendo del valor medido por el sensor, se le
asigna un nivel de corriente en mA, es decir, 4 mA equivaldría al menor valor posible de la variable
medida y 20 mA al máximo. En la actualidad, el mundo se ve afectado por la digitalización de la
información y estos procedimientos y medios de medición no se ven excluidos de la misma. Con el
tiempo se han implementado en el campo e industrias otros métodos para poder realizar las
mediciones de modo remoto, sin la necesidad de ir al campo, y que a su vez permitan la transmisión
de una información detallada del equipo y sus funciones. Una de las actuales formas de comunicar
dispositivos es mediante el protocolo Hart, ideado por Fisher Rosemount.
La empresa Flotech S.A., es una empresa venezolana con años de funcionamiento, que presta
servicios a una de las principales extractoras de petróleo del país, PDVSA (Petróleos de Venezuela
S.A.). Siendo Flotech S.A. una empresa que pretende implementar en sus equipos todos los avances
tecnológicos posibles, y bajo petición de PDVSA, de equipos que trabajaran con el protocolo; se hace
necesaria la creación de un nuevo equipo digital con capacidad HART.
Los dispositivos de la empresa se fabricaran de modo que el sensor contenga dos tarjetas
impresas, una de ellas analógica (que no ha sido aún diseñada) y la otra digital. El diseño de la tarjeta
digital es el objetivo principal de este proyecto, sin embargo no es el único, ya que para poder realizar
pruebas e incluso para llevar acabo el proceso de diseño es necesaria una interfaz (software) para el
terminal maestro, que en este caso será un computador personal. Para ilustrar esto el sistema se
muestra en la figura 1.1.
Para poder desarrollar este proyecto se requieren conocimientos a fondo del protocolo HART
y de los materiales o equipos que la empresa pretende utilizar para la implementación de esta
capacidad de comunicación. En el siguiente libro, encontrará toda la información necesaria, además
de las diferentes actividades realizadas para llevar acabo este proyecto: Implementar el Protocolo de
Comunicación HART en los instrumentos de FLOTECH S.A.
Realizar el diseño de la tarjeta digital y la interfaz de usuario del maestro para introducir el
protocolo de comunicación HART en los dispositivos o medidores de nivel y flujo de la empresa
venezolana Flotech S.A.
2
• Diseñar un programa (software) para el maestro, en este caso un computador personal,
que se utilice en la empresa para calibrar y probar los equipos que se venderán.
• El capítulo 3 describe el diseño del circuito digital, del programa del microcontrolador o
el firmware, y del programa del computador. La primera sección describe el hardware:
los circuitos integrados utilizados, el diseño del circuito modulador, el circuito
generador del lazo de corriente, el conversor análogo digital y la interconexión con el
microcontrolador y el computador personal. Luego, en la segunda sección, se menciona
las diferentes rutinas del microcontrolador o firmware, se describe el método de
desarrollo y las funciones de cada una de estas. Finalmente, la creación y el
funcionamiento de la interfaz gráfica para el terminal maestro en el PC (personal
computer ,computador personal).
• En el capítulo 4 encontrará los resultados del proyecto, una descripción general del
producto final obtenido al haber concluido el diseño y las pruebas que se realizaron para
verificar su funcionamiento. Se observa el sistema, con las conexiones pertinentes y las
respuestas que se visualizan en la interfaz del terminal maestro.
3
• El capítulo 5 incluye las conclusiones y recomendaciones, las cuales sirven para informar
al lector de mejoras futuras sobre el diseño, dado que el producto final es un prototipo y
no un diseño para producción masiva.
4
CAPITULO 2.- PROTOCOLO HART
En el siguiente capítulo encontrará toda la información necesaria, en el ámbito de diseño,
sobre el protocolo HART. En el ámbito de diseño implica que algunas de las secciones son muy
específicas.
5
Para hacer uso de estas ventajas, los dispositivos inteligentes requieren de un plug-in o
configurador, una caja con una cantidad de botones y una pantalla LCD (liquid cristal display) para
que el usuario pueda instalar y controlar el instrumento.
El próximo paso por lógica sería permitir que el instrumento y el panel de configuración
estuviesen separados por largas distancias, utilizando comunicaciones digitales seriales bien definidas
entre ellos. Luego se necesitaría incluir esta comunicación en los dos cables ya existentes para
controlar el dispositivo desde el cuarto de control. Esto es lo que nos lleva al uso actual de la palabra
inteligente según Fisher Rosemount, para describir dispositivos de campo en los cuales la señal
analógica, la señal digital y la alimentación del equipo, son transmitidas por el mismo par de cables.
Con tales instrumentos, se obtienen las ventajas de las comunicaciones digitales, mientras se
mantiene la compatibilidad con la señal analógica de entrada requerida por los sistemas actuales.
Ahora, utilizando comunicación digital, además de instalar y controlar de un modo más sencillo el
dispositivo de campo, es posible leer la variable medida y muchos otros parámetros a través de
conexiones punto a punto, como la que se presenta en la figura 2.1.
Conexión punto a punto se utiliza para referirse a casos en los que solo existe un maestro y un
esclavo, o un transmisor y un receptor. Entre los demás parámetros que se pueden incluir, se
encuentra la posibilidad de transmitir hasta cuatro variables, lo cual representa una ventaja ante
sistemas de transmisión de una única variable, entremos más en detalle en cuanto a este aspecto.
6
2.1.2.-Leyendo información mediante comunicación digital
La comunicación digital también hace que valga la pena mantener información adicional en el
instrumento de campo, para ser leída cuando sea necesario. Esto conlleva a una serie de posibilidades.
Nos puede dar información relativa al proceso como el identificador o etiqueta del dispositivo (tag),
una descripción de la medición, las unidades asociadas y rango de calibración del instrumento. O
puede dar información sobre el dispositivo como tal, actuando como una etiqueta electrónica. Más
allá, puede ser utilizado para mantener historias de actividades relacionadas con mantenimiento como
la última fecha de calibración. La administración del sistema de instrumentos automatizados se hace
posible, utilizando información al día del dispositivo mismo.
Una manera más eficaz o eficiente de transmitir los datos sería aumentar el número de
dispositivos de campo conectados a un maestro, de modo que transite mayor información por el lazo.
Sin embargo, al conservar la medición en mA de la variable primaria, la conexión punto a punto es la
única solución , pero si se desea múltiples dispositivos se puede utilizar la conexión multipunto.
2.1.3.-Comunicación multipunto
Si una variable medida va a ser leída por comunicación digital, la señal analógica de 4-20mA
ya no es requerida. Se hace posible conectar múltiples dispositivos de campo en paralelo a un simple
par de cables, y comunicarse con cada uno por turnos para leer sus variables (u otros datos). Para
hacer esto, cada dispositivo debe tener una dirección, a la cual responderá, y cada petición del sistema
de control o maestro debe incluir dicha dirección. Un esquema de este tipo de conexión se puede
observar en la figura 2.2.
Esta conexión multipunto puede reducir de modo significativo los costos de instalación de
cableado de los equipos, y puede ser de valor en sistemas de monitoreo. Note, sin embargo, que el
tiempo entre mediciones de las variables de un mismo equipo aumentará. Ya que antes por un solo
par de cables transitaba la señal de un sensor, pero en el caso de multipunto de 2 a 15 señales
diferentes deberán turnarse el medio.
7
Figura 2.2 Conexión multipunto
El protocolo HART fue desarrollado por Rosemount INC. Con este propósito. HART es un
acrónimo para Highway Addressable Remote Transducer. Para difundir el uso de comunicación
digital en los dispositivos de campo, Rosemount Inc. a transferido todos sus derechos sobre el
protocolo HART a la Fundación de Comunicación HART (HCF, siglas en ingles) y está disponible
para el uso de cualquier compañía o persona.
A modo de resumen, HART utiliza una señal estándar de BELL, 202 codificada por
desplazamiento en frecuencia, para comunicar a 1200 baudios, superpuesta sobre la señal de medición
de 4-20mA. Teniendo un promedio de cero, la señal codificada por desplazamiento en frecuencia no
interfiere con la señal analógica. Para ilustrar esto observe la siguiente figura 2.3.
8
Figura 2.3 La señal HART.
Cada mensaje incluye las direcciones de su fuente y destino, para asegurarse de que es recibido
por el dispositivo correcto, y tiene una suma de verificación (checksum) para poder detectar cualquier
corrupción del mensaje. El estado del dispositivo de campo está incluido en cada mensaje de
respuesta, indicando su estado de operación correcto. Puede o no haber información o datos incluidos
en el mensaje, dependiendo del comando en particular. Dos o tres transacciones de mensajes se
pueden realizar cada segundo.
9
Figura 2.4 Estructura del mensaje HART
Para llevar a cabo diferentes funciones preestablecidas en un sensor, el protocolo hart utiliza los
comandos, el identificador de la función que se pretende realizar. Los comandos del protocolo HART
se definen en tres grupos. El primer grupo es el de comandos universales, y provee funciones que
están implementadas en todos los dispositivos de campo. El segundo grupo, comandos de práctica
común, provee funciones comunes a muchos dispositivos de campo, pero no todos. Si un dispositivo
implementa funciones que estos comandos describen, deberán ser invocadas mediante el número de
comando asignado por la Fundación Hart . El tercer grupo, comandos específicos de dispositivo
(anteriormente llamados específicos de transmisor), provee funciones que son mas o menos únicas
para un dispositivo particular.
10
2.2.1.-Modulación por desplazamiento o corrimiento en frecuencia:
Como ya se mencionó en la introducción (capítulo 1), HART utiliza modulación por
desplazamiento en frecuencia para superponer la señal digital al lazo de corriente analógica de 4-20
mA que conecta la central al dispositivo en el campo.
Estas señales sinusoidales son superpuestas en la señal DC a un nivel bajo. El promedio de las
señales sinusoidales es cero, por lo que al ser incluida en la señal analógica 4-20mA no altera la
misma, sin importar lo que la señal digital pueda contener. La tasa de transmisión de datos es de
1200baudios. Eso quiere decir, que los dígitos binarios se transmiten a una tasa de 1200 bits por
segundo. Esto significa que el 1 es representado por un ciclo de 1200Hz, mientras que el cero es
representado por aproximadamente dos ciclos de 2200Hz.
Dichas frecuencias cumplen con el estándar “Bell 202”, uno de los muchos utilizados para
transmitir información digital vía telefónica.
11
HART que se transmitan por cables adyacentes, o sistemas que no se encuentren bien conectados a
tierra o sistemas de alimentación.
La señal HART debe ser introducida y leída del lazo de corriente. La fuente de poder está casi
en corto circuito para las frecuencias de la señal Hart, por lo que dispositivos secundarios (como el
segundo maestro) no pueden ser conectados directamente al lazo, se deben conectar en paralelo al
transmisor o a la resistencia de carga, en la figura 2.5, entre los puntos A y B. Un equipo con
protocolo de comunicación Hart no debe introducir ninguna carga DC a la línea. Para asegurarse de
que así sea se debe conectar al lazo mediante un condensador de 5µF o más.
Algunos de los dispositivos de campo con lazo de 4-20mA son activos, es decir, estos son los
que alimentan el lazo. Con este tipo de dispositivos no hace falta la fuente de poder. En este caso en la
conexión se elimina la fuente.
12
2.2.4.-Conexión de múltiples dispositivos
Múltiples dispositivos pueden ser conectados al mismo maestro, ya que en los mensajes se
incluye la dirección de los dispositivos que se comunican. Al asignarle a los dispositivos direcciones
diferentes, una cantidad máxima de 15 dispositivos pueden ser conectados a un solo lazo. Las
consecuencias de este tipo de conexión son dos principalmente, retardo en la comunicación entre
maestro y dispositivo y pérdida de la señal analógica. Debido a la existencia de este tipo de
conexiones, existe la dirección de multipunto, que se asigna a cada dispositivo que este conectado en
paralelo, comenzando del cero al quince.
Entre otras de las especificaciones que requiere el protocolo Hart se encuentra la definición de
las cargas respectivas de los equipos (maestro primario resistencia de recepción 230-1100ohm,
resistencia de transmisión 700 ohms máximo). El límite de los 65ms, que hace que la frecuencia de
corte sea de 2500Hz (para 3dB de atenuación). Con lo anterior se impide retardos de la señal y de las
frecuencias que la componen. Especificaciones para el cableado, puestas a tierra, fuente de poder,
ancho de banda de la señal analógica, y más.
Sin embargo, estas especificaciones no son necesarias para el desarrollo del proyecto, puesto
que el equipo al que se incluirá el protocolo HART será incluido en una red ya existente, por
supuesto, deberá cumplir con las normas para esclavos que establezca el protocolo.
En esta sección se describe de modo más detallado los comandos del protocolo, los comandos
universales, los comandos de práctica común y los comandos de dispositivo específico. Incluyendo
los tipos de datos que corresponden a cada uno de estos. Los bytes de estado son aquellos que indican
errores en la comunicación, en esta sección se da a conocer el valor de estos y su significado.
13
que exista un maestro secundario, estos tiene direcciones diferentes, por lo cual pueden distinguir si la
respuesta es para el principal o secundario.
HART es un protocolo Half-Duplex, con lo cual se quiere decir que al terminar cada mensaje,
la portadora debe ser desactivada para permitir que la otra estación transmita. Las reglas de tiempo de
la portadora establecen que la portadora debe ser activada no más del tiempo de 5 bits antes del inicio
del mensaje (preámbulo) y ser desactivada no más del mismo tiempo después de la transmisión del
último byte del mensaje (la suma de verificación).
Para lograr una tasa de transmisión de datos mayor, algunos dispositivos utilizan el modo
ráfaga. Cuando un dispositivo se encuentra en este modo envía un mensaje repetidas veces. Este
modo se activa y desactiva mediante los comandos especiales #107, #108 y #109 (si se implementa el
modo ráfaga, los comandos básicos son #1 y #3, los demás son opcionales). Existe una pequeña pausa
entre mensaje y mensaje, para permitir que el maestro envíe la señal de desactivación, o para iniciar
cualquier otra transacción simple.
Este modo solo funciona para la configuración punto a punto, y se pueden enviar más de tres
mensajes por segundo. En la tabla 2.2 se encuentran las especificaciones de tiempo para los mensajes
en modo de ráfaga.
14
Dispositivo y tipo del mensaje Intervalo t
El maestro primario envía un comando >= 305 ms
El maestro secundario envía un comando >= 380 ms después de que la línea está desocupada
Esclavo en modo BURST envía mensaje >= 305 ms
Maestro sincronizado envía comando 20* - 75 ms después de la respuesta al otro maestro
>= 75 ms después de la respuesta a si mismo
Esclavo, modo normal, responde comando 0-256 ms después del comando
Esclavo en modo BURST envía mensaje 75-256 ms después de su mensaje anterior
0-20 ms después de que responde al comando
inicial "activar el modo BURST", después
de la respuesta a otro comando.
Tabla 2.2 Especificaciones de tiempo en modo de ráfaga
2.3.3.-Codificación de caracteres:
Los mensajes de Hart son codificados como series de 8 bits, es decir bytes. Estos se transmiten
de modo serial, utilizando una UART convencional (Universal Asynchronous Receiver/Transmitter)
para serializar cada byte, añadiendo un bit de inicio, un bit de paridad impar y un bit de fin, esto
permite que la UART receptora identifique el inicio de cada caracter, y para detectar errores en la
transmisión debidos a ruido u otro tipo de interferencia. La cadena completa de bits se muestra en la
siguiente figura 2.6.
El bit menos significativo, D0 se envía primero. La mayoría de los protocolos seriales permiten
pausas entre los caracteres, debido a las especificaciones de tiempo de Hart esto no es posible, de
ocurrir dicho retraso se asume que la comunicación no fue establecida.
15
Existen el formato largo y el formato corto. Los primeros instrumentos Hart (inclusive la
revisión 4) siempre utilizaron el formato corto. En este formato, la dirección del esclavo un byte, de
valor cero, para configuración punto-punto o del 0 al 15 para configuración multipunto. Esta corta
dirección se denomina dirección multipunto. La revisión 5 introduce el formato largo. En este, la
dirección del esclavo es un número de identificación único, un número de 38 bits derivado del código
del fabricante, el código del tipo de dispositivo y el número de identificación del dispositivo. Este
formato impide que los esclavos tomen mensajes que no le corresponden. De un modo estricto, el
identificador único, no es único, pueden haber hasta cuatro veces el mismo número, ya que del código
del fabricante solo se toman 6 bits, cuando el número en realidad consta de 8 bits.
La mayoría de los dispositivos maestros deben incluir ambos formatos en su totalidad, de modo
que puedan trabajar correctamente con los dispositivos ya existentes así como con los nuevos. La
revisión 5 establece que todos los dispositivos deben implementar el comando #0 ( leer identificación
única) en ambos formatos del mensaje. Un maestro normalmente utilizará el comando # 0 para la
primera conexión con el dispositivo, ya que en ese momento el número único de identificación no se
conoce, sin embargo como el mensaje también incluye el nivel de revisión de HART, el maestro sabrá
que formato deberá utilizar.
El preámbulo:
El caracter de inicio en Hart tiene diversos valores posibles, indicando cual formato está siendo
utilizado, la fuente del mensaje, y si es o no un mensaje tipo ráfaga. Estos se muestran en la tabla 2.3.
16
Tipo de mensaje Formato corto Formato largo
Maestro a esclavo 2 82
Esclavo a maestro 6 86
Mensaje BURST del esclavo 1 81
El campo de dirección contiene tanto la dirección del maestro como la del esclavo del mensaje
enviado. Esta contenida en un byte, para el formato corto y en 5 bytes para el formato largo. El bit
más significativo de la dirección, indica si el maestro es el primario (1) o el secundario (0) . Los
mensajes de tipo ráfaga son una excepción, en la cual el dispositivo alterna ambas direcciones, lo que
le da oportunidad a ambos maestros de interrumpir.
También en ambos formatos, el bit que le sigue al más significativo indica si el mensaje
proviene de un dispositivo en modo ráfaga, lo que no implica que el mensaje sea de tipo ráfaga. En el
formato corto, los dispositivos esclavos tienen direcciones de la cero a la quince. Este número se
incluye de modo binario en los 4 bits menos significativos del byte de dirección. En el formato largo,
la dirección de multipunto no es utilizada, en cambio, los 38 bits restantes de los cinco bytes del
campo de direcciones contienen el identificador único como una dirección. En las siguientes se puede
observar la estructura de las direcciones.
17
Figura 2.9 Estructura del formato largo
En la estructura de formato largo, si se asigna cero a todos los bits, se puede utilizar como un
mensaje de transmisión sin destinatario específico, un mensaje que sea aceptado por todos los
dispositivos; esto es solo posible si los datos en el mensaje determinan cual de los dispositivos debe
responder. Por ejemplo, el comando #11 (leer el identificador único asociado a la etiqueta)
normalmente utiliza direcciones de transmisión sin destinatario específico con una etiqueta en el
campo de datos, de modo que todos los dispositivos conectados reciben el mensaje pero solo uno de
ellos responde.
Comando:
Cuenta de bytes:
Este campo contiene un entero, que indica el número de bytes que forman el resto del mensaje
(eso es los campos de estado y de datos, la suma de verificación no se incluye). El dispositivo
receptor utiliza esto para identificar el byte de suma de verificación y saber cuando el mensaje está
completo. Como el campo de datos esta limitado a 25 bytes máximo, esta cuenta puede ser cualquier
número entre 0 y 27.
18
Estado:
Datos:
No todas las respuestas contienen datos. Para aquellas que si lo hacen, y de modo que cumplan
con las reglas de tiempo, el campo de datos no puede exceder los 25 bytes. Los datos pueden estar en
forma de enteros sin signo, números de punto flotante o cadenas de caracteres ASCII. El número de
bytes del campo de datos, y el formato de datos utilizado para cada ítem se especifican de acuerdo al
comando recibido.
19
Maestro a Esclavo:
Esclavo a Maestro:
20
Maestro a Esclavo:
Esclavo a Maestro:
21
Sección 2.4.- Comandos y datos respectivos, bytes de estado.
Los comandos universales se encuentran entre 0 y 30. Estos proveen funciones que son
implementadas en todos los dispositivos Hart. La tabla 2.4 contiene un resumen de estas funciones, la
tabla que se encuentra en el anexo 2 los describe de un modo mucho más detallado.
Comandos Función
0,11 Identificar dispositivo (fabricante, tipo de dispositivo, etiqueta de revisión)
1,2,3 Leer variables medidas
6 Establecer dirección de escaneo.(y modo multipunto).
12,13,17,18 Leer y escribir información introducida por el usuario (tag, fecha,mensaje)
14,15 Leer información del dispositivo (numero serial del sensor, límites del sensor,
operación de alarma, valores del rango, función de transferencia,
constante de tiempo de muestreo)
16,19 Leer y escribir número final de ensamble.
Los comandos #0 y #11, son utilizados para identificar un dispositivo de campo. Desde la
revisión 5, todos los equipos utilizan el formato largo, pero el comando #0 debe ser también aceptado.
Esto permite que el maestro Hart identifique un dispositivo nuevo, sin antes saber su número de
identificación único. Los datos en la respuesta al comando #0 incluyen el código de identificación del
22
fabricante, el código del tipo de dispositivo, y el número de identificación del mismo. De estos, el
maestro puede construir el número de identificación única para ser utilizado en los mensajes
siguientes.
Estos se utilizan para leer las variables medidas de diversas formas. Los comandos #2 y #3
incluyen la actual corriente de salida en mA. Como la verdadera salida analógica, estos valores en mA
representan la variable primaria (VP) solo cuando está dentro del rango configurado. No cuando el
dispositivo se encuentra en operación multipunto ni tampoco cuando la salida tiene un valor fijo,
saturado o un valor fuera del rango. Sin embargo, la VP y otras variables dinámicas retornadas con
sus respectivas unidades a través de estos comandos, no son limitadas por el rango establecido, sino
que siguen la medición del sensor. El porcentaje del rango indicado por el comando #2 también sigue
la salida del sensor fuera de los limites, de modo que se puede ir del 0 al 100 % y por encima de esto.
El comando de práctica común #61 es equivalente al comando #3, para instrumentos similares
con salidas analógicas diferentes a corriente. El comando #110 también devuelve variables dinámicas
(sin el nivel de salida de la señal analógica). El comando #33 provee una selección de hasta cuatro
variables del transmisor. Para múltiples dispositivos de salida, el comando #60 lee cualquier nivel de
señal analógica de salida seleccionada y el porcentaje del rango, y finalmente el comando #62 provee
la selección de hasta 4 niveles de salida.
El comando #6:
Este comando establece la dirección de escáner del dispositivo. Cuando se establece en cero, el
dispositivo funciona en modo punto a punto, generando una señal analógica de salida. Para cualquier
valor entre 1 y 15, el dispositivo se cambia al modo multipunto y su salida analógica se fija en 4 mA.
Estos se utilizan para leer y escribir una selección de la información del dispositivo. Para las
revisiones menores e igual a 4, los comandos eran #4 y #5, con números de bloques utilizados para
seleccionar una particular sección de la información.
23
2.4.2.-Comandos de práctica común:
Los comandos de práctica común #123 y #126 no son “públicos”. Típicamente son utilizados
por los fabricantes para insertar información específica del dispositivo durante su instalación, por
ejemplo el número de identificación del dispositivo, que nunca será alterado por los usuarios, o para
comandos de lectura y escritura directa a la memoria. Frecuentemente se necesita de una clave para
acceder estos comandos.
Comandos Función
33,61,110 Leer variables medidas
34-37,44,47 Establecer parámetros de operación (rango, unidades, función de transferencia)
38 Reiniciar la bandera de "Configuración modificada".
39 Control de la EEPROM
40-42 Funciones de diagnóstico (modo de corriente fija, auto prueba, reset)
43,45-46 Ajuste de la entrada y salida analógica.
48 Leer estados adicionales.
49 Escribir el número serial del sensor.
50-56 Uso de variable del transmisor.
57-58 Información de la unidad (tag, descriptor, fecha).
59 Escribir el número de bytes de preámbulo necesitados.
60,62-70 Uso de múltiples salidas analógicas.
107-109 Control del modo ráfaga.
Los comandos de práctica común, del #50 al #56 están relacionados a estas variables del
transmisor, sus sensores y rangos. En particular, en dispositivos que lo implementan, el comando #51
permite la selección de las variables del transmisor para las primeras cuatro variables. Estas pueden
ser leídas utilizando el comando #3. De otro modo, el comando #33 específica cuatro variables para
ser enviadas en un mismo mensaje.
Los transmisores multi-variables también tienen la posibilidad de más de una salida analógica.
Por definición, las salidas enumeradas 1 a 4 representan las variables dinámicas de Hart (VP, VS, VT
24
y VC) respectivamente. Los comandos de práctica común #60 y # 62 al #70 tienen que ver con la
configuración y control de estas salidas.
Los comandos específicos de dispositivo se encuentran en el rango 128 a 253. Sus funciones
son más o menos únicas para cada dispositivo. En la tabla del anexo 2 se muestran algunos ejemplos
de estos. En la revisión 4 y anteriores, los comandos específicos de dispositivo siempre incluían el
código del tipo de dispositivo como el primer byte del campo de datos, para asegurarse de que un
comando nunca llegara a un dispositivo no compatible. Esto fue abandonado en la revisión 5, cuando
se incluyó el número identificador único, que cumple con la misma función.
Datos:
No todas las respuestas a comandos contienen datos. Para esos que si lo hacen, se pueden
incluir un máximo de 25 bytes. Los datos pueden ser representados como:
Si un comando no tiene éxito (indicado por error en el campo de estado), las respuestas no
deben contener datos. La respuesta a un comando exitoso siempre incluye el mismo set de variables
como las contenía el mensaje de comando; sin embargo, los valores en la respuesta son los
actualmente utilizados, tomados de la memoria del dispositivo de campo, al igual que cualquier
aproximación involucrada. El número de bytes de datos, y el formato de los mismos (de cada
elemento) son especificados para cada comando.
Resumen de comandos:
La tabla 1 del anexo 2 contiene un listado de la estructura de los datos de los comandos
universales. Además contiene las diferencias entre los comandos para las distintas revisiones de Hart.
La tabla 2 del anexo 2 contiene los comandos de práctica común de la revisión 5.
Nota: en estas tablas los tipos de los datos se indican como sigue.
B Bits de banderas
H Enteros xxxxx yyy (xxxxx = revisión del hardware, yyy = código de señalización física)
2.4.5.-Bytes de estado:
Dos bytes de estados, también conocidos como “código de respuesta”, están incluidos en cada
mensaje de los dispositivos de campo. Entre ellos, estos dos bytes guardan tres tipos de información
diferente: errores de comunicación, respuestas a comandos, y estado del dispositivo de campo. La
tabla muestra como se hace esto con solo dos bytes. Si se detecta un error en un mensaje de salida , el
bit más significativo (bit 7) del primer byte se fija en 1, y los demás detalles del error se indican en los
bits siguientes; el segundo byte contiene puros ceros. De otra forma, si la comunicación fue exitosa, el
26
bit 7 del primer byte es cero, el resto del byte contiene la respuesta al comando, indicando cualquier
problema con el comando recibido, y el segundo byte contiene el estado del dispositivo de campo,
indicando el estado operacional del; dispositivo.
Los errores de comunicación son aquellos que podrían ser detectados por la UART. Además
informa cualquier incongruencia entre el registro de recepción y la suma de verificación. Los
comandos de respuesta (enteros en el rango de 0 a 127) se categorizan como errores o advertencias. Y
teniendo múltiples o un simple significado. La tabla muestra los rangos específicos para cada tipo.
La tabla muestra aquellos que tienen múltiples significados específicos para cada comando universal
o de práctica común.
27
CAPITULO 3 .- DESCRIPCION DEL SISTEMA
El siguiente capítulo se refiere al sistema. Las partes que integran el sistema se tratan como
puntos apartes, comenzando con el circuito digital o hardware, del cual se describe los integrados
utilizados y las partes que conforman cada uno de estos, comenzando por el módem Hart HT2012 y
todos los circuitos externos que requiere, el circuito integrado de conversión TTL - RS 232, el circuito
de generación del lazo de corriente, el conversor analógico digital, y el microcontrolador. En cuanto
al programa del microcontrolador o firmware se describe las rutinas implementadas y la forma en la
que las mismas se relacionan y finalmente se trata el software o programa de interfaz para el usuario
del maestro, que en este caso es el computador personal.
Sin embargo, antes de entrar en los detalles del diseño, se menciona los implementos necesarios
para llevar acabo el proyecto en el cual se diseña el sistema de la figura 3.1.
28
realizar un programa que reciba y decodifique el mensaje, para luego ensamblar una respuesta al
mismo tomando los valores necesarios desde el sensor (firmware).
El módem Hart es la parte física del protocolo en sí, es el que se encarga de transformar la señal
digital del microprocesador en una señal analógica con codificación por desplazamiento en
frecuencia, que viaja por un par de cables hasta el módem del maestro. Este módem se describirá con
más detalle en el capítulo de hardware y materiales.
Detalles sobre los programas tanto del microprocesador TIGER, como del PC, los encontrará en
el capítulo de programas del microcontrolador (firmware) y programas en lenguaje Java para el PC
(software), en donde se da respuesta a las preguntas anteriores. Cabe destacar que no se presentan las
rutinas como tal (ya que explicar cada comando o instrucción dentro de la rutina no es objetivo de
este libro), se muestra mediante un diagrama de flujo la conexión entre las diferentes rutinas o
programas que ejecutan funciones diferentes, desde capturar datos hasta ensamblar el mensaje de
respuesta hacia el dispositivo maestro.
3.2.1.-Microcontrolador
Los sensores de flujo de la compañía Flotech S.A., a los que se les desea instalar el protocolo
Hart, funcionan con el microcontrolador Basic TIGER, de Wilke Technologies (figura 3.3 ). Este
microprocesador tiene las siguientes especificaciones:
30
• Capacidad de memoria: aproximada de 2000 a 5000 instrucciones de Basic con la
memoria FLASH de 128Kb y de 10000 a 30000 instrucciones, con la memoria FLASH
de 512Kb, el máximo en memoria Flash en venta es de 4Mb.
• La arquitectura de los pines de I/O del Basic TIGER se diseña para otorgar flexibilidad y
expansión sencilla. El modulo tiene 38 pines I/O que pueden ser utilizados en una gran
variedad de formas. Se pueden asignar otras funciones a los pines de I/O con la
programación apropiada en Basic.
• Dos puertos seriales, puerto serial 1 que tiene las respectivas entradas RxD y TxD, y el
puerto serial cero, que además de TxD y RxD tiene unos pines de RTS y CTS, con la
posible elección entre TTL o drivers de V24 (pines 24-29) que se pueden configurar
mediante el software.
• Los parámetros de comunicación son de 300, 600, 2400, 4800, 9600, 19200, 38400,
76800, 153600 Baudios; con 7 u 8 bits de datos; paridad O/E o N y un bus RS-485.
• Posee convertidores análogo a digital de 8, 10 o 12 bits que poseen una tasa de muestreo
de hasta 50000 muestras por segundo.
• Posee un controlador interno de pantalla LCD 15, con sets de caracteres definibles, con 8
caracteres cada uno. Control del cursor, secuencias de ESC, selección de menú,
símbolos en movimiento etc.
• Reloj de tiempo real con calendario y alarmas, se requiere de una batería externa para
instalar esta aplicación.
31
• Salidas digital análogas de PWM, 2 canales, con resolución de 6 a 8 bits y frecuencias
desde 0.6kHz a 39kHz.
32
Pin No. Name Description
Al principio del proyecto se utilizó la tarjeta que incluía el Basic TIGER, cuando la
computadora y el microcontrolador se conectaban directamente por el puerto serial para comenzar a
programar las rutinas de comunicación, recepción y análisis. Una vez que se disponía de las demás
partes del dispositivo, se instaló el microcontrolador en una tarjeta diferente, en la que pude elegir que
era necesario de lo que contenía el kit y añadir las cosas que el mismo no incluía y eran necesarias.
33
Un conversor analógico digital, para convertir la entrada del sensor de nivel o flujo a un valor
digital de 12 bits. Este se conecta al microcontrolador mediante los pines 20 (Puerto 8 pin 6) y 21
(Puerto 8 pin7), que son puertos controlables mediante software. El conversor ADC utilizado fue el
LTC1298, cuyo circuito interno se muestra en la figura 3.4:
Para mayor información sobre éste integrado y el modo de conexión del mismo, refiérase al
anexo 6 , este contiene algunas de las hojas de datos de este integrado.
Un circuito que genera el lazo de corriente en mA, ya que el dispositivo que estamos creando es
de tipo activo lo cual implica que este debe generar su propio lazo. Luego este circuito se basa en el
integrado AD694 de Analog Devices. Este integrado se coloca en la tarjeta digital mediante el
siguiente montaje (figura 3.5):
34
Figura 3.5 Conexión del generador del lazo de corriente AD694
Para mayor información sobre éste integrado y el modo de conexión del mismo, refiérase al
anexo 5 , este contiene algunas de las hojas de datos de este integrado.
Esto, junto con conectores DB-9 para ambos puertos seriales, conectadores para alimentación
(ya que la fuente no está incluida en esta tarjeta) y un interruptor que se utiliza en el microcontrolador
para elegir entre modo de programación y modo de corrida; además unos leds para indicar en que
modo se encuentra y si el circuito está encendido o no.
Esto es lo que contiene la tarjeta digital, no se incluye el diseño del módem Hart ya que para
este se diseña un circuito impreso individual que se conecta a la tarjeta digital
Para ilustrar lo anterior observe el siguiente diagrama de bloques en la figura 3.6, en el que se
muestra los módulos de la tarjeta digital:
35
Figura 3.6 Elementos de la tarjeta impresa del circuito digital
De todos modos sería necesario el cambio, ya que la empresa que en un principio vendió estos
módems a Flotech S.A., Symbios Logic, había sido comprada y no venderían mas de los circuitos
integrados fabricados por la misma. Ya que no tenía sentido diseñar un producto que no se podría
fabricar porque los componentes al momento del diseño ya estaban obsoletos, se realizó una rápida
investigación (utilizando Internet), sobre la disponibilidad de algún otro módem, y se encontró la
empresa SMAR RESEARCH CORP. Esta es una empresa que vende equipos industriales con
protocolo de comunicación Hart y además algunos integrados, entre ellos el módem que se requería.
También disponían de circuito con el módem incluido que bastaba con conectarlo al puerto serial y
luego al lazo de corriente, sin embargo, este costaba $300 y el módem como integrado solo $5,
36
además, para poderlo conectar al micro esta interfaz Hart, que es el nombre de su producto (para
mayor detalle refiérase al anexo 4), requeriría de todas las conexiones que tiene la computadora hacia
el puerto serial, y que como ya se mencionó en la parte del microcontrolador, este no dispone de todos
los pines de conexión serial estándar. Finalmente, adquirimos el circuito integrado HART2012
(anexo 3) . Este Integrado requería un filtro de entrada y filtro de salida, además de un circuito
integrado MAX232 o MAX202, para compatibilidad con el puerto serial del microcontrolador. Cabe
destacar que los microcontroladores tienen la posibilidad de ser adquiridos sin el conversor RS232
interno, y de ese modo no haría falta este integrado en el diseño del impreso del módem HART, sin
embargo, la empresa adquirió éstos, para poder realizar la programación de los mismos de modo
directo, de modo que la redundancia (TTL a RS 232 y RS 232 a TTL de nuevo) es necesaria y no se
modificará en ningún momento.
Una vez que se dispone de los circuitos integrados y componentes necesarios, se ensamblo el
circuito en el protoboard , para realizar pruebas hasta que funcionase correctamente. Se montó según
el siguiente esquema (figura 3.7):
Aquí, como podemos observar, el circuito dispone de un filtro de entrada, un filtro de salida, el
módem HART 20 12, y un conversor TTL – RS 232.
37
El filtro de entrada, consiste en un amplificador operacional, que en este caso es el LM2904,
que envía su salida a un comparador, el TLC71, luego la salida del comparador es una señal 0 – 5
voltios que entra al módem HART. En la siguiente figura 3.8 se puede observar en detalle el circuito
del filtro de entrada.
El filtro de salida, se basa en un filtro pasa banda RC, con frecuencias de corte 1000Hz y
2500Hz, además un condensador en serie para eliminar el DC de la señal. Observe la figura 3.9, en
esta se incluyen los tres estados que controlan el medio:
Para poder controlar lo que recibe el módem y lo que envía, ya que la comunicación es half-
duplex (la señal transmitida y la recibida comparten el canal o medio de transmisión, por lo que no se
puede hacer ambas cosas al mismo tiempo), se requiere de unas compuertas de tres estados 74HC126,
que se controlan con la señal de RTS.
38
Para la señal de reloj del módem, se requería de un cristal de 460.8kHz, se utilizó la siguiente
configuración de circuito oscilador (figura 3.10):
• Funciona bajo el estándar Bell 202 con una tasa de baudios de 1200 bits por segundo.
A continuación, en la figura 3.11, podrá observar los pines del integrado HT2012:
39
Figura 3.11 Módem Hart HT2012
La señal RTS (ready to send) se encuentra siempre activa de modo que ninguno de los dos, ni el
maestro ni el esclavo, ocupe la línea. Las salidas TTL del MAX 232 van directamente a los pines
respectivos del módem, IRxD (input receive signal) y OtxD (output receive signal). Al bajar la señal
de RTS, el módem comienza a modular con desplazamiento en frecuencia, dependiendo del valor del
pin IRxD, la frecuencia será de 2200Hz o 1200Hz, como lo establece el estándar Bell 202.
Las pruebas que se realizaban eran en un principio con los terminales de dos computadoras, si
el puerto serial se conectaba a los respectivos módems (se requirió de la fabricación de dos de ellos
como mínimo) y se comunicaban entre ellos a una tasa de bits de 1200bps, como se encuentra en los
parámetros del protocolo Hart y del módem en sí.
En cuanto al montaje, para llegar al actual diseño de la tarjeta del módem, se fabricaron dos
prototipos. Los primeros eran circuitos con pistas de cobre de un solo lado, lo cual hacía necesaria la
conexión mediante cables, estos primeros prototipos los puede observar en la figura 3.12 y en el
anexo 8 encontrará el diseño del circuito impreso.
40
Figura 3.12 Primeros circuitos impresos para el módem
Luego se realizó un segundo diseño con correcciones de errores del primero y de doble cara, es
decir, con pistas de cobre por ambos lados de la tarjeta; este es el diseño final del impreso del módem.
Este se conecta a la tarjeta en la cual se encuentra el microcontrolador mediante un conectador de 10
pines, como se observa en la siguiente figura 3.13:
41
Esto concluye la descripción de la parte física del sistema, la tarjeta digital que se incluirá en el
dispositivo, sin embargo este no es un diseño que pueda ser fabricado en cantidad, ya que el circuito
se ensambló en una lámina perforada sin conectadores de cobre de ningún tipo, se debe diseñar un
circuito impreso para colocar todos los módulos de un modo más eficiente, que reduzca el espacio.
Ahora procedemos a describir el firmware del equipo, el programa del microcontrolador que se
encarga del procesamiento de los mensajes en el dispositivo remoto o sensor.
A continuación se describe brevemente cada una de las partes del programa o rutinas y las
funciones que llevan a cabo, se mencionan los nombres utilizados para cada una durante la
programación, de modo que en caso de observar el anexo 10 el lector pueda comprender con mayor
facilidad el fragmento del programa.
42
3.3.1.-Recepción y análisis
Para iniciar el desarrollo del firmware era necesario crear una rutina que recibiese el mensaje.
Para ello se trabajó conectando los puertos seriales del PC y del TIGER directamente. La rutina toma
los caracteres o bytes y los imprime en el LCD. Una vez que se verificó que la rutina recibiera
correctamente los bytes, se procedía a un nivel superior de complejidad, ya que era necesaria una
rutina que analizará lo que recibía como si fuese un mensaje Hart, para este momento fue necesario
realizar un pequeño programa en JAVA que transmitiese un mensaje fijo pero con la estructura
HART, es decir, 20 bytes de preámbulo, dirección, comando y otros. Luego, el TIGER recibe el
mensaje y asignando a un arreglo de bytes lo que se recibe del puerto, divide el mensaje en sus
respectivas partes, e imprime en el LCD el comando (número del comando). Sin embargo, esto no
requería mayor esfuerzo, ya que el mensaje era fijo y se conocía exactamente que longitud, en bytes,
tiene cada parte del mensaje. En el protocolo Hart, como se vio en el capítulo 2, el mensaje puede
variar su longitud, y además puede tener dos formatos diferentes. De modo que, para poder recibir el
mensaje, debía ser analizado a medida que llegaba al puerto serial, por lo que hubo que integrar la
rutina de recepción con la de análisis.
El byte de inicio indica el formato del mensaje, si es de formato corto o de formato largo, esto
se implementó en el programa mediante un IF, y el valor por descarte es un mensaje de respuesta que
indica que el mensaje es errado. De modo que si el byte de inicio es 2 o 186 (02 hex y 82 hex
respectivamente) se descifra el largo del campo de dirección o address, que en un caso es de 5 bytes y
en otro de un solo byte. Luego, si el formato es largo, se reciben los cinco bytes siguientes y son
almacenados en un arreglo denominado ADRESSA, si es un byte se almacena en ADDRESSB.
43
figura de la estructura del programa que se presenta al principio de esta sección. Una vez que se sabe
que el mensaje es para el dispositivo, se continúa la recepción de bytes. El siguiente es el byte de
comando (COMMAND), de modo que de acuerdo a lo establecido por la fundación Hart, ya se conoce
lo que se encuentra en el mensaje, más sin embargo aún no se conoce su longitud. Un breve ejemplo
podrá aclarar lo antes mencionado. El comando número 17 es un mensaje de máximo 32 caracteres,
pero pueden ser menos, de modo que se debe saber cuantos bytes de información han sido enviados.
Para ello, se incluye el byte de cuenta de bytes (BYTECOUNTBYTE), el cual es un entero del 0 al 25
que facilita ese dato y viene inmediatamente después del byte de comando. Luego, se recibe la
cantidad de bytes que este BYTECOUNTBYTE indica y se almacenan en un arreglo denominado
DATAS. Finalmente, en el byte de verificación de suma, que en el programa es CHECKSUM, se
guarda el XOR de todos los bytes desde el de inicio hasta el último dato, para verificar que no hubo
errores de transmisión y que el mensaje está intacto.
3.3.2.-Respuesta al comando
Una vez que se dispone de cada una de las partes del mensaje en arreglos, se procede a realizar
lo que el maestro indica mediante el número del comando. Según el número de comando recibido se
debe realizar o invocar rutinas diversas. La que la mayoría de las veces se ejecuta (la mayoría de los
comandos incluyen este dato) es la medición de la variable primaria, para lo cual se realizó una rutina
aparte.
Para separar estas rutinas, se utiliza un SWITCH con los posibles casos o comandos disponibles
en el dispositivo(para este proyecto, solo fueron incluidos los comandos universales).
En la mayoría de los comandos, los datos enviados son fijos, son parámetros del dispositivo o
de las pocas variables que el mismo mide (variable transmitida en mA). De modo que estas se
almacenan en la memoria del TIGER para ser invocadas y/o modificadas en cuanto sea necesario. En
el anexo 2 se incluye una tabla con todos los parámetros necesarios para satisfacer los requerimientos
de información de los comandos universales.
No se detallará cada uno de los 13 comandos disponibles (los comandos universales), pero más
adelante se incluirá un ejemplo de aquellos que sirvan para describir las demás rutinas del programa.
44
3.3.3.-Transformación de valores
El mensaje recibido se almacena como bytes, de modo que los números decimales negativos y/o
mayores a un byte deben ser incluidos en una rutina de conversión. Esta rutina se denomina en la
estructura del programa ByteToFloat, ya que en el mensaje los números son enteros (un byte máximo)
o de tipo flotante. Siendo de tipo flotante (según el protocolo Hart), cuatro bytes, que representan el
número en dos partes, la mantisa M y el exponente E, siendo el número decimal igual a M x 2E . La
mantisa ocupa los dos primeros bytes más 7 bits del tercero, el exponente ocupa el cuarto byte sin el
bit superior más el bit restante del tercer byte y el último bit indica el signo de la cantidad decimal.
En el momento de transmitir la respuesta se invoca una rutina que hace lo opuesto, pasar del número
flotante recibido del sensor a bytes individuales que se denomina FloatToByte.
Esta es una pequeña rutina que lee el puerto número 8 del TIGER, al cual se ha conectado
previamente la salida de un ADC, circuito integrado que transforma un valor analógico introducido,
en un valor digital a su salida, en forma serial. Al invocar la rutina ADC12bit se obtiene el valor
medido por el sensor, que es el que se asigna a la variable primaria.
45
Conociendo la existencia de estas rutinas de transformación de enteros a flotante, de
compresión de caracteres y obtención de valores, podemos dar ejemplos de comandos y su
implementación en el programa.
Cuando el maestro envía el comando número 18, en el campo de datos se encuentran el tag el
descriptor (con compresión de caracteres) y la fecha (sin comprimir). Luego, se decodifica y se
asignan los valores enviados a los parámetros del dispositivo, la respuesta debe ser igual o incluir los
mismo datos que envió el maestro o los nuevos valores de los parámetros tag, descriptor y fecha.
De los comandos universales, los únicos que incluyen datos del maestro al dispositivo de
campo, son los tres últimos, el 17, 18 y 19. El 17 es el que transmite un mensaje al dispositivo (un
mensaje de 32 caracteres que debe presentarse en la pantalla LCD), el 18 es el antes mencionado y el
19 modifica el número de ensamble final (NFE), uno de los parámetros del dispositivo.
Al recibir los demás comando se debe emitir una respuesta con los datos que según el comando
le correspondan, por ejemplo, el comando número uno es el que transmite la variable primaria (la
medición del sensor) junto con las unidades de la medición. Las unidades se indican de acuerdo a una
tabla con números enteros. Luego el primer byte del campo de datos se utiliza para incluir la unidad, y
los siguientes cuatro bytes, es decir, del 1 al 4, para almacenar los bytes que resulten de transformar el
valor flotante de la variable primaria a bytes. El comando 3 es bastante similar, solo que este incluye
las cuatro variables posibles del protocolo, cada una con su unidad de medición, excepto los primeros
cuatro byte, que indican la corriente del lazo en mA.
El comando 13 envía al maestro el tag, descriptor y la fecha, luego se debe invocar a la rutina
de codificación de caracteres. Para el tag que es de 8 caracteres, se asignan 6 bytes del mensaje; para
el descriptor, de 16 caracteres, se asignan 12 bytes; pero la fecha no necesita compresión, ya que tres
bytes son suficientes, día, año y mes respectivamente. Este comando permite observar los valores sin
poder modificarlos ( cosa que se realiza con el comando 18 se mencionó anteriormente).
Un comando interesante es el comando 12, este es aquel en el que el maestro recibe un mensaje
(de 32 caracteres) del dispositivo remoto, pero dado que el dispositivo remoto en el momento del
diseño del proyecto no incluía un teclado para poder ingresar mensajes, se implementó un mensaje
fijo que se transmite siempre que se le envíe ese comando. En un futuro se pretende añadir pequeños
teclados a los dispositivos, para poder modificar su programación en el campo y enviar mensajes de
texto.
46
Algunos fragmentos del código se encuentran en el anexo 9 de este libro. Finalmente, el
software o programa del maestro (computador personal).
El programa realizado para el maestro de prueba, posee una estructura similar a la del programa
del Basic TIGER, sin embargo, la diferencia entre los lenguajes de programación Basic y Java, hacen
que las rutinas sean algo más complicadas. Para llevar acabo la programación en este lenguaje se
acudió a la interfaz de aplicación de programación de Java (API, clases y objetos ya existentes); y se
procedió a realizar lo mismo que en el programa del TIGER, pero incluyendo una interfaz gráfica
que permite interactuar con el usuario.
Java es un lenguaje de programación orientado a objetos (si desea saber más sobre esto se le
sugiere revise la bibliografía), luego, en vez de programas o rutinas, se les denomina clases, las
mismas se invocan las unas a las otras para lograr el mismo resultado que el programa del TIGER. En
nuestro caso, el maestro dispone de una clase principal que crea la interfaz gráfica y activa los
botones que el usuario utilizará para controlar la aplicación. Al presionar o seleccionar alguno de los
ítem de la ventana de interfaz, se llama a otra clase que determina cual de las acciones se debe
realizar.
47
La interfaz es la siguiente (figura 3.15):
Como puede observar, la interfaz no es para ser utilizada por cualquier usuario, se planea hacer
modificaciones a la misma una vez que todo el dispositivo este completo, para ofrecer el servicio de
instalación completo de dispositivos de campo y maestro, pero cabe notar que para la empresa es
prioridad el dispositivo (hardware y firmware) y no el software. La interfaz contiene campos que
pueden ser editados y otros que no, ya que son los que se calculan al momento de ensamblar el
mensaje.
• El primer campo es la cantidad fija de bytes de preámbulo que poseen los mensajes hacia el
dispositivo.
• El segundo indica el valor hexadecimal del byte de inicio, de acuerdo a lo que el usuario
seleccione con los checkbox el valor que aparece en dicho campo se modifica.
48
• El tercer campo es el de la dirección. Dicha dirección se escribe en valores decimales byte por
byte, de no introducir correctamente la dirección el programa genera errores (no se ha incluido
en el programa diálogos de error, de modo que de cometer algún error este será visible en el
command prompt o el terminal desde el cual se corrió el programa java Hart).
• El cuarto no es un campo sino una lista de selección con los comandos disponibles del
dispositivo, aunque, siendo este un maestro para utilizar con cualquier dispositivo Hart, debería
permitir escritura, de no poseer el dispositivo dicho comando, deberá enviar un mensaje en el
cual los bytes de estado o estatus indican que el mismo no dispone del comando.
• El campo de datos presenta lo que se añade al mensaje, de no poseer ningún dato se indica o
simplemente aparece el comando que se ha seleccionado. Recuerde que, como se mencionó en
la parte del programa del TIGER, solo los comandos 17, 18 y 19, son los que envían datos del
maestro al dispositivo.
• Finalmente, un campo de texto en el que se escribe lo que el programa esta realizando o recibe
del dispositivo de campo.
Los botones:
De modo que para poder enviar un mensaje al dispositivo ocurren los siguientes eventos:
Finalmente al obtener una respuesta del TIGER se invoca la clase MessageAnalisis que se encarga
de dividir el mensaje en las partes respectivas y según el comando que se envió se muestra en el
campo de Mensaje del TIGER los valores de los bytes o campos individuales del mensaje más
importantes y luego lo que el comando en si debe enviar. Por ejemplo el comando 3 incluye la
corriente del lazo, las unidades y variables (de la primaria a la cuarta) y se muestran de la siguiente
forma:
50
El programa del maestro no es un programa secuencial, a diferencia del programa del TIGRE,
este llama a las diferentes clases o rutinas a medida que se necesita de ellas, por ejemplo, por cada
byte que se recibe se invoca la clase SerialConection y la clase MesageAnalisis.
51
CAPITULO 4.- PRUEBAS Y RESULTADOS
Como se puede observar, la tarjeta digital incluye todo lo que se mencionó en su descripción.
Se puede observar el módem (la tarjeta que se encuentra conectada por encima de ambos
conectadores DB-9), el circuito conversor analógico digital, que se observa en el lado izquierdo del
microcontrolador y el circuito generador del lazo que se encuentra debajo de la tarjeta del módem.
Este circuito contiene el hardware y firmware del diseño.
52
4.2.- Interfaz para el usuario
La interfaz gráfica para el usuario en el PC, o en otras palabras el maestro funciona del
siguiente modo:
53
Figura 4.3 Interfaz una vez presionado COMPONER
Como se puede observar para este momento, los campos contiene los valores introducidos por
el usuario y los establecidos por el sistema, en este caso el número de bytes de preámbulo es 20, el
formato de mensaje elegido es el formato largo, el cual contiene un campo de dirección de cinco
bytes, el valor de ésta dirección se encuentra en el siguiente campo de texto. El comando que había
sido elegido, la cuenta de bytes que en este caso es cero (recuerde que el comando 3 no contiene datos
del maestro hacia el dispositivo) y el campo de datos que muestra el comando elegido (se mencionó
anteriormente que en caso de que el comando no contuviese ningún dato se mostraría en este campo
el comando elegido. Una vez listo el mensaje se presiona el botón de SEND y la pantalla aparece esta
vez del siguiente modo (figura 4.4):
54
Figura 4.4 Interfaz después de presionar SEND
En la figura se nota que el botón SEND queda inhabilitado una vez que se presiona, esto es para
impedir que el usuario presione el mismo varias veces y cree un conflicto dentro del programa, este se
reactivará una vez que se presione componer de nuevo.
El botón de RESET reinicia la ventana, quedando esta como se muestra en la figura 4.2 en la
cual se borra el contenido del mensaje del TIGRE, para poder continuar enviando mensajes sin la
necesidad de utilizar las barras deslizantes del área de texto (scrollbars) , sin embargo deberá rescribir
los campos de dirección para cada vez que utilice el RESET.
55
Figura 4.5 Interfaz con los resultados del proceso de comunicación
Como puede observarse, los resultados incluyen el valor de los bytes de inicio, la dirección, el
comando y el de estado; sin embargo a un usuario que no esté programando no le interesa el valor de
estos, sino la frase que indica que el mensaje fue recibido correctamente y los valores que pidió
mediante el comando elegido.
Al notar que todos los comandos implementados recibían la respuesta esperada, se dio por
culminado el diseño. Tomando en cuenta que aún faltaban detalles, como los datos enumerados y la
implementación de los muchos otros comandos, pero que para ese momento era imposible
implementar, ya que el diseño de la parte analógica del sensor no había sido realizada y las rutinas de
calibración y demás opciones que permite el protocolo no podían ser programadas sin éste.
En la foto que se presenta al final de ésta sección (figura 4.6) puede observar todo el sistema
conectado, el circuito digital, con el microcontrolador, el módem y demás partes, y la conexión
mediante solo dos hilos hacia el módem del computador que se conecta al mismo vía serial. Se
observa en la pantalla del computador el programa o interfaz funcionando y en la pantalla LCD un
mensaje que da la bienvenida a Hart de Flotech S.A.
57
Figura 4.6 Sistema con capacidad de manejar el protocolo Hart
58
CAPITULO 5.-CONCLUSIONES Y RECOMENDACIONES
• Se diseño una tarjeta digital con capacidad de comunicación mediante el protocolo Hart.
• El dispositivo diseñado contiene únicamente los comandos universales, a pesar de ello cumplen
el requisito básico de la fundación Hart.
• El diseño del firmware se realizó de modo modular, es decir, basta con incluir un case nuevo
en cada switch para poder implementar los comandos de práctica común tanto como los
comandos específicos de dispositivo.
• Al realizar la programación del protocolo en una rutina aislada de aquella que controla el sensor
como tal, se hace posible la implementación de la misma en múltiples sensores o equipos que
utilicen dicho protocolo.
• Se diseño una interfaz gráfica que corre en cualquier máquina o computador personal ya que
fue desarrollada en el lenguaje Java, de uso relativamente sencillo y fácil comprensión visual.
59
Sección 5.2.- RECOMENDACIONES
• Adquirir de la fundación las hojas de datos y especificaciones del protocolo, las cuales si
se registra la compañía en la Fundación son enviadas como uno de los materiales de
ingreso, pero de no pretender ser miembro de la fundación se venden por separado por
un precio de $400. Para adquirir estas especificaciones de protocolo deberá contactar a
la Fundación Hart. Dirección electrónica : http://www.hartfundation.com
• Incluir en el programa del dispositivo remoto o TIGER las tablas que indican las
unidades de medida y demás símbolos que se interpreten mediante las mismas. Por
ejemplo, las unidades de metros corresponden a algún entero del 0 al 255 (se asigna 1
byte para unidades, es decir, 255 unidades de medición posibles).
• Realizar un circuito impreso final que incluya todos los componentes digitales, el
microcontrolador, el generador del lazo de corriente, el módem hart con la circuitería
correspondiente y el conversor análogo digital. Ésta deberá conectarse al circuito
impreso o a la tarjeta analógica mediante conectadores y fijarse de modo que ambas
queden estables dentro de la caja a prueba de explosión.
60
REFERENCIAS BIBLIOGRÁFICAS
1. Bowden R., "HART Field Communications protocol. A Technical Oveview", Segunda Edición,
Agosto de 1997, 85 páginas.
2. Wilke Technology GmbH, “BASIC TIGER MANUAL” , Versión 2.8, Junio de 1998, todo el
manual.
7. http:// www.hartfundation.com
8. http:// www.smarresearch.com
9. http:// www.javasun.com
61
ANEXO 1
HART field communication protocol
el microcontrolador
'---------------------------------------------------------------------------
' Variables para la compresión de mensajes ASCII
'---------------------------------------------------------------------------
ARRAY PACKCHAR(25) OF BYTE 'arreglo que contiene el mensaje comprimido
ARRAY UNPACKCHAR(33) OF BYTE 'arreglo que contiene el mensaje sin comprimir
BYTE C
BYTE BIT2220 'diferentes bytes para la compresión de
BYTE BIT0002 'los caracteres o mensajes de texto ASCII
BYTE BIT2200
BYTE BIT0022
BYTE BIT2000
BYTE BIT0222
BYTE BIT0200
BYTE BIT0220
BYTE TEMP
BYTE TEMPA
BYTE M,O,P,R,S,T
BYTE Packet_size
BYTE Unpacket_size ' variable que me da el tamaño de lo que se
BYTE Unpacket_to ' comprime o descomprime.
BYTE Packet_to
'---------------------------------------------------------------------------
'Rutina Principal
'---------------------------------------------------------------------------
TASK MAIN ' inicio de la rutina MAIN
#INCLUDE DEFINE_I.INC ' definicion de simbolos
'---------------------------------------------------------------------------
' Drivers de los dispositivos y parámetros
'---------------------------------------------------------------------------
INSTALL DEVICE #LCD, "LCD1.TDD" ' instala el display (BASIC-Tiger)
FOR D=0 TO 32
MESAGE(D)=0 ' mensaje de hasta 32 caracteres
NEXT
FOR D=0 TO 16
DESCRIPTOR(D)=0
NEXT
iii
'---------------------------------------------------------------------------
' al hacer la operación And
BIT2220=11111100b ' solo se extraen los 6 bits superiores
BIT0002=00000011b ' solo se extraen los 2 bits inferiores
BIT2200=11110000b ' solo se extraen los 4 bits superiores
BIT0022=00001111b ' solo se extraen los 4 bits inferiores
BIT2000=11000000b ' solo se extraen los 2 bits superiores
BIT0222=00111111b ' solo se extraen los 6 bits inferiores
BIT0200=00110000b ' solo se extraen los 2 bits medio izq
BIT0220=00111100b ' solo se extraen los 4 bits medio
'---------------------------------------------------------------------------
' Rutina que recibe el mensaje completo desde el puerto serial
'---------------------------------------------------------------------------
TASK MesageReceiver
DIR_PIN 7,3,0
iv
ELSE
v
ANEXO 9
Fragmentos del código de
import javax.swing.*;
import javax.swing.JComponent.*;
import java.awt.*;
import java.awt.Component.*;
import javax.swing.SwingConstants.*;
import javax.swing.plaf.*;
import java.awt.GridBagConstraints.*;
import javax.comm.*;
class Hart5
{
Byte size;
static TextField preambelbytes = new TextField("",20);
static TextField startbyte = new TextField("",20);
static TextField addressbytes = new TextField("",20);
static TextField commandbyte = new TextField("",20);
static TextField bytecountbyte = new TextField("",20);
static TextField databytes = new TextField("",32);
static TextArea mensajeout = new TextArea("",1,50,TextArea.SCROLLBARS_HORIZONTAL_ONLY);
static Choice commandchoice = new Choice();
static TextArea mensajein = new TextArea("",10,50);
//definicion de variables
JFrame f = new JFrame("MASTER TERMINAL");
JPanel p1,p2,p3;
preambelbytes,startbyte,
addressbytes,commandbyte,
bytecountbyte,databytes,
conect,enviar);
addressbytes );
commandchoice.addItem("0");
commandchoice.addItem("1");
commandchoice.addItem("2");
commandchoice.addItem("3");
commandchoice.addItem("6");
commandchoice.addItem("11");
commandchoice.addItem("12");
commandchoice.addItem("14");
commandchoice.addItem("15");
commandchoice.addItem("16");
commandchoice.addItem("17");
commandchoice.addItem("18");
commandchoice.addItem("19");
commandchoice.addItemListener(comando);
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label3,c);
p2.add(label3);
c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(preambelbytes, c);
p2.add(preambelbytes);
iii
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label4, c);
p2.add(label4);
c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(startbyte,c);
p2.add(startbyte);
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE;
gridbag.setConstraints(label11,c);
p2.add(label11);
c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(largo,c);
p2.add(largo);
c.gridwidth = GridBagConstraints.RELATIVE;
gridbag.setConstraints(label12,c);
p2.add(label12);
c.fill=GridBagConstraints.NONE;
c.weightx = 0.0;
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label5, c);
p2.add(label5);
c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(addressbytes , c);
p2.add(addressbytes );
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label6, c);
p2.add(label6);
c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(commandbyte , c);
//p2.add(commandbyte );
c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(commandchoice , c);
p2.add(commandchoice );
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label7, c);
iv
p2.add(label7);
c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(bytecountbyte , c);
p2.add(bytecountbyte );
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label8, c);
p2.add(label8);
c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(databytes , c);
p2.add(databytes );
/**
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label2, c);
p2.add(label2);
c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(mensajeout, c);
p2.add(mensajeout);
*/
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label10, c);
p2.add(label10);
c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(mensajein, c);
p2.add(mensajein);
ensamble.addActionListener(eVentos);
borrar.addActionListener(eVentos);
enviar.addActionListener(eVentos);
salir.addActionListener(eVentos);
largo.addItemListener(selecion);
corto.addItemListener(selecion);
conect.openConnection();