Hola Boris buen día,

Estoy tratando de resolver un problema de conectividad en el que llevo meses y no lo puedo resolver.

Tengo 2 tipos de conectividad en uso, en las que tengo problemas: a) Subida de datos a ThingSpeak b) Un servicio de notificación que es llama PushingBox, que es muy util y se invoca por http.

El problema es que de un momento para otro "dejan de andar": los correspondientes http utilizados para ThingSpeak o PushingBox dejan de realizar su función, y retornan códigos de error. Eso es así de un momento para otro, y no se subsana más .... HASTA QUE hago un PLC reset.
El sistema funciona bien por unos 5 días (a veces solo 2), y luego deja de andar la conectividad. Todo lo demás anda perfecto (incluyendo los emails y ModBus).

He actualizado firmware y PLCLadder a lo último, pensando que allí había algunas mejoras sobre la parte de stacks y TCPIP, pero no, el problema persiste.

Ya tengo hecho un pequeño código que todos los días "detecta" la situación y me envía un email para avisarme y resetar el PLC y así todo comienza a funcionar de nuevo. El problema es que resetear el PLC es demasiado "hard", y podría estar apagando dispositivos que están encendidos, y se pierden también los totalizadores y variables que están en RAM.

La solución que estoy buscando es una de dos: a) Encontrar la causa de este problema  o bien b) Como puedo ejecutar comandos para resetear completamente la parte de conectividad a internet (stacks, resolucion de nombres, etc, etc) que sea EQUIVALENTE a un PLC RESET ... pero sin hacer PLC RESET.  Será esto factible?  Si esto se puede hacer, yo puedo detectar diariamente cuándo se da la situación anómala, y "reseteo" lo necesario para que vuelva a funcionar.

Ya he probado a ejecutar   ResolvClearCache()  +  HttpSendClose()  + HttpSendSetCompletedEvent() cuando la situación se da, pero no soluciona el problema. No equivale a resetar el PLC.

Desde ya muchas gracias,
Pablo.

Muchas gracias Boris,
Esta semana hago las correcciones y pruebo.
(el upgrade al último firmware ya está hecho, pero me falta el entorno y recompilar).

Saludos !
Pablo.

Clarísimo. Muchas gracias !

Hola Boris,

Impecable. Ya lo tengo andando.

Te cuento lo que hice, siguiendo tus indicaciones:

1) Actualicé firmware y StxLadder.
2) Modifiqué las 2 funciones que usaban direccionamiento a caracteres dentro de un string nLcdPrintMultLines() y ReemplazarEspacios(), cambiando los corchetes por llaves.

Con estos 2 cambios, compila OK, y la memoria consumida baja de 19668 bytes a 11640 (!!).

Pruebo a ejecutar, y todo parece funcionar bien, pero en un sitio donde muestro strings a través de VirtualHMI, no salen bien. Entonces recorro el fuente hasta encontrar todos los lugares donde haya StrFormat(), y cambio "false" por "true" (primero cambié por "packed", pero tiró error al compilar, entonces le puse "true").

Con esto último, aparentemente todo está funcionando bien de nuevo, con software actualizado a lo último.
Si algo no quedó bien, en los próximos días me voy a dar cuenta.

De paso. Debo esperar algún cambio o mejora derivado de las siguientes mejoras del firmware?:
      + Se amplia de 6 a 10 la cantidad de conexiones abiertas
        simultáneas TCP.
      + Se amplia de 12 a 20 la cantidad de puertos disponibles para
        escucha de paquetes TCP.
      + Se amplia de 2 a 4 la cantidad de conexiones abiertas
        simultáneas ModBus TCP (esto se conoce en documentación
        como parámetro "NumberMaxOfTransactions").

Muchas gracias por tu ayuda como siempre !
Saludos,
Pablo.

Hola Boris buen día,

Muchas gracias por tus explicaciones.
La verdad es que tenía la sensación de que estaba super-holgado de memoria en mi PLC, pero evidentemente no es así (probablemente esté holgado de memoria flash para almacenar el programa en sí, pero jugado con la cantidad de RAM usada para variables).

Voy a tener que revisar bien el código antes de hacer cualquier upgrade de versiones, porque me parece que sí uso strings via subíndice en alguna parte, y me podría dar cualquier resultado. Fijate en las siguientes 2 funciones, que me parece que vos me las pasaste prehechas en algún momento, y las vengo utilizando. No tengo claro qué hacer con esas funciones para que sean compatibles con ese switch de compilación:

// ********************************************************************************
// Funcion     : ReemplazarEspacios()
// Descripcion : Al string que viene, se le reemplazan todos los ESPACIOS.
//
// ********************************************************************************

ReemplazarEspacios(const String[])
{
   new Buffer[30]
   new i=0
   
   // Hacer un lazo que parsea el string
   while(TRUE)
   {
      // Copiar una línea de String[] en Buffer[].
      if(String != ' ' && String != '\0')
      {
         Buffer = String
      }

      // Viene un ESPACIO en String ?
      if (String == ' ')
      {
         // Si, reemplazar por otro caracter
         Buffer = '_'
      }     
     
      // Fin de caracteres en String ?
      if (String == '\0')
      {
         Buffer = '\0'
         return Buffer
      }
      i = i+1
   }
}



// ********************************************************************************
// Funcion     : nLcdPrintMultLines()
// Descripcion : Imprime una cadena con múltiples líneas en VirtualHMI.
//               Soporta \n, que de otra manera no funciona
// ********************************************************************************

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

Así como están ya no funcionarían, verdad ?
Gracias!
Pablo.

OK, gracias por la info.

Entonces como lo vengo haciendo es lo correcto (para recibir 10 bytes de payload estoy poniendo 0B en CMDIN_ARGSIZE0_OFFSET). O sea que no tengo error de protocolo.
La recepción de paquetes UDP la estoy haciendo desde 3 dispositivos ubicados en mi red LAN, via WiFi. De dos de ellos anda 100% perfecto siempre (son módulos ESP8266). Pero desde el tercer dispositivo (mi celular), es errático. Ya voy a investigar pero es como que en algún punto "alguien" está filtrando los paquetes UDP.

Muchas gracias !
Pablo.

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.