Detención indeseada PLC

  • 18 Respuestas
  • 127 Vistas

Soporte

  • Global Moderator
  • Experto
  • *****
  • Mensajes: 1914
  • Soporte Técnico
Re:Detención indeseada PLC
« Respuesta #15 : octubre 16, 2018, 12:12:24 pm »
Buenos días Mariano,

En la última prueba que realicé pasé el PLC a modelo D1. Le cargué el firmware v200 y el programa inicial que tenía en servicio (sin uso de instrucciones para la memoria EEPROM) y volvió a funcionar todo normalmente sin fallas.

Para esto, tuve también que instalar stxladder versión 1.8.2 en lugar de la 1.9.3. Esta última no me dejaba compilar el proyecto inicial (el que estaba normalmente en servicio) por falta de memoria RAM.

Voy a examinar más exhaustivamente la diferencias entre versiones, para determinar que puede haber cambiado y hacer algunas pruebas.

¿Podrías enviarme por mail, el proyecto que cargás al PLC que te funciona?.

El proyecto que no te funciona, ¿supongo que es el mismo que ya me pasaste, no?.

Quería agregarte que en la configuración del router están asignados los puertos 81 al webserver y 82 al tcp server. Donde pide el tipo de puertos entre TCP y UDP está definido en las dos alternativas como Both (ambos). Habrá algún conflicto con los números de puerto asignados. (No hay ningún otro servidor virtual instalado como sistemas de alarma o vigilancia ni nada por el estilo)

No, esto no creo que sea un problema.

Saludos!
« Última Modificación: octubre 16, 2018, 12:16:37 pm por Soporte »
SOPORTE TÉCNICO

Slicetex Electronics
www.slicetex.com

Mariano

  • Aprendiz
  • **
  • Mensajes: 72
Re:Detención indeseada PLC
« Respuesta #16 : octubre 16, 2018, 17:55:37 pm »
Buenas tardes Boris

Te comento las últimas pruebas. Si bien el programa original anduvo un tiempo sin presentar fallas. Después de unas 7 u 8 horas comenzó a bloquearse cada intérvalos de 40 o 50 minutos mayormente y a veces llegaba a funcionar un par de horas hasta que se volvía a bloquear. Esto es, corriendo el programa original, con PLC en modo D1, firmware v200 e instalado con stxladder 1.8.2

Se me ocurrió cambiar los puertos 81 y 82 a otros números y al parecer se solucionó la falla y no volvió a resetearse. Entonces le cargué el programa completo. (Sólo que en modo D1 me dejaba usar la mitad de la EEPROM). No hubo fallas. Lo que hice hace una hora, fue mudar todo de nuevo. PLC a D2, StxLadder a 1.9.3 etc. Lo estoy probando y te aviso. Al parecer el reset se origina por usar esos números de puerto... o bien por lo menos uno de ellos (calculo el 82 asignado al TCP) es el que causaba el problema...

Voy a examinar más exhaustivamente la diferencias entre versiones, para determinar que puede haber cambiado y hacer algunas pruebas.

Con respecto a esto, tal vez no haya diferencias entre versiones, ni de D1 a D2 ni en los entornos de Stxladder. Dejame completar esta última prueba para no buscar la falla en vano.

Lo que sí sería conveniente es que el PLC de algún tipo de aviso ante este tipo de errores sin que el programa se llegue a bloquear y ser necesario un reset por watchdog de todo el PLC. Esto es a los fines de que no entren en juego los actuadores que dependen en todo momento de las distintas salidas.

Saludos


Soporte

  • Global Moderator
  • Experto
  • *****
  • Mensajes: 1914
  • Soporte Técnico
Re:Detención indeseada PLC
« Respuesta #17 : octubre 17, 2018, 11:04:04 am »
Buenos días Mariano,

Se me ocurrió cambiar los puertos 81 y 82 a otros números y al parecer se solucionó la falla y no volvió a resetearse. Entonces le cargué el programa completo. (Sólo que en modo D1 me dejaba usar la mitad de la EEPROM). No hubo fallas. Lo que hice hace una hora, fue mudar todo de nuevo. PLC a D2, StxLadder a 1.9.3 etc. Lo estoy probando y te aviso. Al parecer el reset se origina por usar esos números de puerto... o bien por lo menos uno de ellos (calculo el 82 asignado al TCP) es el que causaba el problema...

No podría haber imaginado una solución de ese tipo, bastante extraño, a lo mejor ambos puertos deban estar un poco más separado para evitar algún conflicto. Pero intento comprender a que se puede deber, ya que no debería ser así.

Lo que sí sería conveniente es que el PLC de algún tipo de aviso ante este tipo de errores sin que el programa se llegue a bloquear y ser necesario un reset por watchdog de todo el PLC. Esto es a los fines de que no entren en juego los actuadores que dependen en todo momento de las distintas salidas.

Si, es que pudiendo reproducir la falla me seria más fácil entender el por qué. El manejo de comunicaciones por parte del PLC es una "tarea" independiente, por lo tanto es raro que si se "bloquea" detenga al resto de las actividades.

Es decir, si se cuelga en la "comunicación" y nunca devuelve el control al programa del PLC, es lógico que se te dispare el watchdog, ya que no lo podes alimentar.

Si se cuelga en la "comunicación", pero de alguna forma sigue respondiendo, por ejemplo si conectas StxLadder y lo interrogás para ver información menú "PLC > Configurar PLC", y responde, es porque de alguna forma no está totalmente bloqueado, pero falla al devolver el control al PLC.

Si no responde nada, es algún tipo de otra falla interna, como error de memoria o un error no contemplado.

Pero comentame como sigue.

Saludos!
SOPORTE TÉCNICO

Slicetex Electronics
www.slicetex.com

Soporte

  • Global Moderator
  • Experto
  • *****
  • Mensajes: 1914
  • Soporte Técnico
Re:Detención indeseada PLC
« Respuesta #18 : octubre 17, 2018, 16:23:22 pm »
Algo que me olvidé de sugerir para que pruebes, es llamar al siguiente comando al inicio del programa en PlcMain() por una sola vez:
 
Código: (Pawn) [Seleccionar]
   // Desactivar TCP split en stack TCP/IP.
   NetTcpSplitOff()

Utilizar tanto en el cliente, como en el servidor (es decir ambos PLC tienen que estar configurados con esta opción al iniciar para que se puedan comunicar).

Esto evita que el PLC divida los paquetes TCP para mejorar desempeño, pero que quizás con tu router este dando problemas.

Saludos!

SOPORTE TÉCNICO

Slicetex Electronics
www.slicetex.com