oct 31

Escrito por: Soporte CPKSoft Ingeniería
31/10/2008 14:08

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.

Tags: