Mostrar Mensajes

Esta sección te permite ver todos los mensajes hechos por este usuario, recuerda que solo puedes ver los mensajes en áreas en donde tu tienes acceso.


Mensajes - PabloGa

Páginas: [1] 2 3 ... 6
1
Hola,

Si, efectivamente, estoy usando SMTPSIMPLE.

Enconces el cambio ocurrió con el último firmware, por el tema del spam. No tenía claro de dónde venía ese texto...

Muchas gracias,
Pablo.

2
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.


3
Hola Boris,
La nueva versión de firmware 223 funciona excelente !
Con respecto a al superposición de emails+http, te cuento que ese tema no me es problema, porque la lógica que tengo implementada en los 3 servicios (email + thingspeak + pushingbox), cuando uno debe "actuar", verifica que los otros no estén en proceso. Y recién cuando finalice el servicio "en curso", se activa el siguiente.
Acabo de instalar el nuevo firmware, hice unos ajustes al software, y hasta ahora anda un espectáculo.
Queda en producción. Voy a ver qué pasa en los próximos días; cualquier cosa te aviso.

Muchísimas gracias por atender mis requerimientos !
Pablo.

PD: Te debo otro café !

4
Hola Boris !
Me alegro mucho que hayas encontrado el problema.
Fijate que mi PLC es "-D2" por lo tanto me parece que el firmware que posteaste no lo debería grabar...
Quedo a la espera de la versión correcta para probar.
Muchas gracias,
Pablo.

5
Hola Boris,
Bienvenido de regreso.

No sé si habrás tenido oportunidad de leer mi post inmediato superior.
He podido reproducir con bastante certeza dónde está el problema de las funcionalidades que dependen de internet (emails y http). El problema está en la resolución de nombres de dominio. Una vez que una de las 2 funcionalidades hizo la resolución de nombre, "la otra" queda sin funcionar.

Espero que puedas resolverlo. Muchas gracias !
Saludos,
Pablo.

6
Hola Boris !

Se que estás de vacaciones, asique este mensaje lo mando "para el día depués"...

BUENAS NOTICIAS:

1) Creo que encontré el problema de la "incompatibilidad" entre el envío de mails, y ThingSpeak.
En realidad es una incompatibilidad entre el envío de emails, y cualquier uso que se haga de http que implique la resolución de un nombre de dominio.
El problema pasa cuando el PLC hace una resolución de un nombre de dominio. Por ejemplo: si le hacés resolver el nombre "api.thingspeak.com" en algún momento del programa (como por ejemplo cuando vas a subir datos a ThingSpeak), a partir de ese momento, no resuelve más los nombres de dominio de los emails.
Probé a cambiar api.thingspeak.com por su número de IP: "184.106.153.149", y aparentemente ahora funciona. Obviamente que esto no es solución definitiva, porque los IP cambian, pero al menos sirve para encontrar el problema.

2) El problema también se me presentó porque empecé a enviar datos a un servicio que se llama Pushingbox.com (api.pushingbox.com, MUY interesante). Allí también hay que ejecutar una URL tipo http://api.pushingbox.com?blabla, y esta funcionalidad TAMBIÉN me provocaba que los emails no salgan. Por eso comencé a atar cabos...

3) El problema descripto más arriba en el thread sobre el error de compilación relacionado con "NetTcpSplitOff()" continua vigente, aunque no es un problema.

4) He encontrado que no es 100% confiable el resultado retornado por la función HttpSendCheckValidTransaction(). Hay veces que la transacción se hizo correctamente y retorna "0". Otras veces también se hizo correctamente, y retorna "1".

5) Finalmente, cómo puedo hacer para imprimir el valor de una variable que tiene adentro un número de IP?? Por ejemplo, si uso nLcdPrintf(0,01,0,"THINGSPEAK IP= %X", ThingSpeakIP), me muestra todo en hexadecimal, en vez del formato "184.106.153.149". Hay alguna función que ya haga este formateado??

Saludos y felices vacaciones !
Pablo.

7
Hola Boris,
Pudiste reproducir el problema ??
Feliz 2017 !!
Saludos,
Pablo.

Citar
Esto me parece que es el mismo problema que paso una vez con SmtpInitSimple().
Se trata de un error de declaracion interno, que seguro se propagó al basarme en la declaración erronea.
Lo solucionaré para la próxima revisión de StxLadder.

Voy a armar una prueba con envío de Emails y ThingSpeak al mismo tiempo, así compruebo el error.

Me fijo y te aviso que encuentro.


8
Hola Boris buenas tardes,

Estoy posteando en un hilo que no es el adecuado, pero de todas formas aquí veníamos con el tema... :)
Le he dedicado un buen tiempo a probar el tema de la interacción entre Modbus / ThingSpeak / Email para dilucidar la cuestión, y creo que he (si bien no lo pude resolver), tengo buena información para rastrear el problema:

Esta es la secuencia de las pruebas que hice:

1) Probé a comentar la sentencia NetTcpSplitOff(), tal como me sugeriste en tu anterior post. Nada cambió: el primer email sale bien, y los subsiguientes siguen sin salir.

2) Probé a colocar NetTcpSplitOff() "al comienzo", de mi proceso plcmain(), ya que lo estaba poniendo "en medio" de todas las inicializaciones de los distintos servicios. Por las dudas decidí probar a poner esa instrucción antes. Lo que me encontré es que tira un error de compilación "Invalid Expression, assumed zero", si coloco NetTcpSplitOff() antes de VirtualHmiInit() (what?!?). O sea: si no está primero la sentencia VirtualHmiInit() en el código fuente, NetTcpSplitOff() tira error. Si la pongo un renglón después, compila normal. De todas formas, este último problema no tiene nada que ver con el tema que estoy buscando resolver, que es la no salida de los emails; igual te lo comento, porque ahí me parece que hay un bug en el compilador STX Ladder.

3) Luego probé a comentar la sentencia ThingSpeakInit() que tengo en PlcMain() o sea inutilizando la salida a ThingSpeak ... y con esto los emails empezaron a salir normal !

4) Para seguir acorralando el tema, volví a habilitar ThingSpeakInit() en PlcMain(), pero comenté la instrucción que ejecuto una vez por minuto ThingSpeakUP(). Esta función lo que hace es armar el string y lo sube a ThingSpeak. Los emails anduvieron !

5) Pensando en una interacción entre SendMail() y ThingSpeak, hice que la subida a ThingSpeak NO se realice si en ese momento la variable Sending==1, o sea si hay un email "saliendo" en curso (cada mail tarda unos 10 segundos en ser enviado).  Los emails dejaron de salir a pesar de esto.

6) Volví a inhabilitar ThingSpeakUp(), que quedó como único cambio, y los mails salen perfectamente.

Y hasta aquí llegué. La conclusión a la que llegué es que CON SOLO UNA VEZ que ese ejecute mi función ThingSpeakUP(), los emails dejan de funcionar. Momentáneamente, dejé inhabilitada la subida con ThingSpeakUp() para re-reconfirmar que los emails funcionan perfecto. Hice unas docenas de pruebas, y todos saliendo correctamente.

Transcribo a continuación mi función ThingSpeakUP(), para que la veas. No tiene nada "raro".
En mi opinión, hay alguna interacción en el firmware, que hace que cuando se hace una subida a ThingSpeak, algun flag o variable del firmware queda mal seteada, y eso hace que los emails siempre se aborten por timeout (error= -1):


ThingSpeakUP()
{
   // Comprobar si no hay conexiones en curso con Thingspeak.
   if(ThingSpeakSending == 0)
   {     
      // Limpia las variables con el string que se enviara a ThingSpeak:
      ThingSpeak_String1 = ""
      ThingSpeak_String2 = ""
      ThingSpeak_String3 = ""
      ThingSpeak_String4 = ""
      ThingSpeak_String  = ""

      // aquí armo 4 strings con los conjuntos de "fields". Luego se concatena todo para enviarse a ThingSpeak()
      StrFormat(ThingSpeak_String1, 50, false, "field1=%d.%d&field2=%d.%d&field3=%d&", Var1,Var1a,Var2,Var2a,Var3)
      StrFormat(ThingSpeak_String2, 50, false, "field4=%d&field5=%d&field6=%d&",Var3,Var5,Var6)
      StrFormat(ThingSpeak_String3, 50, false, "field7=%d.%d&", Var7,Var7a)
      StrFormat(ThingSpeak_String4, 50, false, "field8=%d", Var8)
     
      // Concatena los 4 segmentos
      StrFormat(ThingSpeak_String, 100, false, "%s%s%s%s", ThingSpeak_String1,ThingSpeak_String2,ThingSpeak_String3,ThingSpeak_String4)
       
      // Aquí hace la subida de la info a ThingSpeak
      if(HttpSendGet("/update?key=%s&%s", THINGSPEAK_APIKEY, ThingSpeak_String) == 0)
      {         
         // Marca que hay un envío en curso
         ThingSpeakSending = 1
      }
   }
   return 0
}


9
Hola Boris,

1) Con respecto a nLcdPrintMultLines, yo también pensé que habría alguna interacción con alguna variable global del proyecto, pero no, no existe tal cosa, o al menos no la encontré. De todas formas, con el pequeño cambio que le hice, como te comenté, ya está funcionando ok.

2) Sería perfecto si lográs hacer que nLcdPrintf() procese \n  !
Si esto te implica modificar VirtualHMI, acordate de que en VirtualHMI Android existía una limitación en cuanto a la impresión de strings: VirtualHMI Android no puede presentar strings "largos" (creo que el límite estaba en unos 34 caracteres por línea). Mi sugerencia en su momento era hacer que cuando se imprimía un string largo, al llegar al final derecho de la pantalla, simplemente continúe en la linea siguiente. Y de esa manera, que VirtualHMI muestre el string "completo". Si vas a sacar un nuevo release, quizá se podrían hacer las 2 cosas.

3) Con respecto al envío de emails: estoy seguro de que si instalo el script de envío periódico de emails van a salir perfectos. Con certeza tengo algún tipo de interacción en el uso del recurso Ethernet/TCP, que me trae el problema. Estoy usando ModBus, recepción de datos de sensores mediante paquetes UDP, envío de datos a ThingSpeak, VirtualHMI y envío de emails !!  El tema es ... cómo encontrar dónde está la interacción ?  No se ni por donde comenzar.
No creo que sea una interacción a nivel de variables, porque soy muy cuidadoso con eso, y para cada cosa tengo variables específicas (no "reusadas"). En fin, algún día me pondré a "separar" y ver cuál puede ser el factor que ocasiona este problema.

Saludos y muchas gracias!
Pablo.

10
Hola Boris, que tal ?

Estuve trabajando para implementar nLcdPrintMultLines(), lo que parecía muy simple. Si embargo, no me anduvo: siempre, invariablemente siempre, me mostraba en VirtualHMI solo la primera línea de la cadena, hasta el primer \n. Las siguientes, nunca.
Revisé el código que me enviaste, y me pareció perfecto, no pude encontrar un error.
Luego instalé el proyecto que me enviaste (que simplemente manda una cadena) ... y anduvo !
Finalmente, volví a mi proyecto, y hice unos cambios mínimos en el código de nLcdPrintMultLines, y con eso anduvo: le puse el incremento de la variable "y" al final, en lugar de hacerlo dentro de la instrucción nLcdPrintf(), y le saqué el delay.
No entiendo bien por qué esto fue la solución, pero ... ahora funciona. Ver código como quedó a continuación:

nLcdPrintMultLines(x, y, const String[])
{
   new Buffer[160]
   new i=0, j=0
   new Stop = FALSE
   
   // Parsear cadena.
   while(Stop == FALSE)
   {
      // Copiar una línea de String[] en Buffer[].
      while(String != '\n' && String != '\0')
      {
         Buffer[j++] = String[i++]
      }
     
      // Si hay carateres en Buffer[], imprimir.
      if (j != 0)
      {
         // Agregar terminador de fin de cadena.
         Buffer[j] = '\0'
         
         // Imprimir en VirtualHMI Buffer[] e incrementar numero de línea.
         nLcdPrintf(x, y, LCD_CLRLINE, "%s", Buffer)       
      }
     
      // Fin de caracteres en String[] ?
      if (String == '\0')
      {
         // Si, parar Loop.
         Stop = TRUE
      }
      else
      {
         // No, ajustar variables para próxima línea.
         j=0
         i++
         y++
      }
   }
}

Por ahi no creo que sea muy complejo hacer que nLcdPrintf soporte \n y con eso todo sería más sencillo :)

Por otro lado te cuento que todo esto lo estoy haciendo para poder mostrar en VirtualHMI los "emails históricos" que voy enviando como notificaciones (como si fuera un LOG de los emails enviados), puesto que siempre tuve muchísimos problemas con los emails que no salen. Con motivo de estas pruebas, pude determinar mejor la casuística de los problemas con los emails, que te la cuento a continuación por si se te ocurre la causa del problema:

- Luego de enceder el PLC o de enviarle un comando de RESET, el primer email de power-on sale perfectamente.
- El email que sigue a continuación (varios minutos después), 99% de las veces no sale, y SmtpStatus termina en -1

- Si ahora le envío un RESET, sale el siguiente mail (obviamente no es el mail "anterior" que falló, sino un "nuevo email" que genero en cada power-on)

Mi función de envío de emails es prácticamente idéntica a la sugerida en la nota de aplicación, utilizando SendMail= para iniciar la transmisión, Sending= para indicar que está en curso un envío, y SmtpStatus con el resultado final.
Y estoy usando SmtpInitSimple().
Probé a poner SmtpInitSimple "CADA VEZ" que voy a enviar un email, pero nada cambió.

Saludos y muchas gracias !
Pablo.

11
Muchísimas gracias.

Este fin de semana la pongo en marcha.

Muy amable Boris.
Saludos.

12
Hola Boris buenas tardes,

Cada vez que envío un email de notificación, primero "armo" en un string "email_cuerpo" todo el cuerpo del email.
Esta variable email_cuerpo contiene "\n" cada tanto, para mostrar el email de una manera fácilmente legible.

Por otro lado, utilizo VirtualHMI para mostrar una gran cantidad de información sobre el funcionamiento del sistema. Entre ellas, tengo una pantalla en donde muestro el cuerpo de la ultima notificación enviada por email, y el resultado de dicho envío.

El problema que tengo es que al mostrar en VirtualHMI (Android) el cuerpo del último email, es como que ignora los comandos de formato "\n" (nueva línea), y todas las líneas aparecen "encimadas" una sobre la otra, en el mismo renglón de VirtualHMI.

La sintaxis que utilizo para mostrar el cuerpo en VirtualHMI es:
nLcdPrintf(0,6,0,"CUERPO= %s", email_cuerpo)

También probé a reemplazar "\n" por "\r\n" y dio el mismo resultado.

Otra opción sería "parsear" completo el string, buscando los "\n" y en base a eso cambiar la posición "Y" de nLcdPrintf(), pero es bastante laborioso.

Donde la estoy errando?  O es que nLcdPrintf() no soporta "\n" ?

Muchas gracias !
Pablo.

13
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

14
Hola Boris,

Si había una sola forma de que SmtpInitSimpe falle, justo esa me tocó a mí :)
La corrección anduvo perfecto !!  Apenas cambiado a Slicetex 1.8.1 y ya estoy enviando emails con SmtpInitSimple, lo cual es una gran cosa, porque me independizo del servidor SMTP de Arnet, que no le confío mucho.

Para terminar de incorporar todo lo nuevo que desarrollaste, lo que me faltaría es hacer funcionar la subida a ThingSpeak SIN utilizar la anterior "receta", para lo cual, de acuerdo a la implementación que me habías pasado antes, yo debería:
- Dejar de incluír en el proyecto el archivo ThingSpeak.INC
- Dejar de incluír en el proyecto el archivo ThingSpeak.P
- Y incorporar el nuevo código que utiliza HttpSendGet según tu ejemplo

Estoy en lo correcto verdad?

Saludos y muchas gracias !
Pablo.

15
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

Páginas: [1] 2 3 ... 6