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


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

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

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

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

6
STX8081 - Familia Power I/O Board / 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.

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


8
Hola Boris, buenas tardes,

Tengo utilizadas las 8 salidas digitales... y me hace falta una más. Es para poder controlar remotamente el ON/OFF de una alarma: básicamente necesito un contacto que pueda cerrar durante un instante, simulando la presión del botón que controla el ON/OFF de la alarma.

La única solución que se me ocurrió es usar una de las salidas PWM, que las tengo aún libres. El tema es que -me parece- necesito proveer de aislación galvánica. Entiendo que NO puedo conectar las salidas PWM al sistema de alarma, porque esto implicaría que estoy vinculando electricamente la alarma con la placa base del PLC, correcto?

Entonces me parece que lo que debería hacer sería agregarle un micro relé, el cual conectaría la bobina a las salidas PWM+ y PWM-, y por otro lado alimentaría a PWMVDC y GND con alguna de las mismas tensiones que tengo en la placa, por ejemplo los +12 Volts.
Sería esa la forma correcta de conectar el relé?
El borne GND de las PWM es necesario vincularlo al GND de la zona de fuentes de tensión, o ya están vinculados internamente?

Y una última pregunta que no tiene nada que ver con lo anterior: en el diseño del PLC está previsto que en Power-ON nunca - ninguna de las salidas se encienda ni por un momento, verdad ?  O no es tan seguro ....

Muchas gracias desde ya por tu ayuda.
Pablo.

9
STX8081 - Familia Power I/O Board / Envío de emails II
« : diciembre 19, 2014, 20:46:54 pm »
Hola Boris, como estas ?

Te acordás que en Junio ya te había reportado que tenía dificultades con el envío de mails.
Bueno, nunca pude resolver el problema todavía.
Pero le he dedicado muchas, muchas horas en estos días, y he podido llegar a algunas conclusiones.

Por lo pronto, te cuento que estoy usando el SMTP de Arnet, con destino a una cuenta Gmail que levanto en mi celular.
Esto está probado y anda perfecto.

En mi opinión, hay un bug en la función SmtpSend().
Y es una falla tipo "toggle", que está presente en una ejecución, y no en la siguiente.

Fijate esta secuencia de eventos:

1- Cargo el firmware al PLC (esto hace que se resetee todo). Automáticamente me envía un email de notificación de encendido. Sale el mail y llega al instante.
2- Provoco un evento que hace salir una notificación. Sale el mail y llega al instante.
3- Provoco un evento que hace salir una notificación. Se queda aprox. 30 segundos en SmtpStatus=127 (enviando), y luego termina con SmtpStatus=-1  (falló el envío).

Ahora repito los pasos 2 y 3:
4- Provoco un evento que hace salir una notificación. Sale el mail y llega al instante.
5- Provoco un evento que hace salir una notificación. Se queda aprox. 30 segundos en SmtpStatus=127 (enviando), y luego termina con SmtpStatus=-1  (falló el envío).

Y así indefinidamente los últimos 2 eventos: el primero sale, el segundo no sale.

Si vuelvo a repetir todo desde el paso 1, se repite todo exactamente igual.

He revisado mi código mil veces, y he llegado a la conclusión de que la función SmtpSend tiene que tener un bug tipo "toggle".

Tengo en uso la última versión de firmware disponible, y también el ultimo entorno de desarrollo.

Bueno, te dejo la inquietud.

Muchas gracias desde ya,
Pablo.

10
STX8081 - Familia Power I/O Board / Sensor de temperatura
« : mayo 22, 2014, 12:45:33 pm »
Hola Boris, buenos días,

Estoy pensando en conectar un sensor de temperatura al PLC, y no me decido todavía cuál utilizar.
Estas son las opciones que he visto:
a- DS18B20: sensor tipo chip, salida serial digital 1-wire (este es el que más me gusta)
b- DHT11: sensor de temperatura y humedad salida digital serial
c- LM35: sensor tipo chip salida analógica

Hay alguno de los digitales (a,b) para el que ya se haya desarrollado el software Pawn de lectura?
El que más me gusta es el DS18B20, porque te permite poner varios sensores utilizando el mismo bit serial de lectura. Pero no estoy seguro si usando Pawn será posible hacer la lectura de dicho sensor.

Desde ya muchas gracias por tu opinión.
Saludos,
Pablo.

11
Hola Boris, qué tal ?   Tengo un par de consultas relativas a programación Pawn:

1) Las operaciones AND y OR tienen algun tipo de precedencia entre sí?
   Concretamente: La operación AND (&&) parece tener precedencia sobre la OR (||):

   if( (Condicion1) && (Condicion2) ||
       (Condicion3) && (Condicion4) ||   
       (Condicion5) && (Condicion6) ||
       (Condicion7) && (Condicion8) )
   {
      Accion
   }

   Si es como a mí me parece, entonces la expresión anterior se evaluará  "renglón por renglón", sin tener que ponerle un paréntesis a cada renglón, de la siguiente forma:

   if( ((Condicion1) && (Condicion2)) ||
       ((Condicion3) && (Condicion4)) ||   
       ((Condicion5) && (Condicion6)) ||
       ((Condicion7) && (Condicion8)) )
   {
      Accion
   }

   O sea que sería igual hacerlo de cualquiera de las dos formas. Es correcto ??


2) Estoy teniendo un problema con los temporizadores tipo Timeout, por el hecho de que todos los Timeouts "comparten" la misma función de servicio @OnTimeout(). El esquema es el siguiente:

Al comienzo del programa:

   // Inicializar los temporizadores tipo Timeout
   TimeoutInitEvent()
   
   // Lanzar el Timeout1 para enviar el primer email al cabo de 10 segundos
   Timeout1SetEvent(10)


En otra parte del programa:

   // En ciertas condiciones, prende una luz en RELAY3, temporizada con Timeout2
   if (Sensor_PIR == 1)
   {
      Forzar_RELAY3 = 1
      Timeout2SetEvent(60)
   }


Y esta es la función de servicio de todos los timeout:

@OnTimeout()
{
   // Comprobar si Timeout1 ha expirado: enviar el email de Power-On
   if(Timeout1Check() == 1)
   {
      email_accion = "ENVIAR EMAIL"
      SendMail = 1
      
      // Borrar el Timeout1 para que no se repita
      Timeout1ClrEvent()                    [1]
   }

   // Comprobar si Timeout2 ha expirado: Apagar la luz en RELAY3
   if(Timeout2Check() == 1)
   {
      Forzar_RELAY3 = 0
      
      // Borrar el Timeout2 para que no se repita
      Timeout2ClrEvent()                    [2]
   }

   return 0
}

Al principio, no tenía colocada ninguna de las 2 instrucciones [1] y [2], con lo cual se producía el siguiente efecto: al cabo del primer Timeout1, se enviaba el mail (bien), pero con cada disparo del Timeout2, además de prenderse (y apagarse) la luz en RELAY3, también
se despachaba un email (mal), debido a que Timeout1Check() quedó en "1".

Leyendo el manual, deduzco que cuando un TimeoutX finaliza, la función TimeoutXCheck() retorna "1" en forma permanente de ahí en más, hasta que se lo resetee.

Entonces agregué en ambos lugares [1] y [2] los correspondientes reseteos de los temporizadores, para que cada uno se ejecute solo una vez hasta que se lo regenere de nuevo. El problema que me hace ahora es que cuando se da la condición de prender la luz en RELAY3, ésta se prende bien, pero no se apaga más.

Es como que hay alguna interacción rara entre las funciones TimeoutXClrEvent().  No logro discernir si una influye sobre la otra, pero pareciera que Timeout1ClrEvent() borra Timeout1 y también el Timeout2, y viceversa.

Puede ser que haya un error de firmware ??

Desde ya muchas gracias y un gran saludo,
Pablo.

12
STX8081 - Familia Power I/O Board / Consultas sobre uso del ModBus
« : febrero 27, 2014, 10:24:44 am »
Hola Boris, buen día,

Activé en mi aplicación las funcionalidades de ModBus, para poder hacer la lectura/escritura de parámetros al sistema en forma remota desde el celular. Por el momento hice las pruebas con el cliente ModBus que viene en el entorno windows, y anduvo de entrada.

Tengo las siguientes consultas:

a) No encontré an la AN22 las instrucciones necesarias para "Read Coils". Sí encontré las necesarias para leer GPCoils. De todas formas, pude convertir el estado de los RELAYx a variables, y leerlos a través de GPCoils. Pero me parece que está faltando la función que lee las Coils directamente ( direcciones 1 a 8 ). O yo estoy entendiendo mal...?

b) Como el objetivo buscado era el monitoreo y control via android desde el celular, instelé la aplicación sugerida, Modbus-Droid. La verdad es que es malísima (por algo es gratis). Solo permite leer las secuencias de registros, pero no tiene la posibilidad de asignarles una etiqueta a cada uno, no permite crear una pantalla con los registros que a uno le interesa, etc. Y lo peor de todo es que en la configuración solo se le puede asignar un número de IP. Pero cuando el IP es dinámico (como en mi caso), lo que yo necesito es poder cargar una dirección tal como: micasa.dyndns.org:puerto. Y eso no se puede hacer.
En síntesis: conocés algún otro cliente Android ModBus mejor?  Has experimentado algo desde el celular?
El que yo vi en Play Store y aparentemente es mejor es el "ModBus Master", pero es pago, y no hay forma de probarlo antes, para ver si funciona:
<https://play.google.com/store/apps/details?id=se.inux.android.mbmaster>

Saludos y muchas gracias desde ya,
Pablo.

13
STX8081 - Familia Power I/O Board / Envío de emails
« : febrero 02, 2014, 18:17:27 pm »
Hola Boris, buenas tardes,

Antes que nada te cuento que el PLC que adquirí hace unos 45 días atrás funciona espectacular !  Es realmente una maravilla. Toda la programación la estoy haciendo en Pawn, ya que me resultó más agil que hacerla en el diagrama ladder. Aquí van las consultas que quisiera hacerte:

El único problema se me ha planteado ahora con las funcionalidades del envío de emails, que no las puedo hacer funcionar.
Primero hice un programa con 2 líneas: el SmtpInit, y SmtpSend, y no logré que nunca un email salga.
Probé con distintas cuentas: Yahoo, Arnet, y finalmente abrí una cuenta en AOL como se sugiere en el manual, pero siempre obtengo errores -4 (Error en proceso de Auth) o bien -11 (Error al enviar “.” para finalizar mensaje).
A continuación, por las dudas, utilicé el Ejemplo2.zip, al que le ajusté los parámetros de mis cuentas de email ... y tampoco logré que los emails salgan. Alguna sugerencia?  Has probado recientemente si funciona con Yahoo por ejemplo (me parece que Yahoo cambió sus mecanismos de autenticación recientemente, por eso probé con AOL, pero tampoco me funcionó).

Otra consultita: cómo sabés cuál es el tamaño del programa que uno ha implementado, y cuánta memoria de programa le queda libre al PLC?

Muchas gracias desde ya y nuevamente felicitaciones por tan buen producto.
Pablo.

Páginas: [1]