virtualization - tipos - labview gratis
¿Por qué las personas no utilizan LabVIEW para otros fines que no sean la adquisición de datos y la virtualización? (14)
Alguien dijo que LabView solo es demandado en el campo de Automatización. Simplemente no escribo en absoluto. Tiene aplicaciones en Procesamiento de señales digitales, Sistemas de control, Comunicaciones, Basado en Web, Matemáticas, Procesamiento de imágenes, etc. Comenzó como un método de adquisición de datos e inventaron el nombre de Instrumentación Virtual, pero ahora ha ido mucho más allá. Es un lenguaje de programación científico con una interfaz gráfica inigualable. Está mucho más allá de Simulink y si te gusta Matlab, entonces tiene un tipo de scripting de Matlab incorporado para aquellos que gustan de tales formas de programación. Está evolucionando todo el tiempo. Lo único que me resultó difícil fue escribir código para el Compact Rio: es complicado pero mucho más fácil que la alternativa. Es caro pero obtienes un producto de calidad. Personalmente no he encontrado ningún error en la programación ordinaria. Es un lenguaje de ingenieros, pero cualquiera podría usarlo para programar.
Esto está marcado como una pregunta subjetiva, aunque espero no obtener demasiados votos.
LV parece ofrecer una buena alternativa gráfica a la programación tradicional basada en texto. Según tengo entendido, no es un lenguaje de programación de virtualización / adquisición de datos. No obstante, parece tener ese paradigma vinculado al nombre de su creador.
Mi pregunta surge porque no parece ser ampliamente utilizada para aplicaciones multipropósito. No soy un experto en LV de ningún tipo, soy más como un aprendiz. Todavía me estoy acostumbrando a LV.
Comencé a usar Labview en un laboratorio de física de la universidad. Inicialmente, pensé que era lento y engorroso en comparación con otros idiomas basados en texto. Era demasiado difícil crear una lógica compleja y el código se volvió descuidado muy rápido (cables en todas partes).
Luego, unos años más tarde, aprendí a usar sub-vi''s y paquetes. ¡Que diferencia! En este punto, estaba usando Labview para funciones de muy alto nivel. Estaba tomando información sin procesar de una cámara, utilizando todo tipo de filtros de imagen y procesando para finalmente analizar las líneas en una carretera para que un vehículo pudiera conducir por esta carretera sin conductor; era para el DESAFÍO URBANO DARPA. También estaba generando mapas a partir de datos de puntos de referencia de texto, realizando funciones de análisis de alto nivel y una gran cantidad de otras aplicaciones que no tenían nada que ver con el procesamiento de datos desde dispositivos de entrada. Fue realmente muy divertido. y rápido.
Después de dejar la universidad, ahora he vuelto a usar idiomas basados en texto. He estado usando: PHP, Javascript, VBA, C #, VBscript, VB.net, Matlab, Epson RC +, Codeigniter, varias API, y estoy seguro de algunos otros. A menudo me frustra mucho la cantidad de sintaxis que debo memorizar para poder programar con una velocidad significativa. Me resulta molesto tener que cambiar de escuela de pensamiento en función del lenguaje que estoy usando ... ¡cuando todos los lenguajes de programación hacen esencialmente lo mismo! Necesito un segundo monitor para tener la ayuda en todo momento, de modo que pueda encontrar la sintaxis para las mismas funciones en diferentes idiomas. Extraño mucho a Labview, es una lástima que sea tan caro, de lo contrario lo usaría para todo.
La programación gráfica basada creo que tiene un gran potencial. Al no estar restringido por la sintaxis, puede centrarse en la lógica en lugar del código. Es posible que Labview todavía esté en su infancia en términos de soporte y depuración, pero creo que, conceptualmente, supera a la competencia. Es simple una forma más intuitiva de programar.
He estado pensando en esta pregunta durante décadas (sí, desde 1989 ...)
Como todos los lenguajes de programación, LabVIEW es una herramienta de alto nivel utilizada para manipular el flujo de electrones. A menos que usted sea un purista y se niegue a usar cualquier otra cosa que no sea una tabla y cables; Los transistores, circuitos integrados y lenguajes de programación son probablemente algo bueno si desea construir algo de alguna importancia.
Pero como todas las herramientas de alto nivel, el solo hecho de empuñar una no te convierte en un artesano profesional. En el día de los soldadores, los amplificadores operacionales y los UART, se requería una gran cantidad de estudio cuidadoso antes de poder crear un sistema que realmente funcionara. El dominio moderno de los lenguajes basados en texto está tan dominado por la sintaxis que el programador debe entenderlo justo antes de compilar y ejecutar. Para escribir código que funcione, el programador debe aumentar su nivel de habilidad para crear sistemas mucho más grandes que "Hello World".
LabVIEW no está dominado por la sintaxis, sino por el flujo de datos. En el pasado, llegar a su plantilla de diagramas de flujo y desarrollar el diagrama de un sistema de información bien equilibrado era la parte artística y estética del trabajo. Solo después de tener el diagrama de flujo revisado en la mano, incluso considerarías pasar por la monotonía de marcar el código. (sí ... tarjetas perforadas)
LabVIEW es un sistema de desarrollo que le permite al programador usar herramientas de diagramas de flujo para diagramar el sistema de información completo y presionar "ejecutar" ... LabVIEW "saca el código" y lo compila por usted. No hay necesidad de luchar con la sintaxis del texto A o el idioma B.
Con una herramienta tan poderosa, los principiantes pueden construir grandes programas de trabajo rápidamente, lo que implica cierto nivel de destreza profesional ya que funciona. Sin embargo, si el sistema no funciona con elegancia, o si el diagrama del código fuente es un desastre, no es culpa de LabVIEW.
La gente suele señalar que "LabVIEW solo es bueno para el desarrollo de grandes sistemas de adquisición de datos". Quizás esas personas deberían considerar el profesionalismo de los científicos e ingenieros que trabajan en la adquisición de datos. Si saben lo suficiente para obtener los cables reales adecuados para los sensores y transductores, puede ser una buena apuesta que también sean expertos en desarrollar diagramas de cableado de LabVIEW.
He estado utilizando LabVIEW durante aproximadamente dos años para desarrollar la automatización. Si se le da el debido cuidado y el diseño adecuado, podemos desarrollar una aplicación de LabVIEW que se pueda mantener y que tenga muy buena apariencia. Creo que esto es lo mismo para todos los demás idiomas que existen. He visto códigos igualmente malos en LabVIEW principalmente de personas que lo usan solo para desarrollar automatización de trabajo rápida y sucia. La programación gráfica IMHO es mucho más fácil de codificar y entender si se hace correctamente. ¡Pero dicho eso, siento que la programación basada en texto se ''siente'' más poderosa! LabVIEW se comercializa principalmente para la automatización industrial, tiene soporte inherente para gran parte del hardware de NI y puede hacer que los hardware de terceros trabajen con él con bastante rapidez. Creo que esa es la razón por la que lo ves solo en el campo de la automatización. Además, es bastante costoso y está bloqueado con NI, ya que ni siquiera puede abrir su código si no le compra el software.
He usado LabView durante unos 10 años. Es genial para la búsqueda de datos científicos, es decir, como Matlab o Simulink, pero 10 veces mejor. Si tienes problemas, entonces estás haciendo algo mal. Se necesita tiempo para aprender como cualquier idioma. En cuanto a usar .Net en su lugar, ¿estas personas están incluso en el mismo planeta? ¿Por qué se tomaría la molestia de escribir todo desde cero cuando puede decir que levante una FFT, etc. y use un código escrito ya leído? .NET está bien para programas simples pero no tan bueno para el procesamiento científico. sí, puedes hacerlo, pero no sin un montón de complementos para gráficos, etc. La búsqueda de nombres en G es mucho más fácil que el texto basado en problemas científicos. Por supuesto, puede programar en c si se está interconectando y usa la dll. Ahora hay cosas que no usaría LabView para: el reconocimiento de voz, por ejemplo, puede ser un poco desordenado en este momento. Sin embargo, más al punto, ¿por qué a las personas les gusta programar en forma de texto desactualizado cuando hay una alternativa fácil? Es como si la gente quisiera complicar las cosas para justificar su trabajo de alguna manera. Simplifica Simplifica!
Labview es fantástico si tiene hardware de National Instruments y desea hacer algo como adquirir, trazar y registrar los datos.
Cuando comienza a conectarse a dispositivos personalizados, el cableado entre los módulos se complica al tener que realizar todo el trabajo de manipulación de cadenas para la entrada y salida a un dispositivo.
En mi lugar de trabajo, descubrimos que nos molestaba tener que hacer VIs masivos y complicados para interactuar con los dispositivos y comenzar a escribirlos en .NET e interconectarlos con Labview.
Al final, terminamos desechando Labview todos juntos y usando NI Measurement Studio para Visual Studio para darnos todos los controles de NI de aspecto encantador (diagrama de forma de onda, tanque, medidores, interruptores, etc.) con la flexibilidad de C #.
En resumen, incluso con un par de pantallas de 24 ", a veces el cableado para el código Labview puede ser demasiado complejo y se vuelve imposible de comentar, depurar y hacer extensible para futuros cambios. Le sugiero que mire a Measurement Studio para Visual Studio y usando tu lenguaje .NET favorito con los bonitos controles de NI.
Labview se puede utilizar para crear proyectos de software grandes y complejos. Labview es, sin duda, mucho más divertido de usar que un lenguaje basado en la sintaxis. He programado simulaciones dinámicas matemáticamente densas utilizando labview. Las versiones más recientes de Labview incluyen muchas características interesantes, especialmente para la utilización de múltiples procesadores. Me gusta mucho Labview. Pero no lo recomiendo a nadie.
Desafortunadamente, es una pesadilla absoluta para cualquier otra cosa que no sea simple adquisición y exhibición. Puede que algún día se desarrolle lo suficiente como para ser considerada como una alternativa viable a los idiomas basados en texto. Sin embargo, los desarrolladores de NI siempre han optado por ignorar los tres problemas fundamentales que afectan a Labview.
1) Es inestable y plagado de errores. Hay miles de errores que se han publicado en los foros de soporte de Labview que aún no se han solucionado. Algunos de estos son bastante graves, como fugas de memoria o errores matemáticos en funciones básicas.
2) La documentación es atroz. La mayoría de las veces, cuando busca ayuda con una función de vista de laboratorio en el archivo de ayuda local, encontrará una oración que simplemente reafirma el nombre del elemento en el que está tratando de encontrar algunos detalles. por ejemplo, un usuario busca el archivo de ayuda en la configuración del modo de filtro de textura y lo único que está escrito en el archivo de ayuda es "Modo de filtro de textura: selecciona el modo utilizado para el filtro de textura". Caramba, gracias. Eso aclara las cosas, ¿no? El problema va mucho más profundo en eso; con bastante frecuencia, cuando le pide a un representante técnico de los instrumentos nacionales que proporcione detalles críticos sobre la funcionalidad de Labview o el comportamiento específico de las funciones matemáticas, simplemente no saben cómo funcionan las funciones en su propia biblioteca. Esto puede sonar como una exageración, pero créeme, no lo es.
3) Si bien no es imposible mantener el código gráfico limpio y bien documentado, Labview está diseñado para hacer estas tareas difíciles e ineficientes. Para evitar que su código se convierta en un lío confuso y enredado, debe emplear rutinariamente (cada pocas operaciones) estructuras como clusters, y controles definidos de tipo gigante y sub-vis (que pueden extenderse sobre múltiples pantallas en un proyecto grande). Estas estructuras consumen memoria y destruyen el rendimiento al obligar a Labview a realizar múltiples copias de los datos en la memoria y realizar operaciones gratuitas, todo por el bien de evitar que el diagrama gráfico se vea como un espagueti de color arco iris sin comentarios ni texto en ningún lugar a la vista. Programar en labview es como jugar pictionary con el diablo. Imagine su proyecto de software gigante escrito como un diagrama de flujo del tamaño de una pared sin palabras. Ahora imagine que todas las líneas se cruzan entre sí mil veces, de modo que el rastreo del flujo de datos es completamente imposible. Acaba de imaginar la forma más natural y eficiente de programar en Labview.
Labview es genial. Labview está mejorando con cada nueva versión. Si National Instruments sigue mejorándolo, será un gran día como lenguaje de programación general. En este momento, es una opción extremadamente mala como plataforma de desarrollo de software para proyectos grandes o lógicamente complejos.
Mis dos experiencias con "alternativas gráficas a la programación tradicional basada en texto" han sido terribles. Encuentro que tales lenguajes son lentos de usar, difíciles de editar e inexpresivos. Depurarlos es una pesadilla. Y no ofrecen ventajas reales.
Para estar seguro, ha pasado bastante tiempo desde que miré uno, pero las opiniones de otros que les he preguntado han sido tibias, por lo que nunca me he tomado el tiempo para mirar de nuevo. Las razones para volver a mirar son bienvenidas y se tendrán en cuenta ...
Nuestra compañía está utilizando LabVIEW durante los últimos 10 años para medir, monitorear y reportar nuestros temas (trenes).
Recientemente, hemos comenzado a utilizar LabVIEW como GUI para bases de datos con una gran cantidad de datos, el poder de LabVIEW con las nuevas características recientes (Classes, XControls) permite crear este tipo de GUI para una fracción de los costos de desarrollo en otras plataformas. Si bien no necesitamos programadores externos a tarifa de consultoría.
Tonelada
Pensé que LabVIEW era un sueño para la programación de FPGA. Bloques ejecutables independientes solo ... trabajo. En general, uso LabVIEW para varias tareas que interactúan con mi hardware DAQ y FPGA, pero eso es todo. Parece (de nuevo para mí) que este es el punto fuerte de LabVIEW y la razón por la que fue construido, pero fuera de ese campo se siente "engorroso". En cuanto a hacer las cosas, es como cualquier otro idioma con una curva de aprendizaje: una vez que lo descubres, no es tan malo para hacer el trabajo. He visto a varias personas rendirse antes de pensar que la curva de aprendizaje era permanente o algo así.
Recoger un monitor de 30 "hizo una gran diferencia.
Una cosa que a la gente no le gusta es la integración del control de versiones.
Edición: LabVIEW / hardware es muy caro para el uso "solo por diversión". Dejé $ 10K en su hardware (precios para estudiantes) y obtuve el software gratis de la escuela para hacer juguetes en la casa.
Pero las personas utilizan LabView para otros fines que no sean la adquisición de datos y la virtualización. Por supuesto, LabVIEW se usa principalmente en laboratorios y entornos de producción porque es (o fue) uno de los principales objetivos de los clientes de NI.
Sin embargo, puede hacer muchas cosas diferentes con LabVIEW, como programar un robot que realizaría muchos análisis de imágenes y luego twittear los resultados. Eche un vistazo a los videos de NI Week 2009 en you-tube y verá cuán poderosa es esta herramienta. Por ejemplo, existe la posibilidad de escribir código y desplegarlo en MCU de ARM (consulte este artículo de Dev Monkey desde 2009.08.10).
Y finalmente verifica este grupo de LabVIEW DIY.
Utilizamos LabVIEW para ejecutar nuestro equipo de prueba de final de línea y es ideal para la adquisición y control de datos. Típicamente, midiendo de 15 a 80 voltajes diferenciales y controlando cámaras ambientales, controladores de flujo másico y varios dispositivos seriales, LabVIEW es más que capaz.
La interfaz con dispositivos personalizados se puede simplificar en gran medida utilizando el asistente del controlador de instrumentos de NI para crear VI''s reutilizables, interactuando con archivos DLL personalizados si es necesario. En una serie de proyectos, hemos creado dichos controladores para hardware personalizado y, una vez creados, se pueden reutilizar en proyectos futuros sin modificaciones.
El uso de estructuras dirigidas por eventos las interfaces de usuario responden y usamos regularmente aplicaciones de LabVIEW para interactuar con una base de datos.
Sea cual sea el entorno de programación que elija, lo que más importa es el proceso de diseño de la aplicación. Estoy de acuerdo en que puede crear algunos diagramas de bloques realmente horribles e ilegibles en LabVIEW, pero también puede crear código ilegible en Visual studio. Con solo un poco de reflexión y planificación, se puede hacer que un diagrama de bloques de LabVIEW se ajuste a un solo monitor de 24 "con mucho espacio para agregar comentarios.
Yo usaría LabVIEW sobre Visual Studio para la mayoría de los proyectos.
Utilizo LabView en casa , ya que es parte de Lego Mindstorms, que a mi hijo le encanta. Y realmente me gusta la forma de componer sistemas como este.
Sin embargo, en mi trabajo (sistemas embebidos), es generalmente restrictivo. Pero también aquí, estoy tratando de avanzar en la abstracción: - control y comportamiento del estado: diseño basado en modelos (es decir, Rhapsody) - algoritmos de datos, etc. Simulink
A veces, un modelo gráfico puede requerir más clics que una pieza de código. Pero esto también incluye el trabajo que un buen programador debe hacer en diseño y documentación; no sólo el código de escritura. La notación gráfica elimina muchos problemas y generalmente es mucho más rápida si la herramienta es lo suficientemente poderosa para la complejidad a la mano. Así que espero que este tipo de herramientas ganará más popularidad en los próximos años a medida que maduren y la gente se familiarice con ellas.
Yo ** he estado escribiendo en LabVIEW por casi 20 años. Desarrollo sistemas de prueba automatizados. He desarrollado sistemas de prueba de señal mixta de RF, Vison, digital de alta velocidad y muchos tipos diferentes. Fui programador "C" antes de cambiar a LabVIEW.
Es cierto que puede crear algunos programas rápidamente en LabVIEW, pero al igual que en cualquier otro idioma, se necesita mucha capacitación para aprender a construir una aplicación grande que sea fácil de mantener con código reutilizable. En 20 años nunca tuve un error de LabVIEW que me impidiera terminar un proyecto.
De vuelta en el día, NIWEEK tendría un tiroteo de software cada año. A los programadores de LabVIEW y LabWINDOWS (versión de NI de "C") se les daría el mismo problema y tendrían una carrera para ver qué grupo terminó primero. Todos y cada uno de los años, todos los programadores de LabVIEW se realizaron antes de que la primera persona de LabWINDOWs terminara. He desafiado a muchos de mis amigos dedicados a la programación basada en texto a shootouts y todos admiten que no tienen ninguna posibilidad, incluso si les dejo definir el problema del software.
Entonces, siento que LabVIEW es una gran herramienta de programación. Definitivamente es el camino a seguir si está interactuando con cualquier tipo de hardware de NI. No es la respuesta para todo, pero estoy seguro de que hay muchas personas que no lo usan simplemente porque no consideran a LabVIEW como un "lenguaje de programación real". Después de todo, solo unimos un montón de bloques, ¿no? Me parece gracioso cuántos programadores basados en texto rechazan sus narices porque están muy orgullosos del desorden del código de texto que han creado, que solo ellos pueden entender. Un buen programador en cualquier lenguaje debe escribir código que otros puedan leer fácilmente. Escribir un código demasiado complejo que es imposible de seguir no convierte al programador en un genio. Significa que el programador es un "compliator" (alguien que puede tomar un problema simple y complicarlo). Creo en el principio KISS (KEEP IT SIMPLE STUPID).
De todos modos, ¡valen mis dos centavos! **