How Do I Start my Real-Time Application without setting it as a Startup Executable?
Primary Software: LabVIEW Modules>>Real-Time Module
Primary Software Version: 8.5
Primary Software Fixed Version: N/A
Secondary Software: N/A
Problem: My real-time VIs are completed, and now I am preparing to build a real-time executable. Since real-time targets typically DO NOT have user interface, how am I suppose to start my real-time application without choosing "set as startup"?
Solution: For many applications, real-time targets will use
stand-alone applications that are selected as startup executables. By choosing "set as startup", every time the real-time controller reboots the application is started. This is because in most targets will be running industrial controls systems that must persist even through power surges.
Some applications call for the user to select when to run a real-time application (to begin a test scenario, etc.) There are three common ways of starting applications on real-time targets. Each has advantages and disadvantages that will be discussed.
- Idle State in a State Machine - A common LabVIEW architecture is the state machine. A state machine is a way to implement a flow chart in LabVIEW code. In your real-time application you would use a state machine, and make the first state an "Idle" state. The application will still be set as startup, but will remain in the idle state until the user sends a command (in the form of a TCP, UDP, or shared variable communication).
Advantages - The executable always loads at startup. If you store (in a file) which state the program is in, then after a power surge the program can return to that specific state. Plus the program starts quickly because it is only waiting for a command.
Disadvantages - A host-side program is required to send commands. If you use shared variables, the real-time target will need variable client support installed.
- VI Server - VI server can be used to dynamically call a VI remotely on a real-time target. For more information about how to use VI Server refer to the LabVIEW help. For an example on how to call a VI programmatically using VI server refer to the LabVIEW example finder and search for VI Server. The example is called "VI Server.lvproj" and only installs with the real-time module.
Advantages - A startup executable is not required in this architecture.
Disadvantages - When opening a reference to the VI with VI Server, it takes time to load the VI into memory, thus a slower reaction time to start. A host side program is required to make VI Server commands. Additional setup is needed to configure VI Server.
- Remote Front Panel - Remote front panels allow users to view and control the VI front panels remotely from LabVIEW or from a web browser without any programming. Essentially the real-time target will broadcast the front panel of the VI and if enabled, allow the user to interact with the VI through a web browser (Internet Explorer, Firefox, etc.) Instruction on how to enable and configure a remote front panel for a real-time target can be found here.
Advantages - A host side program is not needed to start the VI. The VI is still built into an startup executable, but typically a button on the real-time VI begins the test program. With the purchase of more remote front panel licenses, more than one user can view the remote front panel. Be sure to activate your remote front panel licenses for Real-Time.
Disadvantages - Because real-time targets are meant to be headless, no programmatic information about the front panel is stored on the controller. Thus it is not advised to manipulate the front panel with property and method nodes.
Related Links: Developer Zone Tutorial: Application Design Patterns: State MachinesLabVIEW 8 Help: Building VI Server ApplicationsKnowledgeBase446JE42F: How Do I Create a Remote Front Panel for Use on a Real-Time Target Executable?KnowledgeBase 2UD9C67V: Multi-User Remote Panel Licenses for LabVIEW Real-Time Targets
Attachments:
Report Date: 12/27/2007
Last Updated: 01/09/2008
Document ID: 4GQAE4JV
