2009-08-04 16 views
19

Esto está marcado como una pregunta subjetiva, aunque espero que no obtenga demasiados votos a la baja.¿Por qué las personas no usan LabVIEW para otros propósitos que no sean la adquisición de datos y la virtualización?

LV parece ofrecer una buena alternativa gráfica a la programación basada en texto tradicional. Según entiendo, no es solo 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 de usos múltiples. No soy un experto en LV de ningún tipo, soy más como un aprendiz. Todavía me estoy acostumbrando a LV.

+0

Duplicado: http://stackoverflow.com/questions/226010/why-use-labview (y algo así también http://stackoverflow.com/questions/372557/what-specific-features-of-labview- son-frustrante para usted) – gnovice

+3

¿Qué es en realidad después de aquí? ¿Argumentos en contra de LabVIEW para ayudarlo a construir un caso en su contra? intenta cambiar tu mente? ¿o que? – nekomatic

+2

@nekomatic, ninguno. – Anzurio

Respuesta

25

Labview es fantástico si tiene hardware de National Instruments y desea hacer algo como adquirir, trazar y registrar los datos.

Cuando comience a hacer interfaz con 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 comenzamos a escribirlos en .NET e interconectarlos a Labview.

Al final terminamos eliminando Labview todos juntos y utilizando NI Measurement Studio para Visual Studio para darnos todos los hermosos controles NI (trazado 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 del código Labview puede ser demasiado complejo y es imposible comentar, depurar y hacer extensible cualquier cambio futuro. Sugiero echar un vistazo a Measurement Studio para Visual Studio y usando su lenguaje .NET favorito con los lindos controles NI.

+8

Si "el cableado entre los módulos se vuelve complicado cuando comienza a interactuar con dispositivos personalizados", parece que no ha organizado y encapsulado los diferentes niveles de funcionalidad dentro de los subVI. Como otros han notado, es fácil hacer un lío con LabVIEW si lo haces mal, pero no es tan difícil hacerlo bien si te tomas un pequeño problema para aprender. – nekomatic

+6

He intentado hacer esto de varias formas en Nekomatic, pero realmente no hay forma de hacer que un conjunto sea un evento, con un vistazo dentro de él, que tiene unas pocas condiciones para parecer bonito. La mayoría de mis problemas vienen con el mantenimiento del "código" Labview hecho por científicos con poca experiencia de codificación para hacer su trabajo (porque así es como se comercializa), y sin cuidado y atención ¡su cableado se vuelve loco muy rápido! – Fuzz

+4

Si entendí tu intento de explicar lo que estabas tratando de hacer, podría ayudarte. Estoy completamente de acuerdo con usted acerca de codificadores inexpertos que hacen un desastre, pero eso no significa que LabVIEW no sea una buena herramienta para las personas que desean escribir un buen código. – nekomatic

17

Mis dos experiencias con "alternativas gráficas [s] a la programación basada en texto tradicional" han sido terribles. Encuentro que estos lenguajes son lentos de usar, difíciles de editar e inexpresivos. Depurarlos es una pesadilla. Y no ofrecen ventajas reales.

Desde luego, ha pasado bastante tiempo desde que miré uno, pero las opiniones de los demás que les pregunté han sido tibias, así que nunca me tomé el tiempo de mirar nuevamente. Las razones para mirar nuevamente son bienvenidas y se tomarán en cuenta ...

+3

Supongo que esta es una respuesta honesta y literal a la pregunta, pero no veo que agregue mucho a un debate sobre los méritos de LabVIEW. – nekomatic

+0

No tengo experiencia con las versiones anteriores de LabVIEW pero en las versiones recientes, es extremadamente fácil depurar su sistema (software/hardware). –

6

Pensé que LabVIEW era un sueño para la programación de FPGA. Los bloques ejecutables independientes simplemente ... funcionan. En general, uso LabVIEW para varias tareas de interfaz con mi hardware DAQ y FPGA, pero eso es todo. Me parece (una vez más) que este es el punto fuerte de LabVIEW y la razón por la que fue construido, pero fuera de esa arena 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 está tan mal para hacer tu trabajo. He visto a varias personas darse por vencidas antes de pensar que la curva de aprendizaje era permanente o algo así.

Recogiendo un monitor de 30" hizo una gran diferencia

sé una cosa que la gente no les gusta es la integración de control de versiones

Editar:.. LabVIEW/hardware es hella caro para "sólo para el uso de diversión". Se me cayó $ 10K en su hardware (precio de estudiante) y obtuvo el software de forma gratuita desde la escuela para la fabricación de juguetes en la casa.

+2

"hardware es * hella * caro" AFAIK que es cierto para todos los engranajes DAQ decentes. – dmckee

0

me hago usar LabVIEW en casa, ya que es parte de Lego Mindstorms, que mi hijo ama. Y realmente me gusta la manera de componer sistemas como este.

Sin embargo, en mi trabajo (sistemas integrados), generalmente es restrictivo. Pero también aquí, yo estoy tratando de moverse hacia arriba en la abstracción: - control y comportamiento de los estados: el 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 la documentación de diseño &; no solo el código de tipeo La notación gráfica elimina muchas molestias y, en general, es mucho más rápida si la herramienta es lo suficientemente potente para la complejidad en cuestión. Así que espero que este tipo de herramientas gane más popularidad en los próximos años a medida que maduren y las personas se familiaricen con ellas.

2

Usamos 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 mide de 15 a 80 voltajes diferenciales y controla cámaras ambientales, controladores de flujo másico y varios dispositivos seriales LabVIEW es más que capaz.

La interconexión con dispositivos personalizados puede se simplificará en gran medida al usar el asistente del controlador de instrumentos NI para crear VI reutilizables, interactuando con dll personalizados si es necesario. En una serie de proyectos, hemos creado dichos controladores para hardware personalizado y, una vez creados, son reutilizables en proyectos futuros sin modificaciones.

Uso de estructuras impulsadas por eventos Las interfaces de usuario son receptivas y regularmente utilizamos aplicaciones de LabVIEW para interactuar con una base de datos.

Cualquiera que sea el entorno de programación que elija, es el proceso de diseño de la aplicación que más importa. Estoy de acuerdo en que puedes crear diagramas de bloques realmente horribles e ilegibles en LabVIEW, pero también puedes crear código ilegible en Visual Studio. Con un poco de pensamiento y la planificación de un diagrama de bloques de LabVIEW se pueden hacer para caber en un solo 24" monitor con un montón de espacio para añadir comentarios.

me gustaría utilizar LabVIEW sobre Visual Studio para la mayoría de los proyectos.

0

I han estado usando LabVIEW durante aproximadamente dos años para desarrollar la automatización. Si se les presta la debida atención y un diseño adecuado, podemos desarrollar una aplicación que se pueda mantener y realmente buena en LabVIEW. Creo que esto es igual para todos los demás idiomas que he visto. código incorrecto en LabVIEW principalmente de personas que lo usan solo para desarrollar una automatización de trabajo rápida y sucia. En mi humilde opinión, la programación gráfica es mucho más fácil de codificar y entender si se hace correctamente. ¡Pero eso me hace sentir 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 cantidad de hardware de NI y usted puede obtener los hardwares de terceros que trabajan 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 compra el software de ellos.

6

Nuestra empresa está utilizando LabVIEW durante los últimos 10 años para medir, controlar y reportar nuestros temas (trenes).
Recientemente hemos comenzado a usar LabVIEW como GUI para bases de datos con muchos datos, los poderes de LabVIEW con las nuevas características recientes (Classes, XControls) permiten crear este tipo de GUI por una fracción de los costos de desarrollo en otras plataformas. Si bien no necesitamos programadores externos a la tasa de consultoría.

Ton

2

pero la gente no usar LabVIEW para fines distintos de 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 clientes de NI.

Sin embargo, usted puede hacer muchas cosas diferentes con LabVIEW, como programar un robot que realice una gran cantidad de análisis de imágenes, y luego twittear los resultados. Echa un vistazo a los videos de NI Week 2009 en you-tube, y verás qué poderosa es esta herramienta. Por ejemplo, existe la posibilidad de escribir código y desplegarlo en ARM MCU (vea esto Dev Monkey article desde 2009.08.10).

Y, por último comprobar esto LabVIEW DIY group

+4

La cosa es que he visto muchas cosas ordenadas con las herramientas equivocadas. La pregunta no es si LabView puede usarse para X, sino si sería una buena idea hacerlo si tuviera otras herramientas. –

1

He estado pensando acerca de esta cuestión durante décadas (sí, desde 1989 ...)

Al igual que todos los lenguajes de programación, LabVIEW es una herramienta de alto nivel utilizado para manipular el flujo de electrones. A menos que seas un purista y te niegues a utilizar cualquier cosa que no sea una placa de prueba y cables; los transistores, los circuitos integrados y los lenguajes de programación son probablemente una buena cosa si desea construir algo de alguna consecuencia.

Pero, como todas las herramientas de alto nivel, simplemente empuñar una no lo convierte en un artesano profesional. En la época de soldadores, amplificadores operacionales y 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 obtenerlo justo antes de compilarlo y ejecutarlo. 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. De vuelta en el día, buscando su plantilla de diagramación de flujo y desarrollando el diagrama de un sistema de información bien equilibrado fue la parte de arte y belleza del trabajo. Solo después de tener el diagrama de flujo revisado en la mano, incluso consideraría trabajar duro a través del trabajo tedioso de perforar 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 para usted. No es necesario luchar a través de la sintaxis del lenguaje de texto A o el idioma B.

Con una herramienta tan poderosa, los principiantes pueden crear grandes programas de trabajo, lo que implica un cierto nivel de artesanía profesional, ya que se ejecuta. 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.

Las personas a menudo señalan que "LabVIEW solo es bueno para desarrollar sistemas grandes de adquisición de datos". Quizás esas personas deberían considerar la profesionalidad de los científicos e ingenieros que están trabajando en la adquisición de datos. Si saben lo suficiente como para obtener los cables adecuados para los sensores y transductores, puede ser una buena apuesta que también sean expertos en el desarrollo de diagramas de cableado de LabVIEW.

11

Labview se puede utilizar para crear proyectos de software grandes y complejos. Labview es, sin dudas, mucho más divertido de usar que un lenguaje basado en sintaxis. He programado simulaciones matemáticamente densas y dinámicas usando labview. Las versiones más nuevas de Labview incluyen muchas características interesantes, especialmente para utilizar múltiples procesadores. Me gusta Labview mucho. Pero no se lo recomiendo a nadie.

Desafortunadamente, es una pesadilla absoluta para cualquier cosa que no sea la simple adquisición y visualización.Algún día puede estar lo suficientemente desarrollado como para ser considerado como una alternativa viable a los lenguajes basados ​​en texto. Sin embargo, los desarrolladores de NI han optado sistemáticamente por ignorar los tres problemas fundamentales que aquejan a LabVIEW.

1) Es inestable y está 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 pérdidas de memoria o errores matemáticos en funciones básicas.

2) La documentación es atroz. En la mayoría de los casos, cuando busca ayuda con una función labview en el archivo de ayuda local, encontrará una oración que simplemente repite el nombre del elemento sobre el que intenta encontrar detalles. p.ej. Un usuario busca el archivo de ayuda en la configuración del modo de filtro de textura y lo único que se escribe en el archivo de ayuda es "Modo de filtro de textura: selecciona el modo utilizado para el filtrado de texturas". Gee, gracias. Eso aclara las cosas, ¿no? El problema es mucho más profundo en eso; Con bastante frecuencia, cuando le preguntas a un representante técnico de los instrumentos nacionales que proporcione detalles críticos sobre la funcionalidad de laboratorio 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éanme, 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 enredo confuso y enrevesado, debe rutinariamente (cada pocas operaciones) emplear estructuras como clusters, y subvisores y controles definidos de tipo gigante (que pueden extenderse a través de 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 datos en la memoria y realizar operaciones gratuitas, todo por el simple hecho de evitar que el diagrama parezca espagueti de colores del arco iris sin ningún comentario o texto a la vista. La programación en labview es como jugar pictionary con el diablo. Imagine su proyecto de software gigante escrito como un diagrama de flujo de tamaño de pared sin palabras en absoluto. Ahora imagina que todas las líneas se cruzan entre sí mil veces, por lo que rastrear el flujo de datos es completamente imposible. Acabas de imaginar la forma más natural y eficiente de programar en labview.

Labview es fresco. Labview está mejorando con cada nueva versión. Si National Instruments continúa mejorando, será un gran día como un 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.

+0

1) La estabilidad ha mejorado mucho desde LabVIEW 2011 – CharlesB

+0

2) completamente en desacuerdo con la documentación, hay toneladas de recursos y ayuda en el foro – CharlesB

+0

3) estoy de acuerdo hasta cierto punto; mucha gente ha contribuido a los patrones de diseño para grandes aplicaciones, y una jerarquía de objetos cuidadosamente diseñada puede ayudar a mantener la complejidad relativamente baja. – CharlesB

0

He usado LabView durante unos 10 años. Es brillante para la preparación científica, es decir, como Matlab o Simulink, pero 10 veces mejor. Si tiene problemas, entonces está haciendo algo mal. Lleva tiempo aprender como cualquier idioma. En cuanto a usar .Net en su lugar, ¿estas personas están en el mismo planeta? ¿Por qué te tomas la molestia de escribir todo desde cero cuando puedes decir que levantas una FFT, etc. y usas un código ya escrito? .NET está bien para programas simples pero no tan buenos para el procesamiento científico. sí, puedes hacerlo, pero no sin montones de complementos para gráficos, etc. Prorgamming en G es mucho más fácil que el texto basado en problemas científicos. Por supuesto, puede programar en c si está interactuando y usar el dll. Ahora hay cosas para las que no utilizaría LabView: el reconocimiento de voz, por ejemplo, puede ser un poco desordenado en la actualidad. Más al punto, ¿por qué a la gente le gusta la programación en forma de texto obsoleto cuando hay una alternativa fácil. Es como si la gente quisiera complicar las cosas para justificar su trabajo de alguna manera. Simplificar Simplificar!

+2

Buenos puntos. El caso que está creando es el mismo caso que los desarrolladores de .NET hacen a los desarrolladores de C++.Por qué complicar las cosas, escríbelas desde cero, cuando se realizan tantas cosas como eventos, recolección de basura, generación de código, etc. Sin embargo, todos debemos recordar que, a veces, realmente necesita ese bajo nivel de acceso arenoso bajo las sábanas. –

0

Alguien dijo que LabView solo se demanda en el campo de Automatización. Simplemente no escribir en absoluto. Tiene aplicaciones en Procesamiento Digital de Señales, Sistemas de Control, Comunicaciones, Basado en la Web, Matemáticas, Procesamiento de Imágenes y más. Comenzó como un método de adquisición de datos e inventaron el nombre Virtual Instrumentation, pero ahora ha ido mucho más allá. Es un lenguaje de programación científica con una interfaz gráfica insuperable.Está mucho más allá de Simulink y si te gusta Matlab, tiene un tipo de scripts de Matlab integrados para aquellos que les gusta esas formas de programación. Está evolucionando todo el tiempo. Lo único que encontré difícil fue escribir código para el Compact Rio: 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.

9

I ** he estado escribiendo en LabVIEW durante casi 20 años. Desarrollo sistemas de prueba automatizados. He desarrollado, RF, Vison, digital de alta velocidad y muchos sabores diferentes de sistemas mixtos de prueba de señal. Yo era un programador de "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 mucho entrenamiento para aprender a construir una aplicación grande que es fácil de mantener y limpia con un 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. Cada año todos los programadores de LabVIEW terminaron antes de que terminara la primera persona de LabWINDOWs. He desafiado a muchos de mis amigos dedicados a la programación basada en texto a tiroteos y todos admiten que no tienen ninguna posibilidad, incluso si dejo que definan el problema del software.

Entonces, creo que LabVIEW es una gran herramienta de programación. Definitivamente es el camino a seguir si está interactuando con cualquier tipo de hardware 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 conectamos un montón de bloques, ¿no? Me resulta gracioso cuántos programadores basados ​​en texto se niegan a escucharlo, ya que están tan orgullosos del desorden de código de texto que han creado que solo ellos pueden entender. Un buen programador en cualquier idioma debe escribir un código que otros puedan leer fácilmente. Escribir código excesivamente complejo que es imposible de seguir no hace que el programador sea un genio. Significa que el programador es un "compliator" (alguien que puede tomar un problema simple y complicarlo). Creo en el principio de KISS (MANTENGALO ESTUPIDO SIMPLE).

De todos modos, hay mi granito de arena vale la pena! **

+1

¿Cómo se hace la revisión del código? La programación no se trata solo de lo rápido que se puede escribir, sino de cómo interactúa con un gran corpus de código y qué tan bien otros pueden usar/extender lo que usted hizo. – EngrStudent

3

empecé a usar LabVIEW en un laboratorio de física de la universidad. Inicialmente, pensé que era lento y engorroso en comparación con otros lenguajes basados ​​en texto. Era muy 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í sobre el uso de sub-vi's y paquetes. ¡Que diferencia! En este punto, estaba usando labview para funciones de muy alto nivel. Estaba tomando entrada sin procesar desde una cámara, usando todo tipo de filtros de imagen y procesamiento para finalmente analizar las líneas en una carretera para que un vehículo pudiera conducir por sí mismo sin conductor: era para el DARPA URBAN CHALLENGE. También estaba generando mapas a partir de datos de waypoints de texto, realizando funciones de análisis de alto nivel, y un montón de otras aplicaciones que no tenían nada que ver con el procesamiento de datos de los dispositivos de entrada. Fue realmente muy divertido. y rápido.

Después de dejar la universidad, ahora vuelvo a utilizar idiomas basados ​​en texto. He estado usando: PHP, Javascript, VBA, C#, VBscript, VB.net, Matlab, Epson RC +, Codeigniter, varias API, y estoy seguro de que algunos otros. A menudo me siento muy frustrado por la cantidad de sintaxis que tengo que memorizar para poder programar con cualquier velocidad significativa. Me resulta molesto tener que cambiar las escuelas de pensamiento basadas en el lenguaje que estoy usando ... ¡cuando todos los lenguajes de programación esencialmente hacen lo mismo! Necesito un segundo monitor solo para tener la ayuda activa en todo momento, así puedo encontrar la sintaxis para las mismas funciones en diferentes idiomas. Extraño mucho Labview, es una lástima que sea tan caro que de lo contrario lo usaría para todo.

La programación basada en gráficos creo que tiene un gran potencial. Al no estar limitado por la sintaxis, puede centrarse en la lógica en lugar del código. Labview en sí mismo todavía puede estar 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.

Cuestiones relacionadas