En este post vamos a dar unos tips de como configurar un Intouch en RDS.
Para ello, lo primero que vamos a dejar claro, es que necesitamos un Servidor con el role de RDS instalado.
En nuestro ejemplo tenemos un Servidor que se llama RDPSERVER con una IP 192.168.1.100
Y que tenemos preparados unos usuarios para iniciar dichas sesiones.
Tambien tenemos dos clientes, uno de ellos con nombre RDP1PC y su IP 192.168.1.96 . El siguiente tiene como nombre RDP2PC y su IP 192.168.1.98, donde estan iniciadas las sesiones al servidor como se muestra
Lo siguiente que tenemos que tener claro son las funcionalidades de las que vamos a disponer en este tipo de configuración.
Y las funciones que vamos a utilizar son las siguientes:
Ahora conceptos a considerar, la sesión console será la responsable de iniciar el alarm DB Logger y será la primera en iniciar, posteriormente todos los clientes que se hayan configurado.
En este ejemplo tenemos dos clientes conectados y así es como hemos configurado el Alarm DB Logger.
En la siguiente imagen podemos observar como hemos configurado las query de nuestro servidor y todos los clientes que se tengan que configurar.
Para saber el estado constante de todas las instancias ejecutándose, vamos a configurar el Script de inicio y el while running.
Este podría ser un ejemplo , aunque se podría simplificar un poco mas, pero así vemos como utilizar todas las funciones TSE
Con la configuración de estas varibles ya sabremos qué estado tenemos de todos nuestros clientes y servidor.
Como detalle, todas esas variables que son internas, estan configuradas como I/O apuntando a View para no conectar un PLC . Se deberían sustutuir por variables de PLC, pero lo que tenemos que tener claro es que deben de ser I/O porque necesitamos saber su valor en todas las instancias.
Todas las variables internas que tenga nuestro proyecto, serán instanciadas en tantas sesiones como clientes se conecten y sus valores serán independientes en cada sesión.
Aqui podemos observar como las variables internas en cada instancia tienen su propio valor, que será independiente de cada sesión.
También nos van a servir para saber que función va a ejecutar cada cliente, restringir acceso a pantallas dependiendo de donde se ejecute y todo lo que nos interese.
El claro ejemplo sería, si trabajamos con Base de Datos y hacemos una inserción de datos, solo nos interesa que se ejecute una sola vez, para no duplicar registros etc… y que no se ejecuten en todas las sesiones
Y cuando vayamos a cerrar el runtime podemos utilizar el siguiente script.
Ahora ya solo nos queda ir iniciando las sesiones y comprobar su funcionamiento, en este caso ya tenemos el servidor y un cliente conectado.
Todas las sesiones iniciadas y todos los (providers and consumers) funcionando correctamente.
Como ya hemos comentado vamos a poder filtrar que alarmas y eventos queremos ver en cada cliente, ya que sabemos si se está ejecunto o no y donde, con lo cual, la query será dinamica para cada cliente.
Y en los historicos observamos todos los registros que se van registrando.
En este ejemplo, estamos utilizando el mismo proyecto y mismo directorio para todas las instancias.
Pero, ¿qué pasa si necesitamos que todas nuestras variables internas sean variables retentivas? Pues utilizaremos está configuración en NAD para todos los clientes.