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.