外文文献翻译-LabVIEW程序框图设计

LabVIEW程序框图设计摘要：一个真正好的程序就像一件艺术品一样，而差的程序看起来就像意大利面那样乱。

这篇文章提出的风格能确保我们实际应用中在规定时间内开发出整洁，结构清晰的程序。

结合其他规则，我们能开发出可读性好的，易于维护的LabView源代码。

LabVIEW的程序框图长于源代码表述。

一个真正好的程序是发人深省的，甚至是令人敬畏的，就是一件艺术品一样。

而一个差的程序，看起来就像一碗意大利面条那样凌乱。

事实上，这两种极端的情况就像《风格的重要性》中Meticulous VI 和 Spaghetti VI所表现的那样。

而大部分程序处于艺术品和意大利面条之间。

一些程序开发者有连线整齐的习惯，但程序框图往往却大而宽泛。

其他的一些程序开发者却过度使用模块化编程，就像自己在搭建筑一样。

而仍有一些编程人员喜欢使用变量方式而非数据流方式。

很多很多开发人员在文档上节省时间。

此外，很多程序是在好的风格和节约时间两者之间取得平衡下为特征下完成工作的。

总体结论就是在吸引人的程序外观，个人喜好和程序功能上取得折中。

大多数开发人员都错误认为吸引人的程序编写上受到许多束缚使开发进度变慢，而现实中程序开发都有时间限制。

似乎快速开发程序的和程序具有美感是相矛盾的。

事实上，多花些时间来优化复杂程序的外观是可能的如果你知道什么才是好的风格所要遵循的规则和如何执行这些规则，你将会在程序开发中更加轻松。

屏幕分辨率决定程序开发人员在开发程序时的可见区域和程序移植到用户计算机后的界面显示。

因此，将程序分辨率统一是非常有好处的，那样应用程序在使用相同分辨率的PC上打开时窗口界面将保存一致。

程序分辨率设置得越高，界面上的控件将根据屏幕大小相应的缩小，屏幕上也能容纳更多的程序代码。

合适的屏幕分辨率是不仅要能使程序的可见区域最大化，而且不能让你的眼睛不舒服。

LabView开发环境设定的最小程序分辨率为1024*768。

与PC显示技术发展相适应的1280*1024的屏幕分辨率能提供更多的可视区域。

不要采用高于1280*1024的分辨率，因为当前还不广泛支持如此高的分辨率，更大的工作区域也意味者程序框图更大，模块化程度降低。

同时，取决于显示器的大小，如果过高的分辨率容易使你的眼睛疲劳。

今天许多计算机都支持多显示器。

在LabView开发环境采用两个显示器是非常有好处的。

使用一个显示器来显示前面板，另外一个显示器来显示程序框图。

这样就能同时看到这两个窗口，而不需要在前面板和程序框图之间进行切换。

不要给程序框图着色。

界面的背景色和每个结构的子界面都默认为白色。

数据流向必须非常容易识别。

我们希望对象尽量布局紧凑，但同时不希望对象靠得太近引起对象和连线重叠。

总之，尽量缩小程序框图大小使之能在一个屏幕显示出来。

在某些情况下，比如说某些复杂的程序包含很多个并行循环，要满足这个限定非常困难。

在这种情况下，调整程序框图，或者将一些循环变成子VI来减小所占背面板空间，使背面板仅在一个方向上滑动。

开发程序时，VI之间应采用从上至下和自下而上相结合的方法来构建多层次结构关系。

VI的层次结构可以通过选择View»VI Hierarchy来查看。

从窗口的工具条中取消选择包括VI Lib ,包括全局变量和包括自定义类型，并且只显示你自己提供的用户VI。

通常的几何形状包括金字塔形，钻石形和椭圆形。

除了非常简单的应用程序外，VI层次结构中在顶层VI之下的应包含多行子VI。

在第一章中，模块化率被定义为是用户VI数与总的节点数之比，再乘100。

这些数据的大小可以通过选择Tools»Profile»VI Metrics快速查看到。

典型应用程序的模块化率推荐为3.0以上。

取决于设计样式，许多顶层程序都应包含结构，连线，VI组件和子VI。

VI组件是处于非常高层的子VI，或者是将一个应用程序的主要部分或子系统封装为插件后动态调用的VI。

一个应用程序的图形用户见面和数据采集引擎是以单独的vi实现的，它们就是组件VI的一个例子。

顶层和高层vi应该尽可能减少的低层数据处理函数，例如数学函数，数组处理，格式化字符串以及类似的函数。

一些应用程序需要大量的数值属性节点来控制GUI行为。

许多属性节点的读写操作是由GUI事件触发。

因此，事件结构是理想的处理属性节点的结构。

因为，事件结构为每个事件分支包含一个单独的子程序，通常一个事件分支的程序不会跑到其他的事件分支。

然而，多事件分支需要许多个相同的属性节点，它们的值因每次读写操作而不同。

将这些普通的属性节点模块化为子VI，通过控件引用和属性值传递到子VI中。

每个子VI程序代表在内存中同一属性节点的备份。

这减小了内存使用和程序复杂性。

同样的，将你程序中的高层组件模块化为较低级的子VI。

使用自顶向下的设计和开发方法，将任何低层程序模块化为强内聚的子VI。

在任何的地方如果你用到了已有代码的副本来共同构成一个程序，将这些代码替换成子VI。

一个子VI是否是内聚的要看你是否能将它要完成的工作清楚的描述为两三句话，就像子VI描述信息那样。

子VI非常有用，因为相对于一个大型程序来说，它易于开发，测试，调试，维护和代码重用。

如图4-2C所示，子VI也为程序开发中节省了可观的背面板空间。

总之，如果同一函数，属性节点，程序被多次用到，将这些重复代码换成子VI将使程序开发变简单。

同样，如果几个没用被重复使用的节点彼此相关，并且一起完成某项工作，不管它们是否被多次用到，也将它们变为一个内聚的子VI。

但是，也不要为了节省空间而随便选择将程序的某部分变成子VI。

以这种方式创建的子VI不是内聚的，也不够直观并且不可重用。

同样也不要为只有少量接线端的程序代码创建子VI。

这种情况，子VI图标不需要在程序框图掩盖它下层的代码。

子VI只包含一个数组索引函数。

然而，子VI的图标，名字和描述信息掩盖数组索引函数。

LabView函数和将子VI打包成的VI.lib通常是可识别的，因而不需再单独将它们封装成子VI。

为每个子VI创建一个有含义的图标和相结合的描述。

住为每个子VI创建一个有含义的图标和相结合的描述。

再怎么强调它的重要性都是不够的。

这是我们最神圣的信条。

图标和描述信息能帮助我们在调用这些子VI的程序时通过帮助窗口的文字识别这些子VI。

这些描述迫使我们进行内聚性测试。

如果你不能通过2到3句话总结子VI的功能，子VI可能包含了太多的子代码。

隧道连线通过结构左侧边界进入结构，并从结构的右侧边界穿过结构。

不要让隧道在结构的顶部或底部穿过。

同样如果结构内部未使用到也不要让连线穿过结构，除非其目的是为了标示清楚。

特别令人困苦的是浏览一个多帧结构的许多帧时，要去寻找那些在连线上被修改的数据，比如说条件结构或者是事件结构。

然而，有时条件结构通过一些额外的连线线是非常有用的将没有连线的前面板控件在程序框图上放在一起，那样程序开发人员就能非常容易的将找到它们。

标记那些在程序只用到一次，不在循环结构中的接线端。

实践中大多数局部变量，全局变量和顺序结构都不是必要的。

没有学习过有效数据流法则的开发者经常过多地使用局部变量和全局变量。

强迫自己避免使用变量和顺序结构是最有效的掌握数据流的方法，除非完全必要要用到它们。

的确，掌握数据流和尽可能避免使用变量和顺序结构具有相同的含义。

为了避免连线混乱且保持有组织秩序，紧凑地放置移位寄存器且将它们聚集到靠近循环的顶部。

这样如同在靠近循环顶端位置有限的区域内修建一条数据公路且使线路交叉最少。

除了聚合了包括错误簇和条件选择器的移位寄存器外。

只要在移位寄存器之间留下刚好够放置自由标签的位置就行了，这些标签将被放置在靠近移位寄存器左边终端的线上。

错误簇经常在循环的底部进出，而条件选择器经常处于中间位置。

因此，错误簇和条件选择器经常与靠近循环顶部的数据公路是分离的。

最糟的编程习惯是从一个选定区域创建一个VI而且不清理创建子VI后的狼藉场面。

终端位置，标签，线，连接器分配，图标以及描述文档都需要进行矫正。

有时这样还会导致子VI的程序结构图就像在里面投了一颗炸弹一样。

用这种工具创建的子VI从来就不是一个好的风格而且程序必须改写。

关闭检查展示出从右向左的线是一个文件路径，它是由Case结构里面的若干底层函数所形成的。

不管怎样，在顶层VI上由若干底层函数共同组成以完成某种功能的程序最好用一个子VI的形式出现。

这篇文章提出的风格能确保我们实际应用中在规定时间内开发出整洁，结构清晰的程序。

结合其他规则，我们能开发出可读性好的，易于维护的LabView源代码。

而且，遵守这些好的编程风格所要求的准则将可能会使我们开发出令人赞叹的LabView程序。

The LabVIEW Program Diagram DesignABSTRACT：A really good diagram is like a work of art. Some developers have neat wiring practices but large, flat diagrams. This chapter presents style rules that ensure neat and organized diagrams that are practical to implement in real applications with tight deadlines. Combined with the rules in other chapters, they ensure readable and maintainable LabVIEW source code The LabVIEW block diagram excels at conveying source code. A really good diagram is enlightening, even awe-inspiring, like a work of art. Some developers have neat wiring practices but large, flat diagrams. Others have overly modular diagrams that disguise the architecture. . Indeed, these two extremes are depicted by Meticulous VI and Spaghetti VI in Chapter 1, "The Significance of Style." Somewhere in the middle between artwork and spaghetti is where most applications reside. Still others prefer variables over data flow. Many, many developers skimp on documentation to save time. Moreover, most diagrams are characterized by tradeoffs between good style and shortcuts deemed necessary to get the job done. The overall outcome is a compromise among attractive appearance, personal preferences, and functional performa nce.Many developers wrongfully assume that attractive diagrams require a level of toil that is impractical for real-world applications that have tight deadlines. It seems faster and more productive to avoid getting caught up in diagram aesthetics. Indeed, it is possible to expend excessive time optimizing the appearance of a complex diagram, If you know the style rules and how to implement them, you eliminate the toil.The LabVIEW development environment is designed for a minimum 1024x768 resolution. A resolution of 1280x1024 provides additional real estate while maintaining compatibility with mainstream PC display technology. Avoid resolutions much higher than 1280x1024 because higher resolutions are less universally supported, and the larger work area promotes larger diagrams and potentially less modularity. Also, depending on the monitor size, very high resolutions may strain your eyes.The display resolution affects the visible area the developer has to work with and how the diagram appears when opened on a given target computer. It is beneficial to standardize on one display resolution so that the diagram window maintains a consistent appearance when opened on PCs with similar display capabilities. The higher the resolution setting, the smaller the diag ram objects shrink relative to the screen size, and the more code fits on one screen. A fairly high resolution is recommended to maximize the viewable diagram area without straining your eyes. Today many computers support multiple monitors. It is particularly useful to utilize two monitors for LabVIEW development. This allows you to dedicate one monitor to the front panel and the other monitor to the block diagram, and have both windows simultaneously visible without having to navigate between them.Do not color the diagrams. Leave the background of the diagram, and every subdiagram of every structure, default white. Data flow must be easy to visualize. A high density of objects is desired, without crowding objects too close and causing wires and objects to overlap. In general, try to limit the diagram size to one display screen. In some situations, it is difficult to work within this constraint, such as a complex diagram containing multiple parallel loops. In this case, organize the large diagram so that it may be viewed by scrolling in only one direction, or modularize the loops into subVIs to reduce space.Develop your applications as a multilayer hierarchy of subVIs using a combination of top-down and bottom-up design and development techniques. The VI Hierarchy is viewed by selecting View»VI Hierarchy. Deselect Include VI Lib, Include Globals, and Include typedef from the toolbar to remove these items from the window, and view only the hierarchy of user VIs that you provided. Common geometries include pyramid, diamond, and oval. Except for very simple applications, the VI Hierarchy should contain multiple rows of subVIs below the top-level VI. In Chapter 1, the modularity index was defined as the ratio of the number of user VIs to total nodes, multiplied by 100. These quantities are quickly referenced using the VI Metrics window, selected from Tools»Profile»VI Metrics. A modularity index of 3.0 or greater is recommended for a typic al application.Depending on the design pattern, most top-level diagrams should consist of structures, wires, component VIs, and subVIs. Component VIs are very high-level subVIs, or dynamically loaded plug-in VIs, that encapsulate a major portion or subsystem of the application. An application's graphical user interface and data acquisition engine, implemented as separate VIs, are examples of component VIs. The top-level and high-level diagrams should contain very few low-level data-manipulation functions, such as math, array manipulations, string formatting, and similar functions.Some applications require large numbers of Property Nodes for controlling GUI behavior. Most Property Node read and write operations are triggered by GUI events. Consequently, the Event structure is an ideal construct for handling Property Nodes. Because the Event structure contains separate subdiagrams for each event case, it is uncommon to run out of space. However, it is common to have multiple event cases that require many of the same Property Nodes, with different values read or written to them in each. Modularize these common Property Nodes into subVIs, and pass the Control References and property values to the subVI in each location. Each instance of the subVI refers to the same collection of Property Nodes in memory. This substantially reduces memory use and diagram complexity.Likewise, modularize the diagrams of your high-level component VIs into lower-level subVIs. Using the top-down design and development approach, modularize any low-level routines into cohesive subVIs. Anywhere you have a collection of related functions that work together to perform a specific routine, replace them with a subVI. A subVI is cohesive if you can clearly describe its purpose in two or three sentences, such as when entering the subVI's description.SubVIs are advantageous because it is easier to develop, test, debug, maintain, and reuse software modules as subVIs versus sections of a large diagram. As shown in Figure 4-2C, they also provide a considerable space-saving benefit. In general, if the collection of functions or Property Nodes or other routine is used in more than one place, it is an easy decision: Replace the repeated code with a subVI. Likewise, if several nonrepetitive nodes are related to one another and work together to perform a specific task, modularize them into cohesive subVIs, whether they are needed in multiple places or not. However, do not randomly select areas of the diagram and create subVIs just to save space. SubVIs created in this manner are not cohesive, intuitive, or reusable. Also, do not create trivial subVIs that contain few nodes. In this case, the subVI icon unnecessarily masks the underlying code on the diagram. For example, the subVI in Figure 4-3 contains only a single Index Array function. However, the subVI's icon, name, and descr iption disguise the function. The LabVIEW functions and shipping subVIs within vi.lib are universally recognizable, so avoid masking them within trivial subVIs.Create a meaningful icon and cohesive description for every subVI!Always create a meaningful icon and cohesive description for every subVI. I cannot emphasize this enough. At Bloomy Controls, this is one of our most sacred precepts. The icon and descriptio n identify the subVI from the diagram of the calling VI through the Context Help window. The description enforces the cohesion test. If you cannot summarize its purpose in two or three sentences, it probably contains too much code for one subVITunnel wires into structures through their left border, and out of structures through their right border. Avoid tunneling wires through the top and bottom borders. Also avoid passing wires through structures if they are not utilized within the structure, unless their purpose is clearly labeled. It is particularly annoying to flip through many frames of a multiframe structure, such as a Case or an Event structure, searching for places where the data in the wire is modified.Place any unwired terminals of front panel objects in a consistent location on the diagram so that developers can find them easily. Note that any terminals not contained by a repeating structure are read only once.Most local and global variables and Sequence structures used in practice are not neces sary. Most often, they are overused by developers who have not learned efficient dataflow principles. The best way to master data flow is to force oneself to avoid variables and Sequence structures unless absolutely required. Indeed, mastering data flow is synonymous with minimizing variables and Sequence structures.To avoid wire clutter and maintain organization, space most shift registers tightly, and group them near the top of the loop. This creates a data highway that is limited to an area near the top of the loop and minimizes wire crossovers. Leave just enough space between the shift registers to apply free labels on each wire near the left terminals. Exceptions to shift register grouping include error clusters and case selectors. Error clusters normally enter and exit near the bottom of loops. Also, case selectors are frequently positioned near the middle. Therefore, error clusters and case selectors are usually kept separate from the data highway at the top.For example, the task ID and error control terminals are improperly labeled task ID out and error out. Additionally, one of the indicators has the generic label Numeric. What is curious is that the subVI has a custom icon and description, and the control terminals are within reasonable proximity to the structure. Perhaps it was partially repaired. The wiring and terminal labels have been cleaned up in Figure 4-14B. Also, Figure 4-14C contains equivalent code using the waveform data type and the newer sound output VIs released with LabVIEW 8. This is the preferred implementation.Close inspection reveals that the right-to-left wire is a file path that is formed by some low-level functions within an inner Case structure. Whenever a collection of low-level functions that work together to perform a cohesive routine appears on the diagram of a high-level VI, it is a good opportunity for a subVI,This chapter presents style rules that ensure neat and organized diagrams that are practical to implement in real applications with tight deadlines. Combined with the rules in other chapters, they ensure readable and maintainable LabVIEW source code. Moreover, mastery of these style rules may lead to awe-inspiring LabVIEW diagrams.。