自从在NIWeek 2017 发布LabVIEW NXG 1.0和LabVIEW 2017以来，LabVIEW工程师阵营经常询问几个问题，最常见的是为什么不只是发布LabVIEW NXG，还要发布传统新版本的LabVIEW环境？为什么要持续投入两种LabVIEW版本的跟进？要回答解释清楚是比较复杂的，但其实也挺简单。

现归结为以下几个关键原因：

没有更好的方法确保你能持续成功

随着时间的推移，NI的一个核心原则是使其客户能够有效地维护他们的软件应用程序。NI致力于确保客户有足够信心和时间决定搬移到新的LabVIEW NXG平台。

LabVIEW NXG 1.0不包含LabVIEW 2017所有功能，大略举例说下，LabVIEW NXG还不支持CompactRIO，也没有类的功能，没有应用程序部署，不能与TestStand集成整合。详细比较请浏览：http://www.ni.com/en-us/shop/labview/compare-labview-nxg-and-labview.html

NI对执行这种平台迁移规模的其他供应商做了大量的研究。对于用户来说，最常见的挫败感是他们觉得被迫升级。即使LabVIEW NXG是完全基于LabVIEW用户基础，绝大多数也需要长时间来确定移动所开发的代码，进入一个“新的LabVIEW的最合适的时间”。

NI致力于授权用户根据其考虑做出决定：项目时间表、基础设施升级和系统不断变化的需求。NI已经并将继续投资于当前版本的LabVIEW，以确保用户可以自己选择。这项投资将包括对新硬件的支持、对性能和稳定性的持续投资以及新的软件能力。

LabVIEW NXG 1.0的功能仅能服务用户基数的一部份

大多数现有的LabVIEW用户嘲笑LabVIEW NXG组态编程的定位。有几个版本的评论，听起来象下面：“LabVIEW是一款强大的编程工具，我用它来做<插入硬件>，这需要编程，不能用非编程解决方案来满足。”

对此我的反应是报以雷鸣般的掌声，我完全同意。LabVIEW NXG的发布没有减少你曾用LabVIEW完成的那些惊人之举，没有使之褪色，没有使你工程师的职责丧失，在市场上，不意味着LabVIEW 2017不是最强劲的工程系统设计软件，它依然还是。在整个太阳系，在整个地球上，LabVIEW 2017在市场领域还是最强劲的工程系统设计软件。我不能确定最后一个，但我有信心。

LabVIEW NXG 1.0引入了新的非编程工作流，旨在减少从传感器连到工程视界的设计时间。像LabVIEW 2017一样，LabVIEW NXG是专为工程系统设计成需要从硬件快速测量。关键区别是，LabVIEW NXG内部工作流比LabVIEW 2017可以让你更臻于走向完整的系统。那些采集测量、捕获数据和设计分析例程的交互式面板，不仅提供了一种简单点击式方法，还可在后台拖放设计代码。

是的，我知道我们有Exprss Vis，也知道有SignalExpress，但让我们回到现实，在这两种情况下生成的代码都不是很好。这就比较糟糕。

LabVIEW NXG针对工程师和科学家提供种途径来达成测量自动化，他们通常不喜欢或不擅长如何编程优化。

LabVIEW NXG不是“或”

LabVIEW NXG是LabVIEW的未来，但目前LabVIEW NXG和LabVIEW 2017是种独特的组合，LabVIEW NXG的许多特性设计成完全的现有部署应用，两者没有代码迁移衔接。让我们探讨两个例子。

LabVIEW 2017包括编写包的能力。软件包是安装和分配软件的行业标准概念。包与库一起创建模块化和可伸缩的软件，这使得构建大型软件应用程序更加容易。最后，我们希望每个人都创建包，因此，我们编写了在LabVIEW 2017中随时可用包的能力。

LabVIEW NXG 2.0将引入调用WebVIs的功能，WebVIs使你不必雇用网站开发人员就可构建丰富的基于Web的测试接口，该接口将包括HTML5控件和直接编辑HTML源代码的功能。它们可部署到任何设备上的任何浏览器，零插件安装。这意味着你可以从任何现有的LabVIEW应用程序去发布数据，使用LabVIEW NXG构建一个基于网络的用户界面。

说到LabVIEW，我们不会把你的双手束缚。相反，我们赋予你的灵感天赋。

在我们前进的过程中对LabVIEW要有信心。在新版本的LabVIEW和LabVIEW NXG中，你会继续看到新的功能，新的硬件支持和改进的性能。

——NI LabVIEW产品管理 Jeffrey P.