Choosing Between LabVIEW Event Structure and Polling Loops for 1 kS/s Deterministic Acquisition

Decision and constraints

The measurement system must acquire analog signals at 1 kS/s, keep the end‑to‑end latency ≤ 1 ms, limit average CPU usage on the real‑time target to < 30 %, and provide deterministic timing for downstream control loops.

Comparison of options

Feature	Event Structure	Polling Loop
Typical latency	<0.5 ms	1‑2 ms
CPU usage	Low – the VI sleeps until an event occurs	Higher – the loop runs continuously
Determinism	High when the event queue does not overflow; missed events only if queue fills	Moderate – jitter depends on loop rate and interference from other tasks
Implementation complexity	Moderate – requires registering the DAQmx read‑complete event	Simple – a timed while‑loop with a DAQmx Read
LabVIEW support	Available since LV 8.0 (Core)	All versions

Trade‑offs

The Event Structure reduces CPU load and can achieve sub‑millisecond response because the VI only wakes when a DAQmx read completes. Its main risk is event‑queue overflow: if the producer (DAQmx) generates samples faster than the consumer (event case) can process them, events are dropped and data loss occurs. Proper queue monitoring and setting the VI priority to High or Time‑Critical on real‑time targets mitigate this risk.

A polling loop guarantees a fixed sample rate because the loop iterates at a set interval, but it consumes CPU cycles even when no new data is available. Jitter can appear if other VPs or OS tasks delay the loop, making it harder to meet the ≤ 1 ms latency bound under heavy load.

Concrete implementation using an Event Structure

1. Place a DAQmx Create Virtual Channel node configuring an analog input channel for 1 kS/s acquisition.
2. Use a DAQmx Timing node set to Continuous Samples with a rate of 1000 Hz.
3. Call DAQmx Start Task to begin acquisition.
4. Insert an Event Structure.
5. Inside the Event Structure, add a DAQmx Read Complete event case.
6. In that case, place a DAQmx Read node (configured for 1 sample per channel) to retrieve the newest waveform, apply any scaling, and forward the data to the control algorithm.
7. Add a timeout case (e.g., 100 ms) that increments a watchdog counter; if the counter exceeds a threshold, flag a possible event‑queue stall.
8. Outside the Event Structure, place a DAQmx Stop Task and DAQmx Clear Task in a cleanup sequence that executes when the VI stops.

// Pseudo‑code (LabVIEW G) – not actual compiled output
DAQmx Create Channel → AI0
DAQmx Timing → 1000 Hz Continuous
DAQmx Start Task
Event Structure
  - DAQmx Read Complete case:
      DAQmx Read (1 sample) → Scale → Control Algorithm
  - Timeout case (100 ms):
      Watchdog Counter += 1
      if Watchdog Counter > 10 → Set Error Flag
DAQmx Stop Task
DAQmx Clear Task

Validation and verification

Latency measurement

Place a Tick Count probe immediately before the DAQmx Read node and another immediately after the control algorithm finishes. Subtract the earlier tick from the later tick for each iteration. Over a run of 1000 iterations, compute the average and standard deviation. The requirement is met if the average latency ≤ 1 ms and the standard deviation ≤ 0.2 ms.

CPU usage check

Open the Performance and Memory tool (Tools → Profile → Performance and Memory). Run the VI on the real‑time target for at least 30 seconds. Observe the average CPU usage; it should stay below 30 % with no sustained spikes coinciding with event processing.

Queue‑overflow monitoring

Add a DAQmx Get Read Total Samp Per Chan Generated node inside the event case. Compare the generated count with the number of samples actually read. A growing difference indicates the queue is filling faster than it is being drained; adjust the event‑case execution time or increase the VI priority.

Limitations and practical checks

• If the control algorithm itself takes > 0.5 ms, the total latency will exceed the budget regardless of the acquisition method.
• On targets with limited interrupt priority levels, setting the VI to Time‑Critical may starve lower‑priority threads; monitor system responsiveness.
• The Event Structure relies on the DAQmx driver generating a read‑complete event; ensure the DAQmx version matches the LabVIEW version (LV 8.0+).

To confirm the implementation works as intended, run the VI, enable Execution Highlighting, and verify that the event case fires approximately every 1 ms (as shown by the Tick Count difference) while the CPU usage reported by the Performance and Memory tool remains under the 30 % threshold.