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 4 ... 7
16
STX8081 / Duda con respecto a "prevención de cortocircuitos"
« : julio 27, 2018, 20:44:49 pm »
Hola Boris de nuevo,

Tengo otra duda desde hace mucho que quiero consultarte, y tiene que ver con la "protección" contra sobrecargas en los contactos de las salidas de relé.

Concretamente la cuestión es esta: varias de mis salidas de relé tienen cargas que son a 220 Volts (luces principalmente). Funciona perfectamente desde hace años y nunca hubo un problema.
Pero me agarró la siguiente preocupación: qué pasa si en alguna de las luces que enciendo con el PLC se produjera (por ejemplo) un cortocircuito en el portalámparas. El PLC tiene previsto pistas que vuelen como protección para estas circunstancias ?

Mi miedo es que por un cortocircuito estúpido en una lámpara se me prenda fuego la casa en algún momento en que no estoy.

Muchas gracias !
Pablo.


17
STX8081 / Duda con recepción de paquetes UDP
« : julio 27, 2018, 20:35:16 pm »
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.

18
STX8081 / Re:Entendiendo las novedades
« : diciembre 26, 2017, 14:18:15 pm »
Entendido !
Muchas gracias y ... excelente 2018 !

19
STX8081 / Entendiendo las novedades
« : diciembre 23, 2017, 20:55:50 pm »
Hola Boris, como estas ?

Te quería consultar donde puedo leer para comprender mejor el significado y uso de las nueva funciones que veo has desarrollado. Hay una nueva versiòn del Manual de Pawn?  Particularmente, las siguientes funcionalidades:

En el Firmware version 224:
+ Funcion ResolvLookUp() permite "forzar" resolver nombre con opcion RESOLV_OPT_FORCE en tercer argumento.

En Lenguaje Ladder 1.8.5:
+ Se agrega componente Network Split, para configurar opción de division de paquetes en conexiones TCP.

No entiendo bien qué son estos dos ítems, pero intuitivamente me parece que me podrían ser de utilidad.

Muchas gracias y felices fiestas !
Pablo.

20
STX8081 / Re:Consulta por emails (nuevo firmware)
« : julio 03, 2017, 16:07:00 pm »
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.

21
STX8081 / Consulta por emails (nuevo firmware)
« : junio 29, 2017, 13:24:32 pm »
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.


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

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

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

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

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


27
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
}


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

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

30
Muchísimas gracias.

Este fin de semana la pongo en marcha.

Muy amable Boris.
Saludos.

Páginas: 1 [2] 3 4 ... 7