Hola a todos !
He comenzado a comunicarme vía RS485 desde el/la PC con distintos dispositivos que les paso a contar.
Un Relé, un DIMMER, un Termómetro I2C (STCN75), un sensor de temperatura y humedad SHT11, un anemómetro, un indicador de dirección de viento y un portón levadizo.
Aún no los he conectado “todos juntos” en la red RS485 sino que he ido comunicándome desde el/la PC de a uno y todo a salido de maravillas.
Los bytes van y vienen comunicando las unidades de manera satisfactoria.
Conecto ó desconecto el relé, mido temperatura, varío la intensidad de una lámpara, todo perfecto, pero ... , pero ...
Estoy ante un inconveniente que interpreto requiere más de experiencia y habilidad imaginativa (que no tengo), que de técnica (que tampoco tengo
) y por eso he decidido crear éste hilo para compartir con Uds. los distintos métodos que utilizan a menudo y/o conocer sus ideas acerca de cómo manejar los tiempos de interrogación/respuesta entre CPU (la/el PC) y Terminales (por darles un nombre)
Grafiquémoslo con un ejemplo:
Tengo mi terminal “Termómetro I2C” que constantemente está sensando la temperatura de un ambiente y controlando si debe conectar calefacción ó ventilación a la misma, para mantener un ambiente agradable de estar.
Es decir, la terminal decide si conecta ó no un relé ú otro (calefacción / ventilación) y a su vez muestra la info en un LCD 16X2.
Desde el CPU y a través de la aplicación que realizo en VB6 llamo a la terminal “por su nombre”, le envío la instrucción para que me informe un dato cualquiera de todos los que maneja (por ejemplo: si la calefacción está encendida) y le indico el final de la instrucción.
El PIC de la terminal requerida “escucha” el llamado, “contesta” la interrogación con los datos solicitados, el CPU lee los datos y los muestra en pantalla en la aplicación en VB6 para así obtener una graficación al estilo de un sistema domótico..
Una teoría hermosa que no logro hacer funcionar cómo quisiera y como se debiera.
Generalmente, cuando desde el CPU genero la interrogación y la envío al bus; el PIC interrogado está haciendo otra cosa, menos estar “atento” con la instrucción “HSERIN” (con ésa leo los datos provenientes del CPU).
Lo hago funcionar, pero generando un evento REPEAT-UNTIL en la aplicación de la CPU hasta que el PIC del terminal conteste, ya que antes generaba ráfagas de 20 ó 30 envíos de instrucciones hacia el PIC y los tiempos no coincidían casi nunca y cuando quería activar remotamente un relé con un botón (por ejemplo), debía hacer clic sobre el mismo muchas veces hasta que coincidieran los tiempos de escucha del terminal.
Sobre éste tema me gustaría leer acerca de las experiencias de Uds.
Cómo ponen a la escucha a terminales que están constantemente trabajando en otras cosas?
Utilizan el mismo método que yo? Bombardear el bus hasta que la terminal requerida escuche y conteste ? Yo interpreto que no es el modo.
Utilizan el TMR0 y que cada determinado tiempo se controle la llegada de información? Es lo mismo que antes. Van a existir muchas oportunidades en que los tiempos no coincidan ….
Cómo hacer coincidir los tiempos ?
En las redes que han visto ó fabricado Uds.; las terminales sólo “contestan peticiones de órdenes” ó las hay también “autónomas” ?.
Es decir, que a intervalos regulares de tiempo envían por sí solas información a la red sin que dependan de un mando desde el CPU ó desde otra terminal, cómo podría ser un terminal con fotodetector para encender la iluminación exterior al anochecer y apagarla al amanecer y a su vez mostrarlo en la pantalla del CPU a dicho estado.
Resumiendo:
Logro comunicar por RS485 de maravillas, pero no me doy cuenta cómo hacer para armonizar los tiempos de comunicación entre la CPU y las laboriosas terminales, que no son simples “oyentes” a la espera de una instrucción que puedo enviar en cualquier momento. Son trabajadoras que disponen de un tiempo de escucha limitado, que no logro dominar.
Sobre esto quería compartir experiencias con Uds.
Gracias a los que me puedan comprender y ayudar.
Saludos.
Mario.
