Siempre que comenzamos a programar, tenemos la incertidumbre de si la forma en la que trabajamos es la más adecuada o no. En la entrada que recupero del ostracismo (y que añado alguna cosa nueva) te voy a contar unas pequeñas pautas que puedes seguir, aunque estas buenas prácticas de programación en S7 no son palabra de Dios, y por supuesto, pueden ser discutibles y/o matizables.
Son unas recomendaciones que te doy, y puede que a lo mejor te encajen en tu forma de estructurar un proyecto o al menos que te sirva para reflexionar sobre cómo has de afrontar los primeros proyectos que desarrolles.
Contenido
- 1 Tengo una hoja en blanco ¿Por dónde empiezo para realizar buenas prácticas de programación en S7?
- 2 Vale, ya tengo más o menos claro qué hace y qué necesito… ¿y ahora?
- 3 Asigna rangos a las I/O
- 4 Asigna nombres a las cosas
- 5 No seas un talibán de ningún lenguaje. Usa todos a tu antojo, pero con orden.
- 6 Alarmas
- 7 Pantallas del HMI
- 8 ¿Cuáles son tus buenas prácticas?
- 9 ¿Estás inmerso en un nuevo proyecto?
Tengo una hoja en blanco ¿Por dónde empiezo para realizar buenas prácticas de programación en S7?
Lo primero que tienes que hacer cuando comienzas un proyecto es respirar hondo y no agobiarte. Te puede pasar que si miras el proyecto en su conjunto pueda ser un tanto mareante al principio… y lo es. Supongo que todos hemos pasado por ello.
Lo bueno que tiene la automatización seguramente junto con otro tipo de programas y software es que es muy modulable ya que la instalación está siempre dividida en máquinas, y estas a su vez en sub-máquinas y estas finalmente en un conjunto de señales y actuadores. Por tanto, podemos abstraernos a la hora de programar del resto de la máquina y centrarnos en muchos casos solamente en una pequeña parte de la máquina.
Pero ojo, no estoy diciendo que comiences a programar con una pequeña porción de la máquina sin pensar en el resto. Estoy diciendo que el problema global que es que la dichosa instalación funcione, la vas a poder cortar en cachitos y que cada cachito por separado no es tan fiero.
Por tanto lo primero que tienes que pensar es en qué máquinas se divide tu instalación y cómo interactuan entre ellas. Lo que deberías hacer en un primer estadio del proyecto es:
- Comprender muy bien la instalación. Qué debe hacer (y qué no).
- Hacer un listado con las posibles divisiones de la instalación o máquina, como máquinas( o submáquinas) independientes.
- De cada máquina y submáquina qué detectores vas a necesitar y qué actuadores.
Una vez comprendas que es lo que debe hacer, podrás dividir la instalación (o máquina) en trozos más pequeños e independientes. Esto nos va a ser útil a la hora de definir los bloques en los que se va a dividir nuestro proyecto.
Por otro lado, la enumeración parcial de cada señal y cada actuador, nos va a dar una idea global del volumen de entradas y salidas del proyecto. Esto te va a ayudar a su vez a valorar entre otras cosas si merece la pena centralizar todo en el armario eléctrico, o si va a ser mejor colocar por la instalación diferentes armarios remotos, por ejemplo.[divider]
Vale, ya tengo más o menos claro qué hace y qué necesito… ¿y ahora?
Ya tienes el qué, vayamos ahora en el cómo:
- Estructura tus bloques
- Asigna rangos de I/O
- Da nombres a las cosas
- Un buen listado de alarmas
- Bocetos de las pantallas del HMI
Cuando digo que estructures los bloques quiero decir que des rangos a tus FC, FB y DB. Imaginate que tienes 3 zonas bien diferenciadas de la máquina, pues una forma de estructurar tus bloques podría ser:
- Del 0 al 99 para bloques genéricos
- Del 100 al 199 a la zona 1
- Del 200 al 299 a la zona 2
- Del 300 al 399 a la zona 3
Así, por poner un ejemplo: imagina que dentro de las zona 1 tienes un transportador. Pues puedes hacer:
- FC110 «Transportador 1» para la lógica booleana que maneje todo lo que haya sobre ese transportador, sus marchas y paros, manual, automático etc.
- FB110 «Motor Transportador 1» Para el manejo del variador de dicho transportador, la gestión de las consignas que puede que le mandes por profibus, alarmas etc.
- DB110 «DB Motor Transportador 1», pues como DB de instancia del FB110
Esto como digo es un ejemplo. La idea que quiero que pienses es que todo lo referente al transportador 1, estará asociado con el concepto numérico «110» como cosa global.
Si tienes un segundo transportador, dentro de la zona 1, pues le asignas el 120.
¿Por qué no el 111?
Dependerá de cada proyecto, pero siempre que puedas, y para mi gusto, separa los bloques. Imagina que encima del transportador 1 tienes un par actuadores neumático que hacen algo, lo que sea. Yo le daría en ese caso:
- FC 111 «Actuador #1 Transp. 1»
- FC 112 «Actuador #2 Transp. 1»
Todo esto suponiendo que tengan suficiente entidad como para que tengan su propio FC y no puedan ser agrupados en un único FC 111 «Actuadores Trans. 1». Espero que cojas el concepto.
¿Qué nos va a permitir esto?
Pues básicamente, un poco de orden. Porque como te acostumbres a poner todos los bloques seguidos, va a ser un caos. Por el simple hecho es que la vida del proyecto es larga, y seguro que vas a tener que insertar nuevos actuadores sobre partes de las máquinas. Como hayas puesto:
- FC 110 Transportador 1
- FC 111 Transportador 2
- FC 112 Transportador 3
- FC 113 Transportador 4
Ahora imagina que los actuadores de los que hablamos, no estaban contemplados en el proyecto inicialmente, y ahora hay que añadirlos… tú lo has dicho, vaya mierd..
Además de eso, en nuestro ejemplo, puede que unos transportadores lleven unos actuadores tipo A, otros transportadores no lleven, otros sean tipo B.. etc.
En cambio, si divides a espaciado fijo, sabes que todo lo que hay en los FC 11x pertenecen a la misma parte de la máquina, el transportador 1 en nuestro caso. Creo que la idea queda suficientemente clara.[divider]
Asigna rangos a las I/O
Al igual que has hecho con los bloques, la idea sería la misma para las entradas y salidas. Intenta dar rangos a las zonas de las máquinas. De tal forma y siguiendo con nuestro ejemplo, imagina que has decidido poner 3 remotas, una por cada zona de tu instalación.
Asigna rangos a las I/O:
- EB100 – EB199 para la zona 1
- EB200 -EB299 para la zona 2
- EB300 – EB399 para la zona 3
¿Qué ganamos con ello?
Como antes, claridad y orden. Pero algo más… orden de cara a futuro.
Si vas a montar 3 periferias remotas y asignas las direcciones de I/O según te las asigna Step7 de forma automática, vas a tener todas las entradas y salidas seguidas como un paso doble Hasta ahí no habría mucho problema más allá de que como digo, queda más limpio saber que si te digo E 212.0 automáticamente sabes que te estoy hablando de una entrada de la zona 2 sin mirar absolutamente nada.
Pero no solamente eso. En un futuro, puede que tengas que ampliar una de las periferias con una nueva tarjeta… pues como no hayas pensado en espaciarlas, no sólamente no tendrás coherencia entre la numeración entre zonas, sino que dentro del mismo rack tendrás numeraciones altas y bajas ya que al añadir una nueva tarjeta, tendrás forzosamente que asignar un número más alto que el último que Step7 le asignó a la zona 3… que si es esta zona, no pasa nada, pero si es la zona 1 queda horrible.
¿Pero habría algún problema por ello?
Ninguno, pero hombre, ya que estamos, además de que funcione, que parezca que le hemos dedicado 10 minutos a pensar cómo asignar las entradas y salidas ¿no?
¿Qué pasa con las marcas, temporizadores etc?
Análogamente, asigna rangos para el resto de elementos. Por ejemplo: Si estas en el tranportador 1, que es el FC 110, pues asigna las marcas 110.0 – 119.7 para dicho transportador, si con ello te va a ser suficiente.
Puedes dar un rango de marcas para las palabras, otro para las dobles palabras… etc. Dale al coco y haz tu propio esquema.
Asigna nombres a las cosas
Y donde digo cosas, me refiero a FC, FB, DB, Entradas, salidas, marcas, temporizadores…
Si no pones nombre a las marcas e I/O va a ser muy complicado el mantener el programa, por no decir imposible. Es una locura encontrarte programas que no están comentados… pero nada comentados. Es para echarse a llorar cuando el programa es complejo. No hay forma de seguirlo muchas veces con comentarios, como para seguirlo sin una triste indicación de qué hace qué.
Lleva mucho tiempo, y no siempre es fácil mantener la tensión de comentar todo, pero hay que intentar que todo esté razonablemente comentado.
Una forma que yo suelo usar ( y aquí cada maestrillo tiene su librillo) es la siguiente:
- Para las entradas y salidas, como nombre simbólico suelo poner el nombre del elemento de campo que es, por ejemplo el «25B3» y como comentario qué es con palabras. Puedes poner el IME completo por ejemplo «+ZonaA-25B3» mientras que te entre en el campo de descripcion de la variable.
- Las marcas/temporizadores etc auxiliares las marco con su propia dirección «M17.5» y en la descripción pongo «auxiliar». Así indico que la marca es necesaria como un auxiliar pero que no sale de ese bloque y que no está usada de forma global en el programa.
Buenas prácticas de programación en S7
Ya hemos visto las cosas que tenemos que tener en cuenta a la hora de organizar el programa, pero aún no hemos programado ni un segmento. Ahora van las propiamente dichas de qué hábitos debes adquirir.
Apunta esta, grábala en letras de oro o haz lo que estimes oportuno pero:
[quote]Sólo da valor a una variable/salida en un sitio[/quote]
Hacer un =A1.0 en dos sitios diferentes del programa es de cárcel. Jamás lo hagas. Si tienes que declarar 8 marcas y hacer la lógica que sea, la haces, pero nunca, nunca nunca nunca nunca, asignes dos veces una salida. Y quien dice una salida, dice una marca. ¿Por qué?
Porque siempre tomará el valor de la última vez que le diste valor. Si cambias el orden de ejecución, cambiará la forma de ejecutarse.
Imagina que has puesto en una parte del programa (FC1) un
U M0.0
S A1.0
Y en otro bloque (FC2)
U M1.0
S A 1.0
Y en otro, pues un reset (FC3)
U M2.0
R A1.0
Vale. ¿Cuánto valdrá A 1.0? Pues mas menos npi. Dependerá de cómo estén las marcas que los hacen un Set o Reset y en qué orden han sido llamados los bloques… y eso, siempre y cuando dentro de un año, no se te ocurra que en el bloque FC2, en vez de un set, es mejor un
U M1.0
= A1.o
Que entonces la fiesta ya es completa.
Si hay varias condiciones que activan y desactivan la A1.0, las asignas una marca, y luego agrupas todas para hacer un set, y por otro lado las que tenga que hacer un reset, o un igual o lo que haya que hacer… pero UNA ÚNICA ASIGNACIÓN ¿Está claro? Repite conmigo:
[quote]Sólo asignaré una salida en un sitio[/quote]
Asigna una marca de ciclo al principio del proyecto
Como ya te conté anteriormente, es bastante práctico seleccionar la marca de ciclo al principio del proyecto de cara a que si en la puesta en marcha, o con la máquina ya funcionando te hace falta un tren de pulsos, dispongas de una forma sencilla de estos, sin tener que volver a compilar el proyecto y mandárselo al PLC pasando la CPU a stop, cosa que siempre no es posible en el momento que lo quieres hacer.
Crear un Always_On y un Always_Off
Esto más que una buena práctica, es un truquillo: si tienes una marca que esté siempre a cero y otra que esté siempre a uno, te ayudará a la hora de hacer pruebas, y desarrollar el programa en la línea ya que podrás hacer un bypass fácilmente a alguna condición, evitar que un segmento no se ejecute etc.
También puedes coger el byte entero lleno de ceros, que te servirá para borrar datos usando el Sfc21 FILL. Para ello, simplemente tendrás que hacer un
L 0
T Mb0
O M1.0
ON M1.0
= M1.0
De tal forma que el byte 0 contendrás siempre ceros y el bit 1.0 estará siempre a 1. Tonto, pero útil.
Deja espacio, sé generoso con el que venga detrás…
Que muy probablemente puedas ser tú. Si vas a crear un DB donde almacenar datos para registro o intercambio con otros PLC por ejemplo, deja espacio libre para que en una eventual ampliación no haya que replantear nada ni hacer grandes modificaciones, sino que con tomar parte del espacio que este libre, sea suficiente.
Lo mismo digo a la hora de asignar las entradas y las salidas, deja espacio para posibles nuevos actuadores o señales, de tal forma que una futura ampliación no provoque la ampliación de un bastidor porque en su día las entradas estaban usadas. Todo cuesta dinero, pero es necesario hacer ese esfuerzo porque a la larga, es más barato si luego no hay que echar nuevas mangueras, instalar más tarjetas etc.[divider]
No seas un talibán de ningún lenguaje. Usa todos a tu antojo, pero con orden.
Una de las entradas que más consultas recibe el blog es la de qué lenguaje elegir a la a hora de programar en Step 7.
Lo que no saben, es que no hay respuesta absoluta para esa pregunta… pues depende.
Acostúmbrate a usar todos los que quieras, cuando quieras. Personalmente no mezclaría en un bloque FUP con KOP, aunque sí cualquiera de ellos con AWL. No los mezclaría porque muchas veces no son traducibles entre sí, y al pasar de uno al otro, puede que el que dejas no sea traducible y se quede en un AWL difícil de digerir así de repente, obligándote a pasar de uno al otro para seguir fácilmente el programa.
Pero por lo demás, cambia cuando quieras, prueba y disfruta de la variedad que ofrece Siemens en ese sentido.[divider]
Alarmas
Una de las cosas más importantes en una buena automatización es la colección de alarmas. Puede parecer trivial, pero para nada lo es. Crear un listado de alarmas relevantes, que aporten facilmente qué es lo que está fallando y sobre todo no dejarte nada en el tintero, es casi imposible.
Pero puedes seguir una serie de pautas:
- Puedes usar marcas o un DB sólo para alarmas. A mi juicio mejor usar un DB con BOOL ya que las verás todas juntas además de poder comentar cada una dando mayor información a simple vista.
- Enumerar los pasos automáticos y coloca timeouts con los que saber en qué paso se ha parado la línea.
- Lista los finales de carrera de seguridad, presostatos, temperaturas etc y decide qué valores son extremos para que salte una alarma.
- Establece dos grupos: los que pararán la máquina (si las hay) y las que simplemente serán indicativas de un malfuncionamiento. Reserva memoria en el DB para ambos grupos de cara a su ampliación.
- Piensa cada texto que va a acompañar a cada alarma. Intenta pensar que cuando salte, lo va a leer alguien que no tiene ni idea de cómo esta programado el PLC. Sé todo lo user friendly que puedas.
Pantallas del HMI
Decía Albert Einstein algo así como «si no puedo dibujarlo, es que no lo entiendo». Además de una cita genial, me da pie a comentarte una cosa fundamental y que por ello lo he dejado para el final.
A ver si me queda lo más claro posible:
- No programas para ti
- Las normas son para cumplirlas
- Intenta tener un poco de gusto
- ¡No programas para ti!
No. No es un error. He puesto que ¡No programas para ti! dos veces. Con esta tres.
¿Qué quiero decir con esto?
Pues eso, que el tipo que va a usar tu máquina probablemente no haya visto un programa en su vida (más que probable) y sinceramente, ni es relevante, ni le importa.
Lo importante es lo que puede ver y hacer desde la pantalla.
- Mandos claros
- Información clara y completa, pero no excesiva
- Fácil de entender la navegación entre pantallas.
- Estéticamente agradable a la vista (dentro de lo que se pueda)
Piensa que la persona que va a manejar la máquina, en general un operario de producción, no le importa ni cuantos motores tiene tu máquina, ni detectores, ni las filigranas que hayas hecho en el código. Hablando groseramente… se la pela.
Lo que le importa, sin duda, es lo que puede hacer desde su pantalla, desde sus mandos y qué información devuelve para que él esté informado.
Por eso es importante que los mandos sean claros, que no haya que leerse mil páginas de manual para entender cómo funciona la máquina y que sea lo más intuitiva posible.
La navegación entre páginas ha de ser lo más coherente posible: los botones y el comportamiento de estos sean previsibles. Es decir, que si los botones de las páginas están abajo, estén siempre abajo, del mismo tamaño, si son con dibujos sean todos coherentes etc.
Por otra parte, las normas especialemente a los colores y modos de trabajo, han de cumplirse. Es pecado capital poner un botón verde como reset o rojo como cycle start.
Finalmente, un cojo-programa con unas pantallas poco cuidadas parecerá que está cogido con pinzas. Ten un poco de gusto, que tampoco cuesta tanto.[divider]
¿Cuáles son tus buenas prácticas?
Y de momento, creo que son todos los consejos de la abuela que me han pasado por la cabeza. Puede que en alguna o muchas discrepes o tengas mejores formas de plantearlo. Si quieres compartirlo con el resto, comentalo y con gusto puedo ir actualizando la entrada con nuevas aportaciones.[divider]
¿Estás inmerso en un nuevo proyecto?
Si por otro lado estás planteándote comprar material de Siemens (u otros fabricantes) para tu próximo proyecto, no dejes de usar el botón arriba a la derecha para solicitar un presupuesto del material. Te vas a sorprender de los precios que puedo conseguirte a través de masvoltaje.com. Te invito a que hagas la prueba y luego me cuentas.
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.
29 Comentarios
Muy bueno, la verdad es que nunca me habia parado en estructurar por numeros!!,
Es resumido, ordenado e intuïtivo
Muy bueno la verdad,
Hola Jose,
Me alegra que te haya parecido interesante. La verdad es que luego ayuda bastante si tienes muchos bloques a encontrar las cosas haber «acotado» las parcelas y saber cada cosas dónde puede estar.
¿Tú cómo lo sueles hacer?
Un saludo,
Hola Iñigo,
Ante todo gracias por la respuesta in info_, y la verdad es que ya te seguía en tu blog, Muy interesante cómo lo explicas, aunque a ráfagas me haya perdido en algunas explicaciones de AWL, estoy empezando, no sé nada comparado con lo que he llegado a ver, me gusta la programación KOP con FC i DB, ya sabes. Me gustaría hacerte saber dudas que tengo en algunos ejemplos tuyos,no todos pero bueno, los enlaces de STEP7. Te las puedo hacer por aqui?
Jose,
Por supuesto que las dudas que tengas de lo descrito en el blog las puedes presentar, faltaría más. Pero cada duda que tengas, en la entrada pertinente, para seguirlo adecuadamente.
Por coherencia y que todo el mundo sepa de que se está hablando y porque seguramente las dudas que puedas tener tú las tendrá más gente.
Si es algo fuera de la entrada, en la sección de ayuda tienes las vías de contacto para que puedas mandarme dudas, sugerencias o lo que creas oportuno.
Un saludo
Hola Íñigo, no fallas, espero que se hayan solucionado los problemas con tu máquina. Con respecto a la entrada voy a leerla, la he visto por encima, y me parece más que interesante. Por otra parte, estoy peleándome unos días con tu ejemplo del programador horario, no obstante, cuando pueda «sacarle las tripas» comento en la entrada correspondiente. Un saludo y gracias por la aportación de hoy, ya que, según nos avisaste, no la esperaba.
Jeje, lo que no hubiera podido hacer es un nuevo vídeo con un ejemplo…
Finalmente he acabado instalando Ubuntu en el portátil y con una máquina virtual pondré las aplicaciones de Siemens. No sé que hago, pero siempre acabo volviendo a Linux. Y luego vuelvo a Windows… para acabar volviendo a Linux.
¿Tanto les costará a los de Redmond hacer algo que simplemente funcione?
Para la semana que viene espero tener todo Ok para poder hacer un nuevo ejemplo y vídeo.
Hola, soy profesor de FP de automatismos, se agradece mucho el trabajo que has hecho. Yo también utilizo Ubuntu + virtual box. Pero ultimament he encontrado un par de problemas.
El ultimo USB-MPI original de siemens(A2) no se puede instalar en el virtualbox porque parece ser que no cumple el standard USB, y el TIA portal no deja acceder a programar por los antiguos puertos serie (COM1….), que tenia virtualizados en el antiguo S7
Muy bueno lo de no poner dos salidas en diferentes lugares del programa, todos los días me toca repetirlo en clase.
Yo para empezar un programa y tener las ideas claras me hago unos cuantos GRAFCET, (principal(main), ciclo continuo, paso a paso,….alarmas)
Que opinas de los GRAFCET’s GEMMAS, Petris, etc…?
Particularmente no me gusta Grafcet. De hecho no o uso mas que en las instalaciones que ya están programadas así.
Prefiero programar mi propio grafcet que en general no es muy complicado y a mi juicio más fácil de mantener y seguir. Pero eso ya es discutible.
Esto me da pie a un día hacer una entrada.
Saludos
Buenos días Iñigo.
Me ah gustado mucho tu explicación. Yo estoy aprendidnedo desde cero a programar y me ha ayudado mucho.
Me gustaría hacerte una pregunta: ¿Puedes poner en el blog algún ejemple de uso de Marcas para evitar asignar dos veces la misma salida?
Tambiénquerría saber si también tienes algo de documentación u otro blog del WinCC.
Muchas gracias.
Hola Jose,
Me apunto lo del ejemplo de asignación.
En cuanto al WinCC no tengo documentación, blog o similar, pero si me dices en qué estás más interesado, si conozco el tema igual lo podemos tratar.
En cualquier caso, muchas gracias por comentar.
Hola Iñigo. Acabo de conocer tu pagina y ha coincidido con que me tengo que poner al dia sobre los temas de S7 y 5, a si que ya tienes a otro seguidor mas. Estoy ahora trabajando con un ingeniero como tu y se ve la diferencia vuestra sobre nosotros los que hemos crecido cuando empezo esto y teniendo que aprender en plan autodidacta o con cursillos, creando un batiburrillo cerebral de primera que alli sigue. Solo he leido lo de «Buenas practicas de programacion» y me a parecido bueno, didactico he interesante. Como te he dicho ahora hay que compilarlo todo en la cabaeza y eso para mi cuesta. Pero estas palabras son para agradecerte lo que haces y tu esfuerzo por enseñarnos. Muchas gracias y sigue con ello. Yo personalmente desde ya te estoy muy agrdecido. Agur.
Muchas gracias Fernando.
Cualquier duda que te pueda solucionar (si puedo), ya sabes.
Un saludo
Hola Íñigo,
Muy interesante esta entrada y sobre todo útil. Me voy a convertir en seguidor de tu blog.
Saludos.
Hola Jaime,
¡Muchas gracias por el seguimiento!
Aquí te espero entonces todas las semanas. No faltes que paso lista.
Un saludo y gracias de nuevo
Me parece muy interesante, tu aporte para poder programar en s7, ya que step 7 tiene muchas variantes, yo soy fiel seguidor de tu blog. Cuando puedas una explicación, sobre MMC y eprom como usar etc,
Saludos
Hola Euclides,
Muchas gracias.
Tomo nota, aunque no hay mucho que contar sobre ello, pero algo apuntaremos.
Un saludo
Muchas gracias, Iñigo por este blog.
Sabia algo de plc de cuando estudie, pero estoy aprendiendo Step7 de forma autodidacta. Me ha encantado esta entrada de consejos practicos, que no viene en los manuales, y donde se ven los consejos de un profesional a la hora de la practica, que finalmente es lo que vale.
Lo de la asignacion de una salida en dos sitios es algo que me ha estado volviendo loco hace unos dias, si te hubiera descubierto antes me lo habria ahorrado. Me uno a la peticion de un ejemplo con marcas.
Tener una lista de estas cosas, es decir, como plantearia yo un proyecto desde cero, y las cosas basicas para no «meter la pata» me parecen fundamentales.
Encantado de conocerte, y tienes un seguidor mas en Salamanca. ( Y una caña pagada si vienes)
Hola Torkua,
Bueno, todo lo que dices es un poco la filosofía del blog. Por un lado transmitir unos conocimientos digamos puramente académicos y por otro el del mundo real de qué y cómo programar dependiendo qué cosas.
Para la parte académica este no es ni de lejos el mejor sitio. Hay sitios donde te lo van a explicar mucho mejor. Yo sólo te voy a poder explicar lo que más o menos creo que puedes llegar a necesitar.
Por otro lado está la parte de práctica, y ahí cada uno hace las cosas como quiere, le han enseñado o le exigen. No hay LA forma, sino formas diferentes de programar, unas mejores y otras peores, pero dentro de las buenas también hay formas que te gustarán más y otras menos y no por ello unas van a ser mejores que otras.
En cuanto a lo de las marcas y todo lo visto en esta entrada lo iremos viendo a lo largo del curso de programación, así que no desesperes «and stay tuned».
Hola, mi duda es sobre el escalado de señales analógicas, si empezamos un programa desde 0, y tenemos bastantes señales analógicas, ¿sería interesante hacer los correspondientes escalados dentro de, pienso yo, un FB, y guardarlos en un DB?, de esa forma a partir de ahí tendríamos los valores reales del proceso bien organizados en un mismo sitio, para poder trabajar con ellos según convenga.
¿tiene alguna pega?
Un saludo
Si es un escalado, yo no usaría un FB por cada escalado, sino un FC y guardaría el valor escalado o bien en marcas o en un DB global.
Un saludo
Yo decía un FB porque ya me había hecho uno digamos «universal» que he guardado en una librería que me cree, tiene como entradas los valores de minimo y máximo de la entrada analógica, minimo y máximo del rango deseado y la entrada analógica a tratar, y como salida la señal escalada, de esta manera no me complico la vida con operaciones para cada uno.
Si, y funcionaría, pero piensa que deberías usar un DB por cada llamada por coherencia con lo que es un FB, de ahí que te aconsejara que uses un FC que te ahorras los innecesarios DB de instancia.
Saludos
Que tal lñigo Gútiez, Quisiera ver si es que puedes enseñarnos como manejar el protocolo MODBUS RTU, he visto que es muy aplicado para obtener datos de una gran variedad de dispositivos, lo he visto aplicado con CFC,s pero no lo entiendo espero que puedas aportarnos algo sobre esto amigo.
Hola Carlos,
Lamento no tener experiencia con MODBUS y no poder ayudarte.
Un saludo
Hola Iñigo.
Gracias por tus consejos ya que tenia dudas de como iniciar un proyecto a un que ya haya realizado alguno. Tus consejos me aportan nuevas ideas.
Yo parto de la vieja escuela y he tenido que reciclarme en el mundo de los autómatas ya que la industria se mueve muy rápido en las nuevas tecnologías y cada vez mas automatizadas, y doy gracias a Dios que así sea por la complejidad de aquellos cuadros eléctricos de control llenos de relés he interminables regleteros.
He leído por hay que eres Ingeniero y además que trabajas en la industria del vidrio, pues te diré que yo trabaje 20 años en la industria del vidrio hueco programando maquinas I.S de EMHAR GLASS pero eso es harina de otro costal como se suele decir Ja Ja Ja. Bueno lo dicho te agradezco tus consejos he intentare de modo todo lo posible de aprender mas de ellos.
Un gran abrazo y gracias por todos tus consejos.
Hola Iñigo,
Muy bueno, muy buenoo, muuuyy bueno esto!!!! creo que uno de los post que mas me gusta! del blog.
Sin embargo quería comentarte algo que me parece fundamental mas cuando trabajas con proyectos de muchas I/O y sub-procesos, o en general considero también una buena practica de programación en autómatas.
Aquí en Venezuela lo denominamos «las imágenes» normalmente, o se realiza un FC personal, o en el OB1 unas imágenes de las I/O con fines muy practico a la hora de fallas en una salida o en una entrada.
Lo que hacemos es algo por el estilo:
U E 0.0
= M 0.0
U E 0.1
= M 0.1
.
.
.
U E X.Y
= M X.Y
Al igual que las salidas….
U M 4.0
= A 4.0
U M 4.1
= A 4.1
.
.
.
U M X.Y
= A X.Y
La idea es que si se detecta una salida o una entrada quemada en el modulo, va ser mucho mas facil reemplazar dicha I/O en el FC asociado a las «imagenes». Aveces hay que también entender que en una fabrica grande donde hay muchos técnicos electricistas, no todos tienen la misma habilidad en S7.
Que te parece?
Tengo problemas con unas entradas analógicas de un S7300 que nunca he programado para poder utilizarlas en mi programa, programadas con TIA PORTAL.
Como comprenderás con esa información poco o nada se puede ayudar.
Gracias!!!!