Recientemente he recibido una consulta de Jorge, alumno de los cursos Step 7 tradicional y TIA Portal, el cual ya implanta en su vida profesional ya que como me dice en su consulta:
Gracias a lo que he aprendido con tus cursos he conseguido desarrollar más de un proyecto de automatización en la empresa donde trabajo actualmente.
Creo que he crecido un par de centímetros al leerlo.
Es genial que lo que van aprendiendo mis alumnos de la plataforma, lo puedan ir aplicando en la industria, que es de lo que se trata.
Ni que decir tiene, que el 99% del mérito es de Jorge, por haber tomado la decisión de formarse, y de ponerse en serio con ello y meter las horas necesarias para lograrlo.
Yo solo pongo el grano de arena de enseñar, lo poco o mucho que sé, a través de los cursos que voy sacando.
Mi enhorabuena desde aquí para él.
Al tema.
Me ha pedido si podía darle otro enfoque a un problema que ya ha resuelto.
Se trata de realizar un tracking en el proceso de fabricación de napolitanas.
Las napolitanas van pasando por una banda a velocidad constante y medido con un encóder.
Todo ello está gobernado con un S7-1214 y una KTP 700.
La idea es que tras ser detectadas por un sensor, un poco más adelante (320mm), tienen que ser pulverizadas con huevo.
Sí, para los que no se acercan a la cocina ni a coger un vaso de agua (que ya sé que no eres tú), el brillo de las napolitanas, empanadas etc, se hace con huevo, no con barniz de pintar las puertas.
Contenido
¿Se puede mejorar el programa?
Jorge lo ha planteado, a mi juicio, bien: cada 10mm de avance, pongo un cero o un 1 en un bit de una doble palabra en función de si hay detectado la napolitana, y desplazo hacia la izquierda todo el doble word.
Posteriormente, leo el bit correspondiente a los 320mm que coincide con la pulverización: si está a uno, pulverizo. Si está a cero, pues no.
La pregunta que me hace es si cree que está bien así, y si se podría mejorar.
La respuesta es SÍ rotundo si la precisión es suficiente, y SÍ, se puede mejorar.
Una cosa que nos tiene que quedar claro cuando programamos es que no hay una única solución válida.
Cada programador que se enfrente a un mismo problema, encontrará seguramente una solución diferente.
Unas se parecerán más entre sí que otras, pero cada uno, lo habrá planteado de forma diferente.
Si funciona, es estable, y no tiene errores de concepto graves, el programa está bien.
Otra cosa es que sea mejorable.
Pero es que siempre lo son.
Siempre habrá una forma de mejorar en algo lo que has hecho.
¿Pero merece la pena el esfuerzo frente a la mejora?
Esa es la cuestión.
Si el programa cumple con las expectativas del cliente, es entendible por un programador extraño, y no hace cosas extravagantes, no deberías preocuparte por no haber dado con la solución óptima.
Si es una buena solución, ¡ya está!
Bien es suficiente.
O al menos, así lo veo yo.
Con el tiempo, irás mejorando, y cada vez los programas serán más completos y mejores en todos sus aspectos.
Habrás programado mucho, habrás visto como lo hacen otros, y te quedarás con las prácticas que te gusten y descartarás las que no.
Lo que se dice Reid Hoffman, cofundador de LinkedIn, es aplicable aquí: si no te avergüenza la primera versión de tu producto, lo lanzaste muy tarde.
Aquí es igual: ¡claro que me avergüenzo de la forma de programar en mis primeros proyectos!
¡Han pasado 15 años desde mi primer programa con un PLC de Siemens!
Estaría bueno que no hubiera aprendido nada desde entonces.
¿Qué otra opción se podría haber usado?
Apoyándome en su idea, le he propuesto otra forma de hacerlo.
Marcar un bit dentro de una cadena de bits como ha hecho Jorge, y mover el conjunto es una buena idea.
El problema que le encuentro es que puede que la precisión de 10mm no sea suficiente. O puede que mañana la distancia sea mayor, y 32 bits sean realmente pocos.
Por tanto, le he propuesto una solución un poco más definitiva.
Yo lo que haría es un array de bits y mover este array.
Imaginemos que tenemos 1000 bits, y cada bit, es un milímetro.
Solo haciendo esto, hemos aumentado la precisión 10 veces, y la longitud que podemos controlar por 3.
Ni que decir tiene, que si fuera necesario, podrían ser más bits, por lo que aumentaríamos la precisión y la longitud a nuestra conveniencia.
Pero supongamos que así, está bien.
La idea, como digo es la siguiente:
- Crear un array de 1000 posiciones de bit
- Poner en el bit 1 del array, el estado del sensor: 0 o 1 en función si hay napolitana o no
- Copiar el array completo a un dummy de iguales dimensiones
- Devolver las posiciones del dummy desde la 1 a la 999 a las posiciones 2 a la 1000
- Poner a cero la posición 1 a la espera del siguiente ciclo.
Para facilitar este trabajo, que es realmente sencillo en TIA Portal, lo vamos a hacer en SCL.
Tendremos en el bloque la siguiente información como entrada:
- Estado del sensor (0 o 1)
- Distancia desde el sensor hasta la dosificación
Como salida tendremos
- Dosificación activa (1) o inactiva (0)
That’s all folks!
¿Lo vemos?
Vídeo del tracking de las napolitanas
En el siguiente vídeo te muestro qué solución le propongo a Jorge:
Let’s go!
¿Qué hay de ti?
¿Como mejorarías tú el problema de Jorge? ¿Se te ocurre una forma de hacerlo diferente en TIA Portal?
Como ves, en SCL se pueden hacer cosas super interesantes en cuatro líneas de código.
Si quieres profundizar en la programación de SCL, y hacer este tipo de cosas como Jorge, recuerda que el curso de TIA Portal tiene incluido la programación desde cero de SCL.
Actualizado:
Pues me han propuesto hacerlo sin el array dummy.
Y es verdad, no es necesario. Con hacer:
#Datos[1] := #Detector_Fotocelula;
MOVE_BLK(IN:=#Datos[1],
COUNT:=999,
OUT=>#Datos[2]);
#Datos[1] := FALSE;
#Activar_Pistolas := #Datos[#Distancia_mm_Pistolas];
Es suficiente.
Con un solo array.
Por otros temas, me puse las orejeras con el dummy.
Pero no hace falta
¿Veis? Siempre hay alguien que tiene una idea mejor jeje.
Enseño a programar PLC de Siemens a través de mis cursos.
Más información sobre mi aquí
Puedes seguirme en cualquiera de las siguientes redes sociales.
14 Comentarios
Hola Iñigo, voy siguiendo tus post desde hace algún tiempo, y me parece muy interesante e instructivo.
Yo me dedico profesionalmente a la programación y ya llevo unos cuantos años haciendolo (mi primer autómata lo programé en 1986….), pero nunca se acaba de aprender.
Me ha gustado mucho este caso, no por el programa en sí, sino por el hecho de usar SCL. Creo que es el gran olvidado y simplifica muchísimo la programación.
Tu propuesta me parece mucho mas correcta que la de Jorge, por que es mas universal, pero yo aun le daría una vuelta mas….
Por que usar dos arrays?
Todo lo podemos hacer en con una sola copia usando un bucle FOR. De esa forma copiamos el Dato[i] en el Dato [i+1], siendo i = 999 al inicio y decrementando el bucle hasta 1.
Luego solo tenemos que borrar el dato[1].
Como tu dices hay muchas formas….
Gracias por difundir este mundo
Saludos
Exacto. Hay muchas formas.
No lo hago con un for-next por el número de iteraciones.
Así como en .NET no hubiera tenido dudas de hacerlo como dices en los PLC me da cosilla.
Se me antoja que 1000 sumas ocupará más recursos del PLC (en tiempo de ejecución) que el copiar el array de esa forma
Sacrificas memoria a cambio de ejecutar menos instrucciones.
Un saludo
Excellent your explanation. What type of encoders do you use for this application? Incremental or absolute? thanks
I really dont know what kind of encoder Jorge is using. I suppose incremental one.
In any case, there’s no difference for this example.
Bye!
Hola Iñigo,
En el ejemplo que pones, ¿qué ocurre si la velocidad de la cinta es tan rápida y el encoder utilizado es de una resolución tal que en un ciclo de scan, la cinta se ha desplazado varios milímetros?
¿Cual sería el límite de velocidad con respecto al tiempo de ciclo del PLC para tener «controlado» el desplazamiento de la cinta?
Saludos.
Efectivamente si es muy rápido dependes del ciclo de scan por lo que tendrás que ponerlo en un Ob suficientemente rápido como para que no se salte dicho mm.
Si no, la precisión será menor. Puede que cada índice del array represente 3 mm por decir algo
Dependerá de la aplicación y circunstancias.
La precisión está clara: e=v*t
Teniendo en cuenta que la velocidad de la cinta es constante (yo no la sé), tienes o bien que disminuir el ciclo del ob donde lo metas o aumentar el tamaño de espacio entre muestreos.
Hay veces que sopas y sorber es complicado.
Saludos.
Muchísimas gracias Íñigo!
Ha sido una solución alternativa muy sencilla y elegante a la situación que se me planteaba, sobre todo más rápida y limpia de programar que la que tenía.
He hecho el cambio en el programa y corre a las mil maravillas, vamos que da gusto, oiga!
Y como bien me decías cuando te hice la consulta, al tener más espacio para memorizar las posiciones me da pie a no complicarme la barba en futuras ampliaciones!
Y todo por el mismo precio!
(Si, no? Jajajaja)
Muchas gracias chicos,
Muchas gracias Iñigo!
Un placer Jorge!!
Me alegra que te haya sido util.
Un saludo!
Buenas noches Íñigo;
Estoy intentando replicar el programa en Step 7 tradicional y no soy capaz de acercarme al resultado final ni de lejos…
Podrías hacer un ejemplo?
Muchas gracias!
Me lo apunto!
Hola buenas tardes.
Me sumo a la petición de Jorge Nieto. Estoy intentando hacer lo mismo con un plc de la gama 300 y la cosa cambia sustancialmente, bajo mi punto de vista. La instrucción usada para mover bloques de datos en el 1200 no funciona igual que en un 300. La instrucción MOV_BLK de un S7-300 usando bits esta bastante restringida ya que hay que mover los bits empezando siempre por el bit 0 y la longitud de la copia que sea múltiplo de 8, 8 bits.
Le estoy dando varias vueltas al tema y estoy algo bloqueado. Lo último que pense es utilizar instrucciones de desplazamiento pero claro solo se pueden usar con un máximo de 32 bits y anidar varias instrucciones de desplazamiento hasta llegar a los 1000bits no es una buena opción.
Veo interesante realizar este proyecto de las Napolitanas pero con un plc de la serie 300.
Gracias y esperamos la o las soluciones.
Me pongo con ello, me pongo con ello!!!
jeje.
Este ejemplo es super fácil una vez explicado.
Crees que podría aplicarlo para saber el tamaño de una pieza?
Si mide 30 mm es buena y si mide 32mm es mala?
Eso es un problema de rapidez de detección y medida, no de programación.