Soporte de TAS-HMITalk

PROBLEMAS AL REGISTRAR HMITALK.OCX EN UNA MAQUINA CON WINDOWS VISTA

Wed, 18 Mar 2009 22:11:00 GMT

Hemos recibido algunos reportes de inconvenientes al intentar registrar el objeto hmitalk.ocx con regsvr32.exe o desde VB5/VB6/VB.Net corriendo en Windows Vista. Aparece un error poco explicativo que dice que es imposible registrar el objeto.

Encontramos que esto usualmente se debe a que la aplicacion desde la que se registre al objeto se debe ejecutar como administrador para que el registro sea permitido. Para ello, es suficiente con localizar el icono del programa y desde el menu que se despliega con el boton derecho del mouse, seleccionar la opcion "Ejecutar como administrador".

PROBLEMA AL EJECUTAR VARIAS APLICACIONES QUE UTILIZAN TAS-HMITALK EN UNA MISMA MAQUINA

Wed, 18 Mar 2009 22:06:00 GMT

Hemos resuelto un nuevo problema tambien reportado por algunos clientes que consistia en que bajo ciertas condiciones algunos objetos funcionando en una aplicacion podian detenerse y dejar de operar al cargarse otros objetos desde otra aplicacion corriendo simultaneamente en la misma maquina.

El problema ya ha sido solucionado y se resuelve descargando la ultima version del producto o bien descargando solo el archivo hmitalk.ocx de la siguiente direccion: http://www.cpksoft.com.ar/Archivos/hmitalk.ocx. Es suficiente con localizar el viejo hmitalk.ocx y pisarlo con el nuevo archivo.

PROBLEMA CON MANEJO DE VARIAS DIRECCIONES IP RESUELTO

Mon, 23 Feb 2009 18:55:00 GMT

Acabamos de publicar una nueva copia del archivo hmitalk.ocx que resuelve un problema que fue reportado por algunos clientes y que se presentaba cuando se colocaban multiples instancias del objeto HMITalk apuntando a diferentes direcciones IP. Esta copia aparecera como version "8.04+" para diferenciarla de la version 8,.04, y no implicara un upgrade de producto

Si usted ha tenido problemas de este tipo le sugerimos descargar nuevamente el producto de nuestra pagina o bien descargar directamente el archivo ocx de la siguiente direccion: http://www.cpksoft.com.ar/Archivos/hmitalk.ocx.

¿Cómo hago funcionar los ejemplos de TAS-HMITalk?

Mon, 03 Nov 2008 20:00:00 GMT

Todos los ejemplos para TAS-HMITalk vienen con su código fuente y en casi todos los casos están preparados para ser abiertos con Visual Basic 5.0 o 6.0, aunque en algunos puede requerirse Visual C#.NET 2005, Visual Basic.NET 2005 o Visual Basic Express.NET 2008.

Muchos ejemplos vienen también con su programa ejecutable, que si bien no se puede modificar si no se tiene el correspondiente editor, en algunos casos puede servir para ensayar el producto si las configuraciones asumidas coinciden con el entorno donde éstos sean probados. Para que los ejecutables corran sin problemas desde el punto de vista de Windows, lo mejor es utilizar Windows XP. Si los ejemplos están escritos para el entorno .NET 2005, va a ser necesario como mínimo asegurarse de tener instalado el Microsoft Framework 2.0 que puede bajarse desde este link de la página de Microsoft:

http://www.microsoft.com/downloads/details.aspx?FamilyID=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=es

En el caso de .NET 2008 puede ser necesario tener el Framework versión 3.5, pero aquí recomendamos bajar e instalar Visual Studio Express 2008 directamente desde la página de Microsoft http://www.msdn.com y dejar que éste ya instale el framework correspondiente.

Además es también necesario como paso previo registrar el objeto hmitalk.ocx que está en el .zip de distribución de TAS-HMITalk. Para ello se debe utilizar el programa regsvr32.exe que es propio de Windows, previamente a intentar ejecutar cualquier ejemplo.

Los pasos resumidos para ejecutar un ejemplo entonces son los siguientes:

- Descargar el .zip de distribución o instalación de TAS-HMITalk, ya se trate de la versión de demo o de la versión final.
- Extraer el contenido del .zip a una carpeta en la máquina local donde quedará alojado el producto.
- Ubicar el archivo hmitalk.ocx.
- Dar botón derecho sobre el archivo seleccionar la opción de menú “Abrir con...”
- Ir a ‘Seleccionar Programa” y navegar hasta la carpeta c:\Windows\System32
- Una vez allí, buscar el programa ‘regsvr32.exe’.
- Aceptar y dejar asociado este programa a las extensiones ocx.
- Repetir este proceso con los archivos linechrt.ocx y grid32.ocx.

Al correr el programa regsvr32.exe, que es propio de Windows, le deberá aparecer una ventana como la siguiente, indicando que el proceso ha sido completado:

Finalizado este proceso, estaremos ya en condiciones de disparar el .exe del ejemplo que se quiera ensayar.

Recordamos que es muy probable que un ejemplo no se comunique con su equipo a menos que se hagan las adaptaciones necesarias en los seteos que hemos asumido, que en la mayoría de los casos son COM1, 9600, N, 8, 1, número de equipo 1.

Podrían aclararme la diferencia de prestaciones entre las licencias de 5, 50 y 500 instancias del TAS-HMITalk

Fri, 31 Oct 2008 17:08:00 GMT

Cuando hablamos de licencias de 5, 50 o 500 objetos, se refiere a la cantidad máxima de objetos que se pueden volcar en una aplicación escrita con TAS-HMITalk. En realidad se pueden volcar más objetos, pero solo funcionan correctamente los objetos que se encuentran dentro del llímite. Este hecho permite que se desarrolle una aplicación completa con cualquier número de objetos aunque se tenga una versión de TAS-HMITalk para menos objetos, de manera que luego se puede cambiar a una licencia que atiende más objetos sin realizar modificaciones en la aplicación donde ya se dejaron preparados los objetos adicionales.

La forma de consumir objetos es a través de ir declarándolos en la aplicación, usualmente por medio de su inserción en diferentes formularios y ventanas, aunque también se pueden crear dinámicamente con técnicas de programacion más avanzadas. Cada vez que se deposita un nuevo objeto en el algún contenedor, se está utilizando una instancia del mismo.

En el ejemplo para VC#.NET que se brinda en el instalador de TAS-HMITalk para el PLC TWIDO, se puede observar que se ocupa una instancia de un objeto hmitalk.ocx para leer 10 registros del PLC y otra para escribir un registro del PLC. Es decir que aquí fueron necesarias en total 2 instancias de objetos y hubiera sido suficiente con la licencia para 5 objetos. Dependiendo de los requerimientos de cada aplicación y de cómo se realice la programación, se utilizarán más o menos objetos en el código final de la aplicación.

Se podría por ejemplo utilizar un único objeto para todas las lecturas que sea necesario realizar, pero esto implicaría ir reprogramando en runtime, dinámicamente, todas las propiedades del objeto para que éste sirva para todos los PLC y todas las zonas de memoria y tipos de datos que se necesite leer. Esto va a ir en obvio detrimento de la claridad del código y del tiempo invertido en la programación. Además, al utilizar un mismo objeto para pedir datos que provienen de orígenes diferentes, se pierde el sentiddo de lo que son buenas virtudes del producto como es el caso de los eventos ante el cambio en los valores (OnPointValueChanged), los eventos de avisos de alarma, etc, ya que no se pueden procesar correctamente si el origen de los datos cambia con cada nueva operacion de lectura.

Si se insistiera con economizar instancias y se siguiera recurriendo a ir sincronizar los cambios de las propiedades necesarios para apuntar al origen de cada nueva lectura, esto también implicaría que se tenga que armar un motor de poleo propio en la aplicación, probablemente basado en un timer, donde se irían tomando las decisiones de esos cambios. Se perdería así el fantástico motor de interrogación embebido que ya provee cada objeto, que es capaz de sincronizarse automáticamente con todos los demás objetos que estén accediendo a un mismo puerto, estableciendo un orden óptimo de lectura con prioridades configurables y otras muchas ventajas, sin tipear una sola línea de código adicional. Es decir, para tener un scan automático, no es necesario programar nada, sino que alcanza con encender la propiedad ScanActive y definir el ScanInterval deseado para cada objeto que se haya declarado y configurado (usualmente en modo diseño). Si las propiedades una vez definidas ya no cambian, se aprovechan totalmente las prestaciones de este motor de barrido, que es un servicio de TAS-HMITalk muy importante para toda aplicación.

Para el envío de salidas es mas común utilizar un mismo objeto para acceder a diferentes registros de un mismo equipo o de diferentes equipos, sin por ello consumir instancias de objetos o complicar demasiado el código, ya que por lo general las salidas se envían a demanda (con el apretado de un botón por ejemplo). En los códigos asociados a esos eventos es cómodo y fácil incluir algunas líneas para preparar las propiedades del objeto para que éste apunte a diferentes destinos. Además, en el caso de las salidas no es importante conservar el último valor que fue enviado, como sí es el caso de las entradas, donde al conservarlo, se puede determinar el evento de cambio.

Hay otros elementos que tambien inciden en la decisión de utilizar más o menos objetos, y es cuando se deben manejar equipos por varios puertos de comunicación en forma simultanea (TAS-HMITalk puede manejar en paralelo varios puertos), o cuando se tienen diferentes tipos de equipos y por lo tanto se necesita utilizar varios drivers y protocolos diferentes para comunicarse con todos ellos. En este caso, intentar utilizar un único objeto para todos es técnicamente posible, pero implica un tremendo esfuerzo de programación que es justamente lo que se intenta evitar con toda la ingeniería puesta en nuestro producto.

Nuevo método TriggerAndWait

Thu, 02 Oct 2008 20:57:00 GMT

Hemos agregado recientemente un nuevo método que le estaba faltando a TAS-HMITalk y que venía siendo sugerido y solicitado por varios de nuestros clientes. Se trata de una variante del método Trigger, que se utiliza habitualmente para disparar manualmente una comunicación, con la diferencia de que TriggerAndWait no retorna el control a la aplicación que lo llama hasta que la comunicación que se haya iniciado haya finalizado, ya sea exitosamente o por algún tipo de error.

Este método permite implementar de manera más sencilla estrategias donde varios objetos deben comunicarse de manera secuencial y encadenada. Hasta el momento, mantener el sincronismo en el disparo de varios objetos se lograba mediante semáforos y llamadas desde los eventos de terminación de la comunicación.

Como ejemplo de uso del nuevo método TriggerAndWait, mostramos este extracto de código que corresponde a un botón que dispara la lectura de un relé de protección y muesra sus datos en un listbox. El código está escrito en C# con Visual Studio.NET 2005:

private void button1_Click(object sender, EventArgs e)

{

axHMITalk1.CommPort = HMITalkLib.enumCommPort.COM1;

axHMITalk1.CommBaudRate = HMITalkLib.enumCommBaudRate._19200_Bauds;

axHMITalk1.CommParity = HMITalkLib.enumCommParity.None;

axHMITalk1.CommDataBits = HMITalkLib.enumCommDataBits._8_Bits;

axHMITalk1.CommStopBits = HMITalkLib.enumCommStopBits._1_Bit;

axHMITalk1.DriverP0 = "1"; // Numero de rele

if (axHMITalk1.TriggerAndWait()) // Se dispara la lectura y si resulta exitosa, se muestran los valores recibidos

{

listBox1.Items.Clear();

listBox1.Items.Add("Numero de Rele: " + axHMITalk1.DriverP0);

listBox1.Items.Add("Eventos disponibles (0=No/1=Sí): " + axHMITalk1.get_PointValue(5).ToString());

listBox1.Items.Add("Alarma declarada (0=No/1=Sí): " + axHMITalk1.get_PointValue(6).ToString());

listBox1.Items.Add("Disparado (0=No/1=Sí): " + axHMITalk1.get_PointValue(7).ToString());

listBox1.Items.Add("Relay 0 (0=No/1=Sí): " + axHMITalk1.get_PointValue(50).ToString());

listBox1.Items.Add("Relay 1 (0=No/1=Sí): " + axHMITalk1.get_PointValue(51).ToString());

listBox1.Items.Add("Relay 2 (0=No/1=Sí): " + axHMITalk1.get_PointValue(52).ToString());

listBox1.Items.Add("Relay 3 (0=No/1=Sí): " + axHMITalk1.get_PointValue(53).ToString());

listBox1.Items.Add("Relay 4 (0=No/1=Sí): " + axHMITalk1.get_PointValue(54).ToString());

listBox1.Items.Add("Relay 5 (0=No/1=Sí): " + axHMITalk1.get_PointValue(55).ToString());

listBox1.Items.Add("Relay 6 (0=No/1=Sí): " + axHMITalk1.get_PointValue(56).ToString());

listBox1.Items.Add("Relay 7 (0=No/1=Sí): " + axHMITalk1.get_PointValue(57).ToString());

listBox1.Items.Add("Corriente en fase A [I0 en Amp]: " + axHMITalk1.get_PointValue(94).ToString());

listBox1.Items.Add("Corriente en fase B [I1 en Amp]: " + axHMITalk1.get_PointValue(95).ToString());

listBox1.Items.Add("Corriente en fase C [I2 en Amp]: " + axHMITalk1.get_PointValue(96).ToString());

listBox1.Items.Add("Corriente en fase N [IN en Amp]: " + axHMITalk1.get_PointValue(90).ToString());

listBox1.Items.Add("Frecuencia [Hertz]: " + axHMITalk1.get_PointValue(8).ToString());

listBox1.Items.Add("Cantidad de operaciones del relay: " + axHMITalk1.get_PointValue(122).ToString());

listBox1.Items.Add("Tensión en fase A [V0 en Volts]: " + axHMITalk1.get_PointValue(104).ToString());

listBox1.Items.Add("Tensión en fase B [V1 en Volts]: " + axHMITalk1.get_PointValue(105).ToString());

listBox1.Items.Add("Tensión en fase C [V2 en Volts]: " + axHMITalk1.get_PointValue(106).ToString());

listBox1.Items.Add("Tensión en fase N [VN en Volts]: " + axHMITalk1.get_PointValue(100).ToString());

}

else MessageBox.Show("Se produjo el siguiente error durante la lectura: " + axHMITalk1.DriverStatus);

}

¿Qué cable debo utilizar para conectar TAS-HMITalk con los PLC Siemens de la serie S7-200?

Tue, 12 Aug 2008 21:06:00 GMT

El driver xs7ppi.tlk se ha utilizado sin inconvenientes en varias aplicaciones desarrolladas con TAS-HMITalk, desde fabricantes de máquinas en Irlanda hasta diversas plantas en México y Argentina. En todos los casos, las aplicaciones se comunicaron con los equipos mediante el cable serial RS-232 multimaestro provisto por Siemens cuyos datos son los siguientes:

- Cable PC/PPI multimaster
- 6ES7 901-3CB30-0XA0
- E-STAND:03

Este cable puede ser ordenado directamente a Siemens de esta manera:

Cable RS232/PPI inteligente con conversor de nivel RS232/RS485 integrado (6ES7 901-3CB30-0XA0)

Configuración sugerida para los DIP Switches del cable:

- 1    0
- 2    1    9600 bauds
- 3    0
- 4    X    Spare
- 5    1    Multimaster
- 6    0    Local DCE
- 7    0    11 bits
- 8    X    Spare

Nota Importante:

La configuración sugerida funciona correctamente con TAS-HMItalk y el driver xs7ppi. No obstante, si usted necesita conectarse con el programa MicroWin de Siemens, debe volver a 0 el dip switch 5 para que el cable se coloque en modo Freeport/PPI en logar de multimaestro. Además, debe tener sin chequear las opciones "Multimaster" y "Advanced PPI" en la configuración de MicroWin. Luego vuelva a 1 el dip switch 5 para volver a comunicarse desde TAS-HMITalk.

¿El sofware TAS-HMITALK me sirve para desarrollar la interfaz HMI ?

Mon, 21 Jul 2008 22:26:00 GMT

Nuestro componente le va a permitir conectarse con sus equipos de campo y obtener sus datos para luego volcarlos en elementos de pantalla que conformarán su HMI. También le va a permitir enviar información hacia sus equipos para controlar sus variables. Pero debemos aclararle que nuestro ActiveX no resuelve específicamente la parte visual de su aplicación sino la parte de manejo del protocolo de comunicaciones y el motor de interrogación y de escritura.

La parte visual se resuelve o bien con los objetos gráficos que ya forman parte estándar de Visual Basic o bien con componentes de terceros como por ejemplo los que usted encontrará en http://www.globalmajic.com/ActiveX-Instrumentation-Library-v35-c61.html o en http://www.dragonflydas.com.

Sólo a modo de bonus, nuestro producto incluye un componente gráfico para armar pequeños gráficos para seguimiento de la evolución de variables en tiempo real. Sobre este componente encontrará algunos ejemplos dentro del paquete de instalación.

¿Qué tipo de conexiones me permite establecer TAS-HMITalk con mis equipos?

Mon, 21 Jul 2008 22:12:00 GMT

Todos nuestros drivers pueden ser utilizados en diferentes configuraciones de vínculo con los equipos, en la medida que éstos lo permitan. La comunicación se puede llevar a cabo con enlaces directos mediante puertos serie, conversores RS-232/485, adaptadores ethernet/serie con o sin redirectores de COM, puertos series virtuales,túneles serie/ethernet/serie o directamente a puertos ethernet de los equipos. El gráfico siguiente ilustra alguinas de estas posibles configuraciones:

¿TAS-HMITalk es lo mismo que un sistema SCADA?

Wed, 16 Jul 2008 19:59:00 GMT

TAS-HMITalk no es precisamente un sistema SCADA pero sí es un excelente sustituto que se puede utilizar como base para armar aplicaciones SCADA de bajo costo.

El producto es un componente ActiveX, también conocido como OCX, que permite, en conjunto con Visual Basic, construir aplicaciones de supervision y control. Nuestro componente se ocupa específicamente de dotar a la aplicacion de la capacidad de comunicación con diversos equipos, es decir, es quien maneja el motor de adquisición de datos junto con los drivers de comunicación para proveer la información de campo a la aplicación. El resto de los aspectos del SCADA, como ser la interfaz con el usuario (HMI), se resuelven por lo general íntegramente con Visual Basic y eventualmente con otros componentes de terceros.

¿Cómo se pueden manipular los bits individuales de un registro del tipo palabra en Modbus?

Mon, 14 Jul 2008 23:23:00 GMT

El comando que deberías utilizar es “Preset Single Register as Unsigned 16-bit Integer”, escribiendo todo el registro de 2 bytes de tu equipo con un valor entre 0 y 65535 que deberás armar previamente a partir de los estados de cada bit involucrado.

Como no existe un comando que maneje automaticamente esto dentro del driver Modbus (me refiero a la posibilidad de armar un valor para un registro analogico a partir de estados individuales de bits), no podrás utilizar un PointValue para cada bit sino que tendrás un único PointValue(0) conteniendo implícitamente todos los bits. Este PointValue contendrá el valor del registro tipo palabra o word que deberás realmente enviar.

Es importante que cuando cambies un bit, no alteres el estado de los demás bits. Sobre todo si cabe la posibilidad de que hayan cambiado en el equipo por medios diferentes al driver del TAS-HMITalk. Para ello recomiendo que al ejecutar la accion de escritura, primero leas con otro objeto el estado actual del registro, luego le modifiques a su valor únicamente el bit que va a ser afectado y finalmente escribas nuevamente el registro desde otro objeto que haga la escritura. Ambos objetos pueden estar encadenados, es decir, en cascada. Cuando quieras escribir, disparas en realidad el hmitalk de lectura (con el método .Trigger). Este, a su vez, cuando ejecuta el evento OnSuccessfullyReceived toma el valor recibido en su PointValue(0), lo altera de acuerdo al bit afectado, lo copia en el PointValue(0) del hmitalk de escritura y llama al método Trigger de este último.

Solo debes tener cuidado al manipular los bits del registro recibido para respetar los demás bits.

Significado de las propiedades de configuración de una comunicación serie

Fri, 04 Jul 2008 15:12:00 GMT

La propiedad CommPort establece cuál es el número de puerto serie a ser abierto y puede ser cualquiera que esté disponible en la PC, ya sea físico o virtual, desde 1 para “COM1” hasta 255 para “COM255”. Para no indicar ningún puerto (NONE), se utiliza el valor 0.

La propiedad CommBaudRate indica la velocidad que tendrá la comunicación, que se mide en “baudios”. Valores típicos para este parámetro son 9600 y 19200. Si bien es un parámetro de tipo entero que puede recibir cualquier valor, sólo deberían utilizarse valores que estén dentro de este rango: 50, 75, 110, 134, 150, 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 28800, 33600, 38400, 57600, 78800 y 115200. Es muy importante que se verifique que los baudios que se utilicen para abrir la conexión coincidan con los que está utilizando también el equipo al que se pretende conectar, ya que de lo contrario éste no entenderá los mensajes y por lo tanto nunca responderá.

La propiedad CommParity indica qué paridad se utilizará durante la comunicación. Los valores más comunes son: None (para ‘N’ o ‘ninguna’), Even (para ‘E’ o ‘par’) y Odd (para ‘O’ o ‘impar’). Las otras dos, Mark y Space, si bien están disponibles casi nunca se utilizan. Al abrir la conexión es muy importante que se verifique que se esté utilizando la misma paridad que esté utilizando el equipo.

La propiedad CommDataBits indica la cantidad de bits de datos que se utilizarán durante las comunicaciones. Puede tomar valores 5, 6, 7 y 8, aunque en la práctica sólo se utilizan 7 y 8, siendo 8 el más común de todos, casi siempre en combinación con la paridad None. Por su parte, es muy común que una cantidad de 7 bits de datos se utilice en combinación con una paridad Even. No obstante, esto no debe tomarse como norma y es de vital importancia para una posterior comunicación exitosa verificar qué cantidad de bits de datos está utilizando el equipo con el que nos pretendemos comunicar.

La propiedad CommStopBits indica la cantidad de bits de parada que se utilizarán durante la comunicación. Los casos que realmente se utilizan son 1 bit de parada (One) y 2 bits de parada (Two), siendo 1 bit de parada el caso más común de todos. Al abrir la conexión es muy importante que se verifique que se esté utilizando la misma cantidad de bits de parada que esté utilizando el equipo.

La propiedad CommTimeout es un entero que establece el tiempo máximo en milisegundos durante el cual el driver aguardará una respuesta del equipo con el que se esté contactando antes de dar por perdida la comunicación en caso de que esta respuesta nunca llegue. Por lo general se define en 2000 milisegundos, es decir, 2 segundos. Este tiempo es suficiente para completar la mayoría de las comunicaciones con equipos de campo.

Cabe señalar que este tiempo no es un retardo sino un límite de tiempo para poder descartar una comunicación fallida y que el driver no se quede indefinidamente esperando una respuesta. El propósito de este parámetro es liberar al driver para que se puedan iniciar nuevos intentos de comunicación con el mismo equipo o con otros equipos.

En condiciones normales de funcionamiento, con una conexión correctamente establecida y con un equipo que se mantiene respondiendo correctamente a todos los mensajes que le llegan, este tiempo jamás se agota ya que por lo general una comunicación exitosa se completa en el orden de 50 a 200 milisegundos, dependiendo de factores como el largo de los mensajes, la velocidad empleada en la comunicación o la velocidad de procesamiento del equipo de campo. No obstante, se debe tener cuidado de no definir un valor de Timeout muy pequeño ya que se podría estar provocando que el driver descarte una comunicación por no haber esperado el tiempo sificiente a que esta termine.

El tiempo de espera Timeout se aplica en realidad a cada dupla de mensajes transmitidos y recibidos y no a toda la comunicación como un conjunto. Comienza a correr ni bien es transmitido un mensaje y se monitorea que este tiempo no sea superado mientras no se reciba una respuesta. Cuando una comunicación única implique el intercambio de varios mensajes entre la PC y el equipo, lo que es un caso bastante normal en ciertos protocolos donde por ejemplo se envía un mensaje previo a cada pedido para lograr la atención del equipo o cuando se bajan archivos de la memoria de un equipo, el chequeo de expiración del timeout se aplicará tantas veces como haya sido necesario transmitir un mensaje durante la comunicación. El parámetro Timeout no debe ser demasiado pequeño (menor de 300 o 400 milisegundos), ya que podría producir errores de timeout indeseados por provocar que el driver abandone la espera de las respuestas del equipo prematuramente.

La propiedad CommT1Delay es un entero que define un retardo en milisegundos que se inserta antes de la transmisión de cada mensaje hacia el equipo y durante el cual se fuerza la señal RTS a un estado alto o activado. Normalmente este retardo se deja en 0 y se utiliza sólo raramente cuando se está utilizando algún tipo de módem o radio para establecer el vínculo que requiere un determinado manejo del RTS.

La propiedad CommT2Delay es otro retardo de tiempo en milisegundos que se utiliza siempre en conjunto con el retardo CommT1Delay y que establece cuánto tiempo se aguarda para bajar la señal RTS una vez que finalizó la transmisión de un mensaje hacia el equipo. Normalmente tampoco se utiliza por lo tanto se deja también en 0.

Un caso en el que se podrían tener que definir valores no nulos para CommT1Delay y CommT2Delay es cuando se usa un conversor RS232/485 antiguo que requiere la manipulación del RTS para cambiar la dirección de su línea de datos. En este caso, de pueden un tanteando valores de unos pocos milisegundos para cada retardo hasta lograr una comunicación exitosa.

La propiedad CommT3Delay es otro retardo de tiempo, también definido en milisegundos, que simplemente introduce una demora fija luego de que se recibe cada mensaje de respuesta desde un equipo. Este retardo sirve para forzar y así asegurar una distancia de tiempo mínima entre la recepción de una respuesta y el envío de un nuevo mensaje hacia el equipo. Casi nunca se utiliza y por defecto se deja en 0, pero puede ser necesario con algunos equipos que necesitan una pausa calibrada entre mensajes por no tener la velocidad de procesamiento necesaria para digerir mensajes que le llegan muy juntos.

El gráfico siguiente da una idea de dónde se insertan los tres retardos recién descriptos.

Las propiedades CommHoldRTSWhileTransmitting y CommHoldRTSWhileReceiving establecen si se va a mantener encendida o apagada la señal RTS (request to send) mientras dure la transmisión y la recepción que conforman la comunicación. Por defecto se define en true (activada), ya que nuestra experiencia nos ha mostrado que muchos conversores RS232/485 actuales se comportan mejor con el RTS encendido que con el RTS apagado, sin ser necesaria una manipulación mas detallada mediante CommT1Delay y CommT2Delay.

Comentarios sobre cómo leer y escribir registros

Fri, 04 Jul 2008 14:16:00 GMT

Para leer un registro:

1) Abre un nuevo proyecto vacio de Visual Basic

2) Agrega el componente HMITalk a tu barra de herramientas

3) Vuelca un objeto HMITalk en tu formulario.

4) Con boton derecho sobre el objeto, accede a su ventana de propiedades

5) Selecciona el puerto y los parametros de comunicacion correctos.

6) Selecciona el driver que corresponda a tu equipo (en este caso nos referimos al XMITSUFX), dejalo como Analog Input, pon DriverNumPoints en 1 y establece los parametros p0=1 (para leer una palabra), p1 con la direccion de la palabra a leer y p2=1 para que lea dos bytes en lugar de uno (estos parametros son de acuerdo lo requerido por el driver XMITSUFX especificamente).

7) En la oreja de Scan deja activada la propiedad ScanActive

8) Acepta los cambios y pon a correr la aplicacion. Deberas ver actividad fluida tanto en la ventana de Tx como en la de Rx. Si esto no es asi y recibes un mensaje de error de Timeout, deberas reconfigurar los parametros de la COM hasta que sean los correctos (los utilizados por tu equipo).

9) Si ya has logrado comunicacion fluida, detén la aplicacion y agrega un Label en tu formulario.

10) En el evento OnPointValueChanged del HMITalk agrega la linea:

"Label1.Caption = HMITalk1.PointValue(0)"

11) Deberias ver el valor en el label variando de acuerdo a la variacion de la variable que pediste del PLC.

Para escribir un registro:

1) Haz una copia del objeto HMITalk con el que lees el registro y nombralo como HMITalk2. Al hacer la copia, nos aseguramos de que herede las mismas propiedades de la COM.

2) Ve a las propiedades del nuevo objeto y en la oreja Driver selecciona la opcion "Analog Output" para la propiedad DriverDataType.

3) Establece el parametro p0=3 (para escribir una palabra). Para este driver, los demas parametros se pueden dejar igual que como ya estaban (estos parametros son de acuerdo lo requerido por el driver XMITSUFX especificamente).

4) Ve a la oreja de "Scan" y apaga la propiedad ScanActive.

5) Asegurate de que la propiedad ScanAutoTrigger este en On.

6) Acepta los cambios realizados y vuelve al form.

7) Agrega un boton Command1 y pon la siguiente linea en su evento Click:

"HMITalk2.PointValue(0)=50".

Con esto asignaremos un valor 50 a la palabra en el PLC y deberas ver que el HMITalk2 genera un mensaje de escritura en las ventanas Tx y Rx. Si la escritura fue exitosa, deberias ademas ver reflejado este valor en el label tan pronto el HMITalk1 haya leido este valor en el PLC.

Basicamente este mecanismo debe funcionar correctamente cualquiera sea el driver que se este utilizando. El ejemplo en project1.vbp que viene en el instalador del HMITalk, utiliza el driver Modbus pero mantiene estos conceptos basicos. Lo que es importante saber es que los valores leidos se retornan en la propiedad PointValue, que es en realidad un vector que tiene "DriverNumPoint", es decir que el rango de indices validos es PointValue(0) a PointValue(DriverNumPoints-1). El HMITalk automaticamente observa si algun valor de cada paquete que se este solicitando ha cambiado su valor desde el pedido anterior y si es asi, despacha el evento OnPointValueChanged informando el indice del point que cambió a traves del parametro "point". En una mismo pedido pueden haber sucedido cambios en varios puntos por lo que este evento se puede disparar varias veces en cada comunicacion, con un valor diferente de "point" cada vez.

Comentarios sobre los conversores ethernet/serial

Fri, 04 Jul 2008 14:08:00 GMT

Una funcionalidad interesante es el hecho de que el TAS-HMITalk soporta conversores ethernet/serial. Esto quiere decir que puedes "rutear" los mensajes producidos por cualquier driver hacia una direccion IP (en lugar de hacia un COM fisico) y, asumiendo que en esa IP hay un conversor IP a 232, comunicarte con un PLC como si estuviera directamente conectado a un puerto serie de la PC. Pero lo haces en realidad a traves de la LAN, sin las limitaciones de distancia de un puerto serie y pudiendo con este metodo dialogar con cientos de IP diferentes, poniendo un conversor en cada PLC (ideal sobre todo en este tipo de PLC que son punto a punto).

Otra ventaja es que si hubiera un problema en la PC, podrias pasar a leer los mismos equipos desde otra PC en la red (tipo hot-standby), sin necesidad de switchear las lineas de comunicacion. Además, la mayoría de estos conversores te permite salir directamente como 485 o 422, por lo que te ahorras el costo de un adaptador 232/485 o 232/422.

Algunos comentarios sobre como ensayar el driver xmitsufx para PLC Mitsubishi FX (incluye conceptos que son válidos para cualquier driver)

Fri, 04 Jul 2008 14:00:00 GMT

Para una prueba rapida, puedes hacer esto:

1) Bajas e instalas la ultima version de TAS-HMITalk disponible

2) Vas a Visual Basic y creas un proyecto nuevo

3) En un formulario vacio colocas un objeto TAS-HMITalk y un Label.

4) Vas a las propiedades del HMITalk y estableces los seteos necesarios en la oreja COM.

5) Vas a la oreja Drivers y seleccionas "xmitsufx"

6) Abres el help del driver y ahi veras (en Read Words of Type T, C or D) que para leer la D100 debes hacer lo siguiente:

a) Estableces DriverDataType como Analog Input (ya esta asi por default)

b) Estableces DriverP0=0 (que es lo mismo que dejarlo vacio o en blanco)

c) Colocas D100 en DriverP6 (si lo haces desde la ventana de propiedades, no le colocas comillas)

d) Como vamos a leer una unica posicion a partir de D100, dejas DriverNumPoints en 1.

e) Todos los demas parametros los dejas como estan por default.

7) Vas a la oreja Scan y le habilitas el ScanActive

8) Aceptas los cambios de las propiedades, vuelves al formulario y das dobleclick en el objeto

9) Te lleva al evento OnPointValueChanged

10) Alli escribes:

Private Sub HMITalk1_OnPointValueChanged(ByVal Point As Integer)

Label1.Caption = Format$(HMITalk1.PointValue(0))

End Sub

11) Echas a correr el programa y veras que el HMITalk se comunica solo y te mantiene actualizado el label con lo que tenga D100.

Variantes:

Si quisieras leer mas de una posicion consecutiva, le aumentas la cantidad en el parametro DriverNumPoints.

Entonces, el evento OnPointValueChanged te ira indicando mediante el parametro 'Point' cual ha sido el punto que fue cambiando. Si cambiaran varios a la vez en una misma lectura (respecto a sus valores anteriores), recibiras tantos eventos OnPointValueChanged como sean necesarios, cada vez con un valor diferente de Point.

Si quisieras mostrar todos los valores leidos, que supongamos que fueran 8, podrias crear un array de 8 labels a partir del Label1 que habias puesto.

Entonces, solo tendras que modificar lo que tenias en el evento OnPointValueChanged por lo siguiente:

Private Sub HMITalk1_OnPointValueChanged(ByVal Point As Integer)

Label1(Point).Caption = Format$(HMITalk1.PointValue(Point))

End Sub

Fijate que las propiedades PointValue(0) a PointValue(7) tendran los valores leidos desde las posiciones D100 en adelante. Esto quiere decir que Point podra variar entre 0 y 7. Asumiendo que el array que armaste tiene indices que varian tambien entre 0 y 7, puedes aprovechar el valor de Point para recorrer el array. Entonces, con una sola linea de codigo en el lugar indicado, ya tienes armada toda la asignacion de los 8 valores a sus respectivos 8 labels. Es decir, con la linea que te estoy mostrando aqui, podrias estar asignando decenas de puntos, sin modificar nada salvo el valor de DriverNumPoints.

Algunos comentarios sobre cómo mejorar la velocidad de barrido y sobre cómo realimentar rápido el estado de una salida sobre la que se acaba de actuar

Fri, 04 Jul 2008 13:55:00 GMT

Si te refieres al tiempo de lectura en si mismo, no hay mucho que se pueda hacer una vez que estableces el baudiaje. Si te comunicas a 9600 baudios, por ejemplo, lo mas que se puede hacer es mantener el ancho de banda ocupado todo el tiempo. No puedes comunicarte mas rapido de lo que te permite el puerto serial en si. Pero si puedes optimizar el ciclo. Por ejemplo, los objetos TAS podrian tener un tiempo de scan bajo (p.e 100ms) y si quieres puedes definir la base de tiempo interna de cada TAS a algo entre 10 y 50 ms (propiedad TimerInterval, que no es lo mismo que ScanInterval pero acelera la respuesta interna de los objetos TAS ante llegada de nuevos mensajes por el COM). Las salidas siempre se intercalan en cualquier momento del loop de lectura. No obstante, si quieres realimentar inmediatamente el estado de una salida que acabas de cambiar, lo que te recomiendo es que establezcas a prioridad alta al TAS encargado de realimentar. Te transcribo un a breve explicacion que le envie hace poco a un usuario:

"1) Para la salida, te aseguras que AutoTrigger este en False para que no la despache dos veces cuando vos haces tu propio llamado a Trigger

2) No utilizar llamadas al metodo Wait del TAS que puedan detener y demorar todo durante los milisegundos que se le indiquen.

3) El hecho de que la escritura no te devuelva "OnErrorSending" ya deberia ser suficiente para asegurar que el dato se envio (salvo que haya una logica interna dentro del PLC tal que el dato sobre el que escribis no es directamente la salida al motor).

4) Si queres confirmar, obviamente utilizas otro tas que se ocupa unicamente de leer ese estado. Ese TAS puede encender su scan (.ScanActive=True) cuando viene el OnSuccessfullySent del tas que envio la salida. Ademas, por si hubiera varios tas leyendo otras cosas y a los efectos de que el feedback se haga tan pronto como sea posible, le pones al tas de lectura ademas .ScanPriority=3, o cualquier otra que sea mas alta que los demas tas.

4) Si no te interesa que el tas de lectura para feedback siga leyendo, simplemente lo auto-apagas cuando se ejecuta su evento OnSuccessfullyReceived.

5) Si quisieras dejarlo prendido todo el tiempo, asegurate de volverlo a una prioridad normal (ScanPriority=0) para que no siga con alta prioridad todo el tiempo. Esto tambien lo haces al recibir el OnSuccessfullyReceived."

¿Cómo puedo compartir un mismo puerto desde varias aplicaciones?

Fri, 04 Jul 2008 13:52:00 GMT

Para utilizar un mismo puerto serial desde varias aplicaciones, la unica condicion es que liberes el puerto en una aplicacion para que lo utilice la otra. Entonces, seteas dinámicamente la propiedad CommPort a COM=none para todos los TAS de una aplicacion para que la otra pueda tomar ese puerto. Para automatizar el proceso, tienes que tener algun tipo de semaforizacion entre aplicaciones. Por ejemplo, una variable que ambas consulten en el registro de Windows, en un archivo o en una base de datos y mediante la cual se indican mutuamente cuando tomar o liberar el puerto.

Recomendaciones para comunicarse con un PLC SLC-500 de Allen Bradley utilizando TAS-HMITalk

Thu, 03 Jul 2008 15:38:00 GMT

En primer lugar, le recomendaria comunicarse utilizando el driver XABSLC5 en lugar de utilizar el XABF. Asumiendo que todas las propiedades relativas al puerto serie (oreja Comm del HMITalk) estan configuradas correctamente, para los datos que usted nos indica (leer 6 salidas) deberia configurar el driver de esta manera:

Utilizar el comando "Generic Read as Binary Values" y para ello setear:

- DriverDataType = Digital Input (asumiendo que las salidas que necesita leer son digitales, es decir, 0 o 1)

- DriverP0 = 1 (direccion del PLC de destino)

- DriverP1 = 0

- DriverP5 = 0 o 1 segun si se utiliza BCC o CRC. Probar con ambos si no se esta seguro del tipo de chequeo que utiliza el PLC

- DriverP6 = "O0:0" o la direccion del primer item a ser leido

- DriverNumPoints = 6

Luego de realizar la comunicacion (mediante el metodo .Trigger o simplemente dejando ScanActive=On), se debe utilizar el evento OnPointValueChanged para leer cada bit leido. Estos bits (su estado) se consultan en el array .PointValue(0) hasta .PointValue(5). El evento OnPointValueChanged entrega una variable "Point" que da el indice del bit que acaba de cambiar. Este indice en este caso ira de 0 a 5. Si mas de un bit cambia a la vez, este evento se repite tantas veces como bits hayan cambiado, cada vez entregando un valor diferente para el indice "Point". Por ello es conveniente plantear el codigo que atiende este evento con una sentencia "Select Case" que dependa de la variable "Point" del evento.

Para enviar salidas, habra que configurar un segundo objeto HMITalk ya que no se puede utilizar el mismo que se utiliza para leer. El HMITalk de escritura puede manejar envio grupos multiplos de 16 bits, es decir que no se puede escribir un bit individual sin afectar tambien los bits que pertenecen al mismo registro de 16bits donde ese bit esta contenido. El comando a utilizarse es el Generic Write as Binary Values que se configura igual que el de lectura, pero tiene DriverDataType = Digital Output. Para mantener iguales los demas bits de un mismo word, es conveniente "cargar" los otros 15 bits del mismo word con los valores que se sabe que esos bits deben tener para no alterar su valor. Aqui se debe tomar nota de lo que en ese momento este leyendo el otro HMITalk que se utiliza para leer esos mismos bits. Por ello puede resultar conveniente leer 16 bits en lugar de los 6 que usted quiere leer para asi tener con que rellenar el word al escribir. Cuando el bit que se desea cambiar y sus 15 bits vecinos estan con los valores apropiados, se llama al metodo .Trigger que despacha la comunicacion (en el caso de salidas, es mejor hacerlo asi en lugar de utilizar ScanActive=On ya que con esto ultimo, se estaria enviando el valor nuevamente en cada ScanInterval). Otra cosa importante al escribir es dejar ScanAutoTrigger=Off (por default viene en On). Los valores a ser enviados se cargan en PointValue(0) a PointValue(15) antes de llamar al metodo Trigger. Si se deja ScanAutoTrigger=On, lo que sucede es que ni bien se carga PointValue(0), la escritura se dispara automaticamenteantes y esto puede pasar antes de haber cargado los otros bits a escribir en el mismo envio.

¿Es sencillo desarrollar aplicaciones HMI/SCADA con TAS-HMITalk?

Thu, 03 Jul 2008 15:24:00 GMT

La facilidad con la que se puede desarrollar una aplicacion HMI/SCADA depende en realidad de la plataforma de programacion que se utilice (Visual Basic, Delphi, etc). TAS-HMITalk es un componente de software del tipo ActiveX que resuelve una parte del problema que es la comunicacion con los equipos de campo y es una herramienta que se debe utilizar en conjunto con otras herramientas. El componente entrega una cantidad de propiedades, metodos y eventos para que el desarrollador de la aplicacion interactue con los datos recibidos o enviados, establezca las estrategias de poleo, etc. Pero luego, todo lo relativo a la manipulacion de esos datos y su presentacion posterior en pantallas graficas, tendencias, historicos, etc, corre mas bien por cuenta de la plataforma de desarrollo. Cualquier aplicación de supervisión y control es prefectamente factible de ser preparada con Visual Basic aunque, claro, se necesita alguna experiencia en el empleo de esa herramienta.

Como alternativa a la manera que utiliza TAS-HMITalk para manejar los Tags, se puede crear una base de datos propia en SQL o Access y utilizar TAS-HMITalk unicamente para que le realice la comunicacion y mantenga actualizada su base. Sino, se pueden directamente utilizar las propiedades PointValue de cada objeto TAS-HMITalk como unico reservorio de los valores recibidos, que entre parentesis es lo que hacen la mayoria de los usuarios de nuestro producto.

TAS-HMITalk es un producto pensado para armar rapido pequeñas aplicaciones, aunque tambien se puede utilizar para grandes aplicaciones. No es mas que una maquina de poleo totalmente programable y configurable que permite utilizar diferentes drivers para manejar diferentes protocolos de comunicacion. Cada objeto TAS-HMITalk individual puede leer paquetes de hasta 1000 valores, aunque siempre esta cantidad se ve luego limitada por el tamaño maximo de los mensajes que los equipos de campo pueden manejar (lo que a su vez depende directamente de las capacidades del protocolo en particular). Una aplicacion puede tener un sin-numero de objetos TAS-HMITalk (hasta 500 objetos por aplicacion) donde cada uno de ellos puede estar dedicado a obtener un paquete de datos de un determinado equipo en una red. Ademas esos objetos TAS-HMITalk se pueden crear en tiempo de ejecucion si la aplicacion asi lo requiriera.

La parte grafica, a nivel de interfaz de usuario donde se muestran los datos, se puede resolver utilizando desde simples objetos Label o Textbox para visualizar los valores y botones para disparar el envio de datos, pasando por otros objetos de uso comun en Visual Basic como ProgressBars, ScrollBars, CheckBoxes, OptionButtons, etc, que enriquecen las pantallas. Todo esto combinado con el uso de colores y tipos de font, recuadros, etc. Hay objetos especificamente para uso grafico como ser el objeto Shape para producir lineas, circulos, etc. Despues existen en el mercado innumerables objetos third-party que, al igual que el TAS-HMITalk, son componentes ActiveX que brindan apoyo al proceso de desarrollo resolviendo temas bien puntuales. Por ejemplo, en www.globalmajic.com encontrara una liberia de componentes que le permiten armar pantallas mas sofisticadas donde mostrar los datos.

Respecto de los historicos y tendencias, algunos integradores simplemente almacenan los datos en tablas SQL o Access y luego utilizan algun producto para graficacion externo a la aplicacion que sepa como acceder a los datos de la base. Es una parte compleja si uno la quiere resolver dentro de la aplicacion, pero hay tambien en este caso muchos objetos ActiveX para embeber capacidades de graficacion directamente en las aplicaciones Visual Basic. Sin ir mas lejos, Visual Basic ya trae incluido un objeto de graficacion elemental pero util llamado MSChart.

Respecto del intercambio de informacion entre varias maquinas, tambien es posible mediante el objeto WinSock, incluido en VB y que permite enviar mensajes entre aplicaciones donde se pueden transmitir los datos deseados.

Armar una pagina web en formato html tampoco es complicado. Son archivos en formato ASCII que se pueden facilmente crear al vuelo desde una aplicacion. Para estamparle graficos, hay formas de convertir a .gif lo que uno esta viendo en pantalla para que luego esto se vea a su vez desde un navegador. Pero este es un terreno donde se puede pedir poco o mucho. Si por ejemplo usted quiere una pantalla web totalmente interactiva, ya debe pasar a un lenguaje tipo asp.net donde el expertise necesario para armar algo ya es otro.

¿Qué significa el mensaje de error ‘[1300] PROTOCOL (Timeout): No Answer’?

Thu, 03 Jul 2008 14:58:00 GMT

Este mensaje es el mas comun para cualquier driver y esta indicando que no esta llegando respuesta del equipo. Esto puede deberse a muchas causas.

Los seteos del puerto serie (bits de stop, paridad, data bits y baudios) son importantes ya que cualquiera que este mal es suficiente para que no te puedas comunicar. Pero la cosa no termina ahi: tambien puede
ser un cable mal armado, un manejo inapropiado de la linea de control RTS, mal el numero de equipo al que se dirigen los mensajes, el formato de los mensajes esperado por el equipo es diferente al que emite el driver, etc.

Lo primero que necesitas hacer es cerciorarte de los baudios, bits de stop, data bits y paridad que el equipo esta utilizando. Si no estas seguro de alguno, prueba todas las combinaciones posibles. Lo ideal es acotar la incertidumbre a un solo dato o seteo, ya que sino tenes que hacer muchas combinaciones con todos los datos inciertos hasta encontrar los correctos.

Suponiendo que ya has verificado que el pin-out del cable que estas utilizando es el correcto y que los seteos de la COM son los correctos, sugeriría probar con diferentes numeros de estacion (generalmente definido en la propiedad DriverP0). Si no apuntas al numero de equipo correcto, este tampoco va a responder.

Si usas un conversor 232/485, hay ademas que jugar con los seteos CommT1Delay y CommT1Delay, mas el tema de mantener RTS arriba al leer o escribir. Algunos conversores necesitan que la señal RTS se mantenga todo el tiempo encendida. Te recomiendo utilizar combinaciones con los parametros DriverT1, DriverT2, CommHoldRTSWhileTransmitting y CommHoldRTSWhileReceiving. En
particular, empezaria por habilitar estos dos ultimos. Si la comunicación aun no funciona, los dejaria deshabilitados y probaria con valores de 10 o 20 en CommT1Delay y CommT1Delay.

Comentarios sobre cómo manejar llamadas telefónicas al comunicarse con un equipo

Wed, 02 Jul 2008 00:24:00 GMT

Respecto de las llamadas telefonicas, puedes utilizar el driver xmodem que se incluye con TAS-HMITalk.

Suponte que tienes que obtener informacion de un equipo al que te conectas por telefono. Tu sabes que el hecho de discar y conectarte via modem lleva un tiempo de conexión que es grande comparado con lo que se tarda en pedir un dato a un equipo.
Entonces, cuando tienes que pedir varios datos y utilizas para ello varios objetos HMITalk, lo mejor es llamar una unica vez, activar todos los hmitalk para que hagan su solicitud (mediante el metodo Trigger de cada uno de ellos para que lean una unica vez), y luego cortas la llamada. Ahora bien, si por algun motivo el modem se conecto bien con el otro modem pero aun asi el equipo no responde porque esta caido o lo que fuese, al intentar comunicarte desde el primer hmitalk de tu aplicación recibiras un error. No tendra sentido entonces disparar un Trigger de los demas hmitalk si ya sabes que el primero no se comunico ya que esto solamente serviria para que todos los demas tambien consuman el timeout y demoren tu aplicación. Esto claro es valido en aquellos casos en los que estas siempre interrogando a algun equipo y necesitas optimizar todo el lazo de interrogacion. Entonces, para lo que sirve el Watchdog es para pedir un dato cualquiera que te permita saber si el equipo esta respondiendo. Si es asi, entonces disparas todos los demas objetos.

En realidad, cualquier objeto hmitalk puede actuar como Watchdog de los demas sin necesidad de crear uno expresamente con ese fin. Cada programador resuelve este tema a su criterio de acuerdo a su necesidad. En este caso, tu decides si la estrategia del ejemplo se acomoda o no a tu necesidad. Lo importante es mostrarte cual es el razonamiento que hay detrás de ella.

Algunos puntos a chequear en caso de no poder comunicarse utilizando un driver Modbus RTU

Wed, 02 Jul 2008 00:07:00 GMT

Estas utilizando algun tipo de conversor 232/485?
Si lo estas utilizando, esta convenientemente cableado y energizado?
Si lo estas utilizando, tienes marcadas las propiedades CommHoldRTSWhileTransmitting/Receiving?
Has probado el cable con algun otro programa que venga con el equipo?
Estas segurisima que este equipo habla Modbus RTU?
Segura que lo hace por el puerto al que te estas conectando y no por otro?
Que numero de estacion tiene el equipo configurado?. Tienes dudas sobre este dato?
Que baudiaje tiene el equipo configurado?. Tienes dudas sobre este dato?
Que paridad tiene el equipo configurada?. Tienes dudas sobre este dato?
Que cantidad de bits de datos tiene el equipo configurado?. Tienes dudas sobre este dato?
Que cantidad de bits de stop tiene el equipo configurado?. Tienes dudas sobre este dato?
Estas saliendo por la COM correcta desde la PC? Tienes mas de una?
Tienes claro el mapa de direcciones validas para este equipo?
Existen las direcciones que has intentado acceder?
Si desconectas el equipo de campo y puenteas los pines tx con rx en el extremo que iba enchufado al equipo, puedes ver entrando en rx lo mismo que acabas de enviar? (si se trata de lectura de registros, seguira dando error de timeout porque lo que vendra no sera la respuesta esperada. Si por el contrario estuvieras enviando una salida, te dara el envio como valido ya que en Modbus, el acknoledge de una escritura es devolver lo mismo que se envio, por lo que el puente que te indico le hara creer al driver que fue el equipo quien respondio).

Comentarios acerca de cómo armar la interfaz gráfica de una aplicación

Wed, 02 Jul 2008 00:04:00 GMT

Respecto de la interfaz gráfica, depende de cual sea el aspecto que le quieras dar. Con Visual Basic puedes armar practicamente cualquier cosa. Si quieres objetos puramente graficos (como frentes de instrumentos de aguja, por ejemplo), los puedes buscar en la web. Rockwell Software y Global Majic tienen buenas propuestas al respecto. Si lo unico que necesitas es armar unifilares, puedes simplemente colocar imágenes de fondo en tus formularios y luego colocarles encima los labels con las mediciones y objetos tipo ‘linea’ que cambien de posicion, grosor o color en funcion de las variables.

Sugerencias sobre cómo armar un panel de alarmas con TAS-HMITalk

Tue, 01 Jul 2008 23:57:00 GMT

Respecto de armar un panel de alarmas, puede ser algo simple o algo complicado, según lo que estes necesitando.

Si se trata de leer algunos estados que luego tú interpretas como estados de alarma, puedes mostrar una pantalla con objetos tipo CheckBox que indiquen que alarmas están ocurriendo en un momento dado.

Si lo quieres tipo un log de alarmas, tal vez puedes utilizar un ListBox al que le vas apendeando mensajes con fecha, hora y un texto descriptivo cada vez que detectas un cambio de una variable a un determinado estado. Este log se puede ir guardando en disco en paralelo, para que quede registrada toda la historia de alarmas que se produjeron.

Si ademas necesitas una notificacion de parte del usuario, puedes proveer un botón que se des-grisa cuando el operados selecciona la alarma que quiere notificar dentro del listbox, y que al presionarlo agregue una nueva linea al listbox (tambien con fecha y hora) indicando un texto de notificacion de esa alarma. Todo esto puede ir quedando tambien en disco, registrandose los hechos (alarmas y notificaciones) en el mismo orden con que se produjeron.

Existen objetos mas complejos que el listbox que te permiten asignar diferentes colores y tipos de letra a los textos que le vas agregando. Hay incluso objetos que imitan pequeñas planillas de Excel que puedes embeber en tus formularios. Depende de lo que quieras lograr, tienes un monton de recursos a tu disposicion, aunque todo lleva su tiempo y depende de cuan familiarizada estes con VisualBasic para producir mas o menos rápido los resultados buscados.

Comentarios de un usuario sobre cómo conectarse con un Siemens S7-226

Tue, 01 Jul 2008 23:33:00 GMT

(Referido al driver xs7ppi para PLC Siemens de la línea S7-200)

Muchas gracias por tu amable respuesta.
Como te comenté telefonicamente, la comunicación con el S7 226 finalmente funcionó.
Por si esta información te fuese útil, te comento como quedaron las configuraciones :

Cable Siemens PPI / RS 232 tipo 6ES7 901-3CB30-0XA0
Dip Switches
1    0
2    1    Esta combinación de S1,S2 y S3 es para 9600 bauds,
3    0    pero consegui que funcione hasta 38.400 con el adaptador USB - RS232
-------
4    X    Spare
5    1    Multimaster
6    0    Local DCE
7    0    11 bits
8    X    Spare

Nota Importante: Te confirmo que no pude comunicarme con el Microwin ver. 4.0 y el cable RS232/ PPI. con la combinción descripta mas arriba del Dip Switch apta para el Hmitalk
Para hacerlo es necesario configurar el Microwin quitando los tildes de "Multimaster" y "Advanced PPI" y poner el DS No. 5 del cable en cero, o sea como
Freeport / PPI y comunicarlo a 9600 bauds.
En cambio, usando el otro cable que tengo que es USB / PPI no hay problema en comunicarse con el MicroWin tanto en forma "Advanced PPI" como "Multimaster"

En cuanto al seteo del Hmitalk corresponde exactamente a lo indicado en el Help sin problemas

Un abrazo y gracias por todo