Cómo realizar un tracking de datos en Step7

Esta semana vamos a ver como realizar un tracking de datos en step7 usando dos funciones integradas: SFC20 y SFC21.

El tracking de datos no va a ser nada más que arrastrar a lo largo de las posiciones de nuestra línea la información del objeto que está circulando por ella, desde la receta (o pauta) que sea, recorrido que ha de llevar, y cualquier característica o información que sea deseable que arrastre desde el principio hasta el final (o que se vaya añadiendo por el camino).

Una cosa importante que has de tener en cuenta a la hora de realizar tu automatización es el grado de importancia que va a tener el arrastrar esta información.

Digo esto porque para realizar una buena trazabilidad y saber qué información lleva qué pieza, has de saber en todo momento donde está qué, de tal forma que no haya posibilidad de error a la hora de arrastrar la información.

Normalmente esto lo vas a realizar mediante la detección y transporte de las piezas, posicionamiento por encóder etc. Pero de alguna forma has de saber cómo detectar o calcular dónde esta cada pieza de tal forma que no cometas errores a la hora de arrastrar la información.[divider]

Tracking de datos en Step7

A la hora de realizar nuestra trazabilidad, puede ser que sólo necesitemos un bit de estado (lleno/vacío, bueno/malo). En tal caso puede que te sirva las operaciones de desplazamiento como ya hemos visto con anterioridad.

Pero lo que vamos a descubrir juntos hoy es como arrastrar una cantidad ingente de información (ingente, es relativo, pero más de un byte vaya).

Para ello vamos a necesitar conocer las siguientes herramientas:

• SFC20: Block Move con el que vamos a poder copiar bloques completos de información.
• SFC21: Fill. Con el que podremos rellenar zonas de memoria con la información que queramos (por ejemplo ceros).
• UDT: ¿te acuerdas de esta entrada? Esta vez le vamos a dar un uso práctico.

El «conceto»

Como decía el gran Manquiñas en Air Bag , lo importante es el conceto.

¿Qué es lo que vamos a hacer?

Pues básicamente, pasar la información de una posición a la siguiente y borraremos la que tenemos en la estación anterior.

Bien, vale… ¿pero cómo?

Vamos a usar las funciones SFC20 y 21. La primera, SFC20 nos va a permitir copiar volúmenes de datos grandes de un origen A a un destino B. Por ejemplo, podemos copiar el contenido completo de un DB a otro DB ¿entiendes por dónde voy?

Y el SFC21 ¿para qué lo quieres?

Una vez que hayamos copiado la información, lo suyo es que borremos la información de la estación origen. Para ello usaremos la función llenar SFC21 «Fill». Tomaremos una zona de memoria que tenga todo ceros y con ella rellenaremos el DB origen (o el área que sea).

 Y claro, vamos a usar DB..

Correcto. Si el volumen de datos es importante y/o tenemos diferentes estaciones, tenemos varias opciones:

• Usar un único DB de tracking.
• Usar un DB de tracking por posición.

Si usamos un único DB de tracking crearemos típicamente un array de posiciones (por ejemplo con números de transpotador). Cada array contendrá la información de cada uno de los transportadores ( o lo que sea) y pasaremos los datos de una zona a la siguiente.

En el segundo caso, cada transportador tendrá su propio DB pasando la información de un DB a otro.

 ¿Cuál es mejor?

Pues ni uno ni el otro, ni todo lo contrario. Dependerá de cada caso.

Contener todo en un DB tiene una gran ventaja, que es mucho más compacto y fácil de saber dónde encontrar toda la información ya que sólo hay un sitio que la contenga.

Pero tiene un gran pero… que más te vale que hayas hecho bien los deberes y tengas claro qué información vas a intercambiar y que hayas dejado suficiente espacio libre de no tenerlo muy claro.

¿Por qué dices eso?

Porque si después de haber estado muchas horas trabajando sobre el proyecto llegan nuevos requerimientos y has de aumentar el volumen en el tracking y no has dejado espacio suficiente te vas a cag.. en lo más barrido.

Tendrás toda la información del tracking difuminada y usada por medio programa y a la hora de elegir los datos, ya no coincidirán los punteros porque tienes que añadir nuevos datos  y por tanto, has de cambiar los índices de las lecturas y/o escrituras.

Por ejemplo. Imagina que has reservado exclusivamente el código de la pieza que tiene 8 caracteres en un string (10 bytes en total) de tal forma que la posición 1 empieza en la 0.0 la dos en la 10.0 la tres en la 20.0 etcétera…

Has programado, leído el código donde has querido o lo que sea que hayas hecho a lo largo del programa… y ahora no sólamente has de arrastrar ese código sino también el número de pieza desde el inicio de turno… ¿entiendes el tamaño melocotón que van a coger las lágrimas que van a recorrer tus mejillas?

Ahora, suponiendo que el número de pieza sea un entero, el índice del código de la pieza dos no empieza en el 10.0 sino en el 12.0, la tres en la 24.0… ¿entiendes la broma de mal gusto?

¿Solución?

Pues dejar más espacio o si es una cantidad importante de datos (o porque el tracking no sea muy largo) hacer para cada posición, un DB.

Si has dejado suficiente espacio, fin del problema. Acomodas los nuevos valores a transferir y listo.

Ojo, porque cuando hagas el tracking, arrastra la información completa, sea espacio libre o no. Es decir, si para cada posición tienes 20  bytes aunque sólo uses 12, arrastra los 20. Esto hará que las futuras ampliaciones sean triviales ya que se estará arrastrando todo siempre, lo usado y el espacio libre. Es obvio, pero mejor dejarlo claro.

Por otro lado, como te comento, puedes asignar un DB para cada posición.

¿Qué ventaja tiene usar un DB por posición?

Pues que básicamente el ampliar los DB es simplemente añadir la información nueva al final y volver a cargar los DB en caso de que hayas superado la longitud máxima.
También te recomiendo que aún usando los DB así, dejes espacio libre al final. Esto evitará que en una ampliación tengas que cambiar los valores de cuántos bytes arrastras. Un 20%-25% puede estar bien (más o menos dependiendo del tamaño que coja y previsión de necesidades). Así por ejemplo si mis datos son 80 bytes, pues sin duda yo dejaría libre hasta completar los 100 bytes.

Otro motivo por el que usar los DB separados puede ser porque sean pocas posiciones de tracking con un volumen algo elevado. Digamos que porque cada posición tiene entidad suficiente como para tener sus propios DB.

Pues siempre uso DB separados y ya está…

Pues puede ser un gran error… Porque si tu línea va a tener muchas estaciones y vas a arrastrar poca información, generas mucho ruido en el proyecto. Imagina que tienes 30 estaciones para arrastrar poco más que un par de bytes. Siempre será mejor crear un DB más grande, dejando 20 bytes para cada posición (por decir algo) que no generar un DB para cada uno.

Vamos, que uses la pelota que tienes encima de los hombros antes de decidir uno u otro.[divider]

 Vayamos con un ejemplo práctico

Como casi siempre, vamos a poner todo esto en práctica mediante un ejemplo. En este caso vamos a hacer algo un tanto abstracto, pero que lo que va a querer simular es una línea con 5 posiciones.

En el ejemplo vamos a tener dos botones.

• Uno para cargar los nuevos datos
• Un botón para generar el tracking

Lógicamente en la vida real no se produce como en el ejemplo, pero con lo que quiero que te quedes es con cómo se mueve la información de un sitio a otro.

En una automatización de verdad, habrá condiciones para pasar la información de un lado a otro y no se hará completamente en cascada.

Para darle una pequeña gracia lo que vamos a hacer es que la información se arrastre siempre que la siguiente posición esté libre, pudiendo moverse siempre la última para dar por finalizado sumando uno a un contador de piezas buenas.

Además le vamos a poner una salida intermedia en la cual, si la información dice que la pieza es mala, salga lateralmente y desaparezca del tracking sumando una al contador de piezas malas.

Como siempre, es más fácil de ver que de explicar con palabras, así que te dejo con el siguiente vídeo donde puedes ver el pequeño ejemplo.

 

 ¿Te ha sido útil esta entrada?

Ahora te toca a ti, te invito a que participes del blog comentando si tienes una forma diferente de hacer los backups, y que si te ha parecido interesante des publiciad a la entrada mediante tus redes sociales. Te lo agradezco de antemano enormemente.

También comentarte que este capítulo junto con otros muchos forman parte del libro Cómo programar Step 7 y no morir en el intento. En este libro podrás encontrar muchos ejemplos además de los proyectos que se describen en los vídeos.