Wireless EtherCAT over BlitzFunk®
Native EtherCAT MainDevice communication, carried over a deterministic industrial WLAN — no protocol gateway, no tunnelling, no slip ring.
EtherCAT is a wired protocol by design — and for most machines, the cable is the ideal choice: it is cheap, fast, easy to install and test and allows completely deterministic data communication. But many machines include a rotating turntable or other parts that move continuously, and this is exactly where the cable becomes the weak point — wear, slip rings and cable breaks cause recurring maintenance costs and unplanned downtime. Together with fünfeinhalb Funksysteme GmbH (fuenfeinhalb.de), we have therefore been running EC-Master over their BlitzFunk industrial wireless link to find out whether native EtherCAT, with no protocol gateway or tunnelling in between, can run reliably over the air.
Rotary filling machines and labellers feature numerous stations on a rotating carousel: servo axes, valves, load cells, and I/O are connected via EtherCAT through a slip ring.
10 msstable cycle time with only 8ms roundtrip time! |
200M+EtherCAT frames in endurance testing |
The key results from our measurements: Stable EtherCAT communication at 10ms cycle time!
Scope of the tests: EtherCAT I/O in Direct Mode
The EtherCAT frame is transmitted by the MainDevice and passes all SubDevices and is then reflected by the last SubDevice – again passing the network back to the MainDevice; as all SubDevices do processing-on-the fly in hardware, the network latency and jitter is minimized. The BlitzFunk link bridges one segment of the EtherCAT line: In our test-setup one BlitzFunk access point is connected to the MainDevice side, one BlitzFunk client to the SubDevice side, and together they behave like a single cable segment. The frame therefore crosses the wireless link twice in every cycle, once in each direction – which is why the latency per direction determines the minimum cycle time (see “How it works”).
We did not specially test EtherCAT Open Mode nor EtherCAT Automation Protocol, as these protocols make use of switched networks – with respective limitations to their real-time capabilities; and acontis already verified that these also work with standard wireless networks (like WLAN).
Test Setup
The acontis EC-Master was operated on a standard test device at acontis – an Intel Core i3-9100based PC with an Intel I210 Ethernet card running Linux with PREEMPT_RT patch. We only ran the EC-Master and the acontis EC-Master Demo application with performance measurement enabled on the PC, and did not use further stress-functions like stress-ng as we wanted to focus on the wireless link, not the MainDevice hardware.
For a simple test setup, the PC was connected to one BlitzFunk device, which acts as a wireless 1:1 bridge to a second BlitzFunk device, which was connected to the EtherCAT SubDevices – two EK1100 couplers with several I/O terminals (EL2004, EL4132, EL1014). DC was not used for this test (also due to the targeted cycle time of 10ms).
The test-setup: MainDevice connected via wireless link to the SubDevices.
We tested the system in different scenarios – from a short wireless link without obstacles up to a distance of approx. 15 m with multiple walls in between (drywalls as well as steel-reinforced concrete walls).
Wireless link data settings of the BlitzFunk devices: BlitzFunk Firmware Version 3.1.0, System Version 2.1.5 (Software from June 2026); 6Ghz band using channel 9 and 45.
Test setup: EC-Master on a PC with Intel I210 NIC, a Beckhoff EK1100/EL-series SubDevice stack, and a pair of BlitzFunk devices (6 GHz) bridging the EtherCAT link.
How it works
EC-Master, acontis' EtherCAT MainDevice stack, uses the acontis real-time Ethernet driver to access the network - exactly the same as when using a classic cable connection. The cable runs to the BlitzFunk device. BlitzFunk's own scheduling protocol reserves a fixed time slot for the link in each direction – this allows guaranteeing a bounded latency per frame transfer. EtherCAT frames pass through the radio link natively — there is no protocol conversion.
As the BlitzFunk devices are transparent to the network, neither the ENI configuration, nor the SubDevice configuration, nor the application above EC-Master needs to be changed. From the EC-Master's point of view, the wireless hop behaves like an extra, well-characterized piece of cable with a bounded delay.
With BlitzFunk's current firmware, that bounded delay is 4 ms guaranteed per direction, which results in 8 ms roundtrip-time and thus – as of today – allows any EtherCAT cycle time longer than 8ms. Longer cycle times (10 ms, 20 ms and above) are therefore expected to run with comfortable margin; the endurance tests described below were performed at 10 ms.
Measured performance
We ran EC-Master over the BlitzFunk devices in long-duration endurance tests at distances from about 1 m up to 15 m, including runs through several walls (drywalls and steel-reinforced concrete walls), at a conservative 10 ms EtherCAT cycle time, with round-trip time and frame loss measured continuously over 24- to 72-hour windows. It should be noted that deliberate deployments through walls are not recommended by fünfeinhalb. The tests through walls were conducted to understand BlitzFunk’s limits
Scenario
|
Distance |
Duration |
EtherCAT Frames |
Frame loss |
Max. round-trip time |
Avg. round-trip |
|
A – short range |
~1 m |
72 h |
51.84 M |
0.077 ppm |
6.2 ms |
3.6 ms |
|
B – mid range, no walls |
~10 m |
24 h |
17.28 M |
1.2 ppm |
7.2 ms |
4.9 ms |
|
C – larger distance, through walls |
~15 m |
24–72 h |
17.28–51.84 M |
0.06–5.1 ppm |
5.7-6.0 ms |
3.4–5.1 ms |
|
D – test with impacted signal quality |
~10 m |
24 h |
17.28 M |
33.16 ppm |
7.3 ms |
4.5 ms |
Frame loss stayed between 0.06 and 5.1 parts per million (ppm) across more than 200 million transmitted frames in total, and maximum round-trip times stayed well inside the 10 ms cycle even at 15 m through walls.
We also checked whether the error rate depends on the time of day; normal activity in the acontis office had no significant effect on it.
Frame loss per hour over a 72-hour endurance run at 15 m distance — isolated single-digit losses per hour, no systematic drift
Stress test: Deliberately poor installation
During testing, we used BlitzFunk’s browser-based configuration tool to check and optimize antenna alignment and link stability.
To find out how much margin the link has, we also ran a stress test that does not reflect the installation guidelines as well as avoiding any best-practise guides: 10 m distance across several rooms, with reinforced concrete walls and drywalls in between, in addition the BlitzFunk devices were placed behind PCs, whose metal housings blocked RF propagation, and the antennas were deliberately misaligned. Anyone who depends on a stable link – for example in production – would never install the system this way. With this scenario we still managed to see signal strengths ranging between -68 and -75dBm – which has impacts on the wireless link. A good signal strength would be better than -60dBm, very good better than -50dBm. As comparison: by adjusting the antennas, but keeping distance, obstacles we already saw -62 to -65 dBm reported by the BlitzFunk devices.
Even in this setup (Scenario D), frame loss rose to 33 ppm at most, and still the EtherCAT communication continued to run stable the used cycle time of 10ms.
After simply moving the PCs out of the line of sight and aligning the antennas correctly (with otherwise identical device placement (Scenario B) we measured a significantly lower error rate below 1.2 ppm.
In short: even a fundamentally flawed installation did not interrupt the EtherCAT communication, and a correct installation reduced frame loss by more than two orders of magnitude. Because stable EtherCAT communication requires a stable link, the installation should be verified with the BlitzFunk configuration and monitoring tools before productive use.
Verification test: Wireless Link between SubDevices
To verify that the BlitzFunk wireless link can be used at any position within the network, we changed the setup – instead of having the wireless link between the MainDevice and the first SubDevice, we moved the wireless link between two SubDevices. To make it most easy for us, we simply added another Test-IO Block to the network and moved the BlitzFunk devices between the SubDevices: The MainDevice is connected to the first I/O block consisting of one EK1100, 2 EL2004 2 EL1014, one EL4132 and one EK1110 – BlitzFunk wireless link - second I/O block consisting of one EK1100, 2 EL2004 2 EL1014, one EL4132 and one EK1110
The test-setup: Wireless link between two SubDevices.
With this configuration, we also checked the user-friendliness: We simply used the EC-Engineer to scan the network to generate a fitting ENI-file: It worked exactly the same as when using this in a standard cabled network!
EC-Engineer scanned the network via the wireless link!
After that we ran a quick check reusing the software and the main setup from scenario A (short range, no obstacles), with cycle time of 10ms. We again saw the same good results as when the wireless link is situated between MainDevice and first Subdevice – the average roundtrip time at 3.6ms and maximum roundtrip time of only 4.9ms. The BlitzFunk wireless link can thus be placed at any place in the network, allowing to have segments of the network connected via cables, and only specific parts using a wireless link.
Conclusion
The measured results are very promising: we achieved stable EtherCAT communication with a stable round-trip time and very low frame loss. The current setup therefore appears suitable for use at cycle times of 10 ms and above, giving much greater flexibility in SubDevice placement: slip rings and similar components can simply be replaced by a 1:1 wireless link. Please note that all tests so far were performed with stationary devices in an office environment.
With these tests we could verify that EtherCAT direct mode can also be used via a wireless link – and depending on the specific requirements of your use-case the BlitzFunk devices might be just the solution you are looking for – however there are for sure applications where the wireless link will not be suitable – e.g. if faster cycle times are needed or multiple wireless links at different points in the network are required, which increase the latency and thus limit the achievable EtherCAT cycle time.
10 ms might seem slow for many people working with high-speed motion applications, but in many use cases, the in-machine network is much slower – 10 or 20 ms cycle times still provide much faster data-transfer and significant better synchronicity of all devices than classic field busses like CANopen or Profibus can achieve.
Note: fünfeinhalb is working on new firmware that provides even lower per-direction latency, which is expected to allow even faster cycle times in the near future.
Typical applications
Wireless communication within EtherCAT can benefit many use cases in which cables have so far been limited by mechanical or environmental constraints.
- Rotary tables, turntables and slip ring replacement — eliminate wear parts on continuously rotating axes.
- Moving tool heads — avoid cable flexing and connector fatigue at the moving interface.
- Hard-to-cable retrofits — add EtherCAT SubDevices to existing machinery where running new cable is impractical.
- Aggressive environments — chemicals or other media that degrade cables.
- Temporary and reconfigurable setups — test cells, event and stage automation, and machines that are frequently rearranged.
Related Products
|
TECHNOLOGY PARTNER fünfeinhalb — BlitzFunkBlitzFunk, made by the German company fünfeinhalb Funksysteme GmbH, is a deterministic industrial WLAN built for moving machines, mobile robots and safety-related control. A proprietary scheduling protocol reserves airtime for every device in advance, so latency and data rate are fixed worst-case guarantees rather than best-effort averages — exactly the property EC-Master needs to carry real EtherCAT traffic over the air. BlitzFunk runs in the 2.4 GHz, 5 GHz and 6 GHz bands (the latter still largely unused), supports seamless roaming between access points with zero added latency, encrypts and authenticates all traffic by default, and is configured through a web interface in about a minute. Visit fünfeinhalb → |