At the recent GLA Summit 2025, I presented how Workers for LabVIEW (version 5.0) has evolved into an effective framework for structured, modular development on NI Real-Time (RT) targets like the CompactRIO. This article summarizes the main insights and key takeaways from my presentation.
🖥️ Modern Hardware Makes It Possible
The capabilities of CompactRIO systems have drastically improved in recent years, making structured frameworks feasible and practical on RT targets. Consider these performance improvements:
CPU Power: Modern cRIO CPUs are 20 to 50 times faster (DMIPS) than early models.
Multicore CPUs: Current models provide dual or quad-core processors, enabling genuine parallelism for multiple real-time processes.
RAM and Storage: Up to 32 times more RAM and significantly greater onboard storage capacities allow for modular and dynamically loaded applications.
FPGA and Ethernet Capabilities: FPGA logic density has increased by approximately 10 times, and Ethernet throughput is substantially higher, enhancing real-time data streaming.
This evolution in hardware means developers are no longer restricted to creating small, tightly coupled, monolithic applications—modular architectures are now practical and beneficial.
Feature
Early cRIOs (2004–2008)
Modern cRIOs (2020–2025)
Improvement Factor
CPU Power
~500 DMIPS
~10,000–25,000 DMIPS
~20x to 50x
CPU Cores
Single-core only
Dual-core and Quad-core available
2x to 4x
RAM
64–128 MB
512 MB – 4 GB
8x to 32x
Storage
128–256 MB Flash
4 – 64+ GB eMMC / SSD
16x to 256x
FPGA Fabric
~200K logic gates (Virtex-II)
1–2M logic elements (Zynq-7020, Kintex-7)
5x to 10x
Ethernet
10/100 Mbps
Gigabit Ethernet, Time-Sensitive Networking
10x
Application Size
Small, monolithic apps only
Large modular apps with HALs, dynamic loading
10x capability
đź§© Why Use Workers on NI Real-Time Targets?
With hardware constraints largely resolved, Workers for LabVIEW becomes an ideal choice for structured RT development, providing:
1. Modern Hardware Compatibility
Current cRIO hardware comfortably supports modular, message-driven architectures like Workers. There's no need for compromise on software design principles.
2. Unified Architecture for Windows and RT
The Workers framework allows you to maintain consistency across platforms—develop once and deploy to both Windows and RT targets seamlessly. This dramatically reduces redundancy and simplifies development workflows.
3. Modular and Scalable Design
Workers naturally encourages breaking applications into isolated, reusable modules. This scalability and modularity help manage complexity as systems grow.
4. Built-in RT-Compatible Tools
Workers includes comprehensive tools designed explicitly for RT development—like automated Worker creation, API scripting, and the Workers Debug Server—greatly simplifying development and troubleshooting.
🔍 Solving Common RT Development Challenges
Challenge 1: Debugging Reentrant VIs
Debugging reentrant VIs on RT is challenging—typically, you can’t pause execution, probe wires, or set breakpoints. Workers resolves this by providing two types of Worker Main VIs:
Main.vi (Reentrant): Standard, suitable for multiple instances.
Main NR.vi (Non-Reentrant): Specifically for RT debugging, allowing standard LabVIEW debugging tools (breakpoints, probes, and stepping).
Switching between these modes is quick and easy using the provided RT Worker Convert Tool, offering flexibility and control during development.
Challenge 2: Limited Runtime Transparency
RT targets traditionally offer minimal runtime feedback. The Workers Debug Server addresses this problem by providing live runtime monitoring and detailed message logs of applications deployed on remote RT targets, significantly enhancing visibility and debugging effectiveness.
Challenge 3: Host-to-RT Data Streaming Complexity
While Network Streams or Network Shared Variables are common, they have limitations and setup complexity. Workers simplifies host-to-RT communication through built-in TCP Server and TCP Client Workers, facilitating robust, scalable, and straightforward data streaming over TCP/IP.
⚠️ Two Crucial Tips for RT Development
Lastly, my presentation highlighted two critical recommendations to avoid common pitfalls:
Disable "Separate Compiled Code from Source"
Keep this flag off for all classes and VIs deployed to RT targets to avoid random deployment issues.Maintain Separate Projects for Host and RT Targets
Using distinct LabVIEW projects for Windows and RT prevents class-locking and ensures compatibility with Workers development tools.
🎯 Final Thoughts
Workers for LabVIEW 5.0 bridges the gap between modern software architectures and embedded RT systems. Thanks to the dramatic improvements in RT hardware, adopting a modular and structured development framework like Workers on CompactRIO targets is now not only possible—but practical and highly effective.
If you'd like more details or access to the full slide deck from my GLA Summit 2025 presentation, feel free to download the slides here:
Thanks for reading—happy wiring!
— Peter Scarfe, Creator of Workers for LabVIEW