Home/blog/Pruebas de carga de ViSnap7
blog

Pruebas de carga de ViSnap7

Pruebas de carga de ViSnap7
Por Iñigo Gútiez

Esta semana vamos a forzar la máquina y vamos a hacer pruebas de carga de ViSnap7.

La idea es que veas hasta dónde puedes llegar con el framework.

Para ello, he modificado el proyecto que te puedes descargar de https://visnap7.org para realizar estas pruebas.

La idea es ver si un sistema así puede competir con softwares propietarios en los que puedes usar diferentes números de tags ( 512, 1024, 2048 ..) en función de sus diferentes licencias.

¿Podrá ViSnap7 competir dignamente?

¿En qué tiempos de ciclo?

La problemática

El crear controles que lean/escriban en el PLC de forma asistida como es en ViSnap7 hace que la lectura sea ineficiente si se realiza de uno en uno.

Si el número de controles es pequeño, no hay un gran problema, pero cuando el número de variables que se quieren leer es alto, la cosa se complica.

Por eso a la hora de crear el motor de lectura, he intentado minimizar el número de peticiones que se realizan al PLC.

Esto ayuda, dentro de unos límites. Si los datos están más o menos seguidos, será muy útil. Si están muy dispersos (en decenas de DB, por ejemplo) poco se podrá hacer.

Además, esta la propia representación de los controles en pantalla. Cuando pasamos a tener muchos centenares de controles visibles, el refresco visual se resiente.

Aquí, poco se puede hacer más allá de tenerlo en cuenta y no meter demasiados a la vez, si es posible. Esto lógicamente puedes paliarlo, al menos parcialmente, con un PC potente.

Prueba de carga de ViSnap7

Pero como siempre, veámoslo funcionar, porque espero que con el vídeo se vea de qué estamos hablando.

¿Qué te ha parecido?

Recuerda que la info del proyecto lo tienes en https://visnap7.org

Poco a poco iré completando información, y como comento en el vídeo, me pongo ya a realizar los vídeos explicativos que subiré en el curso de HMI con Snap7 y en Guorker.com.

#PLC#Siemens
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 (17)

Luis Salazar
Hola Iñigo, he visto tú vídeo, me ha parecido interesante lo que has hecho, aunque es normal que si divides las lecturas, es decir, por ejemplo, de un array de 1500 variables lees de 500 en 500, obviamente es diferente, me ha gustado que demuestres el tiempo de carga de una forma o de otra, ha sido un vídeo detallado para demostrar lo comentado. Yo lo hice el lunes, pero de otra forma, te explico, no es normal que tu hagas un programa de 5000 variables sólo para demostrar una cosa que ya sabemos, de hecho todas tus pruebas realizadas han sido sin conectar el PLC, por lo tanto no es una prueba tan real cómo la mía. Yo, debido a mi trabajo, comunidades de regantes, te imaginarás que si hay 50 regantes, el código de cada uno es igual para todos, (por supuesto con diferentes direcciones de memoria), realizo en su día un programa para crear todos los usuarios partiendo del primero, es por ello, me puedo permitir hacer esta prueba real con sus variables conectadas al PLC, mira este vídeo: https://youtu.be/OSSIhso9CCk Según mi cálculo, real, con el PLC, leyendo de igual modo que tú, me da que se pueden colocar 120 controles a la vez en una misma pantalla, obviamente eso no será así, no por nada, sino porque no caben, además llegado a esa cantidad, está fuera del alcance de los que tú y yo nos proponemos enseñar, cualquier joven que alcance el nivel al que estamos nosotros se podrá dar por satisfecho si controla esa cantidad de controles. También debemos tener en cuenta que no sólo los lee, sino que los grafica creando objetos Graphics en un picturebox. De nuevo comentarte la buena idea que has tenido, más aún ahora que veo que es perfectamente viable, aunque sea con 100 controles solamente, no más, seguiré investigando todo lo que tú expongas por aquí, que si varios formularios, que sirva de no sé que forma etc, por supuesto que sí, además lo que yo me imagine, que por lo pronto será crear una gráfica con un Chart y otra de lectura en tiempo real, esos son los siguientes pasos, después vendrán BD, archivos, imágenes, no sé, has abierto una caja de sorpresas que da para tanto cómo uno se proponga. Saludos y gracias por tu aporte.
Iñigo Gútiez
No sé de dónde sacas que mis pruebas no están hechas de forma real. Todas las pruebas son conectándome con un PLC S7-1200 real. Concretamente con un S7-1212. Sí son reales. No leo de 500 en 500. Leo las 1500 o 5000 a la vez. Lo que luego hago es representar en la prueba de 500 o de 250 en diferentes tabs. Que es diferente. Pero leer, se están leyendo todas a la vez de un PLC REAL aunque luego no se esté viendo en la pantalla. Pero los 3000 bytes se leen en cada ciclo. Ahí radica la gracia. Que para ti, eso sea transparente. Pones los controles, le das la dirección, y te olvidas. El core se encarga de optimizar las llamadas dentro de lo que le estás pidiendo leer. Evidentemente si pides leer 30 variables en 30 DB diferentes, no le queda más coj.. que hacer 30 llamadas. Pero si esas variables están usando unos pocos DB, el se encarga de hacer las llamadas necesarias para optimizarlo. En cuanto a lo de que todo el mundo sabe, como nos ha dicho alguna vez un auditor, "no des por supuesto, lo que no lo es". No todo el mundo sabe lo que tarda un PLC en conectar, ni que leer una variable que ocupe 2bytes o 100 que ocupen 200 bytes si están seguidas, consume los mismos recursos en las comunicaciones. En cuanto a un control que lea lo que tú quieras, ya lo he desarrollado: https://www.linkedin.com/posts/igutiez_visnap7-activity-6838582238850904064-urZI
Luis Salazar
Hola Iñigo, pues lo saco, por el motivo de que para que tus pruebas estén hechas de forma real tienes que crear las variables, lo cual sería un trabajo titánico para hacer un vídeo de unos segundos, eso lo primero, y lo segundo es que cuando arrancas VB NET, yo no te veo conectarte a ningún PLC S7-1200, es más me gustaría ver los valores en el PLC al mismo tiempo que haces el vídeo, como lo hago yo, ejecuto NET, conecto con el PLC. expongo en el vídeo el PLC con los valores y a partir de ahí grabo, mostrando en el vídeo no sólo los resultados, sino todo, tanto para una dirección como para la otra, en tus vídeos no se aprecia la conexión, ni las 5000 palabras corriendo en el PLC. Por otra parte la velocidad me da igual, ya que considero que 120 controles es suficiente para muchísimas cosas, además hay muchas formas de leer las variables, una de ellas es que sólo lea cuando cambie, con lo cual no consume recursos en los gráficos, tal cómo ya he expuesto en uno de mis vídeos, puedes leerlas al entrar el mouse en el botón que no necesita ni timer, puedes leerlas ordenándolas por de lectura o no de lectura, es decir, haces un hueco, por ejemplo, las de lectura son del 0 al 100, ahí sólo las de lectura, y las de escritura a partir de la 102, por ejemplo, ahora cómo aprecias en mi vídeo, no es problema la escritura. sino la lectura, con lo cual, podemos hacer 100 de lectura , a partir de aquí otras 100 de escritura, con lo cual ya podemos trabajar con 200 sin problemas, eso ya no es problema para mi. De todas formas, como ya comento, no me preocupa ni la velocidad, ni la cantidad. En cuanto al control que lea todo, me parece muy bien, de eso se trata, de compartir ideas tanto por tu parte como por la mía, ahora puedes copiar todos los que he realizado, pero me gustaría, insisto Iñigo, verlos mas detallados, ver todo el proceso, desde que te conectas hasta las variables que cambias, verla cambiar. Aquí tienes otros dos controles: https://youtu.be/PDa9hTfVNjo Saludos. Nos vemos.
Iñigo Gútiez
Hombre de poca fe.... Mira los controles funcionando. https://www.youtube.com/watch?v=f2Q5_cquT34
Luis Salazar
Hola Iñigo, hombre de poca fe, que gracioso, ojú, que trabajito me ha costado que hagas los vídeos mas detallados, así es mejor, así me gustan más ya que no quedan lugar a dudas, pero lo más importante es que lo vemos más claro. Me da la sensación de que estamos mirando este tema desde diferentes ópticas, intentaré ser lo más explícito posible con dos ejemplos, el primero con uno mío: Las comunidades de regantes tienen sus variables, como son: el nombre del usuario, hora de comienzo, hora de finalizar, horas consumidas, porcentaje de estas, el pago que lleva por ahora, el historial de riego, las configuración de la zona en la que puede regar, y algunas cosas más que hay, ¿esto que son 20 variables por usuario, 30, 50 si quieres?, pues ninguna esta en el PLC, sino en el PC, ahora bien, ¿cual variables están en el PLC?, dos presostatos de seguridad, por si el regante no abre la válvula o esta falla, un paro de emergencia, para que cualquier regante pueda detener el sistema si hay una tubería rota, punto, ya esta, con esas tres variables, sólo con esas tres variables, controlo yo 50 regantes, el PLC se limita a conectar las electrobombas, estar pendiente de los presostatos o el paro de emergencia, luego yo leería solamente 3 variables con 50 regantes. Programa del PLC, 3 entradas de bit, tantas salidas como electrobombas haya, punto. Dicho esto, realiza tú ese sistema de riego sin VB NET. Y ahora tu caso, un alto horno, que yo desconozco su sistema, pero haré un símil, si la temperatura supera los 50 grados activa tal cosa. si supera los 80, activas tal cosa además esta otra cosa, ahí hay 3 variables, de las cuales en el PLC sólo hay una, la lectura de la temperatura, las demás están en el PC, aparte las salidas de lo que sea, obviamente. Luego leerías una de las tres. Espero que comprendas lo que te quiero explicar, el sistema que estamos analizando, que estamos usando, que estamos perfeccionando si así lo prefieres, cuantas MENOS variables tenga el PLC MAYOR será la fuerza de NET, cuantas MAS variables tenga el PLC MENOR será la fuerza de NET, aquí radica el sentido de lo que estamos creando, al menos para mi. Voy a poner en este caso 2 vídeos para ilustrar mejor lo comentado, en uno veremos un autómata como ese que tienes ahí, resolver sudokus: https://www.youtube.com/watch?v=dJCy8UHpa-o Sólo se usa una única variable, que sería para escribir en la palabra el resultado, sólo UNA variable para resolver un sudoku con un autómata. Y en este otro juega al ajedrez: https://youtu.be/7_lJqqHzfwU Este usa sólo 12 variables para jugar al ajedrez. Espero haber sido lo suficiente explícito con lo que yo entiendo en esta historia, puede ser que a lo mejor tú lo entiendes de otra. Saludos.
Iñigo Gútiez
No sé por qué tengo que hacer los vídeos de este caso más detallados, cuando no aporta absolutamente nada, salvo que dudes de lo que te estoy diciendo. Si te digo que está leyendo del PLC, y me crees, no hace falta detallar más, porque no vas a ver nada que no estés viendo en el HMI, y su prueba de carga, que es de lo que se trata. ¿Qué ha aportado ver los datos moviéndose en el PLC el vídeo que colgué ayer respecto a ver cómo se comporta el HMI? ¿Que no mentía? ¿Realmente era necesario el tener que demostrar que es verdad? Respecto a los HMI, son Human-Machine-Interface, es decir, solamente un interfaz con la máquina, y por tanto, siempre que se pueda, el HMI tiene que ser lo más tonto posible y que toda la lógica del programa resida en el PLC. El PC no debe hacer ni una suma que sea necesaria para el proceso o su control, ya que eso le corresponde hacerlo al PLC. Si una HMI está bien diseñado, deberías poder tirar el PC por la ventana y que todo siga funcionando a la perfección hasta que se necesite meter una nueva consigna. Y esta consigna sigue siendo una variable que maneja el PLC. Pero el funcionamiento jamás debe depender del VB.NET si ese trabajo lo puede realizar el PLC. Otra cosa es que por ejemplo, tengas visión artificial, tratar datos a mansalva que el PLC simplemente no puede tratar. Pero el PC tiene que usarse sólo si no queda más remedio que así sea para procesar instrucciones. Una pantalla de Siemens, la apagas y no pasa nada. El programa del PLC sigue corriendo y salvo que tengas necesidad de trabajar con ella, sigues produciendo normalmente. Nada se para, porque nada depende de ella salvo el cambio de los valores de las consignas que lógicamente hay que cambiarlas cuando tocan y para ello está el HMI. Pero un HMI puro no deja de ser un botón físico, una lámpara o un selector en una botonera. Un simple interfaz con la máquina. Un horno de curvar parabrisas como el que programé ya hace años tiene más de 1000 lazos de control de potencia de resistencias, varias decenas de consignas de variadores, más de una treintena de cadenas de caracteres, centenares de alarmas... en definitiva como 2000 variables de todo tipo y pelaje. Ese HMI puede apagarse sin problemas hasta que no haya un cambio de receta, porque todo el proceso reside como debe ser en el PLC. Y sólo porque quieres ver lo que el horno está haciendo, o necesitas cambiar los datos, necesitas dicho interfaz. En cualquier caso, ya te dije en otro comentario que de lo que hablabas tú, no es de lo que hablo yo. Pero es que se trata de hablar de ViSnap7, de lo que es, y de lo que trato de lograr, no de lo que tu hagas en tu proyecto o de lo que necesites. Porque esa es otra conversación que nada tiene que ver del tema tratado. Solo pido que si digo que son 5000 variables leídas del PLC, no se diga cosas como "de hecho todas tus pruebas realizadas han sido sin conectar el PLC, por lo tanto no es una prueba tan real cómo la mía." Dicho lo cual, creo que queda zanjado el tema porque como bien dices, y yo ya te había dicho con anterioridad, estamos hablando de cosas diferentes, para necesidades diferentes.
Luis Salazar
Buenas Iñigo, parece que te has molestado, si es así te pido disculpas, y no desconfío de ti pues no te conozco personalmente, yo lo que no veo no lo creo, y de lo que veo me creo la mitad, soy una persona que necesito ver para creer, en tu caso dudaba de que hicieses un programa con 5000 variables para dos minutos de vídeo, si le sumamos a esto que no se aprecia ninguna conexión a ningún plc, pues simplemente dudé, y ya esta, si tu dices que has realizado ese programa con 5000 variables, pues me parece bien, por otra parte no es que al decir que mi programa era más real sea mejor ni peor, sino que tenía la certeza de que si estaba conectado. Hombre, el vídeo ha demostrado que si estaba conectado, luego deja menos lugar a dudas, es decir, si esto ocurre en otras condiciones, pues no le daría tanta importancia, pero como se trata de una cosa que no es normal, pues tenía mis dudas razonables y no estaba seguro, nada más. Espero que todo quede en un malentendido. Mañana si puedo haré algunos controles más. Saludos.
Iñigo Gútiez
Pues hombre, evidentemente no sienta bien que se afirmen cosas sin saber, y se ponga en tela de juicio lo que uno dice en su casa. Esto es verdaderamente sencillo: ahí está el código. Un código, que por cierto, a poco que se sepa de cómo se mueve la industria vería las horas que hay que dedicarle para desarrollarlo si sabes cómo hacerlo, o el coste monetario que este supondría si lo mandaras programar para ti, que no serían precisamente unos pocos cientos de euros. Por eso me molesta, sí. Que teniendo el código de forma gratuita, que se puede estudiar, probar y hacer con él lo que se quiera, se ponga en duda lo que estoy diciendo. Es tan simple como antes de afirmar ciertas cosas, pues simplemente, se pruebe. Respecto a los controles, programar controles reutilizables jamás ha sido el problema. Eso es trivial. Solo tienes que ver la necesidad que tengas, lo programas en un user-control y se terminó el problema. No es más complicado que hacerlo directamente contra el formulario y cualquiera que lleve unas pocas horas de vuelo programando en .Net sabe usarlo. El problema es cómo pensar el motor para que tu simplemente arrastrando y soltando, colocando las direcciones en el propio control puedas añadir muchos controles sin que esto perjudique el tiempo de ciclo y encaje en la filosofía de trabajo. Hacer una gráfica no es el problema. Hacer una gráfica en el que en el chart puedas meter 1,2,4,7 o 10 variables según quiera el usuario a graficar sin tener que tocar el código, que este control se entienda con el resto del motor de lectura, y que todo esto no penalice el tiempo de ciclo, ahí reside el problema. Ni siquiera el picar el código es el problema. El problema reside en pensar cómo hacerlo para que todas las piezas encajen con la misma filosofía, sin tener que hacer excepciones raras y que todo sea homogéneo y coherente. Yo mañana quito un control de la plantilla, y tengo que quitar UN nombre en un listado para que todo siga igual sin que parezca que ese control jamás haya existido. Lo mismo para incluir uno nuevo. Solo tienes que añadir la clase nueva en el proyecto, y su nombre en un listado sin tener que tocar ni una sola línea de código más. Ni una. Ahí radica la gracia que estoy intentando hacer. Por lo que hacer controles, como decía Mozart en la película Amadeus, "es solo garabatear y garabatear"
Luis Salazar
Hola Iñigo, veo que eres hombre de palabra, ya veo que no haces las cosas por hacerlas, es cierto, tan cierto como que son muchas horas de trabajo lo que lleva tu proyecto, tan cierto cómo que si te piden lo que haces gratuitamente el costo es muy elevado, tan cierto cómo que muy poca gente comparte semejante trabajo como tú, yo soy más de esfuerzo que de copiar/pegar, por este motivo expongo el resultado, pero rara vez la solución. Esta tarde creo que tengo tiempo, voy a analizar tú código, pero no para ver cómo funciona, eso no puedo hacerlo porque no tengo nada de Siemens, lo que voy a hacer es copiarte los smart tags en mi programa para comprobar que tal va la cosa con respecto a mi forma, ya lo comentaremos. Lo que no entiendo es lo de poner o quitar una línea, yo no hago eso, yo creo un control sin poner línea ninguna, cuando lo quito se quita tal como se puso sin tener que quitar ninguna línea, de todas formas esta tarde voy a hacerlo como tú, por curiosidad. También ocurre que yo quiero hacerlo de mi forma, porque así, cuando comparta el código, la persona que lo coja verá cómo se crea un gráfico de tal tipo, o un botón, o lo que sea, sólo abriendo el control, allí podrá configurar todo, tal cómo has visto en mis vídeos. Para referenciarlo, pues se cambia el nombre respetando el dígito final que será la variable, de la misma forma que si pusieses un textbox normal, pues le tendría que cambiar el nombre igualmente, luego después cuando aprenda las letras, pues podrá escribir sus clases, esa es mi idea, enseñar los códigos específicos como si fuesen las letras por un lado, crear clases etc. por otro una vez aprenda las letras, ya cada cual saque sus conclusiones, tú quieres hacer una cosa que necesitará muchas horas de vuelo como tú dices para poder manipularla. Nos vemos cuando haya investigado. Saludos.
Iñigo Gútiez
La idea es que no haya que tocar una sola línea de código para hacer un hmi del estilo que puedes hacer con una pantalla de Siemens u otros fabricantes. No tener que saber programar nada. La gran ventaja es que como es .net luego podrás hacer con ello lo que te da la gana, adaptarlo a las necesidades etc Cuando digo que solo hay que añadirlo a una lista es porque el control no lee ni escribe en el PLC directamente. El no se conecta al PLC para nada de forma directa. Es el motor que supervisa todo el que lo hace. El control lee en función de su PLC, dirección y tipo (entero, real, string, etc) del objeto cliente que ya tiene esos datos. Cuando quiere escribir, usa al cliente para escribir tal o cual cosa. Pero ningún control lee ni escribe en el PLC. No establece ninguna conexión con el PLC. Por eso es modular y por eso hay que meterlo en la lista para que el cliente lo tenga en cuenta para saber que hay que leer del PLC y cuando le diga que hay que escribir, que escriba.
Luis Salazar
Hola Iñigo, con respecto a tu segundo párrafo: https://youtu.be/2Y2GhWIbUcM He realizado ese vídeo para más detalle, te comento, yo SI tengo que conectar al PLC con net, te comento porque: Una comunidad de regantes de 50, no pueden regar todos el mismo día, luego hay sectores, A, B, C por ejemplo, cada sector abarca unos días a la semana, ¿tú te imaginas hacer ese código en un PLC?, ¿la cantidad de palabras que manejas a la vez, que si el número de usuario, hora de comienzo, de finalización, litros consumidos, porcentajes de horas, etc, etc,? , bien pues eso se soluciona con un evento en NET, en el cual se ha configurado las variables necesarias y al que se llama cuando sea necesario, de esa forma con 5 eventos el trabajo lo hace NET solamente leyendo las entradas de los presostatos, paros de seguridad y las lecturas de contador de litros para que cuando el usuario consuma su parte se cierre la electroválvula hidráulica. Dicho esto, supongamos que lo hacemos en el PLC, ahora entra 5 regantes más, se decide ampliar los sectores a la letra D, ahora vete y haz los cambios en el PLC para los 5 nuevos, si lo haces con Net, basta con crear los 5 usuarios nuevos. así sería algo así: https://youtu.be/nJRnrmmxaZk En mi canal hay muchos vídeos relacionados con este tema, desde servidores en el mismo PC, hasta controlar el riego desde servidor IIS de Microsoft. Observa que se leen 100 bits sin problemas de ningún tipo, además te comento que mis sistema debe poder conectarse por puerto serie ya que en el campo no hay internet. Seguiremos analizando todo esto. Nos vemos. Saludos.
Iñigo Gútiez
Pues no conozco el detalle, pero por lo que cuentas, no parece que no sea capaz de gestionarlo el PLC. Como digo, no conozco el detalle, pero si está bien hecho un programa en el que todos los elementos son iguales en estructura, añadir programas que son exactamente iguales, es añadir tantas nuevas instancias como elementos quieras hacer. No debería ser para nada un trabajo complicado, porque si lo es, es que está mal programado. Para eso Siemens tiene los FB, que está orientado a objetos. Ahora, si la programación está hecha a base de copy&pega usando marcas, cambiando nombres de variables absolutas para cada regante en este caso, el problema no es el PLC, sino cómo está programado. Cada regante debería ser una instancia de la "clase" de "Equipo_Regante" en el PLC, y debería ser igual hacer 1 que 100, más allá de a cada uno, asignarle lógicamente sus entradas y salidas físicas. Pero el código del programa, no se debería tocar. Si para uno funciona, debería funcionar para tantos como quieras poner. Insisto que desconozco el detalle y no sé en Schneider cómo se hace, ni cuáles son las problemáticas, pero por lo que cuentas y si los regantes son equivalentes, eso es carne de código reutilizable en un FB si fuera en Siemens. Luego está el tema de registros de usarios y ese tipo de cosas, que es más un tema de gestión administrativa, que en eso si te compro que los PLC no están para eso. Pero arrancar o parar una bomba en función de una hora, contar número de horas trabajadas, y cálcular agua consumida etc etc, eso lo puede hacer el PLC, y de hecho donde yo trabajo, lo tiene el PLC. Cuándo debe entrar un bombeo, registrar el número de horas trabajadas o cosas similares, se registra en el PLC, no en el HMI. Pero bueno, para todo hay matices y hay muchas formas de hacer las cosas. Lo único que digo es que hay que tratar siempre que el hecho de que una máquina funcione o no, hay que tratar por todos los medios que no dependa de un PC, porque un PLC es infinitamente más robusto que un PC. Anda que no he tenido que reparar PC que trabajan 24/24*365. Sin más. Si funciona y así os va bien, pues ya está, tampoco hay que buscarle las vueltas. Respecto a lo que comentas del código, está escrito en inglés a propósito. Que digas que no se entiende, solo hay que leerlo, que no es complicado: KPLCPropertyAddressing, es decir, K de constante (no una variable) y PLCPropertyAdressing, que es "propiedades de direccionamiento del PLC" Es una tradducción literal de lo que significa. Luego no es ni nombres raros, ni nada por el estilo. No creo que haya demasiadas dudas de qué significa. De hecho, en código libre se usa el inglés a nivel internacional como lengua vehicular. Y por eso lo he escogido así. En cualquier caso, como en 10 segundos, sin haberlo visto jamás, haces una búsqueda de su definición y verás que todas ellas son constantes, y que además, son simples textos literales. En el trabajo sí uso castellano para los desarrollos, pero porque es algo interno y nadie de otro país va a leer dichos programas. Dicho esto, sigues sin entender lo que estoy intentando hacer. Se trata de no tocar ni una línea de código. Por eso tiene las smart-tags y las propiedades, no para que hagan bonito, sino para que no tengas que escribir que el color de fondo es color.black, sino que visualmente veas el elemento color, elijas el negro (o el que sea) y para el que está desarrollando el HMI, eso sea transparente,lo mismo que es transparente para mi si uso el editor de WinCC flexible de TIA Portal, en el cual, no veo el código de cómo está hecho. Ni lo sé, ni me importa. Y por cierto, hacerlo así, es infinitamente más rápido e intuitivo que para cada instancia tener que picar código si quieres que un botón sea azul cuando se pulse y otro sea amarillo, o cualquier cosa específica que quieras programar en el user control. Y mucho más claro y depurable después porque no tienes un montón de código que has tenido que añadir para añadir colores o similares, cuando usando la plantilla que yo propongo en el Form1 no tienes nada. Ni una sola línea aparte de la llamada al PLC. Las tripas del código, las usas si sabes usarlo, y lo entiendes, pero si no sabes.... no hace falta que lo sepas, porque ese es el objetivo. Que te dediques a diseñar gráficamente el HMI, y que picar código sea el último recurso. De lo que comentas de General.DataArea, casi me caigo de la silla... si el que coja el código no sabe lo que es, efectivamente le queda muy grande el programa, porque si no entiende que General es el módulo, y que DataArea es un enum en este caso, o un método, o lo que sea... ¿en serio crees que va a saber qué es una clase heredada? ¿qué es un smart-tag? En fin... El código de ViSnap7, no son clases de Visual .NET, es un código para desarrollar HMI de forma visual. Se da el código libre, porque quiero que sea así. Si no entiendes lo que es una propiedad, lo que es un smart-tag, o lo que es un módulo y las diferentes formas de hacer referencia a su contenido, y por qué DataArea y DataType están en general y no están repetidos mil veces por cada control que fabriques, pues bueno, no lo entiendes. Pero eso no hace ni mejor ni peor el código. El código, como todos los programas del mundo será mejorable y tendrá muchos fallos. Pero la ignorancia del que lo lee, no es uno de ellos si está medianamente bien programado, está limpio y bien estructurado. Seguro que lo puedo mejorar, pero porque no lo entienda uno que empieza, jamás puede ser un motivo. Es como decir que no se pueden usar multiplicaciones, porque el que lo lee, solo sabe sumar y restar. Dicho esto, sigo mejorándolo y poniéndolo más limpio e entendible. Pero si necesito usar una propiedad, y no se sabe usarlas, no es problema del código.
Iñigo Gútiez
Y para ejemplo, y con esto ya termino con este tema, porque no hay mucho más de qué hablar: cómo añadir una gráfica a tu HMI, sin tener que tocar ni una línea de código: https://www.linkedin.com/posts/igutiez_visnap7-activity-6840254368680316928-7Wej Solo elegir las variables que quieres representar, dar los nombres de los ejes, la frecuencia de muestreo, colores... y pista. Ni picar código, ni saber nada de nada de nada de visual basic. ESO es lo que estoy buscando.
Luis Salazar
Hola Iñigo, así es, los programas de riego los tenemos perfectamente estructurados, te he entendido perfectamente desde el principio con lo que quieres hacer, por supuesto que si no sabes lo que es una clase pues no sabes leer ni tu código ni ningún código, etc, etc, etc estamos de acuerdo en todo eso. https://youtu.be/zTjEjUSgWO0 Ahora, llegado a este punto, como bien dices, de momento no hay nada más que comentar, puesto que ya cae todo por su peso, de momento... Dicho esto, tus alumnos deben estar muy satisfechos contigo, eres un crack, el código de los smart tags no lo conocía hasta ahora, reconozco tu trabajo que has hecho o mejor dicho haces, te agradezco que lo hayas compartido, y decirte que he aprendido mucho en tu blog, aún siendo de Schneider, para muestra como has visto, he podido adaptar tu código aún desconociendo Siemens, tu código Visnap7 se entiende perfectamente está muy bien estructurado y no deja lugar a dudas, por lo tanto, insisto, enhorabuena por tu trabajo, gracias por compartirlo, te debo una comida. Saludos.
Luis Salazar
Hola Iñigo, necesito hacerte un consulta, sobre lo que comentamos en las pruebas de carga. Al final, me he decantado por tu sistema, aunque intentaré mantener también el mío, eso si, en proyectos independientes. Tu código ViSnap7 es fabuloso, tanto que he creado varios componentes basados en los tuyos pero dándole mi toque personal para adaptarlos a Schneider, he creado la plantilla para que todos sean realizados a partir de esta plantilla, he creado la clase para que actualice todos los componentes que vayamos creando a partir de ahora sin problemas pero sobre todo sin dejar de pensar en la prueba de carga, creo que, dentro de que nunca se me ha colgado ninguno de los proyectos realizados hasta ahora, he dado con la tecla para leer exclusivamente la variable que necesito, sin tener que cargar todas en ningún array ni recorrer todas las que haya, con lo cual supongo que ya se pueden poner todos los controles que se quieran. ¿Crees que así será mejor, o peor? Mañana cuando me organice todo esto haré un vídeo para mejor detalle. Aparte de esto, tengo en mente varias cosas que aún no sé si de alguna forma podré crearlas, pero creo que son interesantes. Saludos.
SamusEG
En SNAP7, este problema porque se estaría dando? Yo en SNAP7 creaba los controles y los añadía al formulario a mano, en vez de por código. Y en teoría no noté este problema de velocidad. También las lecturas al autómata se hacen cada 500ms. Yo en SNAP7 he hecho una base de datos en .mdf que añade 50 temperaturas cada 5 minutos y 100 presiones cada 5 segundos. En teoría, no he tenido ningún problema de velocidad... El único problema que recuerdo fue con el control de alarmas, que al añadir mas de 400 alarmas el control tardaba en cargar 3 segundos. Pero vamos en teoría este problema solo da si creas los controles por código no?
Iñigo Gútiez
No da ningún problema. Solo si haces muchas llamadas. Como bien indicas que al meter 400 alarmas, tardaba 3 segundos. Eso es muchísimo en un HMI. Por eso agrupar las llamadas hace que todo vaya mucho más rápido. Pero a Snap7 no le pasa nada. El problema se da cuando haces muchas lecturas individuales.