Hola Boris buenas tardes,

Hace unos días trás actualicé la versión de firmware de mi PLC (estaba en 223 y pasé a 224). Todo estaba funcionando bien, y sigue funcionando bien después de la actualización. Actualicé simplemente para tener instalado "lo último".

Lo único que encontré de diferente es que los emails ahora me llegan con un "pie de email", con el siguiente formato:

AQUI VIENE MI TEXTO DEL MAIL.
y lo que sigue lo agrega el PLC
--

PLC
miemail@gmail.com


Aparentemente, la nueva versión de Fw le agrega este "pie de email", o se me está agregando por algún otro lado (Gmail?). Tendrá que ver con lo incluído en Build 224 "Correción para envio de mails con función SmtpSimple(), adaptado para mejorar calidad del mail y no ser considerado SPAM."

La verdad es que me gustaba más antes (sin el agregado...). O yo puedo configurar para que el "pie" salga o no salga?

Saludos !
Pablo.

Hola Boris, buenas tardes !

Sería factible "migrar" el mecanismo de comunicación de VirtualHMI de UDP a TCP ?

El motivo es que a medida en que uno usa más VirtualHMI se da cuenta de que es el mejor medio de visualizar información del sistema. Es espectacular. Pero lamentablemente, al ser UDP solo puede funcionar dentro de la misma red LAN donde está el PLC. Si fuera TCP, podríamos acceder "desde afuera" como hago actualmente mediante ModBUS. Pero ModBUS es extremadamente limitado y lerdo !

Muchas gracias,
Pablo.

Hola Boris, buenos días,
Se que estás de vacaciones, pero te dejo esta inquietud para más adelante.
Hace una semana atrás me puse a hacer unas actualizaciones al software de mi sistema PLC. Como siempre hago, primero chequeo si hay versiones nuevas e instalo todo lo nuevo (aún sin necesitarlo). Entonces actualicé STXLadder a 1.7.2 y el firmware al release 215.
Y me puse a hacer unas modificaciones a mi sistema.

Una de las funcionalidades que tengo, como ya sabés, es consultar el estado del sistema utilizando ModBus, que siempre me anduvo perfecto. En esta oportunidad no toqué nada que tenga que ver con ModBus, pero al probar el sistema, me encontré con que ahora, con el nuevo firmware, la respuesta de ModBus se hizo tan lenta, que no llega a completarse nunca el llenado de las variables que yo leo via ModBus. Es como que llegan a leerse las primeras 3 a 5 variables, y luego se queda como si el tiempo de respuesta del PLC no fuera suficiente para atender los requerimientos de ModBus.

Estuve viendo que en el otro hilo en el que se habla de las nuevas funcionalidades TCP (muy interesante tenerlas!), también se menciona un problema de tiempos de respuesta.
Mi sospecha es que al incluírse las funcionalidades de servidor TCP, se podría haber reducido notablemente la capacidad de responder a los requerimientos ModBus. O quizá tiene que ver con la incorporación de las nuevas funcionalidades de web server.
Aclaro que en mi proyecto, donde se manifestó el problema, no estoy utilizando TCP ni web server. Lo que sí tengo es ModBus, recepción de paquetes UDP y VirtualHMI (que también es por UDP).

La cuestión es que yo pensé que el problema se había generado en las modificaciones de código que había hecho en mi proyecto Pawn. Luego de probar y probar se me ocurrió volver atrás el firmware a la versión que tenía hasta entonces (la 208). La instalé, y todo salió perfecto de nuevo.

O sea que me parece que en el firmware 215 existe alguna interacción (al menos) entre Modbus y Servidor TCP.

Te mando un gran saludo, y felicitaciones por todas las nuevas funcionalidades que le estás agregando. Sabés que todo esto relacionado con la conectividad a mi me parece muy muy importante y útil, como cuando incorporaste ThingSpeak...

Pablo.

Hola Boris, buen día,

Te escribo este post para proponerte algunas ideas sobre los productos, luego de casi 2 años de utilizarlo, y también en función de lo que veo que está ocurriendo en el mundo en materia de IOT (Internet de las Cosas).

Sobre el VirtualHMI para Android: te cuento que lo tengo instalado en el celular, aunque todavía no lo estoy utilizando en la práctica. Pero hay algunas funcionalidades que creo que serían interesantes y no las veo contempladas:
- Cuando se hace la consulta de los datos del PLC (PLC info) está faltando un dato muy importante (o no lo encontré): la fecha y hora actual del PLC.
- De la misma manera, el VirtualHMI debería poder setear la fecha y hora del PLC, tomando la fecha y hora del celular. Esta funcionalidad es muy importante puesto que existe un drift bastante importante en la hora del PLC (varios minutos por mes), y requiere que se actualice con cierta periodicidad, porque si no los eventos comienzan a ocurrir a horas que no son las programadas.
- La posibilidad de utilizar Virtual HMI desde la WAN (o sea, desde internet). Para ello, lo que sería necesario es que en el lugar donde se configura el "Address", se pueda cargar una dirección tal como pepe.dyndns.org:10520.  Entonces "desde afuera" podrías acceder al PLC, consultar su estado, setear variables, etc.
- Y por último, sería espectacular tener la posibilidad de crear pantallas configuradas por el usuario, donde puedas configurar botones con nombres, y cargar valores en las variables.

Sobre la conectividad del PLC: Es un tema sobre el que ya hemos conversado antes, pero por cuestiones laborales he tenido que profundizar y comprender algo más. Hoy en día existen protocolos y plataformas gratuitas, donde los dispositivos IOT pueden fácilmente "subir" estados binarios o valores numéricos a una cuenta asociada, y luego esa información se disponibiliza via web para su consulta, y también para interactuar (se pueden cargar estados via web, que en la próxima consulta del PLC, dicha información llega al PLC).
Existen 2 protocolos y plataformas hoy en día muy en uso (aunque hay muchas otras):
MQTT: www.mqtt.org
ThingSpeak: www.thingspeak.com

Por ejemplo: en el siguiente link tenés una persona que hizo un simple dispositivo que con un chip wifi "sube" periodicamente a ThingSpeak los datos de temperatura y humedad que obtiene con un sensor:
www.instructables.com/id/Low-cost-WIFI-temperature-data-logger-based-on-ESP/?ALLSTEPS
Y en el siguiente link se accede a la correspondiente página ThingSpeak, en la que se consultan los datos recolectados a lo largo del tiempo:
http://thingspeak.com/channels/21857
En definitiva, si nuestros PLC pudieran acceder a estos servicios "en la nube", podríamos ir recolectando información a lo largo del tiempo, y consultarla via web en cualquier instante.

Para poder implementar esto, todo se resume a una cosa: es necesario que el PLC posea adentro el protocolo http y https. Eso es todo. Porque la actualización o envío de información a estos servicios se realiza precisamente ejecutando una URL con ciertos parámetros (que se obtienen con anterioridad al momento de crear la "cuenta"). Habría que ver si para la arquitectura de estos PLC ya existen desarrolladas las librerías http y https, e incorporarlas.

Bueno, te dejo estas inquietudes, que sé que son muuuucho trabajo. Pero es que el tema de la conectividad via internet de todos los dispositivos de control es algo imprescindible.

Dicho sea de paso: el equipo anda espectacular, no se cuelga nunca, no falla nunca !!

Saludos,
Pablo.

Hola Boris, como estas ?

Te acordás que en Junio ya te había reportado que tenía dificultades con el envío de mails.
Bueno, nunca pude resolver el problema todavía.
Pero le he dedicado muchas, muchas horas en estos días, y he podido llegar a algunas conclusiones.

Por lo pronto, te cuento que estoy usando el SMTP de Arnet, con destino a una cuenta Gmail que levanto en mi celular.
Esto está probado y anda perfecto.

En mi opinión, hay un bug en la función SmtpSend().
Y es una falla tipo "toggle", que está presente en una ejecución, y no en la siguiente.

Fijate esta secuencia de eventos:

1- Cargo el firmware al PLC (esto hace que se resetee todo). Automáticamente me envía un email de notificación de encendido. Sale el mail y llega al instante.
2- Provoco un evento que hace salir una notificación. Sale el mail y llega al instante.
3- Provoco un evento que hace salir una notificación. Se queda aprox. 30 segundos en SmtpStatus=127 (enviando), y luego termina con SmtpStatus=-1  (falló el envío).

Ahora repito los pasos 2 y 3:
4- Provoco un evento que hace salir una notificación. Sale el mail y llega al instante.
5- Provoco un evento que hace salir una notificación. Se queda aprox. 30 segundos en SmtpStatus=127 (enviando), y luego termina con SmtpStatus=-1  (falló el envío).

Y así indefinidamente los últimos 2 eventos: el primero sale, el segundo no sale.

Si vuelvo a repetir todo desde el paso 1, se repite todo exactamente igual.

He revisado mi código mil veces, y he llegado a la conclusión de que la función SmtpSend tiene que tener un bug tipo "toggle".

Tengo en uso la última versión de firmware disponible, y también el ultimo entorno de desarrollo.

Bueno, te dejo la inquietud.

Muchas gracias desde ya,
Pablo.

Hola Boris, qué tal ?   Tengo un par de consultas relativas a programación Pawn:

1) Las operaciones AND y OR tienen algun tipo de precedencia entre sí?
   Concretamente: La operación AND (&&) parece tener precedencia sobre la OR (||):

   if( (Condicion1) && (Condicion2) ||
       (Condicion3) && (Condicion4) ||   
       (Condicion5) && (Condicion6) ||
       (Condicion7) && (Condicion8) )
   {
      Accion
   }

   Si es como a mí me parece, entonces la expresión anterior se evaluará  "renglón por renglón", sin tener que ponerle un paréntesis a cada renglón, de la siguiente forma:

   if( ((Condicion1) && (Condicion2)) ||
       ((Condicion3) && (Condicion4)) ||   
       ((Condicion5) && (Condicion6)) ||
       ((Condicion7) && (Condicion8)) )
   {
      Accion
   }

   O sea que sería igual hacerlo de cualquiera de las dos formas. Es correcto ??


2) Estoy teniendo un problema con los temporizadores tipo Timeout, por el hecho de que todos los Timeouts "comparten" la misma función de servicio @OnTimeout(). El esquema es el siguiente:

Al comienzo del programa:

   // Inicializar los temporizadores tipo Timeout
   TimeoutInitEvent()
   
   // Lanzar el Timeout1 para enviar el primer email al cabo de 10 segundos
   Timeout1SetEvent(10)


En otra parte del programa:

   // En ciertas condiciones, prende una luz en RELAY3, temporizada con Timeout2
   if (Sensor_PIR == 1)
   {
      Forzar_RELAY3 = 1
      Timeout2SetEvent(60)
   }


Y esta es la función de servicio de todos los timeout:

@OnTimeout()
{
   // Comprobar si Timeout1 ha expirado: enviar el email de Power-On
   if(Timeout1Check() == 1)
   {
      email_accion = "ENVIAR EMAIL"
      SendMail = 1
      
      // Borrar el Timeout1 para que no se repita
      Timeout1ClrEvent()                    [1]
   }

   // Comprobar si Timeout2 ha expirado: Apagar la luz en RELAY3
   if(Timeout2Check() == 1)
   {
      Forzar_RELAY3 = 0
      
      // Borrar el Timeout2 para que no se repita
      Timeout2ClrEvent()                    [2]
   }

   return 0
}

Al principio, no tenía colocada ninguna de las 2 instrucciones [1] y [2], con lo cual se producía el siguiente efecto: al cabo del primer Timeout1, se enviaba el mail (bien), pero con cada disparo del Timeout2, además de prenderse (y apagarse) la luz en RELAY3, también
se despachaba un email (mal), debido a que Timeout1Check() quedó en "1".

Leyendo el manual, deduzco que cuando un TimeoutX finaliza, la función TimeoutXCheck() retorna "1" en forma permanente de ahí en más, hasta que se lo resetee.

Entonces agregué en ambos lugares [1] y [2] los correspondientes reseteos de los temporizadores, para que cada uno se ejecute solo una vez hasta que se lo regenere de nuevo. El problema que me hace ahora es que cuando se da la condición de prender la luz en RELAY3, ésta se prende bien, pero no se apaga más.

Es como que hay alguna interacción rara entre las funciones TimeoutXClrEvent().  No logro discernir si una influye sobre la otra, pero pareciera que Timeout1ClrEvent() borra Timeout1 y también el Timeout2, y viceversa.

Puede ser que haya un error de firmware ??

Desde ya muchas gracias y un gran saludo,
Pablo.

Hola Boris, buenas tardes,

Antes que nada te cuento que el PLC que adquirí hace unos 45 días atrás funciona espectacular !  Es realmente una maravilla. Toda la programación la estoy haciendo en Pawn, ya que me resultó más agil que hacerla en el diagrama ladder. Aquí van las consultas que quisiera hacerte:

El único problema se me ha planteado ahora con las funcionalidades del envío de emails, que no las puedo hacer funcionar.
Primero hice un programa con 2 líneas: el SmtpInit, y SmtpSend, y no logré que nunca un email salga.
Probé con distintas cuentas: Yahoo, Arnet, y finalmente abrí una cuenta en AOL como se sugiere en el manual, pero siempre obtengo errores -4 (Error en proceso de Auth) o bien -11 (Error al enviar “.” para finalizar mensaje).
A continuación, por las dudas, utilicé el Ejemplo2.zip, al que le ajusté los parámetros de mis cuentas de email ... y tampoco logré que los emails salgan. Alguna sugerencia?  Has probado recientemente si funciona con Yahoo por ejemplo (me parece que Yahoo cambió sus mecanismos de autenticación recientemente, por eso probé con AOL, pero tampoco me funcionó).

Otra consultita: cómo sabés cuál es el tamaño del programa que uno ha implementado, y cuánta memoria de programa le queda libre al PLC?

Muchas gracias desde ya y nuevamente felicitaciones por tan buen producto.
Pablo.