文本与图形编程语言

时间:2008-08-17 15:39:58

标签: robotics labview graphical-language

我是高中机器人团队的一员,对于使用哪种语言来编程机器人存在争议。我们在C(或C ++)和LabVIEW之间进行选择。每种语言都有专业。

C(++):

  • 广泛使用
  • 为未来做好准备(大多数编程职位需要基于文本的程序员。)
  • 我们可以扩展去年的C代码库
  • 让我们更好地了解我们的机器人在做什么。

的LabVIEW

  • 更容易可视化程序流(块和线,而不是代码行)
  • 更容易教(据说......)
  • “编程的未来是图形化的。” (这么想?)
  • 更接近一些新成员可能拥有的Robolab背景。
  • 不需要密切了解发生了什么。只需告诉模块找到红球,不需要知道如何。

这对我们来说是一个非常困难的决定,我们已经争论了一段时间。基于每种语言的专业知识,以及您获得的经验,您认为更好的选择是什么?请记住,我们不一定要追求纯粹的效率。我们也希望为程序员的未来编程做好准备。

此外:

  • 您是否认为LabVEIW等图形语言是编程的未来?
  • 图形语言比文本语言更容易学习吗?我认为它们应该同样具有挑战性。
  • 看到我们正在帮助人们学习,我们应该依赖预先编写的模块多少,以及我们应该尝试自己写多少?(“优秀的程序员编写好的代码,伟大的程序员复制了很棒的代码。“但是,首先不值得成为一名优秀的程序员吗?”

感谢您的建议!


编辑: 我想更多地强调这个问题: 团队队长认为LabVIEW更易于学习和教学。 这是真的吗?我认为C可以轻松地教授,而初级水平的任务仍然可以用C.我真的很想听听你的意见。 是否有任何理由认为{}应该比创建“while box”更困难? 这不是直观的程序逐行流动,只是由ifs修改和循环,因为直观的程序流过电线,只有ifs和循环修改!

再次感谢!


编辑: 我刚才意识到这属于“语言辩论”的主题。我希望它没关系,因为它是针对具体目标的特定编程分支的最佳选择。如果不是......我很抱歉......

25 个答案:

答案 0 :(得分:32)

在我到达之前,我们的小组(博士科学家,编程背景很少)一直在尝试实施LabVIEW应用程序近一年。代码不整洁,太复杂(前端和后端),最重要的是,没有用。我是一名敏锐的程序员,但从未使用过LabVIEW。借助LabVIEW大师的帮助,他可以帮助翻译我熟悉LabVIEW概念的文本编程范例,可以在一周内编写应用程序代码。这里的要点是基本的编码概念仍然需要学习,语言,甚至像LabVIEW这样的语言,只是表达它们的另一种方式

LabVIEW非常适合用于最初设计的内容。即从DAQ卡中获取数据并将其显示在屏幕上,或许在其间进行一些微小的操作。然而,编程算法并不容易,我甚至会建议它更难。例如,在大多数过程语言中,执行顺序通常是逐行跟随,使用伪数学符号(即y = x*x + x + 1)而LabVIEW则使用一系列VI来实现它,这些VI不一定相互跟随(即左在画布上。

此外,编程作为一种职业不仅仅是了解编码的技术性。能够有效地寻求帮助/寻找答案,编写可读代码并使用遗留代码都是关键技能,这些技能在LabVIEW等图形语言中无可否认。

我相信图形编程的某些方面可能成为主流 - 子VI的使用完美地体现了编程的“黑盒子”原理,并且还用于其他语言抽象,例如Yahoo Pipes和Apple Automator - 也许未来的一些图形语言将彻底改变我们编程的方式,但LabVIEW本身并不是语言设计的大规模转变,我们仍然有while, for, if流控制,类型转换,事件驱动编程,甚至是对象。如果未来真的将用LabVIEW编写,C ++程序员将不会遇到太多麻烦。

作为后记,我会说C / C ++更适合机器人技术,因为学生们无疑必须在某些时候处理嵌入式系统和FPGA。低级编程知识(位,寄存器等)对于这种事情是非常宝贵的。

@mendicant 实际上LabVIEW在工业中被广泛使用,特别是对于控制系统。授权NASA不太可能将其用于机载卫星系统,但随后空间系统的软件开发是whole different ball game ......

答案 1 :(得分:11)

我在目前正在研究的研究小组中遇到过类似情况。它是一个生物物理小组,我们正在使用LabVIEW来控制我们的仪器。这非常有效:可以轻松组装UI来控制仪器的各个方面,查看其状态并保存数据。

现在我不得不停止写5页咆哮,因为对我来说,LabVIEW一直是个噩梦。让我试着总结一些优点和缺点:

免责声明我不是LabVIEW专家,我可能会说有偏见,过时或完全错误的事情:)

LabVIEW专业人员

  • 是的,易于学习。我们小组的许多博士似乎已经掌握了足够的技能,可以在几周内甚至更少的时间内进行攻击。
  • 即可。这是一个重点。您必须根据自己的情况仔细研究这个问题(我不知道您需要什么,如果有好的LabVIEW库,或者有其他语言的替代品)。在我的例子中,在Python中查找例如一个好的,快速的图表库是一个主要问题,这使我无法用Python重写我们的一些程序。
  • 您的学校可能已安装并正在运行。

LabVIEW cons

  • 它可能易于学习。无论如何,似乎没有人真的很难学习最佳实践,所以程序很快就会成为一个完整的,无法修复的混乱。当然,如果你不小心,这也必然会发生在基于文本的语言上,但IMO在LabVIEW中做正确的事情要困难得多。
  • 在LabVIEW中查找子VI 时会出现主要问题(我认为甚至高达8.2版本)。 LabVIEW有自己的方式知道在哪里可以找到库和子VI,这使得完全破坏软件变得非常容易。如果你周围没有人知道如何处理这个问题,这会让大型项目变得很痛苦。
  • 让LabVIEW使用版本控制很痛苦。当然,它可以完成,但无论如何我都不会使用内置的VC。查看LVDiff获取LabVIEW差异工具,但不要考虑合并。

(最后两点让一个项目的团队工作变得困难。这在你的案例中可能很重要)

  • 这是个人的,但我发现很多算法在视觉上编程时都不起作用。 这是一团糟
    • 一个例子是严格顺序的东西;很快就会变得很麻烦。
    • 很难对代码进行概述。
    • 如果你将sub-VI用于小任务(就像制作执行小任务的功能并且适合一个屏幕的好习惯一样),你不能只给它们起名字,但你必须画画每个人的图标。这只会在几分钟内变得非常烦人和麻烦,所以你变得非常诱惑而不是将东西放入子VI中。这太麻烦了。顺便说一句:制作一个非常好的偶像可能需要一段时间。试着为你写的每个子VI制作一个独特的,可立即理解的,可识别的图标:)
  • 你会在一周内得到腕管。保证。
  • @Brendan:听,听!

结束语

关于你的“我应该编写自己的模块”问题:我不确定。取决于你的时间限制。如果你不需要,不要花时间重新发明轮子。花太多时间编写低级代码然后意识到你已经没时间了。如果这意味着您选择了LabVIEW,请选择它。

如果有简单的方法将LabVIEW与例如C ++结合起来,我很乐意听到它:这可能会给你两全其美,但我怀疑它有。

但请确保您和您的团队花时间学习最佳实践。看着对方的代码。互相学习。编写可用,易懂的代码。玩得开心!

请原谅我听起来前卫,也许有点迂腐。只是LabVIEW对我来说是一个真正的噩梦:)

答案 2 :(得分:9)

我认为LabVIEW的选择取决于你是否想要学习用常用语言编程作为适销对路的技能,或者只是想完成任务。 LabVIEW使您能够非常快速有效地完成工作。正如其他人所观察到的那样,它并没有神奇地让你不必理解你正在做的事情,如果不这样做,很可能会造成一种不圣洁的混乱 - 虽然有趣的是,LabVIEW中糟糕的编码风格最糟糕的例子是通常由具有文本语言经验并且拒绝适应LabVIEW工作方式的人员执行,因为他们已经知道如何编程,该死的!'

当然,这并不意味着LabVIEW编程不是一种适销对路的技能;只是它不像C ++那样大众市场。

LabVIEW可以非常轻松地管理并行执行的各种操作,在机器人控制情况下您可能会遇到这种情况。应该是顺序的代码中的竞争条件也不应该是一个问题(即如果它们是,你做错了):有一些简单的技术可以确保在必要时以正确的顺序发生事情 - 链接子VI使用错误连线或其他数据,使用通知程序或队列,构建状态机结构,甚至在必要时使用LabVIEW的序列结构。同样,这只是花时间了解LabVIEW中可用的工具以及它们如何工作的情况。我不认为必须制作子VI图标的抱怨非常有针对性;你可以非常快速地创建一个包含几个文字的文本,也许带有背景颜色,这对于大多数用途来说都没问题。

'图形语言是未来的方式'是基于错误二分法的红鲱鱼。有些东西非常适合图形语言(例如并行代码);其他东西更适合文本语言。我不希望LabVIEW和图形编程要么消失,要么接管世界。

顺便说一下,如果NASA 没有在太空计划中使用LabVIEW,我会非常惊讶。最近有人在Info-LabVIEW邮件列表中描述了他们如何使用LabVIEW开发和测试波音787上由电动机驱动的飞行表面的闭环控制,并给人的印象是LabVIEW在飞机的开发中被广泛使用。它还用于Large Hadron Collider!

中的实时控制

除了National Instruments自己的网站和论坛之外,目前获取更多信息和帮助LabVIEW的最活跃的地方似乎是LAVA

答案 3 :(得分:6)

LabVIEW的另一个优势(除了库)是并发性。它是dataflow language,这意味着运行时可以为您处理并发。因此,如果您正在做高度并发的事情并且不想进行传统同步,LabVIEW可以帮助您。

未来不属于今天的图形语言。它属于能够提供数据流表示(或其他并发友好类型的编程)的人,它与图形方法一样简单,但也可由程序员自己的工具解析。

答案 4 :(得分:6)

这不会直接回答您的问题,但您可能需要考虑使用解释语言混合的第三种选择。例如,Lua在机器人领域是already used。它速度快,重量轻,可以配置为使用定点数而不是浮点运行,因为大多数微控制器都没有FPU。 Forth是另一种具有类似用法的替代方案。

在C中编写一个精简的界面层应该很容易,然后让学生放松解释脚本。您甚至可以将其设置为允许动态加载代码而无需重新编译和刷新芯片。这应该减少迭代周期,让学生通过更快地看到结果来更好地学习。

我使用LabVIEW等可视化工具对反对有偏见。我似乎总是打出一些不会或者不会像我希望的那样工作的东西。所以,我更喜欢用文本代码获得的绝对控制。

答案 5 :(得分:4)

我认为与文本语言相比,图形语言的表现力总是有限的。比较尝试以视觉符号(例如,REBUS或手语)进行通信以使用单词进行通信。

对于简单的任务,使用图形语言通常更容易,但对于更复杂的逻辑,我发现图形语言会受到妨碍。

然而,在这个论点中隐含的另一个争论是声明性编程与命令式。对于任何你真的不需要对如何完成某些事情进行细粒度控制的事情,声明性通常更好。你可以以声明的方式使用C ++,但你需要更多的工作才能做到这一点,而LABView被设计为一种声明性语言。

一张图片胜过千言万语,但如果一张图片代表了你不需要的千言万语而且你无法改变它,那么在这种情况下,一张图片毫无价值。然而,您可以使用文字创建数千张图片,指定每个细节,甚至明确地引导观众的焦点。

答案 6 :(得分:4)

有一项由National Instruments主持的已发表的主题研究:

A Study of Graphical vs. Textual Programming for Teaching DSP

它特别关注LabVIEW与MATLAB(而不是C)。

答案 7 :(得分:4)

我的第一篇帖子:)温柔......

我来自汽车行业的嵌入式背景,现在我在国防工业。我可以从经验中告诉你,C / C ++和LabVIEW是真正不同的野兽。 C / C ++总是用于微控制器的嵌入式工作,因为它很紧凑,编译器/工具很容易获得。另一方面,LabVIEW用于驱动测试系统(以及测试台作为音序器)。我们使用的大多数测试设备来自NI,因此LabVIEW提供了一个环境,我们拥有工作所需的工具和驱动程序,以及我们想要的支持。

就易学性而言,C / C ++和许多网站都有很多资源可以提供设计考虑因素和示例算法,几乎可以免费获得。对于LabVIEW,用户社区可能没有C / C ++那么多样化,并且需要花费更多精力来检查和比较示例代码(必须拥有正确版本的LabVIEW等)......我发现LabVIEW很容易挑选起来学习,但是有些人在这里提到了并行性和其他需要一些经验才能意识到它们的事情。

那么结论呢?我会说两种语言在学习上是值得的,因为它们确实代表了两种不同的编程风格,而且当然需要注意并熟练掌握这两种语言。

答案 8 :(得分:4)

LabVIEW让您快速入门,并且(正如其他人已经说过的那样)拥有庞大的代码库,可用于进行各种测试,测量和测量。控制相关的事情。

然而,LabVIEW的最大挫折是你失去了程序员为自己编写的所有工具。

您的代码存储为VI。这些是不透明的二进制文件。这意味着你的代码真的不是你的代码,它是LabVIEW的代码。您无法编写自己的解析器,也无法编写代码生成器,也无法通过宏或脚本进行自动更改。

当你拥有一个需要进行一些小调整的5000 VI应用时,糟透了。你的唯一选项是手动完成每个VI,如果你错过了某个角落某个VI的变化,天堂可以帮助你。

是的,因为它是二进制的,你不能像文本语言一样做diff / merge / patch。这确实使得使用多个版本的代码成为可维护性的可怕噩梦。

无论如何,如果您正在做一些简单的事情,或者需要原型,或者不打算维护您的代码,请使用LabVIEW。

如果您想进行真实的,可维护的编程,请使用文本语言。你可能会开始变慢,但从长远来看你会更快。

(哦,如果你需要DAQ库,那么NI也有C ++和.Net版本。)

答案 9 :(得分:3)

天啊,答案很简单。使用 LabView

我已经对嵌入式系统进行了10年的编程,我可以说,如果没有至少几个月的基础设施(非常谨慎的基础设施!),那么使用 LabView <,你将不会像第1天那样高效。 /强>

如果你正在设计一个可以出售并用于军队的机器人,请继续从C开始 - 这是一个很好的电话。

否则,请使用允许您在最短的时间内尝试最多样化的系统。这是 LabView

答案 10 :(得分:2)

我喜欢LabVIEW。我强烈推荐它,特别是如果其他人记得使用类似的东西。普通程序员需要一段时间才能习惯它,但如果你已经知道如何编程,结果就会好得多。

C / C ++等于管理自己的记忆。你会在记忆中游泳并担心他们。使用LabVIEW并确保阅读LabVIEW附带的文档并注意竞争条件。

学习语言很容易。学习如何编程不是。即使它是图形语言,这也不会改变。图形语言的优点是可以更容易地看到代码将执行的操作,而不是坐在那里并破译一堆文本。

重要的不是语言而是编程概念。你学习编程的语言并不重要,因为只要付出一点努力,你就应该能够用任何语言编程。语言来去匆匆。

答案 11 :(得分:2)

我认为图形语言可能是未来的语言.....对于所有那些特殊的MS Access开发人员。对于纯文本编码人员来说,总有一个地方。

就个人而言,如果一切都为你完成,我必须问一下构建机器人的真正乐趣是什么?如果你只是放下一个“找到红球”模块并观察它?你对自己的成就感到骄傲吗?就个人而言,我不会有太多。此外,它将教你如何编码,或者在机器人技术中关键的软件/硬件接口的(非常重要的)方面?

我不是自称是该领域的专家,但问自己一件事:你认为美国宇航局使用LabVIEW编写火星漫游者的代码吗?你认为在机器人技术方面真正优秀的人都在使用LabView吗?

真的,如果你问我,唯一使用像LabVIEW这样的cookie切割器来构建这个就是为你做一些后院机器人建造者而已。如果您想要一些能够提供更多行业经验的东西,那就建立自己的'LabVIEW'型系统。建立自己的find-the-ball模块或您自己的“跟随线”模块。这将会困难得多,但也会变得更酷。 :d

答案 12 :(得分:2)

免责声明:我没有见过LabVIEW,但我使用过其他一些图形语言,包括WebMethods Flow和Modeller,大学的动态模拟语言,以及呃MIT的Scratch :)。

我的经验是图形语言可以很好地完成编程中的“管道”部分,但是我积极使用的那些语言会影响算法。如果您的算法非常简单,那可能没问题。

另一方面,我认为C ++也不适合你的情况。与在有用的工作中相比,您将花费更多时间来跟踪指针和内存管理问题。

如果您的机器人可以使用脚本语言(Python,Ruby,Perl等)进行控制,那么我认为这将是一个更好的选择。

然后是混合选项:

如果你的机器人没有脚本选项,并且你的团队中有一个C ++ geek,那么考虑让那个极客编写绑定来将你的C ++库映射到脚本语言。这将允许具有其他专业的人更容易地对机器人进行编程。绑定将成为社区的好礼物。

如果LabVIEW允许,请使用其图形语言将用文本语言编写的模块连接在一起。

答案 13 :(得分:1)

我对LabView(或许多关于C / C ++)一无所知,但是......

  

您是否认为LabVEIW等图形语言是编程的未来?

没有...

  

图形语言比文本语言更容易学习吗?我认为他们应该同样具有挑战性。

更容易学习?不,但他们 更容易解释和理解。

要解释一种编程语言,你必须解释变量是什么(这是非常困难的)。对于流程图/节点编码工具,如LEGO Mindstroms编程接口或Quartz Composer,这不是问题。

例如,in this is a fairly complicated LEGO Mindstroms program - 很容易理解发生了什么......但是如果你想让机器人运行INCREASEJITTER阻挡5次,然后向前驶10秒钟怎么办,然后再次尝试INCREASEJITTER循环?事情开始变得很乱......

Quartz Composer是一个很好的例子,为什么我认为图形语言不会“成为未来”

它可以很容易地真正冷却东西(3D粒子效果,相机由网络摄像头的平均像素亮度控制)..但是很难做到简单的事情,比如迭代XML文件中的元素,或将该平均像素值存储到文件中。

  

看到我们在帮助人们学习方面的根深蒂固,我们应该依靠预先编写的模块多少,以及我们应该多少尝试自己编写? (“优秀的程序员编写优秀的代码,优秀的程序员可以复制优秀的代码。”但是,首先不值得成为优秀的程序员吗?)

对于学习,解释和理解图形语言要容易得多。

那就是说,我会推荐一种专门的基于文本的语言作为进展。例如,对于类似ProcessingNodeBox的图形。它们是“普通”语言(Processing is Java,NodeBox是Python),具有非常专业,易于使用(但非常强大)的框架,根深蒂固。

重要的是,它们是非常互动的语言,您不必为了在屏幕上显示圆圈而编写数百行。您只需键入oval(100, 200, 10, 10)并按下运行按钮即可显示!这也使他们很容易证明和解释。

更多与机器人相关的东西,甚至像LOGO这样的东西都是一个很好的介绍 - 你输入“FORWARD 1”并且乌龟向前驱动一个盒子。输入“LEFT 90”并且它转90度..这与现实非常相关只是。您可以看到每条指令的作用,然后尝试并确认它确实以这种方式工作。

向他们展示那些看起来很有光泽的东西,他们将从中获取他们从C中学到的有用东西,如果他们感兴趣或进步到他们需要“真实”语言的地步,他们将拥有所有这些知识,而不是遇到语法错误和编译砖墙..

答案 14 :(得分:1)

我建议你使用LabVIEW,因为你可以开始使机器人更快更容易地做你想做的事。 LabVIEW就是这样设计的。 OfCourse C(++)是很棒的语言,但是LabVIEW做得比其他任何东西做得更好。 人们可以在LabVIEW中编写非常好的软件,因为它为此提供了充足的范围和支持。

答案 15 :(得分:1)

在我的应用程序中使用LabVIEW时,我发现了一件大事:组织设计复杂性。作为一名物理学家,我发现Labview非常适合原型设计,仪器控制和数学分析。在LabVIEW中,没有一种语言可以让你获得更快更好的结果。我从1997年开始使用LabView。自2005年以来,我完全切换到.NET框架,因为它更容易设计和维护。

在LabVIEW中,必须绘制一个简单的“if”结构,并在图形设计上占用大量空间。我刚发现很多商业应用程序很难维护。应用程序越复杂,读取就越困难。

我现在使用文字语言,我在维护一切方面要好得多。如果您将C ++与LabVIEW进行比较,我将使用LabVIEW,但与C#相比,它不会获胜

答案 16 :(得分:1)

你在高中。你有多少时间在这个项目上工作?你们小组中有多少人?他们是否已经了解C ++或LabView?

从你的问题来看,我发现你了解C ++,而大多数人都不知道。我还怀疑小组组长足够敏锐地注意到团队的某些成员可能会受到基于文本的编程语言的威胁。这是可以接受的,你在高中,这些人是 normies 。我觉得普通高中生能够比C ++更直观地理解LabView。我猜大多数高中生都像一般人一样害怕命令行。对你来说,差别要小得多,但对于他们来说,这是白天和黑夜。

您是正确的,可以将相同的概念应用于LabView作为C ++。每个都有自己的优点和缺点。关键是为工作选择合适的工具。 LabView是为此类应用程序设计的。 C ++更通用,可以应用于许多其他类型的问题。

我将推荐LabView。如果使用合适的硬件,您几乎可以开箱即用。您的团队可以花更多的时间让机器人做您想做的事情,这就是这项活动的重点。

图形语言不是编程的未来;多年来,它们一直是为解决某些类型的问题而创建的选择之一。编程的未来是远离机器代码的逐层抽象。在未来,我们会想知道为什么我们一直在浪费一遍又一遍地编写“语义”。

我们应该依赖预先编写的模块多少,以及我们应该尝试自己写多少? 你不应该浪费时间重新发明轮子。如果Labview中有可用的设备驱动程序,请使用它们。您可以通过复制功能相似且根据您的需求定制的代码来学习很多东西 - 您可以看到其他人如何解决类似问题,并且必须先解释他们的解决方案,然后才能将其正确应用到您的问题中。如果你盲目地复制代码,那么让它工作的机会很小。即使您复制代码,也必须保持良好状态。

祝你好运!

答案 17 :(得分:1)

总之,这取决于。

我使用LabVIEW大约20年了,从简单的DAQ到非常复杂的可视化,从设备控制到测试序列发生器,都做了很多工作。如果不够好,我肯定会改变。也就是说,我开始使用标语编写Fortran,并在8位“机器”上使用了大量编程语言,从基于Z80的机器开始。语言从汇编程序到BASIC,从Turbo-Pascal到C.

LabVIEW是一项重大改进,因为它拥有广泛的数据采集和分析库。然而,人们必须学习不同的范式。你肯定需要一个轨迹球; - ))

答案 18 :(得分:0)

两种选择都有其优点;但是,由于您的域名是一种教育体验,我认为C / C ++解决方案最有利于学生。图形编程总是一个选项,但是根本不能以优雅的方式提供功能,这使得它比低级编程的文本编程更有效。这不是一件坏事 - 抽象的全部意义在于允许对问题域进行新的理解和查看。我相信很多人可能对图形编程感到失望的原因是,对于任何特定的程序,从C编程到图形编程的增量增益与从汇编到C的增量几乎不同。

图形编程知识肯定会对任何未来的程序员有所帮助。未来可能会有机会只需要图形编程知识,也许你的一些学生可以从早期的经验中受益。另一方面,通过文本方法提供的基本编程概念的坚实基础将使所有的学生受益,并且肯定必须是更好的答案。

答案 19 :(得分:0)

似乎如果你正在努力让我们的团队为编程的未来做好准备,那么C(++)可能是更好的选择。使用可视化构建块构建的通用编程语言的承诺似乎从未实现过,我开始怀疑它们是否曾经存在过。似乎虽然可以针对特定问题域进行,但是一旦您尝试解决许多一般问题,基于文本的编程语言就很难被击败。

有一段时间我曾经接受过可执行UML的想法,但似乎一旦你超越对象关系和一些流程,UML将是构建应用程序的一种非常悲惨的方式。想象一下,尝试将它连接到GUI。我不介意被证明是错误的,但到目前为止我们似乎不太可能很快点击编程。

答案 20 :(得分:0)

我大约2年前开始使用LabVIEW,现在一直使用它,所以可能有偏见,但发现它非常适合涉及数据采集和控制的应用。

我们主要使用LabVIEW进行连续测量和控制气阀和ATE外壳的测试。这涉及数字和模拟输入和输出,信号分析程序和过程控制全部从GUI运行。通过将每个部分分解为子VI,我们可以通过鼠标的单击和拖动来重新配置测试。

与C / C ++不完全相同,但使用Visual BASIC进行测量,控制和分析的类似实现似乎很复杂,难以通过比较来维护。

我认为编程过程比实际编码语言更重要,您应该遵循图形编程语言的样式指南。 LabVIEW程序框图显示了数据流(Dataflow programming),因此尽管我从未遇到任何问题,但应该很容易看到潜在的竞争条件。如果你有一个C代码库,那么将它构建成一个dll将允许LabVIEW直接调用它。

答案 21 :(得分:0)

人们总是将labview与C ++和日期进行比较“哦,labview是高级别的,它具有如此多的内置功能,尝试获取数据做一个dfft并在labview中显示数据这么容易在C ++中尝试”。

误区1:很难用C ++完成任何事情,因为它的级别和实验室水平很低,已经实现了很多东西。 问题是如果你用C ++开发一个机器人系统,你必须使用像opencv,pcl等的库,如果你使用专为构建机器人系统(如ROS(机器人操作系统))而设计的软件框架,你会更聪明。因此,您需要使用一整套工具。事实上,当您使用ROS + python / c ++以及opencv和pcl等库时,可以使用更多高级工具。我已经使用了labview机器人技术,坦白地说,像ICP这样的常用算法并不存在,而且你现在不能轻易使用其他库。

神话2:理解图形编程语言更容易

这取决于具体情况。当您编写复杂的算法时,图形元素将占用宝贵的屏幕空间,并且很难理解该方法。要理解labview代码,您必须阅读从上到下阅读的代码中O(n ^ 2)复杂度的区域。

如果您有并行系统怎么办? ROS基于使用回调实现的订阅者/发布者消息实现基于图形的体系结构,并且很容易使多个程序运行和通信。将各个并行组件分开使其更容易调试。例如,单步执行并行labview代码是一场噩梦,因为控制流从一个地方跳到另一个地方。在ROS中,你没有像在labview中那样明确地“画出你的结构”,但你仍然可以看到我运行命令ros run rqt_graph(它将显示所有连接的节点)

“编程的未来是图形化的。” (这么想?)

我希望不是,labview的当前实现不允许使用基于文本的方法和图形方法进行编码。 (有数学脚本,但这非常慢)

很难调试,因为你无法轻易隐藏并行性。

很难阅读labview代码,因为你需要查看这么多区域。

Labview非常适合数据aq和信号处理,但不适用于实验机器人,因为大多数高级组件如SLAM(同时定位和映射),点云注册,点云处理等都缺失。即使他们确实添加了这些组件,并且像ROS一样易于集成,因为labview是专有且昂贵的,他们永远无法跟上开源社区。

总之,如果labview是机电一体化的未来,我正在改变我的投资银行业务道路......如果我不能享受我的工作,我也可以赚钱并提早退休......

答案 22 :(得分:0)

  

队长认为是LabVIEW   更容易学习和学习   教学。这是真的吗?

我怀疑任何单一语言或范例都是如此。对于拥有电子工程背景的人来说,LabView肯定会更容易;在其中制作程序“简单地”绘制电线。然后,这些人也可能已经接触过编程。

除了图形之外,一个重要的区别是LV是基于需求的(流程)编程。你从结果开始,然后告诉我们需要做些什么。传统的编程往往是必要的(反过来说)。

有些语言可以提供这两种语言。我最近为Lua制作了一个多线程库(Lanes),它可以在其他必要的环境中用于基于需求的编程。我知道有成功的机器人主要在Lua那里运行(Crazy Ivan在Lua Oh Six)。

答案 23 :(得分:0)

您是否看过Microsoft Robotics Studio? http://msdn.microsoft.com/en-us/robotics/default.aspx

它允许可视化编程(VPL): http://msdn.microsoft.com/en-us/library/bb483047.aspx 以及C#等现代语言。 我鼓励你至少看看这些教程。

答案 24 :(得分:0)

我对Labview(以及Matlab在这方面)的抱怨是,如果你计划将代码嵌入到x86以外的任何东西中(并且Labview有工具将Labview VI放在ARM上)那么你将不得不抛出那么多的马力尽可能地解决问题,因为它效率低下。

Labview是一个很棒的原型设计工具:很多库,很容易将块组合在一起,可能有点难以进行高级算法,但可能会阻碍你想做什么。您可以快速完成功能。但是,如果你认为你可以把那个VI放在一个设备上你就错了。例如,如果在Labview中创建一个加法器块,则有两个输入和一个输出。那个内存使用量是多少?三个变量的数据?二?在C或C ++中,您知道,因为您可以编写z=x+yx+=y,并且您确切知道代码正在做什么以及内存情况如何。内存使用率可能会迅速上升,特别是因为(正如其他人所指出的)Labview是高度并行的。所以要准备好投入比你想象的更多的RAM。而且处理能力更强。

简而言之,Labview非常适合快速原型设计,但在其他情况下您会失去太多控制权。如果您正在处理大量数据或有限的内存/处理能力,那么请使用基于文本的编程语言,以便您可以控制发生的事情。