Choosing Run‑as Startup vs Manual Deployment for Headless LabVIEW Real‑Time Targets

Problem: How to get a LabVIEW Real‑Time VI running on a cRIO or cDAQ without a host PC?

When you design a field‑deployable device, you often need the VI to start automatically after power‑on, or you might prefer to trigger it manually when you want to re‑deploy or debug. LabVIEW Real‑Time gives two deployment paths: Run‑as Startup (automatic boot‑time launch) and Manual Deployment (host‑initiated launch). Choosing the right one is critical for deterministic behavior, maintenance, and safety.

Thesis: Use Run‑as Startup for true headless, production‑grade operation; use Manual Deployment only when you need on‑demand control or rapid iteration.

1. Run‑as Startup – The “Always‑On” Mode

When you configure a VI as the Startup VI in the target’s settings, the RT OS loads and launches that VI immediately after boot. No host PC is required, and the VI runs in the background of the RT system.

• Pros – No dependency on a host; deterministic start‑up time; suitable for safety‑critical or production equipment.
• Cons – No front panel; debugging requires remote probes or a network UI; you cannot change the VI without redeploying.

To enable it:

// In LabVIEW Project Explorer
// Right‑click the target → Properties → Run‑as → Startup
// Select the VI you want to run automatically

After building, the VI is copied to the target’s file system (e.g., /usr/local/ni_rt/vi/ for NI Linux RT). The RT OS will launch it on boot. Verify by powering the cRIO, disconnecting the host, and checking a known output (digital line toggle, log file).

2. Manual Deployment – Host‑Initiated Control

With Manual Deployment, the target sits idle until a host PC sends a Deploy command. This is handy during development or when you need to switch between multiple VIs.

• Pros – Easy to switch VIs; can pause or stop without reboot; useful for iterative testing.
• Cons – Requires host connectivity; launch time is longer; not suitable for safety‑critical or fully autonomous operation.

To deploy manually:

// On the host PC
LabVIEW Project Explorer → Right‑click target → Deploy

The target receives the VI over Ethernet, writes it to its file system, and starts it. The VI will keep running until you stop it or the target reboots.

3. Concrete Example: A Simple Digital‑Line Toggle

Let’s walk through a minimal example that demonstrates both deployment modes. The VI toggles a digital output every second and logs the timestamp to a local file.

// VI: ToggleOutput.vi
// Front panel: None needed for startup mode
// Block diagram:
// 1. While Loop
//    a. Write 1 to Digital Line (e.g., /Dev1/port0/line0)
//    b. Wait 0.5 s (Wait Until Next Sample)
//    c. Write 0 to Digital Line
//    d. Wait 0.5 s
//    e. Append timestamp to file (e.g., C:\Logs\toggle.log on cRIO)

**Setup**

1. Open LabVIEW 2026.1 (assumed); create a new project.
2. Add your cRIO target by IP (e.g., 192.168.1.10).
3. Place the VI on the target node.
4. In the target’s properties, set the VI as Startup VI for Run‑as Startup, or leave it as a regular VI for Manual Deployment.
5. Build the project.
6. For Startup: Power‑cycle the cRIO, disconnect the host, and check the log file and digital line state.
7. For Manual: Keep the host connected, deploy, observe the log, then stop the VI via the host UI.

**Verification**

• Use MAX (Measurement & Automation Explorer) to confirm the target is reachable and the OS type (Pharlap ETS or NI Linux RT).
• After build, check the target’s log folder (/var/log/ni_rt/ or similar) for deployment status.
• If the VI is missing or not running, re‑build or check the license status.

4. Trade‑offs & Limitations

• Determinism – While LabVIEW RT provides priority‑based scheduling, the startup VI runs at a fixed priority (default 10). Setting it to Time‑Critical can reduce jitter but may starve other system tasks.
• Debugging – Remote front panels over Ethernet introduce latency; use Probe or NI‑Web UI for live monitoring, but remember they are not real‑time.
• File System Differences – Pharlap ETS targets use C:\ paths; NI Linux RT uses Unix‑style paths. Scripts or VI paths must be adapted accordingly.
• License & Version – The Real‑Time Module must match the LabVIEW version. A mismatch will prevent deployment.
• Network Dependencies – Manual deployment requires Ethernet connectivity. If the target is in a radio‑quiet zone, startup mode is safer.

5. Actionable Takeaway

For production or safety‑critical devices that must run autonomously, set a single, well‑tested VI as the Startup VI. Keep the host disconnected after deployment and use network‑published shared variables or a web UI for monitoring. Reserve Manual Deployment for development, debugging, or when you need to switch between multiple VIs on the fly. Always verify the target’s OS, license, and network reachability before building, and use MAX logs to confirm deployment success.