Components of a Project

At minimum, an NI VeriStand project consists of one project file (.nivsproj), one system definition file (.nivssdf), and one screen file (.nivsscreen). A project also can contain supported NI hardware, custom devices, compiled models, models developed using The MathWorks, Inc. Simulink® software environment, any customization VIs, and more.

A project consists of the following components:

• Project File—The .nivsproj file that defines the screen file used by the host computer, determines which system definition file runs on the execution host, defines the available users and their permissions for the project, defines the list of tools you can launch from the Tools menu of the Workspace window, determines which services run when you deploy a project to the execution host, specifies the host-side actions that occur when an alarm is detected on the execution host, specifies the IP address of the VeriStand Gateway, and contains a list of any stimulus profiles or custom files used by the project.
• System Definition File—The .nivssdf file you configure in the System Explorer window. A system definition file contains the configuration settings of the VeriStand Engine, including:
  
  
  • The rate at which the system runs.
  • The number of signal generators instantiated on the system.
  • The list of NI-DAQ devices, NI-XNET devices, NI FPGA targets, or reflective memory devices.
  • The task and channel configurations for hardware.
  • The models to execute in the system, including your compiled model to run, the order in which they execute, and the rate at which they execute.
  • The list of active alarms. You can use alarms to trigger actions on the execution host, such as procedures, or can display dialog boxes that alert the user of an event.
  • The list of procedures that can execute on the execution host. A procedure is a script of commands that define a set of actions in the VeriStand Engine.
  • The list of channels for data objects in the system. Channel types include:
    • Hardware I/O channels (DAQ, FPGA, etc.)
    • Model channels (inputs, outputs, parameters, signals)
    • User channels (used to store or map user-defined values in the system)
    • Calculated channels (channels that represent the result of a user-defined calculation of other channels in the system)
  • The system mappings that determine how channels are connected.
• Screen File—Defines the configuration and settings for the screens and display items you view in the Workspace window.
• Host Computer—The computer that runs the VeriStand Gateway and hosts the screen file. The host computer must be a PC running Windows 7, Vista, XP, or Server.
• Execution Host—The desktop PC or RT target on which you run the system definition file and VeriStand Engine.

Note  When deploying to a desktop PC the host computer and execution host can be the same desktop PC.

• VeriStand Engine—The non-visible execution mechanism that controls the timing of the entire system as well as the communication between the execution host and the host computer. The VeriStand Engine consists of multiple timed loops that use RT FIFOs to transfer data between the loops.
• VeriStand Gateway—Creates a TCP/IP communication channel that facilitates communication with the VeriStand Engine over the network. The VeriStand Gateway receives channel values from the VeriStand Engine and stores these values in a table that can be viewed using the Channel Data Viewer, available in the Tools menu of the Workspace window.
  
  If you run a project on a desktop PC, the VeriStand Gateway initiates the VeriStand Engine. If you run a project on an RT target, the VeriStand Gateway synchronizes with the system definition file that is running on the RT target. If the system definition file currently running on the VeriStand Engine does not match the system definition file that the VeriStand Gateway expects, then the VeriStand Gateway does not synchronize with the system definition file running on the RT target.
• Model—A simulation block diagram, generally a mathematical representation of a real-world system. A model responds to stimuli by producing outputs in a way that emulates the behavior of the modeled item. Models contain inputs and outputs that send and receive data. Models contain parameters you can manipulate and signals whose values you can view. For example, a model that generates a sine wave contains parameters that adjust the amplitude and frequency of the sine wave. You can view the value of the sine wave using the model signal.
  
  You can build models using several different modeling environments, including The MathWorks, Inc. Simulink® application software, Esterel SCADE Suite™ software, TESIS DYNAware software, MATRIXx™ SystemBuild™ software, and the LabVIEW Development System. Refer to the KnowledgeBase or visit ni.com/info and enter the info code: exy5ez for more information about supported modeling software packages.
  
  You can run a model (.mdl) you created in the Simulink simulation environment without compiling it if you have The MathWorks, Inc. MATLAB® and Simulink software installed on your computer. In this case, the host computer also must be the execution host. You only can run an uncompiled model (.mdl) you created using the Simulink software on a computer running the Windows operating system because NI VeriStand requires that a model be compiled before it can run on an RT target.
• Compiled model—A simulation model in compiled form. NI VeriStand requires that a model be compiled before it can run on an RT target. A compiled model also can run on a desktop PC. NI VeriStand supports compiled models from any modeling environment that enables you to compile a model into a DLL, .out, or .lvmodel file.
  
  You can use The MathWorks, Inc. Real-Time Workshop® software and Microsoft Visual C++ to convert your model into a DLL, or the GNU Toolchain to convert your model into a .out file. Real-Time Workshop converts your model and any subsystems into a C code version of the same model. The resulting C code version of your model is the same Simulink block diagram model, just in a C code form. The compiler (Microsoft Visual C++ or the GNU Toolchain) then compiles the C code model into a file named ModelName.dll or ModelName.out, where ModelName is the name of the model. Real-Time Workshop places the compiled model file into the current working directory. The following figure shows this conversion process.
  
  

  

  
  
  NI VeriStand supports Microsoft Visual C++ 6.0, .NET 2003, 2005 (Professional or Express), or 2008 (Professional or Express).
• NI VeriStand Server—The server that uses a TCP/IP connection to transmit data between NI VeriStand and your uncompiled model (.mdl) running in the Simulink software environment. Before running a project, you must launch the NI VeriStand Server, which starts automatically when you launch MATLAB. By default, the NI VeriStand Server runs on port 6012.
  
  If your project uses a compiled model you do not need to use the NI VeriStand Server.
• Stimulus profile—A file that contains Stimulus Profile Editor settings, such as stimulus generator mappings and the locations of any calibration files and header VIs you add. You create and run a stimulus profile using the Stimulus Profile Editor.
• LabVIEW Development System—If you want to create custom devices, workspace controls/indicators, Stimulus Profile Editor headers, timing devices, and/or Tools menu utilities, you need the LabVIEW Development System.
• LabVIEW Real-Time Module—You must install RT support onto the RT target to run an RT project. You need this module to use RT functions in custom device VIs.
• LabVIEW FPGA Module—If you add a National Instruments FPGA target to a project, it must have an associated FPGA bitfile. NI VeriStand provides FPGA bitfiles for certain FPGA devices. If you want to customize these FPGA bitfiles or create a custom FPGA bitfile for another FPGA target, you need the FPGA Module.
• National Instruments Driver Software—You need the appropriate National Instruments driver software to communicate with hardware installed on an execution host. NI VeriStand supports the following driver software versions you can use with the associated hardware types:
  
  
  • NI-RIO 3.5 or later
  • NI-XNET 1.1 or later
  • NI-DAQmx 9.1.5 or later
  • NI-VISA 5.0 or later

Note  Use Measurement & Automation Explorer (MAX) to install and configure software on the execution host.