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 5 6
31
Lo suponía. Muchas gracias !


Hola Pablo,

Tenes razón, en este caso hay un error de tipeo interno en StxLadder 1.7.3 qué hace qué no se llame la función correctamente, pero no es un error de firmware.

Luego te aviso cuando suba la actualización.

Saludos

Enviado desde un dispositivo móvil usando Taptalk.

32
Hola Boris,

Hice los 3 pasos (actualizar StxLadder + actualizar a Firmware 216 + agregar  NetTcpSplitOff()) y el problema con ModBus volvió a aparecer exactamente igual que antes.

Volví a la versión 216 beta (seguí con StxLadder 1.7.3 pero eliminé la instrucción NetTcpSplitOff), y volvió a funcionar bien de nuevo.

Quizá tenés algún error en la implementación de NetTcpSplitOff ???  Porque el tema ya lo tenías resuelto en FW 216 beta...

Saludos !
Pablo.


Hola Pablo,

La versión 216 de firmware liberada para la STX8081 arregla la parte de ModBus TCP que tiene el comportamiento extraño que indicas con la App Android.

Para que te funcione, instala tambien StxLadder v1.7.3 y ejecuta la siguiente linea al inicio del tu proyecto:

Código: (Pawn) [Seleccionar]

   // Desactivar TCP split en stack TCP/IP.
   NetTcpSplitOff()


Luego proba el ModBus TCP con el programa Android.

Solo hace falta llamar una sola vez a la función en todo el proyecto.

Esa linea mantiene la compatibilidad en funcionamiento TCP como lo hacia en versiones previas.

Con NetTcpSplitOn() se vuelve a la versión actual (que es activada por defecto) y que mejora el desempeño del Servidor Web con navegadores en Windows solamente.

Avísame si la probas.

Saludos

33
Hola Boris,

Bueno, instalé el firmware 216 beta y ... todo volvió a la normalidad en materia de comunicaciones ModBus !! Excelente.
O sea: todo está tal cual como siempre (bien!).

Me hice ilusiones de que esto podría interferir o tener que ver con el otro problema de que no suben todos los fields a thingspeak, asi que me puse a probar de nuevo ese tema con el nuevo firmware. Pero no, no influye en nada. Se comporta exactamente igual que como te describí en el otro hilo específico del tema.

Me parece que en materia de firmware, el beta está OK. Cuando lo pases a definitivo avisame y reinstalo la versión definitiva (si es que le vas a hacer algun cambio más).

Por último, te recuerdo si fuera posible que el HMI Android pueda mostrar líneas más largas que 37 caracteres, estaría muy bueno. Lo ideal sería que haga line wrap a un determinado número de caracteres (o cuando llega al final de la pantalla), y pase automáticamente a la línea siguiente. Hoy en día no hay forma de mostrar un string largo (como la URL que mando a ThingSpeak por ejemplo).

Muchas gracias, excelente trabajo como siempre !
Pablo.

Hola Pablo,

Mi dispositivo Android no es compatible con esa aplicación (debe requerir un Android más moderno), así que no pude probarla.

Pero te adjunto un firmware 216-beta1 con el funcionamiento original del TCP (como en la version 208), pero con las nuevas
características añadidas (Servidor Web, etc).

Fíjate instalarlo y decime si te funciona correctamente, ya que pienso que esa parte es la que puede darte problemas.

Saludos

34
OK muchas gracias. Entre hoy y mañana pruebo...

Hola Pablo,

Mi dispositivo Android no es compatible con esa aplicación (debe requerir un Android más moderno), así que no pude probarla.

Pero te adjunto un firmware 216-beta1 con el funcionamiento original del TCP (como en la version 208), pero con las nuevas
características añadidas (Servidor Web, etc).

Fíjate instalarlo y decime si te funciona correctamente, ya que pienso que esa parte es la que puede darte problemas.

Saludos

35
Hola buen día,

El acceso ModBus lo hago mediante un pequeño software de "Scada" para Android, en el cual se leen aproximadamente unas 20 variables ModBus (entre coils e integers).
El Scada es este:
https://play.google.com/store/apps/details?id=evolution.kod

Estoy bastante convencido que con los cambios introducidos "algo hay"... porque al volver al firmware anterior se solucionó instantaneamente...
Saludos,
Pablo.


Buenas tardes Pablo, disculpa la demora pero recien retorno de vacaciones.

Te comento que estoy probando ModBus TCP con un panel HMI ethernet y el mismo accede a variables ModBus en intervalos de 80 a 250 mS, y no noto problemas.

En las versiones nuevas de firmware se modifico el soporte TCP del stack para que responda mas rápido con maquinas que usan Windows (ya que para el WebServer fue necesario), y no descarto que pueda provenir de ahí el error, pero las pruebas que estoy realizando no muestran ninguna anomalía.

Te consulto, ¿con que programa o aplicación estas experimentando este problema ?. ¿Hay alguna forma que yo pueda replicarlo así lo analizo y determino donde esta el problema?.

Quedo a disposición.

36
Hola Boris, feliz regreso !

Eventualmente, podría hacer una lógica para subir 3 fields y luego los otros 3 fields. Pero hay un problemita: cada "subida" es computada por thingspeak, que no te deja subir datos con una frecuencia mayor a 15 segundos. O sea que hay que asegurarse que entre una subida de datos y la próxima pasen al menos 15 segundos. Se puede implementar la lógica ... pero es un poco desprolijo ...

Saludos !
Pablo.

Buenas tardes Pablo, disculpa la demora pero recién retorno de vacaciones.

Ya voy a analizar mejor lo que me comentas y te daré mas respuestas a tus preguntas.

Es probable que sea un tema de limite de caracteres a enviar, por un tema de buffers internos, ya que se envía un string con con todos los fields, headers y valores numéricos.

Te consulto: ¿No podes enviar primero 3 fields y luego los otros 3? ¿Hay algún inconveniente con eso?.

Quedo a disposición.

37
Hola Boris nuevamente,

Hoy estuve extendiendo el uso de las funcionalidades de ThingSpeak en mi PLC, y me encontré con un problema que no pude descifrar. Te explico:
Yo hasta ahora venía usando 4 canales: field1, field2, field3 y field4.
A partir de esta "ampliación", empecé a utilizar 6 canales: field1, field2, field3, field4, field5 y field6
Y me encontré que en ningún caso puedo subir la información de los 6 fields simultáneamente, o sea armando correctamente el string con toda la cadena conteniendo los 6 fields.
Sí puedo subir los primeros 4. O bien los últimos 2. o bien los 3 primeros y uno más. Pero nunca los 6 campos. En otras pruebas simplemente no pude subir ningún dato a los fields4, 5 y 6 (!?).
Pensé que habría un problema en thingspeak.p en cuanto al tamaño definido de los strings[], asi que les puse 300 char a todos. Pero eso no cambió nada (aunque tengo el pálpito que con los valores originales nos estamos quedando cortos).

Para mí el problema está en la zona de la función ThingspeakSendFields(), en la parte donde hace los getargs(), pero no pude encontrar ningún error.

Tengo varias dudas:

1- Existe alguna limitación para que no se pueda subir mas de 4 fields al mismo tiempo?

2- Qué hace la función getargs(), como funciona?

3- Cuál es el tamaño máximo de los strings? En el manual si no me equivoco habla de 160 caracteres, pero en tu codigo thingspeak.p ya había originalmente strings más grandes (antes de que yo lo edite). Entonces en algún momento se ha extendido la capacidad de los strings?

4- Existe alguna función substring(string,comienzo,numero_de_caracteres), o sea para extraer un string a partir de un punto.

5- Para monitorear y debugear todo este tema de ThingSpeak, siempre envié el string que armo con los "field´s" al VirtualHDMI Android, pero encontré que VirtualHDMI tiene aparentemente un límite de algo así como 37 caracteres por renglón y trunca la línea, y es como que no hay forma de mostrar un string completo que sea realmente largo (50-200 bytes), si es necesario haciendo line break hacia el siguiente renglón. Quise "partir" mi string largo en varios strings, pero como no tenía función substring() no lo pude resolver. Fijate que VirtualHDMI Android en el modo "Menu Keys" tiene una pantalla enorme, y caracteres muy pequeños, por lo que se podrían mostrar strings realmente largos.

Bueno, si se te ocurre algo avisame. Me gustaría saber si vos podés hacer la prueba y definís en ThingSpeak un Channel con 6 ó mas fields, y les mandás un dato a cada uno, si te los toma o no. Para mí no funciona. Estuve como 5 horas probando y probando !

Desde ya muchas gracias y buenas vacaciones!
Pablo.


PD: se me ocurre ahora: no se tratará de un problema de tiempos?  O sea: que al protocolo TCP no le den los tiempos para realizar la transacción con ThingSpeak cuando la cantidad de campos es más de 4 ??  Fijate que en otro hilo estoy reportando un problema similar con el firmware revisión 215, en el que encontré que accediendo via ModBus, el sistema responde solo con las primeras variables, pero llega un punto en el que se traba...

38
Hola Boris, buenos días,
Se que estás de vacaciones, pero te dejo esta inquietud para más adelante.
Hace una semana atrás me puse a hacer unas actualizaciones al software de mi sistema PLC. Como siempre hago, primero chequeo si hay versiones nuevas e instalo todo lo nuevo (aún sin necesitarlo). Entonces actualicé STXLadder a 1.7.2 y el firmware al release 215.
Y me puse a hacer unas modificaciones a mi sistema.

Una de las funcionalidades que tengo, como ya sabés, es consultar el estado del sistema utilizando ModBus, que siempre me anduvo perfecto. En esta oportunidad no toqué nada que tenga que ver con ModBus, pero al probar el sistema, me encontré con que ahora, con el nuevo firmware, la respuesta de ModBus se hizo tan lenta, que no llega a completarse nunca el llenado de las variables que yo leo via ModBus. Es como que llegan a leerse las primeras 3 a 5 variables, y luego se queda como si el tiempo de respuesta del PLC no fuera suficiente para atender los requerimientos de ModBus.

Estuve viendo que en el otro hilo en el que se habla de las nuevas funcionalidades TCP (muy interesante tenerlas!), también se menciona un problema de tiempos de respuesta.
Mi sospecha es que al incluírse las funcionalidades de servidor TCP, se podría haber reducido notablemente la capacidad de responder a los requerimientos ModBus. O quizá tiene que ver con la incorporación de las nuevas funcionalidades de web server.
Aclaro que en mi proyecto, donde se manifestó el problema, no estoy utilizando TCP ni web server. Lo que sí tengo es ModBus, recepción de paquetes UDP y VirtualHMI (que también es por UDP).

La cuestión es que yo pensé que el problema se había generado en las modificaciones de código que había hecho en mi proyecto Pawn. Luego de probar y probar se me ocurrió volver atrás el firmware a la versión que tenía hasta entonces (la 208). La instalé, y todo salió perfecto de nuevo.

O sea que me parece que en el firmware 215 existe alguna interacción (al menos) entre Modbus y Servidor TCP.

Te mando un gran saludo, y felicitaciones por todas las nuevas funcionalidades que le estás agregando. Sabés que todo esto relacionado con la conectividad a mi me parece muy muy importante y útil, como cuando incorporaste ThingSpeak...

Pablo.

39
Hola Boris,

El hecho de "ver el dato online" obviamente que es útil. Pero no es la principal utilidad que yo le voy a dar.
El punto es que cuando vos tenés el PLC monitoreando distintas entradas (analógicas o digitales), y vas "actuando" en función de eso, en definitiva lo que tenés en cada instante (en los emails de notificaciones o en el display por ejemplo) es una "foto" en ese momento, o bien porque se generó una situación que amerite una notificación.
Con la utilización de ThingSpeak, uno puede subir una vez por minuto aquellas variables que pueden ser interesantes de monitorear, y vas a tener diariamente TODA LA CURVA, y no solo "fotos" en el momento que consultaste.
Ejemplos:
- Medición de temperatura
- En qué momentos se encendió la caldera
- Nivel del tanque de agua
etc

En definitiva, visualizando un conjunto de variables sobre una escala del tiempo, te da mucha más información que una simple foto en el momento en que te pongas a verla. Ni que decir que el visualizar la curva completa también te permite detectar anormalidades o corregir errores, o eficientizar procesos.

Un gran saludo y felicitaciones de nuevo por tu trabajo.
Pablo.


Buenísimo Pablo, seré curioso pero cual seria mas o menos la aplicación que le darías ? Mas allá de ver el dato on-line.

40
Hola Boris,

Actualicé el firmware del PLC.
Actualicé STX Ladder.
Instalé la librería de ThingSpeak.
La integré con mi proyecto.
Compilé.
Y anduvo desde el primer intento !!!!!

Sinceras felicitaciones y agradecimiento. Excepcional trabajo.

Pablo

41
Anda perfecto !
Muchas gracias,
Pablo.

Buenas tardes Pablo,

Ya fue actualizado Virtual HMI con la característica que solicitabas.

Ver resumen en: http://www.slicetex.com/foro/smf/index.php?topic=161.0

Citar
...entre los parámetros de configuración del programa, sería muy bueno tener una opción tal como:
- Seleccionar el Panel por defecto  (Basic, Menu Keys, Function, etc, etc). O bien...
- Un checkbox: Iniciar en el último Panel Utilizado
Yo por ejemplo, el panel que siempre uso es "Only LCD", pero tengo que ir y seleccionarlo cada vez...

Estamos en contacto.

42
STX8081 - Familia Power I/O Board / Re:Recibir datos via UDP
« : octubre 20, 2015, 08:59:08 am »
Perfecto !
Sí, con este protocolo básico voy a andar bien. No creo que necesite handshake.
Mil gracias !
Pablo.

Citar
Sobre el tema del formato de los paquetes UDP. Ahora entiendo !!! Por eso es que no me funciona enviando paquetes UDP desde un "programita cualquiera" que envía paquetes UDP. Es porque hay que enviarlos con cierto preámbulo o formato. Y por eso es que SI funciona si envío el paquete desde PawnudpTx.exe.
Efectivamente: yo voy a enviar paquetes UDP desde un dispositivo ESP8266, y por lo tanto sí necesitaría pedirte los datos de cómo hay que armar el "formato" de paquetes UDP, porque si no no lo voy a poder comunicar nunca :).
Encontré el siguiente thread, pero no sé si tenés alguna documentación más específica del protocolo CSP:
http://www.slicetex.com/foro/smf/index.php?topic=34.0

Así es Pablo, en ese mensaje se explica como es el el encabezado para enviar datos UDP al PLC.

Básicamente, si queres enviar dos bytes (con valores 1 y 55) haces:

Código: [Seleccionar]

   // Configurar CSP Header

   // Clave (32-bits) - Es la clave configurada en el PLC de destino.
   Data[0] = 0   // LSB
   Data[1] = 0
   Data[2] = 0
   Data[3] = 0  // MSB

   // Proto version.
   Data[4] = 2

   // Type
   Data[5] = 0xFA

   // Argument size.
   Data[6] = 3  // 1 byte + 2 bytes
   Data[7] = 0

   // Código de comando (UdpRx())
   Data[8] = 6

   // Argument size.
   Data[9] = 2  // Cmd UdpRx Arg. Size (2 bytes)

   // Set data values.
   Data[10+1] = 1       // Value 1
   Data[10+2] = 55     // Value 2


Como podes ver, en el array Data cargas los bytes a enviar a partir del elemento 10.

  • En el elemento 9 la cantidad de bytes enviados.
  • En el elemento 6 la cantidad de bytes enviados + 1.
  • El resto de los elementos del array tienen valores constantes (a menos que cambies la clave del PLC, en ese caso debes cambiar la clave enviada en el paquete para que sea aceptada como validad)..

Esa es la forma mas simple de enviar datos al PLC con UDP, ya que hay otro modo donde se utiliza un "handshake" (que lo usa la librería y otros programas) y sigue un protocolo con respuestas y estados, y depende del campo "TYPE". Pero eso no lo tengo documentado y es mas complejo.

Cualquier duda avisame.

43
Fantásticoooo !  Muchas gracias.
Te mando feedback apenas lo haya probado.
Saludos,
Pablo.

Buenas tardes Pablo,

Ya es posible usar thingspeak.com, te paso el link al tema del foro abierto para esa función:

http://www.slicetex.com/foro/smf/index.php?topic=160.msg727#msg727

Probalo y seguimos por ahí con esa funcionalidad.

Saludos

44
Citar
Con respecto a la versión Android (que es espectacular!), aquí va una sugerencia: si llegás a tener que recompilarlo para solucionar lo del tema del nombre del host, quizá se podría agregar lo siguiente: entre los parámetros de configuración del programa, sería muy bueno tener una opción tal como:
- Seleccionar el Panel por defecto  (Basic, Menu Keys, Function, etc, etc). O bien...
- Un checkbox: Iniciar en el último Panel Utilizado
Yo por ejemplo, el panel que siempre uso es "Only LCD", pero tengo que ir y seleccionarlo cada vez...

Si estoy de acuerdo, lo habia pensado pero me olvide de agregarlo.
Lo voy a hacer y te aviso.
Excelente !!  (no hay apuro, es solo una sugerencia)

Citar
según tengo entendido, todos los ISP no permiten que sus routers trafiquen paquetes UDP
Los ISP de telefonia celular cierran todos los puertos, solo quedan algunos TCP, y para UDP ni hablar.
Con respecto a los ISP de Banda Ancha, es depende, pero el tema es que UDP muchas veces como decís
se pierde en la "nube". No es fiable para VirtualHMI por internet.
Como bien decís, debería ser por TCP.
Sí, lamentablemente las cosas son así.

Citar
Por otro lado te comento que estoy haciendo pruebas con Thingspeak, te mantengo al tanto cuando logre actualizar
un dato en la Web.
Fantástico. Te sugiero el siguiente procedimiento para verificar básicamente si funciona: crear una cuenta en ThingSpeak (gratis), y vas a ver que en un minuto podés armar una sentencia URL que se ejecuta desde el navegador, y eso te graba el valor en ThingSpeak. Luego meter esa misma URL en la nueva función de Pawn, y ver si se actualizan los valores en ThingSpeak.

Muchas gracias y buen fin de semana.

45
STX8081 - Familia Power I/O Board / Re:Recibir datos via UDP
« : octubre 16, 2015, 22:29:28 pm »
Hola Boris,

Muchas gracias por tu respuesta.
Desde ya te anticipo que ya lo hice andar !! (al menos, lo básico). Igualmente, aquí van las respuestas punto por punto.

1) Sí, estoy usando PawnudpTx.exe que está en el CD que vino con el equipo. Quizá no es la última versión. Pero al final sí me comenzó a funcionar. No sé qué fue lo que cambió, pero ya no me tira más el error que te mencioné mas arriba.

2) Ahora reimplementé las funcionalidades UDP utilizando @OnUdpRx(), o sea por eventos, porque veo que así parece ser el método preferido. Creo que este fue el punto o el punto 3) hicoeron que empiece a funcionar.

3) Con respecto a la función UdpRxBufUnread(), creo que la utilicé mal, porque seguí el ejemplo del manual que dice (página 209), quizá está mal ejemplo en el manual:
     // Comprobar si el buffer tiene nuevos datos sin leer.
     if(UdpRxBufUnread() == 0)
     {
     // Leer datos del Rx Buffer.
     }

4) Sobre el tema del formato de los paquetes UDP. Ahora entiendo !!! Por eso es que no me funciona enviando paquetes UDP desde un "programita cualquiera" que envía paquetes UDP. Es porque hay que enviarlos con cierto preámbulo o formato. Y por eso es que SI funciona si envío el paquete desde PawnudpTx.exe.
Efectivamente: yo voy a enviar paquetes UDP desde un dispositivo ESP8266, y por lo tanto sí necesitaría pedirte los datos de cómo hay que armar el "formato" de paquetes UDP, porque si no no lo voy a poder comunicar nunca :).
Encontré el siguiente thread, pero no sé si tenés alguna documentación más específica del protocolo CSP:
http://www.slicetex.com/foro/smf/index.php?topic=34.0

Citar
Por otro lado, el PLC recibe datos UDP con un cierto "formato" que incluyen el password del PLC, asi el mismo puede aceptarlos.
Pero si lo haces desde algún otro programa o lenguaje, podes enviar al PLC pero debes agregar 10 bytes al paquete con informacion.
¿ Eso queres hacer ?
Decime y te paso el formato para el envio si no estas utilizando nuestra librería para C#.

Muchísimas gracias,
Pablo.

Páginas: 1 2 [3] 4 5 6