Hola Boris,

Implementé ThingSpeak con la nueva metodología usando HTTP.

Anduvo perfecto desde la primera compilación !

La verdad es que el código ahora quedó mucho más compacto y sencillo, habiéndose eliminado ThingSpeak.INC y ThingSpeak.p

Como ya te había comentado, con la implementación anterior estaba teniendo una "colgada" de ThingSpeak aproximadamente una vez cada 20 días. Simplemente se cortaba la subidad de datos a ThingSpeak, y la única forma de habilitarlo era reseteando el PLC. Vamos a ver qué pasa ahora que es totalmente diferente...

Muchas gracias !
Pablo

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

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.

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 buen día,

Quisiera saber si es posible "mostrar" una variable INTEGER como si fuera una FLOAT con 1 decimal.

O sea: Yo tengo en una variable INTEGER un valor (de temperatura) = 154, pero que en realidad es 15.4 grados.
En todo el software, las temperaturas las proceso de esa manera: multiplicadas por 10. Pero al mostrarlas, debería mostrar los grados y los decimales con el punto.

La consulta es si en el momento de "mostrar" ese valor en el display o en VirtualHMI es posible "simular" como si fuera una float (sin covertirla a float), tal que se muestre "15.4".

Estuve probando con
nLcdPrintf(0,1,0,"TEMP= %03.1d, Temp)
nLcdPrintf(0,1,0,"TEMP= %02.1f, Temp/10)
y varias más, pero ninguna me anduvo.

Muchas gracias desde ya,
Pablo.

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 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!