Enviar datos a Thingspeak.com con PLC (IoT)

Excelente Boris,

En estos días hago la prueba. Yo necesito subir las 8 variables de un Channel de ThingSpeak al mismo tiempo. Vamos a ver si funciona y te aviso.

Gracias !
Pablo.

Buenos días Pablo,

Te paso el proyecto modificado para que acepte mas parámetros, yo lo probé hasta con 6 campos.

También debes actualizar la versión de firmware a la V220 que te adjunto.

Avísame si te funciona bien.

Saludos!

Hola Boris,

Estoy por hacer el upgrade de firmware, pero me detuve por un detalle que me llamó la atención:
El firmware que me citás para hacer el upgrade incluye "D1" en su nombre, y mi modelo de equipo es "D2" (no me acuerdo qué significaba la diferencia), pero me temo que si hago el upgrade puedo planchar el PLC.
Me podés confirmar si prosigo o no ?

Gracias !
Pablo

Buenos días Pablo,

Te paso el proyecto modificado para que acepte mas parámetros, yo lo probé hasta con 6 campos.

También debes actualizar la versión de firmware a la V220 que te adjunto.

Avísame si te funciona bien.

Saludos!

Hola Pablo,

No, necesitas el firmware "D2" para el modelo de PLC que tenes.

No recordaba tu modelo. Te lo adjunto al correcto.

Saludos.

Anduvo perfecto !!!
(y estoy subiendo los 8 canales juntos)
Muchísimas gracias !
Pablo.

Hola Pablo,

No, necesitas el firmware "D2" para el modelo de PLC que tenes.

No recordaba tu modelo. Te lo adjunto al correcto.

Saludos.

Perfecto,

Una consulta, para enviar los 8 campos usas la función de la siguiente forma?:

ThingspeakSendFields("field1=%d&field2=%d&field3=%d&field4=%d&field5=%d&field6=%d&field7=%d&field8=%d", Value[0],Value[1],Value[2],Value[3],Value[4],Value[5],Value[6],Value[7])
Por otro lado, los valores son enteros ? Que máximo y mínimo ?.

Es para saber la cantidad de caracteres que podrías emplear en la conexión.

Gracias.

Hola !

La forma en que yo subo los valores es de la siguiente manera (una instrucción para armar un string, y luego una para subirlo):

StrFormat(ThingSpeak_String, 100, false, "field1=%d.%d&field2=%d.%d&field3=%d&field4=%d&field5=%d&field6=%d&field7=%d.%d&field8=%d.%d", Temp,Temp_d,Hume,Hume_d,Lumi,Nivel,TC,TPIR,Temp2,Temp2_d,Hume2,Hume2_d)
         
ThingspeakSendFields(ThingSpeak_String)

Como podrás ver, los valores pueden ser decimales, y anda perfecto. Ejemplo:
"field1=%d.%d"  arma en el string una parte entera, el punto decimal, y luego la parte decimal, y cuando ves el gráfico en ThingSpeak lo tomó como un número real perfectamente.

No sé cuáles son los valores máximos y mínimos permitidos, habría que buscar en ThingSpeak.com, pero intuyo que son valores reales muy grandes; me parece que es algo que no tiene muchas restricciones.

APROVECHO para reportarte una nueva situación, derivada de lo de ThingSpeak:
Ya me pasó varias veces que de pronto el PLC "deja" de subir la información a ThingSpeak (esto ya ocurre desde varias versiones de firmware atrás, no es nuevo). Sin embargo, la conectividad Ethernet no está "colgada", porque sigue funcionando por ejemplo Modbus y el VirtualHMI.
Pero deja de funcionar la subida de datos (y eso que el acceso a ThingSpeak está con un número de IP fijo, por lo tanto no habría resolución de nombres DNS, que sería un factor más).

Estuve haciendo varias pruebas para tratar de encontrar el asunto, y detecté que el problema se resuelve haciendo un REINICIO del PLC a partir de VirtualHMI Android. O sea: no necesita ser desenergizado. Solo con un reinicio del PLC es suficiente. Lamentablemente, con esta acción pierdo los valores de todas las variables y acumuladores; es como si hubiera desenergizado.

Habría que ver qué funciones de red se "reparan" al hacer un reinicio del PLC, y ver si sería factible tener alguna instrucción Pawn para que el software cada X tiempo, o cuando detecta que estas funciones no andan, hacerse a sí mismo un reinicio de las funcionalidades TCP (o lo que corresponda), y con eso se resucita solo. Me explico? Quizá algo así como la SMTPInit(), que tenía una funcionalidad para reiniciar cuál era el servidor y número de IP que tiene que usar, si no me equivoco.

Muchas gracias, saludos!
Pablo.

Perfecto,

Una consulta, para enviar los 8 campos usas la función de la siguiente forma?:

Código: (Pawn) [Seleccionar]

ThingspeakSendFields("field1=%d&field2=%d&field3=%d&field4=%d&field5=%d&field6=%d&field7=%d&field8=%d", Value[0],Value[1],Value[2],Value[3],Value[4],Value[5],Value[6],Value[7])
Por otro lado, los valores son enteros ? Que máximo y mínimo ?.

Es para saber la cantidad de caracteres que podrías emplear en la conexión.

Gracias.

Hola Pablo,

Te adjunto el proyecto modificado para que en cada transmisión inicialice la conexión.

Fíjate que la función nueva (en PlcMain.p) incializa y envía en cada transmisión:

ThingspeakInitAndSend()
{
   // Inicializar cliente Thingspeak.
   // Nota: La conexion previa debe estar cerrada.
   ThingspeakInit()
   
   // Enviar 6 campos con valores de array "Value[]" a Thingspeak.
   ThingspeakSendFields("field1=%d&field2=%d&field3=%d&field4=%d&field5=%d&field6=%d", Value[0],Value[1],Value[2],Value[3],Value[4],Value[5])
   
   // Incrementar elementos de array Value[].
   Value[0]+=1
   Value[1]+=1
   Value[2]+=1
   Value[3]+=1
   Value[4]+=1
   Value[5]+=1
}

Es para que pruebes si eso te da mejor resultado con el tiempo.

Los archivos thingspeak.p y thinkspeak.inc no fueron modificados respecto a ultimo ejemplo "Thingspeak_Enhanced".

Por otro lado, respecto a tu código creo que te conviene hacer:

ThingspeakSendFields("field1=%d.%d&field2=%d.%d&field3=%d&field4=%d&field5=%d&field6=%d&field7=%d.%d&field8=%d.%d", Temp,Temp_d,Hume,Hume_d,Lumi,Nivel,TC,TPIR,Temp2,Temp2_d,Hume2,Hume2_d)

Desde un punto de vista de memoria, es mejor.

Finalmente, estoy pensando hacer el soporte para ThingSpeak de forma nativa, para que sea mas eficiente.

Saludos

Hola Boris buenas noches !

Gracias por tu feedback.
No se me había ocurrido hacer ThingspeakInit() periódicamente.
Como transmito 1 vez por minuto, en vez de ejecutar ThingspeakInit()  cada vez que voy a transmitir (me parece mucho), lo metí dentro de una función que se ejecuta cada una hora. Vamos a ver qué pasa.

Por otro lado, con respecto a incorporar soporte ThingSpeak de forma nativa... te parece necesario?  El viejo refrán dice " Si funciona, mejor no lo arregles !! "

ACTUALIZACIÓN 19/06/16: Luego de haber incorporado la inicialización ThingspeakInit() una vez por hora, y luego lo pasé a 1 vez a la medianoche, en ambos casos, cuando se re-inicializa ThingSpeak ... deja de funcionar. Por lo tanto lo eliminé, y volví a dejar todo como estaba antes. La forma como lo había agregado creo que fue correcta, porque hice la verificación de que no hubiera una conexión abierta:

   // Esto se ejecuta cada 1 hora, o bien a medianoche... pero no anduvo
   if(ThingspeakCheckWaitResponse() == 0)
   {
        ThingSpeakInit()
        }


Muchas gracias.
Saludos,
Pablo.

Buenas tardes Pablo,

Te comento que hay un cliente web disponible para utilizar con el PLC, el mismo te permite hacer peticiones GET para acceder a Thingspeak.com.
Es mas eficiente que el método que estas utilizando, ya que esta optimizado para ese tipo de aplicaciones.

Te paso link a la nota de aplicación donde explica como usarlo (al final están los ejemplos para Thingspeak):

http://www.slicetex.com/docs/an/an032/index.html

Necesitas actualizar el firmware de la placa a V221 y usar StxLadder 1.8.0.

Cualquier duda avísame.

Saludos


PD: También esta actualizado el cliente de mail (que era otra cosa que utilizas), añade la función SmtpInitSimple() que configura el PLC para usar su SMTP interno y te olvidas de configurarlo con Arnet y otros proveedores, fíjate el ejemplo de la nota de aplicación AN020.

Hola Boris buenos días,

Muchas gracias por ponerme al tanto de los avances, en este caso con lo de ThingSpeak.
Lo voy a estudiar y voy a ver si modifico la forma en que lo vengo usando, hacia este nuevo método.

Aprovecho para comentarte que unos días atrás me puse a hacer unos cambios en mi proyecto PLC, y ví que había una nueva versión de STXLadder (era la 1.7.8 y yo tenía en uso la 1.7.6).
La instalé, y de entrada empecé a tener problemas: el proyecto no compilaba, me decía que varias variables no estaban definidas, y el proyecto no se podía compilar. Me volví loco buscando qué pudo haber cambiado, y no encontré nada. Bajé la 1.7.6 anterior, la instalé, y ... tampoco anduvo !! (o sea, el proyecto que compilaba perfecto con 1.7.6, ahora no compilaba).

Después de bastante renegar llegué a la conclusión de que después del upgrade a 1.7.8 se había modificado de alguna manera el archivo "PROYECTO.SLP", que está en la carpeta raíz del proyecto, y el programa se estaba compilando en el estricto orden en el que los archivos .p aparecen en "PROYECTO.SLP". O sea: si primero aparece el "motores.p", y más adelante el "plcmain.p", todas las variables que aparezcan en "motores.p" van a aparecer como no definidas, y el proyecto no compila.

Qué hice? Modifiqué con un editor de textos el "PROYECTO.SLP", para que "plcmain.p" aparezca primero que todo, y con eso el proyecto volvió a compilar.

Luego volví a instalar la 1.7.8 para ver si el problema estaba resuelto, pero no ... todo volvió como al principio, y el proyecto no compiló. Desinstalé, volví a 1.7.6, edité "PROYECTO.SLP", y así me quedé.

Me parece que se trata de un pequeño bug introducido a partir de la 1.7.8. Quizá ya lo detectaste y está corregido en la 1.8.0....

Muy interesante también lo de la nueva  SmtpInitSimple(). Tengo que verla...

Saludos y muchas gracias !
Pablo.

[....]

Aprovecho para comentarte que unos días atrás me puse a hacer unos cambios en mi proyecto PLC, y ví que había una nueva versión de STXLadder (era la 1.7.8 y yo tenía en uso la 1.7.6).
La instalé, y de entrada empecé a tener problemas: el proyecto no compilaba, me decía que varias variables no estaban definidas, y el proyecto no se podía compilar. Me volví loco buscando qué pudo haber cambiado, y no encontré nada. Bajé la 1.7.6 anterior, la instalé, y ... tampoco anduvo !! (o sea, el proyecto que compilaba perfecto con 1.7.6, ahora no compilaba).

Después de bastante renegar llegué a la conclusión de que después del upgrade a 1.7.8 se había modificado de alguna manera el archivo "PROYECTO.SLP", que está en la carpeta raíz del proyecto, y el programa se estaba compilando en el estricto orden en el que los archivos .p aparecen en "PROYECTO.SLP". O sea: si primero aparece el "motores.p", y más adelante el "plcmain.p", todas las variables que aparezcan en "motores.p" van a aparecer como no definidas, y el proyecto no compila.

Qué hice? Modifiqué con un editor de textos el "PROYECTO.SLP", para que "plcmain.p" aparezca primero que todo, y con eso el proyecto volvió a compilar.

Luego volví a instalar la 1.7.8 para ver si el problema estaba resuelto, pero no ... todo volvió como al principio, y el proyecto no compiló. Desinstalé, volví a 1.7.6, edité "PROYECTO.SLP", y así me quedé.

Me parece que se trata de un pequeño bug introducido a partir de la 1.7.8. Quizá ya lo detectaste y está corregido en la 1.8.0....

[....]

Buenos días Pablo,

En realidad no es un bug, fue un cambio necesario que se introdujo en StxLadder 1.7.8 para que los archivos sigan un orden alfabético al compilarlos, ya que antes de esa versión no respetaba un ningún orden en particular y variaba de proyecto en proyecto. Lo cual tenia incoherencia. Por otro lado, no había forma de hacer retro-compatible esta modificación.

Pero la ventaja es que ahora podes crear un archivo encabezado por ejemplo global.inc o motores.inc y ahi pones todas las variables que necesites en los archivos con código ".p". Ya que desde la versión "1.7.8", los archivos ".inc" se incluyen primero que los ".p" y esto permite que sean visibles antes las variables.

Como regla quedaría:

• Archivos ".inc" se leen e incluyen primero que los ".p" al compilar. En el grupo de los archivos ".inc", el que este primero alfabéticamente, se lee primero también.
• Archivos ".p" se leen en orden alfabético al compilar, teniendo prioridad el que comience primero.

Así que simplemente pone las variables globales en el archivo .inc y debería funcionar normalmente.

Saludos y cualquier duda me avisas.

Hola Boris buenas tardes,

Bueno, empecé de a poco a "digerir" todos los cambios y ventajas que has implementado en el sistema. Hice lo siguiente:

- Instalé la nueva versión del entorno Slicetex V1.8.0
- Hice el upgrade el firmware del PLC a la V2.21
- Generé un archivo INICIAL.INC, a donde moví toda la parte de definición de variables (que antes estaba en PLCMAIN.p)
- Ahora con esto ... el programa compila, con lo que los errores de compilación que tenía el otro día están solucionados.
- Lo envío al PLC, y todo funciona igual que siempre. Perfecto !

Ahora quiero empezar a implementar "lo nuevo", y decido comenzar con el tema del SmtpInitSimple(), que me parece fantástico porque me independizo de la cuenta y el SMTP de Arnet que venía usando (muy poco confiable).

Por lo que ví en la Nota de Aplicación más el proyecto ejemplo MailExampleSimple2, lo único que tengo que hacer es cambiar SmtpInit(lista de parámetros) por SmtpInitSimple().
Hago el cambio, y tira error al compilar: "Error 029 Invalid Expression, assumed zero" en las líneas donde está SmtpInitSimple()
Es como si no me reconoce correctamente SmtpInitSimple()
Revisé una por una las variables utilizadas, y todas están correctamente definidas en INICIAL.INC.
Probé a cambiar de lugar SmtpInitSimple() y ponerla en PlcMain(), y me cambia de lugar el error, pero sigue igual.

Ahora pruebo a instalar el ejemplo MailExampleSimple2, y compila perfectamente !?!. No entiendo.
Para mí tiene que ver con el tema este del "órden de compilación" nuevo a partir de 1.7.8. Alguna sugerencia ?

Saludos y muchas gracias !
Pablo.

Buenas tardes Pablo,

Tiene pinta como que cerca de las lineas de SmtpInitSimple() hay algún error de sintaxis.

¿ Como la estas llamado a la función ?

Hola Boris que tal? Así es como estoy usando SmtpInitSimple():

InitEmail()
{
   // Inicializa las variables de email
   Sending = 0
   SendMail = 0
        SmtpStatus = 0
   
   // Inicializa el servidor SMTP (viejo metodo comentado, nuevo método sin comentar)
   //SmtpInit("arnet.com.ar", "smtp.arnet.com.ar", 25, "usuario@arnet.com.ar", "password", SMTP_OPT_DEFAULT)
        SmtpInitSimple()
   
         // La identificación del enviador de emails:
   SmtpSetFromName("PLC")

   return 0
}

Esa forma de invocar SmtpinitSimple() es la que figura en la AN20Rev3 y tira el error al compilar.

Sin embargo, hoy se me ocurrió crear una variable SmtpInitDummy y poner:
SmtpInitDummy = SmtpInitSimple()

Y así ya no tira el error al compilar, pero los mails no salen...
Cual es la forma correcta de invocar SmtpInitSimple()  ?

Saludos !
PG

Buenas tardes Pablo,

Respecto a el error de compilación usando SmtpSimpleInit(), con tu código pude obtener el mismo error, y se debía a un error en StxLadder al declarar la función, pero que no se replicaba con otros códigos.

Ahora esta corregido en StxLadder 1.8.1.

Fíjate de probar con el software actualizado si te funciona los mails.

Al enviar, corrobora que no estén llegando a la carpeta de "Correo no deseado" o "Spam" en tu cliente de correo (gmail.com o hotmail.com). Es probable que debas entrar a la aplicación web de tu correo, donde te lista todas las carpetas.

Finalmente, si sigue el problema, podes probar solo este proyecto:

http://slicetex.com/docs/an/an020/files/MailExampleSimple2.zip

Y cambias la línea 113 en PlcMain.p:

if(SmtpSend("juan@gmail.com", "0", "pepe@yahoo.com.ar", "Mensaje del PLC", "Soy un PLC que envia E-MAILS!.\nLa entrada discreta DIN1 tiene el valor \"%d\".\nSaludos.", DinValue(DIN1)) == 0)

Por direcciones de mail validas en el campo "To" y "From".

Luego con DIN1=1 se envía el mail.
En VirtualHMI te aparecen los códigos de errores.

Cualquier duda avísame.