Hola Boris que tal?

Hoy me dispuse a hacer una modificación al programa de mi PLC, y -como hago siempre- primero actualizo el StxLadder a la última versión disponible, y lo mismo con el firmware del PLC (el mío es un 8081-D2). Luego de la actualizaciòn tuve problemas; te paso la info:

Lo que tenía antes de actualizar era:
StxLadder 1.8.8
Firmware 227

Luego de actualizar pasé a:
Stxladder 1.9.2
Firmware 229

El problema se manifiesta así: al compilar el programa (ya con el nuevo entorno), me tira el siguiente error:

Error de Memoria: Insuficiente memoria RAM: El proyecto requiere 19668 bytes y el dispositivo tiene disponible 16384 bytes. Disminuya variables globales, variables locales inicializadas, comparta/reutilice variables globales, utilice packed strings, agrupe datos, etc.


Entonces voy a ver en el PLC qué marca, y en el display tiene el siguiente cartel:
PLC Return Code C:200 R:0

Pensé que habría un problema con el firmware, asi que lo volví para atrás a la V227. Pruebo a compilar con F6, y me da el mismo error. Entonces volví para atrás también el entorno StxLadder, y todo volvió a la normalidad (me apareció un cartel diciendo que el programa había sido construído con una versión de StxLadder superior, y que podría haber pérdidad de datos, pero seguí adelante y todo anduvo normal).

Aclaro que al grabar el firmware me aseguré de elegir la versión correcta del archivo, de acuerdo al modelo de PLC que uso: stx8081-d2.sff

En conclusión, no me queda claro si el problema está en el firmware o en el entorno.
Por lo pronto, tengo todo funcionando a la perfección, por lo que no hay ningún apuro en resolver nada.

Saludos y muchas gracias !
Pablo.

Hola Boris como estas?

Te consulto una duda que me surgió con relación a la recepción de paquetes UDP, que en algunos momentos me anda medio errático (hay paquetes que llegan, y otros que no llegan).

La duda es sobre los parámetros del protocolo CSP. Supongamos que yo tengo que enviar 10 bytes de payload, cuáles son los valores correctos para los bytes "CMDIN_ARGSIZEx" del array?

Offset  Parameters          Value
06      CMDIN_ARGSIZE0     03  -- Aquí tengo que poner 03, o tengo que poner 0B
07      CMDIN_ARGSIZE1     00  -- Este siempre lo dejo en cero
09      CMDIN_ARGS            0A  -- Aquí le pongo siempre 0A porque envío 10 bytes de payload.

En realidad no entiendo el significado de los parámetros CMDIN_ARGSIZE0 y CMDIN_ARGSIZE1, puesto que en realidad el tamaño de la payload ya va en CMDIN_ARGS. Es como que tienen la misma función.

Lo curioso es que analizando esta cuestión he probado con el valor "03", y con el "0B", y en ambos casos anda (pero con fallos). Los paquetes los estoy enviando de un dispositivo no-pc, en el que yo programo completa la secuencia de la trama UDP a enviar hacia el PLC.

Desde ya muchas gracias !
Pablo.

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.