Architecture Note: Deterministic 1 kHz Loop on LabVIEW Real‑Time Targets

Requirements

The system must execute a control loop at a fixed 1 kHz rate with jitter < 1 ms, allow the host PC to change set‑points and monitor health, and revert to a safe actuator command if the host link fails. Determinism is required for closed‑loop stability, and the design must isolate untrusted UI or file‑system code from the real‑time kernel.

Smallest Suitable Design

A single LabVIEW Real‑Time VI deployed to an NI‑RT target (e.g., cRIO‑9030 or sbRIO‑9607) contains:

• A 1 kHz Timed Loop set to High priority (priority = 90 on NI‑LinuxRT).
• Analog input reads (e.g., NI 9205 module) → PID algorithm → analog output writes (e.g., NI 9263 module).
• Front‑panel objects limited to a Boolean Run switch, a Status indicator, and numeric displays for set‑point and process value.
• A Network Stream endpoint named ctrl_stream configured with NI‑secure credentials (username/password) for authenticated, encrypted traffic.
• A watchdog timer (NI‑RT Watchdog VI) that resets the VI if the Timed Loop exceeds its period.
• Error clusters from the Timed Loop are forwarded to the host via the same Network Stream; loss of the stream triggers a safe‑state (zero voltage/current command) while the VI attempts reconnection.

Trust and Data Boundaries

The RT target runs the minimal NI Linux RT kernel. Trusted data paths are:

• Authenticated Network Streams (NI‑secure credentials) for configuration, set‑points, and health telemetry.
• FPGA‑to‑RT DMA channels for high‑speed I/O (if an FPGA is present).

All other interfaces—UI controls, file system access, generic TCP/UDP sockets—are disabled on the RT target. The development host runs the full LabVIEW IDE and may open file dialogs or display graphs, but those components never execute on the deterministic core.

Operational Checks and Failure Modes

Watchdog Reset

If the Timed Loop body takes longer than 1 ms (its period), the NI‑RT Watchdog VI triggers a VI restart. The watchdog must be fed (Watchdog Feed) at the end of each loop iteration.

Host‑Side Logging

Error clusters (e.g., timeout, overflow) are bundled into a Variant and pushed onto the Network Stream. A simple host‑side VI reads the stream and writes entries to a rolling log file.

Loss of Network Stream

The RT VI polls the stream state with Network Stream Get Status. When the status reports Not Connected, the VI:

1. Writes a safe‑state value (e.g., 0 V) to all actuator channels.
2. Starts a reconnection timer (configurable, default 500 ms).
3. Attempts to reopen the stream using the same credentials.
4. Resumes normal control once the stream reports Connected.

Configuration Example

// LabVIEW Project Explorer settings (no code, just properties)
Target: NI cRIO-9030 (NI‑LinuxRT 2022)
LabVIEW Version: 2022 SP1
Timed Loop:
  Period: 1 ms
  Priority: High (90)
  Timing Source: 1 kHz Internal Clock
Network Stream:
  Name: ctrl_stream
  Endpoint Type: Buffered
  Max Buffer Size: 1024 bytes
  Security: NI‑Secure (username: rtuser, password: ******)
Watchdog:
  Timeout: 2 ms (must be > loop period)
  Feed Location: End of Timed Loop
Safe‑State:
  Analog Output Channels: 0.0 V
  Digital Output Lines: Low

Verification Procedure

Perform these checks on the deployed RT VI; they require LabVIEW Developer Suite access to the target and the ability to open the LabVIEW Profiler.

1. Jitter Measurement: Open Tools » Profile » Performance and Memory, select the Timed Loop, run for at least 5 minutes, and record the Period Jitter statistic. Verify that the 99.9th‑percentile jitter remains ≤ 1 ms.
2. Watchdog Trigger: Insert a temporary Wait (20 ms) function inside the Timed Loop (outside any critical section). Deploy the VI, observe the RT target’s console (via ni-rtcli target console) for a watchdog reset message, and confirm that the host‑side logger receives an error cluster with code 0xBF000001 (watchdog timeout). After removing the wait, the VI should resume normal operation.
3. Network Stream Failure: With the VI running, disable the host‑side listener or unplug the Ethernet cable. Verify that the RT VI’s front‑panel Status indicator changes to Disconnected, actuator outputs drop to the safe‑state value, and the VI logs a reconnection attempt every 500 ms. Re‑enable the listener or reconnect the cable; the VI should restore the Connected state and resume control without manual intervention.

Limitations and Practical Checks

Version sensitivity: The default priority inheritance model for Timed Loops changed between LabVIEW 2019 and 2022. If you develop on 2022 but deploy to a target running the NI‑RT kernel from 2019, the loop may run at a lower effective priority, increasing jitter. Check the kernel version with ni-rtcli target info and match it to the LabVIEW Runtime version used for the build.

Priority inversion: Any low‑priority VI that acquires a semaphore or mutex also needed by the high‑priority Timed Loop can cause unbounded delay. Use NI‑recommended Semaphore VIs with the Priority Inheritance flag set to true, or eliminate non‑essential background loops from the RT target.

To verify that no unwanted background loops are running, open the RT target’s ni-rtcli target listv command and ensure only the control VI appears in the list of VIs with High priority.

Conditions That Would Change the Design

• If the required loop rate drops below 500 Hz, a standard While Loop with a Wait Until Next ms Multiple could replace the Timed Loop, simplifying the watchdog logic.
• If host communication must carry large data bursts (e.g., waveform downloads) exceeding the Network Stream buffer, consider adding a separate TCP/IP stream for bulk data while keeping the control stream for set‑points and health.
• If the system needs fault‑tolerant redundancy (dual RT targets), the safe‑state logic would need to coordinate via a shared variable or network‑published heartbeat rather than acting independently.