cRIO and WAGO over EtherCAT: channels in a file, not in the code

On several test benches, I have used a CompactRIO (cRIO) controller as an EtherCAT master to drive remote WAGO inputs and outputs, with a LabVIEW Real-Time application. The topic: the architecture I chose, what you need to know about EtherCAT on the NI side, and the design rule that has made the biggest difference to these projects.

Why this architecture

• The cRIO runs the real-time application and acts as the EtherCAT master. Its second Ethernet port, switched to EtherCAT mode, is reserved for the field network; the first remains dedicated to the development PC.
• WAGO 750-354 couplers host the I/O modules on the rail and expose them over EtherCAT. They are daisy-chained port to port, without a switch: the frame turns round at the last coupler and returns to the master.
• The WAGO 750/753 system offers a very wide choice of modules (digital, analogue, special) at a moderate cost, as close as possible to the wiring.

EtherCAT on the NI side: the Scan Engine is in charge

• One frame per cycle: each slave reads and writes its share of the frame on the fly. A counter (Working Counter) reports within the same cycle that a slave has not processed its data.
• The NI Scan Engine publishes each data point as an I/O variable and refreshes all channels together, at a single period. It does not buffer: a value not read before the next scan is lost.
• The Scan Engine mode sets the slave states: in Active mode they go to Operational; in Configuration mode they return to Pre-Operational. Any deployment that changes the project forces Configuration mode.
• A third-party slave such as the 750-354 only appears in the project after its description file (ESI) has been imported and LabVIEW restarted. Otherwise it remains an "Unknown Device".

The core rule: no hard-coded channels

Dragging I/O variables onto the block diagram is fine for a prototype. On a bench that evolves, the name of every channel ends up frozen in the code. So I separated two levels of configuration:

• The network configuration, managed by NI: the imported ESI file, then the topology (master, couplers, modules, scan period) saved in the LabVIEW project and deployed to the cRIO.
• The channel configuration, managed by the application: a file that maps each I/O variable to a functional alias, a type, a direction, scaling and a fallback value.

• A channel manager reads the file at start-up and refuses to start the control loop if a channel does not exist, a type does not match or an alias is duplicated.
• The application only knows the aliases, never the hardware paths.
• Reading a whole module costs far less than reading channel by channel: the manager reads by module, then distributes the values by alias.

The result: a change of wiring or sensor is handled without recompiling, and the same application serves several benches that differ only in their channel file.

Points to watch

• The order of the modules in the project must match the physical order on the rail: it sets the coupler's process image. Any mismatch shifts all the channels.
• The versions of the EtherCAT driver and LabVIEW must be compatible: I freeze them for each project and record them.
• The safe state: on loss of communication, the WAGO coupler forces all its outputs to 0. I therefore wire each output so that 0 is the safe state, and I include a cable disconnection test in acceptance.
• Recovery: after a disconnection, the coupler waits for an acknowledgement from the master. My application monitors the state of each slave and provides the recovery sequence.
• Powering a node: a power supply module after the coupler, an end module at the end of the rail, and a power budget checked with WAGO Smart Designer before ordering.
• In operation, the application starts as an executable on the cRIO, never from the development environment: running a VI triggers a deployment and can change the Scan Engine mode.

Key takeaways

• Most difficulties come from configuration (ESI import, module order, versions), not from the EtherCAT protocol itself.
• Declaring channels in a file rather than in the code makes the bench modifiable without recompiling.
• Safety is designed into the wiring: 0 must be the safe state of every output, and disconnection is tested during acceptance.

Further reading

NI, NI-Industrial Communications for EtherCAT and the NI Scan Engine, ni.com; NI, EtherCAT on CompactRIO, ni.com; WAGO, 750-354 Fieldbus Coupler EtherCAT, wago.com