que nxg full español entre diferencias diferencia descargar características aplicaciones alcances labview

nxg - ¿Qué características específicas de LabVIEW son frustrantes para usted?



labview nxg que es (19)

Lo que más me frustró fue que me quitó las manos del teclado. Soy un mecanógrafo táctil y puedo programar con bastante rapidez en un lenguaje de texto. LabVIEW le obliga a usar el mouse para seleccionar VIs y nodos de programa de sus menús, y para conectar los nodos entre sí. Aunque esto es realmente rápido y conveniente si eres un ingeniero eléctrico, acostumbrado a diseñar circuitos en un entorno gráfico, es una pena si estás acostumbrado a escribir tu código.

Divulgación: Han pasado aproximadamente dos años desde la última vez que utilicé LabVIEW, por lo que estos dos próximos pueden ser arreglados por ahora.

La siguiente molestia fue el control de la fuente. Una de las cosas que hace más a menudo con su repositorio de control de código fuente es diferir su versión actual con una versión anterior para encontrar los cambios. No puedes hacer eso con un lenguaje gráfico como LabVIEW. Los sistemas de control de revisiones populares como CVS y SVN usan herramientas de diferencia basadas en texto detrás de escena. Espero que National Instruments haya creado su propia solución de control de revisión para todos ustedes que todavía están usando LabVIEW.

La última molestia que tuve fue la falta de características reales del lenguaje orientado a objetos. LabVIEW 6i, la última versión que utilicé, estaba basada en objetos en el mejor de los casos. Nadie podría afirmar con exactitud que estaba orientado a objetos. No pude crear una jerarquía de clases real utilizando herencia, y el polimorfismo se reservó solo para unos pocos tipos incorporados. Me doy cuenta de que 6i fue hace dos versiones, así que realmente espero que esto se solucione.

Por favor tengan paciencia conmigo: este no es un debate lingüístico o una llama. Es una verdadera solicitud de opiniones.

Ocasionalmente, tengo que ayudar a educar a un codificador de texto tradicional sobre cómo pensar en LabVIEW (LV). A menudo, durante este proceso, escucho acerca de cómo LV apesta. Rara vez es esta idea acompañada de observaciones racionales que no sean "¡Language X es mucho mejor!". Si bien esta afirmación les satisface, no me ayuda a comprender qué es lo que los frustra.

Entonces, para aquellos de ustedes con LabVIEW y experiencia en el lenguaje de texto, ¿qué cosas específicas acerca de LV los vuelven locos?

------ Resúmenes -------

¡Gracias por todas las respuestas! Algunos de los problemas se responden en los comentarios a continuación, algunos existen en otros sitios, y algunos son solo problemas genuinos con LV. En el espíritu de la pregunta original, no intentaré responder a todas estas preguntas aquí: revise LAVA o el sitio web de NI , y se sorprenderá gratamente de cuántas de estas cosas se pueden superar.

  • Concurrencia involuntaria
  • Sin acceso a las herramientas tradicionales de manipulación de texto
  • Control de código fuente binario solo
  • Difícil de ramificar y fusionar
  • Demasiadas ventanas abiertas
  • El texto tiene una sintaxis más clara / clara / más expresiva
  • La codificación limpia requiere mucho tiempo y manipulación
  • Sistema de paleta / API grande y de difícil acceso
  • Requiere mouse
  • Espaciado de nombres de archivo: no hay archivos duplicados con el mismo nombre en la memoria
  • Los objetos LV son nativamente solo por valor
  • Requiere entorno de desarrollo para ver el código
  • La falta de zoom
  • Inicio lento
  • Memoria de cerdo
  • El código "Gigante" es difícil de trabajar
  • El bloqueo de UI es fácil de hacer
  • Trackpads y LV no se mezclan bien
  • La manipulación de cadenas está gráficamente hinchada
  • Personalización de IU limitada
  • Primitivos "ocultos" (sí, estos existen)
  • La falta de capacidad de metaprogramación oficial (aunque no por mucho más tiempo)
  • La falta de soporte Unicode

Escribí un programa (en C ++) para controlar un dispositivo rs232 desde una computadora pero me pidieron que proporcionara un controlador o Vi o lo que sea para labview. Descargué LabVIEW con plena confianza de poder hacer algo rápidamente. (Soy un graduado de ciencia ficción de una escuela de hiedra, he programado en C ++ durante 15 años, aprendí y usé C, Scheme, C #, Java, etc. - esto debería ser una obviedad)

También descargué una aplicación de muestra y documentación para labview.

Estaba horrorizado por el resultado. Labview es ENORME, LENTO y no intuitivo. No sigue ninguno de los paradigmas a los que estoy acostumbrado, ya sea con MFC o Visio o Rational Rose o VB, etc. Tratar de encontrar la documentación correcta también fue una experiencia difícil. Hay tanto por ahí que uno necesita entender Labview solo para saber por dónde empezar.

Es un gran programa que hace tanto. Sin alguien que le muestre cómo usarlo es muy difícil. Me autoaprendí muchas cosas, pero hasta ahora, labview me ha eludido. (dado que no he pasado tanto tiempo como debería, pero hasta el momento fue una experiencia frustrante)

Para resumir, es enorme, lento y no intuitivo. Los documentos son abrumadores.

(Todavía tengo grandes esperanzas un día para terminar el proyecto)

Azim,

Estarás contento con la versión 8.6 que tiene dos características que atacan tu frustración:

  • Diagrama de Auto Clean
    Una herramienta para limpiar el código desordenado.
    Sin embargo, se observa que esta herramienta no se debe utilizar en el código limpio ( foros LAVA y NI ).
  • Quick Drop
    Una herramienta para seleccionar nodos y VI mediante el uso de atajos de teclado, un video en Youtube muestra la caída rápida en acción. Después de 1:07 verá la herramienta Auto Clean Up.

Tim, ¿a qué te refieres con eso?

Labview es ENORME, LENTO y no intuitivo

Si tiene ejemplos y mejoras, hágaselo saber.
Si tiene problemas para construir un controlador, eche un vistazo a los controladores enviados (por ejemplo, para un multímetro). Trate de encontrar un instrumento similar con un controlador y ajústelo según sea necesario, sé con seguridad que NI está dispuesto a ayudarlo o que otros lo harán. Ven con tus preguntas a LAVA o foros de NI .
El Paradigma diferente que usa LabVIEW (flujo de datos) puede ser la solución para la programación paralela (al menos eso es lo que NI nos dice), Visio no es un languange de programación, perdón por dar la noticia. Usar un libro para principiantes (LabVIEW para todos) es un muy buen comienzo.

Tonelada

LabVIEW hace que la implementación de simultaneidad / programación paralela sea más fácil, verdadera. Sin embargo, no hace que la depuración, las pruebas o la similitud entre concurrencia / paralelismo sean más fáciles. Todavía puede escribir código concurrente con errores en LabVIEW, y (como en cualquier idioma, plataforma o conjunto de herramientas) no hay una bala de plata o una varita mágica que haga que la concurrencia sea "solo trabajo".

En todo caso, debe tener más cuidado con la simultaneidad, ya que si no piensa (y declara) explícitamente, LabVIEW puede hacer cosas concurrentes que usted no esperaba.

Otros beefs: no es texto. Representar el flujo de datos de una manera que tenga sentido significa un lenguaje gráfico, lo que significa que no puede usar las herramientas que hemos tenido durante décadas para manipular texto, todo desde sed a emacs. También significa que las aplicaciones de control de código fuente deben tratar su código como binarios opacos, en lugar de como ... código fuente. Esto, a su vez, hace que la ramificación y la fusión sean un ejercicio de dolor.

Una aclaración sobre las "diferencias gráficas" de LabVIEW:

LabVIEW no puede tener múltiples copias de un VI con el mismo nombre en la memoria simultáneamente.

Hasta la versión 8.5, esto significaba que si quería modificar My VI.vi revisión 2 contra la revisión 1, tenía que (manualmente) crear una copia con un nombre diferente, abrir eso y luego decirle a LabVIEW que lo compare con mi original.

Tengo entendido que automatizaron este proceso en 8.5, para darte una especie de herramienta de combinación de 3 vías.

No ser capaz de acercar y alejar el diagrama de bloques. Sí, los diseños deben guardarse en una sola pantalla o desplazarse en una sola dirección, pero obtuve el código de proveedores de terceros que deben usar monitores de 50 pulgadas para desarrollarse: ¡el código continúa para siempre en todas las direcciones!

(23 de enero de 2009): utilice Ver-> Ventana de navegación para ver a vista de pájaro todo el diagrama (paneles frontal y de diagrama). Esto podría ser útil cuando LabVIEW decide poner un nuevo control creado desde el diagrama de bloques en una ubicación aleatoria en el frente.

Un elemento por encima de todos los demás:

La falta de herramientas para hacer Desarrollo impulsado por prueba

Si me puedo relajar por un momento, este es un gran problema ahora que no voy al baño sin escribir una prueba.

EDIT :: Me llevo todo, echa un vistazo a http://forums.jkisoft.com/index.php?showtopic=973 . ¡Hasta ahora funciona genial!

1. Los objetos LaVIEW no se pasan por referencia.
2. No existe otro visor (especialmente el gratuito) para ver los diagramas de bloques.
3. Necesita abrir una gran cantidad de ventanas para ver un proyecto. Me gustaría que fuera MDI para que se reduzca la cantidad de ventanas.

Labview es ideal para controlar hardware. He escrito varias aplicaciones de Labview para recopilar datos (voltaje analógico de varios sensores) y hardware de control (principalmente motores piezoeléctricos). Labview hace que sea bastante fácil realizar varias tareas en paralelo.

Ahora para responder a tu pregunta. ¿Qué encuentro frustrante sobre Labview?

  1. Tiempo dedicado a organizar el diagrama de bloques

    • moviendo los cables alrededor
    • nodos organizadores

    Tal vez, dado que soy autodidacta, paso demasiado tiempo tratando de limpiar los cables e intentando seguirlos en un intento de descifrar qué datos llevan y hacia dónde se dirigen.

  2. Apuntar y hacer clic en la cosa de la caja de herramientas buscando el nodo / función que quiero colocar en el diagrama de bloques o panel frontal.

Debería simplemente escribir el nombre de la función / método que necesito con los parámetros y ponerme en marcha en lugar de ...

"hmmm ... necesito calcular el RMS vi ahora, ¿dónde estaría eso? ahora necesito una operación AND. OK, vuelva al nivel superior, a funciones lógicas, cuál de ellas es Y oh, correcto, es esa. ¡Conéctalo y prueba! ¡Eso solo tomó 15 minutos! "

Pero probablemente haya una manera más eficiente de trabajar con Labview, ¡simplemente no lo sé!

Un hoyo característico: no hay instalaciones de metaprogramación de las que hablar, IIRC. Es genial para construir cosas, siempre y cuando lo que sea que estés construyendo esté en el mismo nivel de abstracción que los diseñadores de LV pensaban que querías.

En los últimos 20 años, me he mudado (generalmente) a niveles cada vez más altos de abstracción. Durante aproximadamente un año, LV estaba limpio, porque era un poco más alto que lo que estaba usando. Luego pasé volando, y LV parece más anticuado cada año.

Labview se puede usar 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 dinámicas densas matemáticamente 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 solitaria que simplemente reafirma el nombre del elemento sobre el que intenta encontrar detalles. Por ejemplo, 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 que 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, sub-vis y controles definidos 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 forzar 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 se vea como 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 genial. 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.

  • Docenas de ventanas abiertas son un dolor definitivo.
  • Los vi que fueron editados por alguien con un monitor más grande tienen que ser redimensionados.
  • La interfaz de usuario se bloquea temporalmente cuando se procesan otras cosas (tal vez aún no he descubierto el potencial de subprocesos múltiples de labview)
  • la edición en una computadora portátil con un panel táctil es horrible, (no olvides el pequeño problema del monitor).
  • la manipulación compleja de cadenas toma acres de espacio (hay un nodo funcional para ecuaciones, ¿por qué no un nodo regex para la manipulación de cadenas?)
  • a veces encuentro vi primitivos en el código de otras personas que no puedo encontrar en ningún lugar de los menús.
  • La interfaz de usuario solo se puede personalizar a un punto.

Me gustaría agregar que creo que Labview es notablemente poderoso y bien diseñado. muy raramente me encuentro con algo que me hace desear tener un idioma diferente.

La falta de Diff y Merge (a excepción de la licencia "profesional")

Usamos SVN y TortoiseSVN en el trabajo. Estoy frustrado porque no puedo hacer una diferencia para ver qué ha cambiado en un archivo. Hacer "diffs" es parte del flujo de trabajo diario cuando se usa SVN, por lo que es frustrante ver que un archivo ha cambiado, pero no tengo idea si fue algo trivial o sustancial. Hacer diffs también permite una revisión sistemática de los cambios.

He oído que "profesional" tiene algún tipo de herramienta diff. Sin embargo, tendré problemas para convencer a la gerencia de que necesitamos profesionales para una característica "diff". Y no he podido leer concluyentemente que realmente se integre sin problemas con TortoiseSVN.

El uso del control de código fuente se considera una de las mejores prácticas de la industria, por lo que sería grandioso que NI lo respaldara completamente, no solo en la licencia "profesional", para que no se vea que NI inhibe la adopción de las mejores prácticas.

Personalmente, creo que LabView es un excelente programa para lo que está diseñado para hacer. Además de heredar un código terrible, que es un problema en cualquier idioma, con buenas prácticas es muy eficiente y rápido para armar todo tipo de sistemas de control, automatización, prueba y medición de procesos. Al igual que la codificación de texto, también existe una buena práctica con LabView: si tienes un VI codificado y desordenado, es realmente culpa del codificador y no del lenguaje. Los lenguajes codificados en texto también pueden estar muy codificados: el programador tiene la responsabilidad de no crear código innecesariamente desordenado u ofuscado.

Si comienza a escribir su código pensando en futuras expansiones, no es difícil crear VI que puedan crecer con las necesidades del programa sin ser engorroso. Igual que el código de texto incorrecto puede convertirse rápidamente en un desastre si lo piratea con una vista a corto plazo, solo para que crezca y deje de serlo. Sin embargo, significa que debe tomarse el tiempo para aprender LabView, al igual que tiene que dedicar tiempo a aprender cualquier idioma o IDE.

Lo más probable es que si LabView está frustrando sus esfuerzos, probablemente debería utilizar algo más para crear su programa, o al menos algo más para esos componentes del programa.

Por ejemplo, si necesita hacer un montón de manejo de cadenas, más de lo conveniente para hackear las funciones de cadenas de LabView, pero realmente quiere o necesita usar LabView para la carne de su aplicación, entonces hay muchas opciones disponibles para usted . Puede codificar fácilmente DLL en algo como C o cualquiera que sea su idioma favorito y luego acceder a esas funciones a través de la interfaz DLL de LabView. Esto se aplica a cualquier tipo de función de alto nivel o abstracta que es incómoda de implementar con las herramientas básicas de LabView.

Esto tiene dos grandes ventajas: primero puede enfocar su codificación de texto simplemente escribiendo funciones o procedimientos. La tarea de construir la aplicación alrededor de sus funciones se vuelve inexistente. Al mezclarlo con LabView, obtienes la segunda ventaja del rápido y potente constructor de IU de LabView y la conectividad de instrumentación.

En términos de control de fuente, lo más importante que puede hacer es flexionar la capacidad inherente de LabView para la modularidad. Si bien no cuenta con herramientas de texto que lo ayuden, por ejemplo cuando intenta clasificar un código heredado desconocido, tiene otras características muy potentes que, de manera abstracta, pueden hacer muchas de las mismas cosas. Probablemente sea el lenguaje más fácil que existe para refactorizar, lo que significa que, en general, se puede refactorizar el código heredado MIENTRAS aprendes lo que hace.

Si va a una fuente de datos y rompe el cable, verá instantáneamente todo a lo que estaba conectado, por ejemplo. La lista de errores le dará una lista completa de todo lo que se rompió debido a una dependencia en esa fuente de datos y podrá trabajar inmediatamente para crear paquetes y clusters para limpiar los espaguetis LabView. Incluso resalta las conexiones de datos rotas en el panel posterior para que pueda rastrear hacia dónde va todo. Puedes encapsular cosas rápidamente en subVIs si está claro que están ensuciando el proceso principal con desorden, etc. Para cuando hayas descubierto lo que hace tu código, estará ordenado y limpio, y de repente se podrá volver a mantener.

La gran excepción a esto es si el programa usó muchos elementos globales innecesarios. Sorpresa: los globales también complican las cosas en LabView. En ese caso, no hay nada que hacer excepto maldecir al idiota que te dejó el desastre. Aún así, no es el fin del mundo.

Supongo, en resumen, lo que estoy tratando de decir es que LabView es un lenguaje muy diferente. Si parece frustrante, no es porque las herramientas no existan para hacer las cosas a las que estás acostumbrado en la codificación de texto, sino simplemente porque a menudo se implementan de maneras radicalmente diferentes. El código de expansión no es un fin en sí mismo, por ejemplo, sino solo un medio para un fin: el propósito es descubrir enlaces y referencias a lo largo del programa. Si bien no puedes gregar el código de LabView, puedes descubrir enlaces y referencias, simplemente se hace de una manera totalmente diferente. Aprendiendo cosas de la curva.

Soy nuevo en LabVIEW. Una característica de barrido del mouse similar a Photoshop (retención de la barra espaciadora, clic izquierdo y arrastre) sería muy intuitiva.

Agradezco LabView de muchas maneras, especialmente la capacidad de conducir fácilmente hardware (bueno, cuando es el hardware de National Instruments, por supuesto), y las características de programación simultáneas. Pero es una mierda contra los lenguajes de programación basados ​​en texto en la navegación por código:

  • cuando navegas por el código, terminas con toneladas de ventanas abiertas, a medida que abres SubVis una y otra vez
  • porque las palabras son más expresivas que los iconos, se ven menos instrucciones en una pantalla, en comparación con los lenguajes de texto, especialmente en sintaxis expresivas, como python
  • no hay manejo de excepciones como lo conocemos en otros idiomas; los errores se expresan en estructuras, se transportan de un VI a otro, y para cada VI debe agregar un if error return; else do stuff if error return; else do stuff código de if error return; else do stuff .
  • No hay forma de detener la depuración cuando se produce un error

Difícil de ramificar y fusionar: el diff no hace un buen trabajo al aislar los cambios, un pequeño cambio en un caso en una estructura de caso puede darte muchas "diferencias". La fusión tiene que hacerse manualmente, por lo que yo sé.

Exige mucho tiempo construir lógicas simples: me parece que las lógicas simples pueden requerir mucho cableado y dibujo, una vez que quieres cambiarlas, tienes que volver a dibujar todo.

En Labview no puedo encontrar a los llamadores de VI si no se abren primero.