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.


Temas - PabloGa

Páginas: [1] 2
1
Hola Boris, como estás,
Una consulta: en la aplicación de mi PLC estoy creando una "pagina web" que en realidad es una simple cadena de texto (valores separados por comas); en definitiva la "página" es simplemente un renglón, una línea de texto. Así lo tuve funcionando hace meses.
Al agregarle ahora más datos al string CSV (se hizo más largo), pareciera que cuando se genera la página mediante WebServerPrintStr(), hubiera alguna limitación en cuanto al número de caracteres que puede tener el renglón; aparentemente serían 90 caracteres. Cuando llega al caracter 90 el string se trunca. Puede ser ?
Esta es la sintaxis utilizada (todo es 1 renglón Pawn):
WebServerPrintStr("%02d/%02d/%02d,%02d:%02d:%d,%s,%d,%d,%d,%s,%d,%s,%02d/%02d,%02d:%02d,%02d/%02d,%02d:%02d,%d.%d,%d.%d,%d.%d,FIN", Dia, Mes, Anio, Hora, Min, Seg, DATO1, DATO2, DATO3, DATO4, DATO5, DATO6, DATO7, DATO8, DATO9, DATO100, DATO11, DATO12, DATO13, DATO14, DATO15, DATO16, DATO17, DATO18, DATO19, DATO20, DATO21)

De paso: la instrucción en lenguaje Pawn que genera ese string es larga (tiene como 480 caracteres)... hay alguna limitación en el compilador para el largo de un renglón de código fuente?  Me surgió esta duda buscando de resolver el problema del punto anterior...

Desde ya muchas gracias.
Saludos!
Pablo

2
STX8081 / Consulta por problemas de conectividad con internet HTTP
« : marzo 16, 2021, 12:36:38 pm »
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.

3
STX8081 / Integrar el PLC con Google Home o Alexa
« : mayo 08, 2020, 13:45:44 pm »
Hola Boris, buen día,

Alguna vez pensaste en que se podría hacer una integración entre Google Home y los PLC ? O sea: que desde un dispositivo como Google Home se podría enviar (y recibir) comandos desde el PLC.

Leyendo un poco he visto que en muchos casos hacen esta integración entre Google Home y un Raspberry Pi. También entre Google Home y un ESP8266. Por lo tanto, con las capacidades de un PLC (que tiene http), pensé que sería factible.

Viste algo de esto?
Saludos!
Pablo.

4
Hola Boris buenas tardes !
Estoy haciendo el upgrade de mi entorno StxLadder, pasando de la version 1.9.9 a la 2.0.2
Al intentar compilar, me tira error en todos los lugares donde está la instrucción StrCat (concatenar 2 strings), como si fuera que no existe más el comando.
Hice el downgrade a 1.9.9 y compila perfecto nuevamente.

De paso: tenés algún listado nuevo de todos los comandos Pawn (actualizado) ?

Muchas gracias desde ya,
Pablo.

5
STX8081 / Problema con las últimas versiones (packed string)
« : agosto 04, 2018, 20:05:27 pm »
Hola Boris que tal?

Hoy me dispuse a hacer una modificación al programa de mi PLC, y -como hago siempre- primero actualizo el StxLadder a la última versión disponible, y lo mismo con el firmware del PLC (el mío es un 8081-D2). Luego de la actualizaciòn tuve problemas; te paso la info:

Lo que tenía antes de actualizar era:
StxLadder 1.8.8
Firmware 227

Luego de actualizar pasé a:
Stxladder 1.9.2
Firmware 229

El problema se manifiesta así: al compilar el programa (ya con el nuevo entorno), me tira el siguiente error:

Error de Memoria: Insuficiente memoria RAM: El proyecto requiere 19668 bytes y el dispositivo tiene disponible 16384 bytes. Disminuya variables globales, variables locales inicializadas, comparta/reutilice variables globales, utilice packed strings, agrupe datos, etc.


Entonces voy a ver en el PLC qué marca, y en el display tiene el siguiente cartel:
PLC Return Code C:200 R:0

Pensé que habría un problema con el firmware, asi que lo volví para atrás a la V227. Pruebo a compilar con F6, y me da el mismo error. Entonces volví para atrás también el entorno StxLadder, y todo volvió a la normalidad (me apareció un cartel diciendo que el programa había sido construído con una versión de StxLadder superior, y que podría haber pérdidad de datos, pero seguí adelante y todo anduvo normal).

Aclaro que al grabar el firmware me aseguré de elegir la versión correcta del archivo, de acuerdo al modelo de PLC que uso: stx8081-d2.sff

En conclusión, no me queda claro si el problema está en el firmware o en el entorno.
Por lo pronto, tengo todo funcionando a la perfección, por lo que no hay ningún apuro en resolver nada.

Saludos y muchas gracias !
Pablo.

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


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

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

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


10
Hola Boris buenas tardes,

Cada vez que envío un email de notificación, primero "armo" en un string "email_cuerpo" todo el cuerpo del email.
Esta variable email_cuerpo contiene "\n" cada tanto, para mostrar el email de una manera fácilmente legible.

Por otro lado, utilizo VirtualHMI para mostrar una gran cantidad de información sobre el funcionamiento del sistema. Entre ellas, tengo una pantalla en donde muestro el cuerpo de la ultima notificación enviada por email, y el resultado de dicho envío.

El problema que tengo es que al mostrar en VirtualHMI (Android) el cuerpo del último email, es como que ignora los comandos de formato "\n" (nueva línea), y todas las líneas aparecen "encimadas" una sobre la otra, en el mismo renglón de VirtualHMI.

La sintaxis que utilizo para mostrar el cuerpo en VirtualHMI es:
nLcdPrintf(0,6,0,"CUERPO= %s", email_cuerpo)

También probé a reemplazar "\n" por "\r\n" y dio el mismo resultado.

Otra opción sería "parsear" completo el string, buscando los "\n" y en base a eso cambiar la posición "Y" de nLcdPrintf(), pero es bastante laborioso.

Donde la estoy errando?  O es que nLcdPrintf() no soporta "\n" ?

Muchas gracias !
Pablo.

11
VirtualHMI - Terminal HMI Remoto / VirtualHMI por TCP en vez de UDP
« : septiembre 02, 2016, 18:48:40 pm »
Hola Boris, buenas tardes !

Sería factible "migrar" el mecanismo de comunicación de VirtualHMI de UDP a TCP ?

El motivo es que a medida en que uno usa más VirtualHMI se da cuenta de que es el mejor medio de visualizar información del sistema. Es espectacular. Pero lamentablemente, al ser UDP solo puede funcionar dentro de la misma red LAN donde está el PLC. Si fuera TCP, podríamos acceder "desde afuera" como hago actualmente mediante ModBUS. Pero ModBUS es extremadamente limitado y lerdo !

Muchas gracias,
Pablo.

12
STX8081 / Consulta de sintaxis sobre uso de nLcdPrintf
« : julio 03, 2016, 13:59:50 pm »
Hola buen día,

Quisiera saber si es posible "mostrar" una variable INTEGER como si fuera una FLOAT con 1 decimal.

O sea: Yo tengo en una variable INTEGER un valor (de temperatura) = 154, pero que en realidad es 15.4 grados.
En todo el software, las temperaturas las proceso de esa manera: multiplicadas por 10. Pero al mostrarlas, debería mostrar los grados y los decimales con el punto.

La consulta es si en el momento de "mostrar" ese valor en el display o en VirtualHMI es posible "simular" como si fuera una float (sin covertirla a float), tal que se muestre "15.4".

Estuve probando con
nLcdPrintf(0,1,0,"TEMP= %03.1d, Temp)
nLcdPrintf(0,1,0,"TEMP= %02.1f, Temp/10)
y varias más, pero ninguna me anduvo.

Muchas gracias desde ya,
Pablo.

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

14
STX8081 / Recibir datos via UDP
« : octubre 15, 2015, 21:53:28 pm »
Hola Boris, disculpame que haga tantas consultas.

Estoy tratando de recibir en el PLC un paquete de datos (8 bytes) via UDP, y no lo consigo hacer funcionar.
Lo he implementado de la siguiente manera (pooleado, no por eventos):

- En powerOn, ejecuto UdpRxBufFlush() para vaciar buffer
- En un punto que se ejecuta cada 1 segundo, hago:
   if(UdpRxBufUnread() == 0)
      UdpRxDataRead(RxData,0,8,false)
      Y aqui asigno las variables a los distintos bytes de RxData
      Y ahora pongo en el display los valores de dichas variables
   endif

- Teóricamente, con esa programación, se deberían actualizar las variables SOLO cuando se reciba un paquete UDP. Por lo tanto, el display debería mostrar estáticamente el último valor de los bytes recibidos, correcto ?

- Pero no he podido recibir nunca ningún byte.

He probado a enviar paquetes UDP con un aplicativo Android (que funciona, porque el PawnUdpRx.exe Receiver me los muestra), y también probé a transmitir con el PawnUdpTx.exe. Con este último, la cosa es bastante errática, porque si presiono el botón Enviar "Hola Mundo", supuestamente sale (pero no llega). Sin embargo, si hago el envío de xx bytes, siempre obtengo el cartel de error ERROR_DISABLED. Es como que el PawnUdpTx.exe no me está funcionando...

Preguntas:
- Está bien planteado el esquema de programación arriba descripto?
- Cuál es el puerto en que el PLC "escucha UDP": 4950 verdad ??

Cualquier sugerencia muy bienvenida. Muchas gracias !
Pablo.

15
STX8081 / Ideas para VirtualHMI Android y http/https
« : julio 15, 2015, 10:13:50 am »
Hola Boris, buen día,

Te escribo este post para proponerte algunas ideas sobre los productos, luego de casi 2 años de utilizarlo, y también en función de lo que veo que está ocurriendo en el mundo en materia de IOT (Internet de las Cosas).

Sobre el VirtualHMI para Android: te cuento que lo tengo instalado en el celular, aunque todavía no lo estoy utilizando en la práctica. Pero hay algunas funcionalidades que creo que serían interesantes y no las veo contempladas:
- Cuando se hace la consulta de los datos del PLC (PLC info) está faltando un dato muy importante (o no lo encontré): la fecha y hora actual del PLC.
- De la misma manera, el VirtualHMI debería poder setear la fecha y hora del PLC, tomando la fecha y hora del celular. Esta funcionalidad es muy importante puesto que existe un drift bastante importante en la hora del PLC (varios minutos por mes), y requiere que se actualice con cierta periodicidad, porque si no los eventos comienzan a ocurrir a horas que no son las programadas.
- La posibilidad de utilizar Virtual HMI desde la WAN (o sea, desde internet). Para ello, lo que sería necesario es que en el lugar donde se configura el "Address", se pueda cargar una dirección tal como pepe.dyndns.org:10520.  Entonces "desde afuera" podrías acceder al PLC, consultar su estado, setear variables, etc.
- Y por último, sería espectacular tener la posibilidad de crear pantallas configuradas por el usuario, donde puedas configurar botones con nombres, y cargar valores en las variables.

Sobre la conectividad del PLC: Es un tema sobre el que ya hemos conversado antes, pero por cuestiones laborales he tenido que profundizar y comprender algo más. Hoy en día existen protocolos y plataformas gratuitas, donde los dispositivos IOT pueden fácilmente "subir" estados binarios o valores numéricos a una cuenta asociada, y luego esa información se disponibiliza via web para su consulta, y también para interactuar (se pueden cargar estados via web, que en la próxima consulta del PLC, dicha información llega al PLC).
Existen 2 protocolos y plataformas hoy en día muy en uso (aunque hay muchas otras):
MQTT: www.mqtt.org
ThingSpeak: www.thingspeak.com

Por ejemplo: en el siguiente link tenés una persona que hizo un simple dispositivo que con un chip wifi "sube" periodicamente a ThingSpeak los datos de temperatura y humedad que obtiene con un sensor:
www.instructables.com/id/Low-cost-WIFI-temperature-data-logger-based-on-ESP/?ALLSTEPS
Y en el siguiente link se accede a la correspondiente página ThingSpeak, en la que se consultan los datos recolectados a lo largo del tiempo:
http://thingspeak.com/channels/21857
En definitiva, si nuestros PLC pudieran acceder a estos servicios "en la nube", podríamos ir recolectando información a lo largo del tiempo, y consultarla via web en cualquier instante.

Para poder implementar esto, todo se resume a una cosa: es necesario que el PLC posea adentro el protocolo http y https. Eso es todo. Porque la actualización o envío de información a estos servicios se realiza precisamente ejecutando una URL con ciertos parámetros (que se obtienen con anterioridad al momento de crear la "cuenta"). Habría que ver si para la arquitectura de estos PLC ya existen desarrolladas las librerías http y https, e incorporarlas.

Bueno, te dejo estas inquietudes, que sé que son muuuucho trabajo. Pero es que el tema de la conectividad via internet de todos los dispositivos de control es algo imprescindible.

Dicho sea de paso: el equipo anda espectacular, no se cuelga nunca, no falla nunca !!

Saludos,
Pablo.


Páginas: [1] 2