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.
¿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.
Comentarios (15)