NI VeriStand 2010 自定义设备开发者指南（Beta版）

需积分: 5 48 浏览量更新于2024-06-18 收藏 3.89MB PDF 举报

"NI VeriStand 2010 Custom Device Developer’s Guide (Beta)" 是一份针对开发人员的指南，旨在介绍如何在VeriStand 2010中创建和使用自定义设备。这份文档属于测试阶段，鼓励用户在NI Developer Zone上提出问题、评论和反馈。本文档的核心内容可能涵盖了以下关键知识点： 1. **NI VeriStand**: NI VeriStand 是一款实时测试和控制软件，主要用于快速构建和部署嵌入式测试系统，如硬件在环(HIL)仿真和自动化测试。它提供了一个直观的图形化界面，允许用户配置系统工程，而无需编写大量的代码。 2. **Custom Devices**: 自定义设备是NI VeriStand中的一个重要组成部分，允许开发人员扩展其功能以满足特定需求。这些设备通常由一系列VI（虚拟仪器）组成，可以处理数据输入、输出、计算和其他系统交互。 3. **开发流程**: 指南可能详细介绍了创建自定义设备的步骤，包括设计接口、编写LabVIEW代码、配置系统结构、以及调试和优化设备性能。 4. **LabVIEW**: LabVIEW（Laboratory Virtual Instrument Engineering Workbench）是NI公司的一款图形化编程语言，常用于科学和工程应用。在VeriStand中，LabVIEW用于编写自定义设备的底层逻辑。 5. **知识产权与法律条款**: 文档中提到了版权和商标信息，强调了对NI软件的合法使用，包括不得未经授权复制或传输，以及尊重他人的知识产权。使用NI软件开发的产品应遵守任何适用的许可协议或其他法律限制。 6. **NI Developer Zone**: 这是一个在线社区，开发者可以在这里获取资源、交流技术问题、分享解决方案，以及参与产品讨论。对于此指南的用户提供了一个直接反馈的平台。 7. **技术支持**: 因为这是一份测试版指南，用户遇到的问题和反馈可能会引导NI改进产品，提供更新的文档或修复，以提高最终版本的稳定性和功能性。 8. **版本信息**: 2010年发布，这表明该指南对应的是VeriStand的一个早期版本。随着VeriStand的不断更新，新的版本可能引入了更多的特性和改进，因此开发者需要关注后续版本的更新以保持同步。通过这份指南，开发者可以深入理解如何利用NI VeriStand 2010的自定义设备功能，定制自己的测试和控制系统，以适应特定行业的应用需求，如航空航天、汽车工程、能源等领域的HIL测试。

1. Embedded Data Logger

2. Gopel LIN

3. Lambda Genesys DC Power Supply

4. Pickering 40-295

In addition to these four devices, a variety of custom devices have already been implemented

by National Instruments and are available for download. You should consult NI Developer Zone

Tutorial: NI VeriStand Add-ons to determine if a custom device has already been developed to

fulfill your specification.

Several hardware vendors have implemented custom devices for their hardware. You should

check with the manufacturer that a custom device doesn’t exist before you build one.

In general, there are three specifications that are best-suited for a custom device.

1. 3

Party Hardware

2. Unsupported Measurement or Generation Mode

3. Feature

Party Hardware

A list of hardware natively supported by NI VeriStand is found in NI VeriStand Help » NI

VeriStand Reference » Supported National Instruments Hardware. If the application requires

other hardware, it can probably be implemented in a custom device.

Unsupported Measurement or Generation Mode

Check NI VeriStand Help » Configuring and Running a Project » Configuring a System

Definition File » Adding and Configuring Hardware Devices to determine if the required

measurement or generation mode of your hardware is supported. If not, it can probably be

implemented in a custom device. For example, single-point hardware-timed analog acquisition

on NI-DAQ devices is supported out-of-the-box. Continuous analog acquisition can be

implemented as a custom device.

Feature

All of the common functionality necessary for most real-time testing applications such as host

interface communication, data logging, stimulus generation, etc, is provided by NI VeriStand –

ready to configure and use. You should first try to meet specifications with the built-in

functionality because it is engineered, tested, and supported by National Instruments.

If a built-in feature does not exist, it can be implemented by extending NI VeriStand. See NI

Developer Zone Tutorial: Using LabVIEW and Other Software Environments with NI VeriStand

for a complete list of ways to customize and extend NI VeriStand. Certain features are best

implemented as custom devices. To determine when a custom device is the most appropriate

mechanism to meet a specification, you should be familiar with all the customization methods

available. A general rule-of-thumb is that custom devices implement features that require or

use NI VeriStand channel data on the execution host.

For example, there is a TDMS File Viewer tool built into the NI VeriStand Workspace. If you

need to log NI VeriStand channels to TDMS without first sending it back to the Workspace (as

with high-speed streaming), a custom device called the Embedded Data Logger fulfills this

requirement. This custom device ships with NI VeriStand 2010. On the other hand, if you need

to display previous test results on the workspace while a new test is running, a custom

workspace object may be more appropriate than a custom device. See NI Developer Zone

Tutorial: Creating Custom Workspace Objects for NI VeriStand for more information.

Custom Device Risk Analysis

The open nature of NI VeriStand is a strong advantage over other real-time/HIL testing

solutions. It’s easy to take advantage of this extensibility by using custom devices written by

other developers. Writing your own custom device incurs a set of manageable risks. This

section provides a list of risks that should be considered before custom device development

begins.

LabVIEW Application Development

Custom devices are written in LabVIEW. The framework generated by the Custom Device

Template Tool is single-loop or action-engine VI. This architecture may be suitable for simple

custom devices.

Non-trivial devices will require more advanced architecture. A requisite for custom device

development is thorough knowledge of LabVIEW programming and application architectures.

This knowledge represents NI Certified LabVIEW Developer (CLD) level expertise, and is

typically obtained through NI's Training and Certification program by completing the LabVIEW

Core 1, Core 2, and Core 3 courses.

It should be mentioned that NI VeriStand custom devices are typically not large LabVIEW

applications. Custom devices are designed to be modular, self-contained plug-ins that add a

specific functionality to NI VeriStand. While custom devices are typically developed by a single

programmer, large application development best-practices may still apply. See LabVIEW 2010

Help: Best Practices for Large Application Development for more information.

LabVIEW Real-Time Application Development

Custom devices are typically designed to execute on real-time systems. This allows the

operator to perform deterministic HIL and RT test procedures. Programming for a real-time

system requires knowledge of real-time operating systems (RTOS) and specialized LabVIEW

development techniques. This knowledge is typically obtained through NI's Training and

Certification program by completing the Real-Time Application Development course, and it is

refined by working on several LabVIEW Real-Time applications.

NI VeriStand Background

Familiarity with the NI VeriStand Engine is crucial to successful custom device development.

The correct type of custom device cannot be selected in the Custom Device Template Tool

without understanding the implications of each. This knowledge is typically obtained by reading

the NI VeriStand 2010 Help, with an emphasis on Understanding the VeriStand Engine.

Experience with NI VeriStand from an operator's perspective is highly desired. This experience

enables you to build operator-friendly interfaces that conform to the standard look and feel of

other NI VeriStand components. Familiarity with NI VeriStand allows the developer to build-up a

complex system definition, which allows thorough and realistic testing and benchmarking.

Hardware Driver Development

Custom device must call a hardware or instrument driver to support 3

-party hardware. All

National Instruments hardware comes with a LabVIEW Application Program Interface (API) that

can be used in the custom device. However, just because a LabVIEW API exists does not

guarantee the custom device can be easily implemented. Consider the following points when

evaluating the feasibility of a custom device for 3

-party hardware.

 Does an Instrument Driver exist? See NI Developer Zone » Instrument Driver Network to

search for instrument drivers.

 Is a hardware driver available?

 Is the driver well documented?

 If necessary, is the driver compatible with LabVIEW Real-Time? See KnowledgeBase

3BMI76L1: How Can I Verify that My DLL is Executable in LabVIEW Real-Time for

instructions on checking compatibility.

NI VeriStand uses channels to pass data between different parts of the system, including to and

from custom devices. All NI VeriStand channels are LabVIEW double data type (DBL). See

LabVIEW 2010 Help » Fundamentals » Building the Block Diagram » How-To » Floating Point

Numbers for more information on LabVIEW data types.

 Can the hardware requirement be met by passing LabVIEW DBLs to and from the

custom device during steady state operation?

If the hardware driver returns a vector, structure, or any non-DBL data, it cannot be passed

directly from the custom device to the rest of the NI VeriStand system. The developer is

responsible for coercing the data (or using an alternative communication mechanism) to pass

data from the custom device to the rest of the system. For more information on the available

communication mechanisms, see LabVIEW 2010 Real-Time Module Help » Real-Time Module

Concepts » Sharing Data in Deterministic Applications » Exploring Remote Communication

Methods.

NI VeriStand also exposes its TCP pope via dynamic event registration. This pipe may suite

your remote communication requirements. See the Custom Device Engine Events section for

more information.

Testing

A custom device is one part of an NI VeriStand system. The complete state of the operator's

system is seldom known by the custom device developer. System state includes the following

information.

 What are the specifications of the execution host and host computer?

 What components are in the system definition?

o How computationally intense are the simulation models?

 What loop rates are required?

 What is the health and resource utilization of the system?

Ideally, the custom device is implemented to be minimally burdensome, extremely efficient, and

easy to use. Depending on its complexity, it may become necessary to test, debug, and

optimize the code on systems representative of the operator’s system. Consider the following

example.

A custom device developer needs to benchmark a 3

-party hardware custom device. He adds

the custom device to the Sine Wave example that ships with NI VeriStand 2010. He deploys

the system definition to a quad-core NI-8110 RT controller. Adding the custom device to the

system in increased the target’s CPU load by 10% per-core and RAM utilization increased

120KB. If the operator is deploying the same custom device to a single-core 8101 RT

controller, with an average CPU load of 60% because of a computationally intense model, it’s

unlikely the operator will achieve the same loop rate after adding the custom device. This

system may be incapable of running the custom device at all.

Time to test, debug and optimize the code must be factored into the development timeline. If

you’re developing for a specific operator, then it's best to test on a system representative of their

system. If you’re developing for unknown systems, then it may be appropriate to include the

specifications of the system used to obtain benchmarking and timing information with the

custom device documentation.

Planning the Custom Device

The most critical phase of custom device development is planning. Several idiosyncrasies of NI

VeriStand require more thorough planning than does a small stand-alone LabVIEW application.

There are five main things that must be planned.

1. Channels

剩余84页未读，继续阅读

身份认证购VIP最低享 7 折!

30元优惠券

面包超人总动员

粉丝: 233

NI VeriStand 2010 自定义设备开发者指南（Beta版）

最新资源