31
STX8091 / Re:Red de PLC's 1Server-nClientes
« : febrero 13, 2019, 09:08:27 am »
Ok Boris.
Gracias por la info.
Gracias por la info.
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.
32
STX8091 / Re:Red de PLC's 1Server-nClientes
« : febrero 12, 2019, 06:32:04 am »
Ok Boris lo pienso por ese lado entonces.
Para encarar el desarrollo en visual que version usar?
Saludos
Para encarar el desarrollo en visual que version usar?
Saludos
33
STX8091 / Re:Red de PLC's 1Server-nClientes
« : febrero 09, 2019, 10:08:41 am »
Buen día Boris.
El número de 30 lo puse como máximo estimado en un futuro lejano.
Supón que la necesidad es de ir agregando PLC's de a uno hasta llegar a 10 clientes por ejemplo.
La finalidad de tener control de un PLC central sobre los demás es implementar un scada en visual c# que muestre un panel virtual de control en un monitor a través de una PC para tener monitoreo y control de todo el sistema en una sola Pantalla.
Los programas en los PLC's clientes no serían demasiado complejos. Pero imagino que si deberían almacenar en memoria datos estadísticos.
La información a transmitir sería mayormente de control (banderas de control ON/OFF) aunque también incluiría datos estadísticos (por ejemplo la corriente y temperatura de un motor eléctrico). Estos deberían poder ser enteros y decimales de coma flotante seguramente.
Porqué tantos PLC's?... El sistema a controlar está distribuído en un área de 5km de radio y los puntos de control podrán localizarse dentro de cualquier punto de ese sector.
Saludos
El número de 30 lo puse como máximo estimado en un futuro lejano.
Supón que la necesidad es de ir agregando PLC's de a uno hasta llegar a 10 clientes por ejemplo.
La finalidad de tener control de un PLC central sobre los demás es implementar un scada en visual c# que muestre un panel virtual de control en un monitor a través de una PC para tener monitoreo y control de todo el sistema en una sola Pantalla.
Los programas en los PLC's clientes no serían demasiado complejos. Pero imagino que si deberían almacenar en memoria datos estadísticos.
La información a transmitir sería mayormente de control (banderas de control ON/OFF) aunque también incluiría datos estadísticos (por ejemplo la corriente y temperatura de un motor eléctrico). Estos deberían poder ser enteros y decimales de coma flotante seguramente.
Porqué tantos PLC's?... El sistema a controlar está distribuído en un área de 5km de radio y los puntos de control podrán localizarse dentro de cualquier punto de ese sector.
Saludos
34
STX8091 / Red de PLC's 1Server-nClientes
« : febrero 07, 2019, 17:27:15 pm »
Buenas tardes Boris,
Tengo dos PLC conectados mediante red inalámbrica. Uno hace de Servidor y el otro de Cliente. Necesitaría agregar por ahora dos PLC's Clientes al sistema y es posible que a futuro sean necesarios más Clientes.
El protocolo usado en ambos PLC es el TCP.
La cantidad de datos que se transmiten es despreciable por el momento, tal vez se podría necesitar, como máximo requerimiento, la transmisión de los datos almacenados en las memorias EEPROM de cada uno de los clientes. (Requerimiento de uso esporádico sólo ante la eventual descarga p/ proceso de datos)
En cuanto a la cantidad de Clientes a agregar al sistema considerando que no hace falta que se comuniquen todos a la vez. Cada cliente se comunicaría cada 10 o 20 segundos al servar. Cuantos clientes harían al límite teórico estimado? (El límite de clientes que yo imagino no superar sería de 30 como máximo)
Y considerando que tal vez en caso de la transmisión de datos desde la memoria EEPROM de un cliente podría tomar varios segundos o minutos, debería generar algún error o conflicto si los demás clientes deben "esperar" las respuestas del server mientras tanto?
Saludos
Tengo dos PLC conectados mediante red inalámbrica. Uno hace de Servidor y el otro de Cliente. Necesitaría agregar por ahora dos PLC's Clientes al sistema y es posible que a futuro sean necesarios más Clientes.
El protocolo usado en ambos PLC es el TCP.
La cantidad de datos que se transmiten es despreciable por el momento, tal vez se podría necesitar, como máximo requerimiento, la transmisión de los datos almacenados en las memorias EEPROM de cada uno de los clientes. (Requerimiento de uso esporádico sólo ante la eventual descarga p/ proceso de datos)
En cuanto a la cantidad de Clientes a agregar al sistema considerando que no hace falta que se comuniquen todos a la vez. Cada cliente se comunicaría cada 10 o 20 segundos al servar. Cuantos clientes harían al límite teórico estimado? (El límite de clientes que yo imagino no superar sería de 30 como máximo)
Y considerando que tal vez en caso de la transmisión de datos desde la memoria EEPROM de un cliente podría tomar varios segundos o minutos, debería generar algún error o conflicto si los demás clientes deben "esperar" las respuestas del server mientras tanto?
Saludos
35
SH-300 / Re:PLC No conmuta Salidas DOUT 1 y 2
« : noviembre 06, 2018, 20:40:54 pm »
Solucionado Boris.
Efectivamente era eso.
Gracias y Saludos
Efectivamente era eso.
Gracias y Saludos
36
SH-300 / PLC No conmuta Salidas DOUT 1 y 2
« : noviembre 06, 2018, 07:52:49 am »
Que tal Boris buen día:
Te adjunto programas PLC 8091-D2 de nombre PruebaSH300 y programa de la pantalla de nombre "1".
Lo que intento hacer es presionando una tecla del panel conmutar la salida a rele correspondiente.
Conmutan la 3, 4 y 8 perfectamente pero la 1 y la 2 no lo hacen.
Los números de registros cargados en la pantalla son 6001, 6002 ... 6008.
Probé con 1, 2 ... 8 pero el relé enciende y se apaga inmediatamente después.
Las lámparas virtuales en la pantalla conmuntan bien, lo único que no funciona son las salidas 1 y 2.
Te paso los programas para que los pruebes haber si se te produce la misma falla.
Saludos
Te adjunto programas PLC 8091-D2 de nombre PruebaSH300 y programa de la pantalla de nombre "1".
Lo que intento hacer es presionando una tecla del panel conmutar la salida a rele correspondiente.
Conmutan la 3, 4 y 8 perfectamente pero la 1 y la 2 no lo hacen.
Los números de registros cargados en la pantalla son 6001, 6002 ... 6008.
Probé con 1, 2 ... 8 pero el relé enciende y se apaga inmediatamente después.
Las lámparas virtuales en la pantalla conmuntan bien, lo único que no funciona son las salidas 1 y 2.
Te paso los programas para que los pruebes haber si se te produce la misma falla.
Saludos
37
STX8091 / Re:Detención indeseada PLC
« : 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...
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
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
38
STX8091 / Re:Detención indeseada PLC
« : octubre 12, 2018, 16:32:25 pm »
Estimado Boris,
Según las últimas pruebas que estuve realizando, estoy en condiciones de asegurarte que los problemas de bloqueo y reset por wdt del programa que suceden en el PLC son causa de alguna anomalía en las instrucciones que corresponden al TCP server.
Al inhibir las instrucciones de definición del puerto y la de activación del evento tcp la falla desaparece.
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.
Necesitaría si podés revisar en que puede radicar la falla para poder poner en servicio el proyecto completo. En principio se me ocurre que podría devenir de alguna diferencia en las intrucciones de declaración del server TCP y/o del evento de recepción de datos que son las que, desactivadas interrumpen la aparición del bloqueo. O bien, de algún error al realizar la "mudanza" de modelo de D1 a D2 del PLC para que de esta forma se permita la carga total del proyecto.
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)
Saludos
Según las últimas pruebas que estuve realizando, estoy en condiciones de asegurarte que los problemas de bloqueo y reset por wdt del programa que suceden en el PLC son causa de alguna anomalía en las instrucciones que corresponden al TCP server.
Al inhibir las instrucciones de definición del puerto y la de activación del evento tcp la falla desaparece.
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.
Necesitaría si podés revisar en que puede radicar la falla para poder poner en servicio el proyecto completo. En principio se me ocurre que podría devenir de alguna diferencia en las intrucciones de declaración del server TCP y/o del evento de recepción de datos que son las que, desactivadas interrumpen la aparición del bloqueo. O bien, de algún error al realizar la "mudanza" de modelo de D1 a D2 del PLC para que de esta forma se permita la carga total del proyecto.
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)
Saludos
39
STX8091 / Re:Detención indeseada PLC
« : octubre 10, 2018, 12:24:44 pm »Otra prueba podría ser desconectar el cable ethernet, pero dejar solo el servidor web habilitado y ver si no se detiene. Luego conectar el cable ethernet y verificar.
Si... así estoy probando. Cable ethernet desconectado y webserver habilitado. Agregué código en el programa para que me avise por sms si se cuelga y hasta ahora no lo hizo. Pruebo conectarle el ethernet dentro de un rato.
Recordar que modelo D1 tiene mitad de memoria disponible, pero en firmware inferior a 211, no se comprueba que programa exceda limites y debería dejar cargar el proyecto original.
Me dejará cargar todo el código incluso el que hace uso de la EEPROM?
Gracias por el archivo.
Pruebo y te aviso
Saludos
40
STX8091 / Re:Detención indeseada PLC
« : octubre 09, 2018, 20:32:31 pm »
Estimado Boris,
Si no queda más alternativa voy a probar con el otro PLC pero espero para probar el cambio de D2 a D1.
La ultima prueba que hice fue desconectarle el panel sh300 y el puerto Ethernet y anular las sentencias que me indicaste además de las dos q hacían uso del panel.
No hubo reset pero habría que probarlo un par de días para tener certezas
Saludos
Si no queda más alternativa voy a probar con el otro PLC pero espero para probar el cambio de D2 a D1.
La ultima prueba que hice fue desconectarle el panel sh300 y el puerto Ethernet y anular las sentencias que me indicaste además de las dos q hacían uso del panel.
No hubo reset pero habría que probarlo un par de días para tener certezas
Saludos
41
STX8091 / Re:Detención indeseada PLC
« : octubre 09, 2018, 15:24:54 pm »
Hola Boris
La unica forma que tendria de corroborar que no se cuelgue seria por la "no indicacion de encendido" del led que se activa por reinicio de wdt. Ya que no podria acceder al webserver del plc. Pero hago la prueba y te aviso.
Lo único q alimento es un led de indicación de reset por desborde de wdt. El arduino y demás tienen alimentación propia y sólo comparten el negativo común.
Lo hago y te aviso.
Con respecto al cable utp, lo cambié esta mañana por uno con blindaje puesto a masa.
Pasamelo para probar ya que aparentemente no ha habido modificaciones en el circuito. Digo aparentemente porque en la caja metálica puesta a tierra donde se haya instalado el PLC no he cambiado nada y en lo que hace al resto de la instalación por lo que he podido revisar no encuentro ni cables cortados ni nada que me haga sospechar de algún desperfecto eléctrico en el circuito.
Por mi parte resumo todas las pruebas y las hago en un rato para informarte Boris.
Gracias por tu tiempo y asesoramiento.
No, me refería a si desconectando el Ethernet tenias la falla.
La unica forma que tendria de corroborar que no se cuelgue seria por la "no indicacion de encendido" del led que se activa por reinicio de wdt. Ya que no podria acceder al webserver del plc. Pero hago la prueba y te aviso.
¿Por casualidad alimentás el kit Arduino u otro circuito con la salida de tensón +5D del PLC?.
Lo único q alimento es un led de indicación de reset por desborde de wdt. El arduino y demás tienen alimentación propia y sólo comparten el negativo común.
Fíjate de comentar también la inicialización del servidor TCP y desconectar el cable del SH-300 directamente.
Código: (Pawn) [Seleccionar]
// TcpServerInit(82, 30)
Lo hago y te aviso.
Con respecto al cable utp, lo cambié esta mañana por uno con blindaje puesto a masa.
Bueno, cabe esa posibilidad después de todo, lo que me llama la atención, es que corro tu programa y no presenta problemas.
Te puedo pasar para cambiar a modelo D1 y que pruebes.
Por otro lado, ¿te acordás que versión de firmware utilizabas sin problema?. Para verificar si hay algún cambio relacionado.
Pasamelo para probar ya que aparentemente no ha habido modificaciones en el circuito. Digo aparentemente porque en la caja metálica puesta a tierra donde se haya instalado el PLC no he cambiado nada y en lo que hace al resto de la instalación por lo que he podido revisar no encuentro ni cables cortados ni nada que me haga sospechar de algún desperfecto eléctrico en el circuito.
Por mi parte resumo todas las pruebas y las hago en un rato para informarte Boris.
Gracias por tu tiempo y asesoramiento.
42
STX8091 / Re:Detención indeseada PLC
« : octubre 09, 2018, 10:52:25 am »
Como el cable utp que conecta al router con el plc es algo largo (12 mts aproximadamente) voy a probar cambiarlo por uno blindado y puesto a tierra.
Ahora, te recuerdo que este reset constante lo hace desde que cambié al plc a D2 y la versiones nuevas de stxladder y firmware.... será necesario que probemos volviendo a d1 y a algún firmware anterior para descartar que sea algún problema de las nuevas versiones?
Saludos
Ahora, te recuerdo que este reset constante lo hace desde que cambié al plc a D2 y la versiones nuevas de stxladder y firmware.... será necesario que probemos volviendo a d1 y a algún firmware anterior para descartar que sea algún problema de las nuevas versiones?
Saludos
43
STX8091 / Re:Detención indeseada PLC
« : octubre 09, 2018, 09:19:51 am »¿Sin conexión desde afuera, ocurre también el problema?.
Con conexión desde afuera te referís a la entrada telefónica del router o a la entrada ethernet del PLC?
¿Conmutas alguna bomba, o carga con rele, contactor, etc, igualmente?.
Directamente desde este PLC no conmuto relé alguno. Lo único que tiene como periférico es un transductor de presión como entrada análógica, sus salidas a relé que cierran las entradas (digitales) de un kit arduino con transmisor de sms por gsm y un led indicador de reset por wdt. Y un pseudo led debug desde una de las salidas pwm usada como digital y otro led indicación de comunicación por enlace exitosa conectada a la otra salida pwm usada también como digital.
En @OnTcpServerRx() proba el siguiente código en remplazo de: while((Id=TcpServerGetUnreadId()) > 0)
Código: (Pawn) [Seleccionar]
for(new Count=0; ((Id=TcpServerGetUnreadId()) > 0) && (Count < 100); Count++)
La última prueba que hice ayer fue comentar o anular si se quiere
la llamada a los eventos
//TcpServerSetRxEvent()
y el de la pantaslla sh300
//MbRtuServInit(1, 9600, SERIAL_8E1, MB_RTU_INTERFACE_RS232);
Se sigue colgando el programa aunque anoche aguantó por lo menos 3 horas hasta donde pude ver. Esta mañana cuando abrí el webserver ya se habia colgado.
En cuanto a hardware el único cambio que hice fue el de la fuente de 12V por una similar a la que viene con el plc
Sigo probando
Saludos
44
STX8091 / Re:Detención indeseada PLC
« : octubre 08, 2018, 12:15:53 pm »
Hola Boris,
La última prueba que hice fue desconectar la antena del modem y aunque sigue bloqueándose y reseteandose por wdt. El intérvalo de tiempo entre bloqueos parece haberse prolongado desde los 5 minutos aproximadamente a los 60 minutos aproximadamente.
Será alguna cuestión vinculada a buffers llenos o interferencia entre eventos?
En el PLC que tengo encendido en laboratorio no se produce reset alguno en los tres día que está funcionando. Este está conectado al router en mi casa, pero no hay aquí antena que tenga que transmitir/recibir datos, por lo cual asumo que la ejecución del evento correspondiente @OnTcpServerRx() ha de ser mucho más rápida.
Se me hace que es un problema de interferencia o "cuelgue" de algún evento...
Saludos
La última prueba que hice fue desconectar la antena del modem y aunque sigue bloqueándose y reseteandose por wdt. El intérvalo de tiempo entre bloqueos parece haberse prolongado desde los 5 minutos aproximadamente a los 60 minutos aproximadamente.
Será alguna cuestión vinculada a buffers llenos o interferencia entre eventos?
En el PLC que tengo encendido en laboratorio no se produce reset alguno en los tres día que está funcionando. Este está conectado al router en mi casa, pero no hay aquí antena que tenga que transmitir/recibir datos, por lo cual asumo que la ejecución del evento correspondiente @OnTcpServerRx() ha de ser mucho más rápida.
Se me hace que es un problema de interferencia o "cuelgue" de algún evento...
Saludos
45
STX8091 / Detención indeseada PLC (solucionado)
« : octubre 06, 2018, 21:21:03 pm »
Buenas tardes Boris,
Tengo un problema de reinicio constante de un PLC stx8091-d2 que hace de servidor para un único cliente remoto que por el momento es stx8091-d1. (Lo pasaré a D2 con el archivo que me pasaste).
El led debug parpadea en forma normal y de repente queda encendido o apagado hasta cumplirse los 60 segundos asignados al watchdog.
La idea serìa sumar varios plc clientes más.
Adjunto proyectos cargados en el server como versión 20.0 y en el cliente como cl_casa_2
Estos plc se comunican por medio de un enlace parabólico. El puerto ethernet del server va a un modem/router y al mismo router el de la antena "access point". Son los únicos dos dispositivos conectados al router en este momento.
Desde el primer momento que se puso en servicio el sistema, se sucedieron detenciones esporádicas... (A veces se producían detenciones dos veces al día como también se ha dado el caso de no detenerse el programa en semanas) lo cual no influía en el desempeño del sistema sin dejar de ser indeseable por supuesto. Pero sucede que después de pasarlo a D2, actualizar firmware a versión 217 y cargarle las sentencias de uso de la EEPROM empezó a "detenerse el programa" en un período de tiempo indefinido que va entre los 5 y los 50 minutos según pude observar desde ayer a la mañana que estoy haciendo pruebas.
Comentarte también que el mismo proyecto lo tengo corriendo en un PLC del mismo modelo y también modificado a la versión D2 con el mismo firm 217 y programado con stx 1.9.3 en mi casa conectado a mi router. Accedo constantemente a ambos servidores (El que está en servicio y el que tengo a prueba) desde la dirección IP externa y el que está en prueba no presenta ningún problema y el otro sí.
Ya probé reiniciar reiteradas veces el modem/router y la antena y no doy con la falla.
La consulta sería como proceder para hallar el segmento de código que me está produciendo el "stop" del plc?
Había pensado en ir guardando en EEPROM números guías dentro del código pawn para acceder a él post reset y así intentar ver al menos en que punto del programa se produce la falla. Quería consultarte si tenés alguna herramienta o técnica que me pueda ayudar a aislar el problema.
Podrá caber la posibilidad de que algún problema de programación de más bajo nivel de la ejecución de sentencias o procedimientos sea responsable de estas paradas en el programa?
Este PLC está en servicio hace ya dos años y medio aproximadamente. Nunca le cambié la batería interna. Podrá ser causa del problema?
Saludos
Tengo un problema de reinicio constante de un PLC stx8091-d2 que hace de servidor para un único cliente remoto que por el momento es stx8091-d1. (Lo pasaré a D2 con el archivo que me pasaste).
El led debug parpadea en forma normal y de repente queda encendido o apagado hasta cumplirse los 60 segundos asignados al watchdog.
La idea serìa sumar varios plc clientes más.
Adjunto proyectos cargados en el server como versión 20.0 y en el cliente como cl_casa_2
Estos plc se comunican por medio de un enlace parabólico. El puerto ethernet del server va a un modem/router y al mismo router el de la antena "access point". Son los únicos dos dispositivos conectados al router en este momento.
Desde el primer momento que se puso en servicio el sistema, se sucedieron detenciones esporádicas... (A veces se producían detenciones dos veces al día como también se ha dado el caso de no detenerse el programa en semanas) lo cual no influía en el desempeño del sistema sin dejar de ser indeseable por supuesto. Pero sucede que después de pasarlo a D2, actualizar firmware a versión 217 y cargarle las sentencias de uso de la EEPROM empezó a "detenerse el programa" en un período de tiempo indefinido que va entre los 5 y los 50 minutos según pude observar desde ayer a la mañana que estoy haciendo pruebas.
Comentarte también que el mismo proyecto lo tengo corriendo en un PLC del mismo modelo y también modificado a la versión D2 con el mismo firm 217 y programado con stx 1.9.3 en mi casa conectado a mi router. Accedo constantemente a ambos servidores (El que está en servicio y el que tengo a prueba) desde la dirección IP externa y el que está en prueba no presenta ningún problema y el otro sí.
Ya probé reiniciar reiteradas veces el modem/router y la antena y no doy con la falla.
La consulta sería como proceder para hallar el segmento de código que me está produciendo el "stop" del plc?
Había pensado en ir guardando en EEPROM números guías dentro del código pawn para acceder a él post reset y así intentar ver al menos en que punto del programa se produce la falla. Quería consultarte si tenés alguna herramienta o técnica que me pueda ayudar a aislar el problema.
Podrá caber la posibilidad de que algún problema de programación de más bajo nivel de la ejecución de sentencias o procedimientos sea responsable de estas paradas en el programa?
Este PLC está en servicio hace ya dos años y medio aproximadamente. Nunca le cambié la batería interna. Podrá ser causa del problema?
Saludos