为什么使用LabVIEW？
我正在学习使用 LabVIEW 作为我的荣誉项目的一部分，并且想知道图形编程语言相对于文本编程语言有什么好处？
I am learning to use LabVIEW as part of my honours project, and was wondering what benefits the graphical programming language has over a textual one?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
对我来说，LabVIEW 的优势不在于图形还是文本。
这是数据流与命令式的对比。
数据流编程适合并发，因为您的执行被建模为黑匣子，当输入是时执行有效，其输入/输出连接在一起。 这与包含如何修改它的指令列表的隐式状态相反。 （宽松地解释“kipedia，上面链接的文章更好。）
每个黑盒都可以在单独的核心/处理器/节点上运行，如果您以数据流方式组织程序，这将为您提供有效的自由并发性。
不幸的是（这对于一般数据流编程来说是一个严重的缺点）可视化和编辑数据流程序的最佳方式是图形化的，而不是文本化的。 这使得使用修订控制和代码生成器等工具变得非常困难。
问题是：对于您和您的项目来说，数据流的利大于弊吗？
To me, the benefit of LabVIEW is not in graphical vs. textual.
It's dataflow vs. imperative.
Dataflow programming lends itself to concurrency, because your execution is modeled as black boxes which execute when their inputs are valid, whose inputs / outputs are wired together. This as opposed to implicit state with a list of instructions on how to modify it. (Loosely paraphrasing 'kipedia, the article linked above is better.)
Each black box can run on a separate core/processor/node, which gives you, effectively, free concurrency if you organize your program the dataflow way.
Unfortunately (and this is a crippling downside to dataflow programming in general) the best way to visualize and edit dataflow programs is graphical, not textual. This makes using tools such as revision control and code generators very difficult.
The question is: Do the pros of dataflow outweigh the cons, for you and your project?
使用 LabVIEW 进行图形化编程的主要优点之一是源代码与电路图非常相似，因此对于电气/电子工程师来说，这是一种非常容易上手的语言。 这就是 LabVIEW 在 EE 丰富的数据采集和自动化领域如此受欢迎的原因之一。
我发现的另一个优势是原始的开发速度。 您可以从可用的前面板控件面板中组装 GUI，这与在 Visual Studio 中的操作方式非常相似。 源代码以类似的方式编写，具有许多预定义的组件，您可以从菜单中放入这些组件并将其连接在一起。
第三个优点是与硬件的兼容性。 NI 的主要业务是数据采集硬件，他们不遗余力地确保其所有产品都可以直接与 LabVIEW 软件进行通信。 数据采集和自动化控制行业的许多其他硬件供应商也在做同样的事情。
One of the main advantages to graphical programming with LabVIEW is that the source code is very similar to circuit diagrams, so it's a very easy language for electrical/electronics engineers to pick up. This is one of the reasons that LabVIEW has become so popular in the data acquisition and automation fields, where EEs are plentiful.
Another advantage that I found was raw speed of development. You assemble your GUIs from a palette of available front panel controls, very similar to how you do it in Visual Studio. The source code is written in a similar manner, with many pre-defined components that you can drop in from menus and wire together.
A third advantage is compatibility with hardware. National Instruments main business is data acquisition hardware, and they go to great lengths to make sure all of their products can communicate with LabVIEW software straight out of the box. Many other hardware vendors in the data acquisition and automation control industry are doing the same.
这一切都与设备驱动程序和用户能力有关。 NI (Labview) 拥有一套得到良好支持且易于连接的实验室设备驱动程序。 测试操作员（不是开发人员）需要一个带有绿色/红色通过/失败大按钮的 GUI。 我在 cygwin 中通过 python 实现了复杂的自动化。 Labview 开发人员能够调用 cygwin/python 系统并对日志文件进行数据挖掘。 所以你可以两者都做。 python 系统是可移植的、可维护的、可扩展的、可用的，最重要的是，免费。
Its all about the equipment drivers and user capabilities. NI (Labview) has a well supported set of lab equipment drivers that are easily interfaced. A test operator (not a developer) needs a gui with a big green/red pass/fail button. I've implemented complicated automation via python in cygwin. A Labview developer was able to invoke the cygwin/python system and data mine the log files. So you can do both. The python system is portable, maintainable, extensible, usable and best of all, free.
我之前使用 Labview 来计算参数来调整 nMRI 机器。 它们的存在是因为从理论上讲，对于缺乏编程语言经验的人来说，创建程序更容易。 控制流和决策结构可以以图形方式排列，并且可以在所需的位置输入公式。
对于教授和实验室助理...很有帮助。
对于真正的软件开发人员......用另一种语言编写会更容易。
I've used labview before for calculating parameters to tune an nMRI machine. They exist because in theory it is easier for someone with little programming language experience create a program. The control flow and decision structures can be arranged graphically and they can type in their formula's where they want.
For professors and lab assistants...helpful.
For real software developers...it would be easier to write in another language.
我过去使用过 LabView，用于数据采集、虚拟仪器等 - 没有什么比它更好的了。 我上次使用它是 10 年前，此后我所见过的一切都无法与 90 年代中期的情况相媲美。
I've used LabView in the past, and for data acquisition, virtual instrumentation, etc - there is nothing better. The last time I used it was 10 years ago, and nothing I've seen since has matched where it was in the mid 90s.
在我看来，LabVIEW 的一些优点是：
内置的用户界面组件，如按钮、图形等，实际上不需要任何编程； 您只需将它们放在前面板上，数据端子就会出现在框图上。
有一个用于数据采集硬件和测试仪器的大型驱动程序库。 如果您的任务基本上是从这些数据中获取数据并在其上放置用户界面，那么您几乎无需编程即可实现它。
多个任务的并行执行是自动处理的 - 在图表上放置两个独立的循环，它们将同时执行。 这通常是数据采集和控制应用程序的要求。
许多人，包括“真正的软件开发人员”，都认为图形范式比文本范式更适合他们思考和可视化软件的方式。 毫无疑问，文本语言在某些方面比 LabVIEW 更适合（在本网站的另一场讨论中对此进行了介绍），但在 LabVIEW 适合的地方，它非常擅长完成工作。
Some advantages of LabVIEW in my view are:
The built-in user interface components such as buttons, graphs etc literally require no programming whatever; you just place them on the front panel and the data terminals appear on the block diagram.
There is a large library of drivers for data acquisition hardware and test instruments. If your task is basically about getting data to and from these and putting a user interface on it then you can achieve it with almost no programming.
Parallel execution of multiple tasks is handled automatically - place two independent loops on the diagram and they will execute simultaneously. This is often a requirement in data acquisition and control applications.
Many people, including 'real software developers', feel that the graphical paradigm suits the way they think and visualise their software better than the textual one. There are undoubtedly things that text languages are better for than LabVIEW (covered in another discussion on this site) but where LabVIEW is suitable it's very good at getting the job done.
对我来说，这取决于你对什么感到满意，如果你对基于文本的语言感到满意，你可能会发现 Labview 只是引入了另一个学习曲线。 除非您有学习和使用 Labview 的特定目标，否则我认为您的项目没有任何意义。
另一方面，如果您不太熟悉基于文本的语言，我倾向于认为 Labview 更容易掌握和学习，特别是对于非软件工程师而言。
我经常使用基于文本的语言进行测试工程以及 Labview 和 TestStand，对我来说，更多的是关于还有谁会使用我的软件，而不是关于我自己。 一些公司有多名经过 Labview 培训的人员，而其他公司则更喜欢使用基于文本的语言进行编写。 在全公司范围内，培训另一种语言可能非常昂贵，并且它改变了公司内职位的招聘要求，因此一些公司实际上“锁定”于一种范式或另一种范式。 我想说，如果你打算在这个行业工作，最好的选择就是精通这两方面，这样你就可以灵活变通。 如果是这样的话，而且你有时间学习其中之一，我会说在你最不舒服的地方工作并扩大你的知识广度，这就是学校的目的，对吗？
To me it comes down to what you are comfortable with, if you're comfortable in text based languages, you'll likely find that Labview just introduces another learning curve. Unless you have a specific goal to learn and use Labview I see no point for your project.
On the other hand, if you aren't particularly comfortable in text-based languages, I tend to have the opinion that Labview is easier to pick up and learn, particularly for non software engineers.
I use text based languages for test engineering as well as Labview and TestStand quite often and for me it's more about who else will use my software than it is about me. Some companies have several Labview trained individuals and others prefer to write in text based languages. Training for another language can be very costly on a company-wide scale and it changes the hiring requirements for positions within a company so some companies are virtually 'locked-in' to one paradigm or the other. I would say your best bet if you intend to work in the industry is to be versed in both, that way you are flexible. If that's the case and you have the time to learn either, I'd say work in the one you're least comfortable with and expand your breadth of knowledge, that's what school is for right?