Home/blog/El caso del registro rapidito
Programación PLC

El caso del registro rapidito

El caso del registro rapidito
Por Iñigo Gútiez · Publicado el

Esta semana te traigo un problema real: cómo registrar datos a altas frecuencias.

Dependiendo de la tipología del problema puede ser que se necesiten registradores industriales para ello.

Pero en caso de que no sea posible, o puedas hacerlo con un PLC.. ¿ cómo podríamos enfrentarnos al problema?

Registro de datos en TIA Portal

Una de los problemas que se tiene siempre en informática es que los dispositivos leen más rápido de lo que son capaces de escribir: discos duros, memorias flash.. cualquiera, también si queremos hacer un registro de datos en TIA Portal.

Por tanto, puede  que seamos capaces de capturar la medida cada digamos 2ms, pero no podamos almacenar dicho dato a esa frecuencia.

Entonces.. ¿cómo lo resolvemos?

Pues espero que el siguiente vídeo, te de alguna idea de cómo afrontar estos problemas.

¿Qué te ha parecido?

Espero que te haya parecido interesante el reto de cómo realizar un registro de datos en TIA Portal.

Seguramente haya más formas de abordar el problema, este solo es uno.

Cuando tenga resuelto el problema, con sus variaciones finales, lo volveremos a ver en una entrada del blog, y cómo no, lo subiré al Curso completo de TIA Portal y en Guorker.com

Sigue aprendiendo

#registro#datos
Iñigo Gútiez

Iñigo Gútiez

Enseño a programar PLC de Siemens a través de mis cursos online. Más de 1.900 alumnos en 45 países.

Ver todos mis cursos →
Comentarios (13)
Antonio
Pues me suena el tema. En mayo tuve que hacer un estudio, para una oferta, sobre lecturas 'rapiditas' de magnitudes analógicas. En teoría el PLC podía recopilar la información, pero no pude asegurar un método de almacenamiento fiable de todas las lecturas, de forma teórica. Era para un banco de pruebas que tenía que hacer millones de ciclos, según la exigencia del cliente de mi cliente. Debería poder estar semanas recogiendo información. Al final perdimos el pedido, quizás alguien pudo resolver el problema, o fue por el plazo de entrega del material Siemens.
Iñigo Gútiez
Hola Antonio, Como he comentado, no lo he probado. Lo mismo no es posible. ¿De qué frecuencias estamos hablando en tu caso? En cuanto a los plazos de Siemens, es una locura absoluta, aunque no es el único, y ni el peor en ese aspecto.
Antonio
Hola Iñigo, La máquina en cuestión realiza movimientos cíclicos cada 250mseg. Durante estos ciclos se han de efectuar el mayor número de lecturas analógicas posibles, y para cuatro magnitudes físicas diferentes relacionadas con el proceso. Con entradas analógicas convencionales es imposible, pero Siemens dispone de módulos analógicos de alta velocidad (HS). Pueden hacer varias lecturas en 1 mseg. Estos módulos los tenía previsto montar en una ET200S con modo isócrono. El módo isócrono provoca interrupciones en el OB1 cada cierto tiempo parametrizable. Tenía previsto un ciclo isócrono de 4mseg. Y hay que tener en cuenta que la rutina de servicio de la interrupción tiene que ser lo suficientemente rápida para que no se solapen las llamadas y para dejar tiempo libre en el OB1, ya que el PLC tiene que hacer otras tareas.
Antonio
Lo que comentas del doble buffer, uno que lea valores en tiempo real, mientras que el otro queda disponible para ser leido por el OPC del sistema escada, puede ser la solución, pero ¿cómo aseguramos a priori que el flujo de datos que va de las lecturas analógicas a la base de datos SQL (.csv u otro) no va a fallar?. Tenemos la comunicación OPC que tiene un tiempo de refresco que no sé muy bien como controlar. Y luego el sistema escada, corriendo en un PC con Windows y sus múltiples servicios corriendo en paralelo.
Iñigo Gútiez
No puedes asegurar que el OPC lo haga siempre bien, independientemente de lo que estés leyendo/escribiendo. Lo mismo que no puedes asegurar muchas otras cosas. A partir de la incertidumbre, tienes que analizar cómo de crítico es lo que estás haciendo. Si es muy crítico pues tendrás que hacer varias mediciones por caminos diferentes y cotejar los datos.. no sé. Quiero decir, que todo depende de qué importancia tenga. Yo parto de la base que el lector del blog estaba intentando registrarlo en la MMC metida en PLC, por lo que se desprende que no es de vida o muerte. A partir de ahí, si de esto depende el proceso o mucho dinero, pues no lo hagas con un PLC. Invierte en equipos específicos con soluciones add-hoc para ello. En lo que comentas del OPC y Windows, tal vez no sea lo más optimo. Puede que un linux pelado con python sea más rápido. Luego en la cabecera de cada DB puedes poner un índice correlativo de tal forma que al leerlo todo de golpe, no item por item, sino leer todo el DB y luego deshacer el ovillo en el PC, sepas si pierdes un envío. Tendrás que controlar el tiempo de ejecución del lado del PC para estar seguros que da tiempo de sobra y como digo, que no está perdiendo paquetes. El tema de la adquisición es otro problema en sí mismo, porque tal vez no se pueda poner en la remota y tenga que ir directamente en el PLC las tarjetas rápidas, o incluso tener que poner un PLC solo para eso. Es que todo depende de la importancia y del presupuesto, como todo en la industria. Aquí solo planteo una solución menor para un problema menor.
Josue Hombre
Antonio, ahora no sabría de cirte cual es el límite de tamaño en un DB de siemens, pero haciendo una array de 8000 registros, te da tiempo mas que suficiente en pasar los datos a un servicio (yo lo hice en c#), realizar el INSERT o UPDATE en la tabla o tablas, y tirar la bandera o FLAG para dejar "ready" el DB de nuevo y si no te da tiempo puedes realizar o usar tres o cuatro o + DB´s.
Josue ombre
Hola a todos los "plceros" y a Iñigo tb (jajaja). Bueno yo realice una aplicación en la que tenía que adquirir cada milisegundo la velocidad y posición de un objeto/os. Lo resolví por la parte de SW almacenando los datos en array de hasta 500 mil registros de size (una pasada). Cuando el objeto ya ha pasado con queries SQL insertaba los resultados en una tabla. El plc que use era el de Bechoff pero creo que con un 1516 o 17 tb funcionaría (ya que ejecutan instrucciones al nanosegundo),. saludos. nota: esto lo escribo en el minuto 2:10 del video porque soy un impaciente. Luego ya diré algo + si cabe.
Iñigo Gútiez
Gracias Josue por comentar. Esta semana la solución.. y veremos que se puede hacer ¡¡muy rapidito!!
Josue Hombre
Bueno, esto de los registros "rápidos" es una buena práctica y enseñanza para aprender a como capturar datos. Ahora a bien me viene a la cabeza cuando debes realizar el control rápido. Por ejemplo el campo electromagnético de los imanes de un acelerador de partículas, pero esto es otra historia y otro blog.
Antonio
La CPU 1515 que tenía previsto utilizar tenía 6Mb de memoria de datos. Las instrucciones en awl de formato word las ejecuta cada 36nseg. No es la CPU más potente de Siemens, pero las demás se disparaban en precio. 6Mb puede parecer mucho, pero para esta aplicación es poco. Además este PLC tenía que controlar más cosas, (PIDs, Servos). Por otra parte, no tiene nada que ver, ¿Cómo ha sido tu experiencia con Beckhoff?, no sé si fiarme de una CPU que en realidad es un PC.
Iñigo Gútiez
Hola Antonio, Esta semana publico y te adelanto que la jugada está más en el lado de leer los datos en el PLC, porque en el lado del PC, podrías registrar a 1ms de registro sin esfuerzo. Yo lo he hecho con un 1200 suponiendo conocidos los datos a registrar y sin problemas registros a 1ms. Lo vemos esta semana.
Antonio
Hola. Lo que te comentaba de este cliente: ya disponía de varios bancos de prueba hechos a medida. Un excelente hardware con muy buena instrumentación (superior a la de Siemens), pero en la cúspide de la pirámide siempre había un PC. No estaban nada contentos con los resultados obtenidos y pidieron una solución con PLC, pensando en la mayor fiabilidad de estos sistemas. Y los PLCs que yo conozco tienen problemas de almacenamiento masivo de datos. También analizamos hacer el banco de prueba con LabView, que tiene una familia de hardware potentísimo, pero al final.....siempre un PC. En este caso además está el tema de la programación. Ya nos dijeron que, dada su complejidad, necesitaríamos de un freelance para hacer el trabajo (aunque te venden que es muy sencillo al principio).
Iñigo Gútiez
Poner un PC en la cúspide de la pirámide no creo que sea el problema, sinceramente. La cuestión es que PC, cómo está configurado, respaldado.. hoy en día hay solución para casi todo. De hecho el PC puede ser solo un intermediario entre el PC y un servidor, y que simplemente, no haga otra cosa. Y dudo que un PC bien configurado y respaldado, sea un problema depende para qué. Ahora, si quieres que además del registro haga otro millón de cosas, a lo mejor empiezan por ahí los problemas, que lo desconozco. Pero vaya, que los PC tienen sus cosas, pero también muchas ventajas.