Wiznet makers

Thumbnail image: AI-generated image

SPOOLER: a wire-EDM tension controller on WIZnet W6100-EVB-Pico2

Introduction

SPOOLER is a dedicated wire-tension controller for a wire EDM machine.

For non-specialists, wire EDM is a machining process that cuts conductive metal with a thin moving wire and controlled electrical discharges. The wire continuously travels through the cutting area, so wire handling and tension are part of the machining process itself, not just an accessory function. (Research and Markets)

Based on the uploaded ZIP snapshot, SPOOLER is the part of the machine that manages that wire path. It runs on W6100-EVB-Pico2, reads a spring-loaded dancer position sensor, drives two stepper-controlled spools, and exposes machine data to a LinuxCNC host over Modbus TCP.

What this project is

AI-generated image

In simple terms, SPOOLER is a small embedded controller that keeps EDM wire tension under control.

The uploaded source snapshot shows a clear machine workflow:

• one motor feeds fresh wire forward,
• one motor takes used wire up,
• a spring-loaded dancer moves when tension changes,
• and the firmware keeps that dancer near a target position by adjusting spool speed.

That makes the project easy to understand even outside CNC circles: it is a closed-loop wire-tension controller for a machine that depends on a very thin moving wire staying stable.

The same ZIP snapshot also shows that this is more than bare motor code. It includes firmware, a Modbus TCP server, a Python desktop monitor, a written firmware spec, live tuning through registers, and fault handling for wire-break and over-travel conditions.

How it works for machine operators

AI-generated image

The operator-facing workflow is straightforward.

In manual mode, the system can jog the feed and recovery spools using front-panel buttons. That is useful for threading the wire, checking motion, or recovering after a stop.

In automatic mode, the controller runs a closed-loop tension algorithm. The dancer sensor is sampled, filtered, and compared with a target position. If the wire becomes tighter or looser, the controller changes the recovery spool speed relative to the feed spool speed so the dancer returns toward its setpoint.

In the uploaded firmware snapshot, this loop runs at 100 Hz.

The same snapshot also shows two fault conditions:

• wire break, when the dancer drops below the minimum limit,
• over-travel/slack, when the dancer rises above the maximum limit.

When either fault is detected, the controller latches the fault and stops both motors until the fault is cleared.

The project also includes a small desktop monitor tool. In the uploaded spooler_monitor.py, it displays live dancer position, feed rate, PID gains, fault state, mode status, manual-button state, and raw TDS sensor value, which makes tuning and troubleshooting much easier during bring-up.

How it works for developers

AI-generated image

From a developer’s point of view, SPOOLER is easiest to understand as a four-layer control architecture.

At the bottom is the machine I/O layer. This is where the controller reads the dancer-position sensor, the TDS input, the auto/manual switch, and the manual jog buttons, then drives the feed and recovery motors through a PIO-based stepper layer.

Above that is the real-time control layer. This is the core of the system. A repeating callback runs at 100 Hz, reads the dancer signal, filters it, applies the PID gains, checks the travel limits, and decides what the two spools should do next. In automatic mode, the controller keeps the feed spool running at the commanded base rate and adjusts the recovery spool to pull the dancer back toward its target position. In manual mode, the same motion hardware is reused, but the PID loop is bypassed and the jog buttons drive the spools directly.

Next comes the shared machine-state layer. The controller keeps its operating state in a compact register bank. Writable values such as feed rate, dancer setpoint, min/max travel, and PID gains sit beside readable values such as dancer position, TDS reading, fault code, and mode state. Architecturally, this is the key boundary in the project: the control loop owns the live machine behavior, while the communication side simply exposes that state to the outside world.

At the top is the communication layer. W6100 provides the wired Ethernet path, and the firmware exposes the machine state through a Modbus TCP server. That separation is important. Modbus is not where the control logic lives; it is the interface through which a host system such as LinuxCNC or the included monitor can observe the controller and adjust parameters.

In runtime form, the flow looks like this:

Sensors and panel inputs → 100 Hz control loop → motor commands → shared register/state model → Modbus TCP over W6100 → LinuxCNC / monitor tool

That structure is one of the project’s strongest points. The host does not directly “run the machine” every cycle. Instead, the embedded controller closes the loop locally, while the host supervises, reads status, and writes targets. That is a better fit for machine integration than a design where Ethernet traffic is mixed directly into real-time motion behavior.

Where WIZnet fits

This project uses WIZnet in a very grounded way.

WIZnet’s official documentation describes W6100-EVB-Pico2 as an RP2350-based board that behaves like a Pico 2 while adding Ethernet through W6100. The same documentation states that GPIO16–21 are internally connected to the W6100 for Ethernet use, and W6100 itself supports hardwired TCP/UDP, IPv4/IPv6 dual stack, 8 sockets, and integrated 10/100 Ethernet MAC/PHY. (WIZnet Docs)

That is exactly how SPOOLER uses it. In the visible source, W6100 is the wired machine interface between the tension controller and the LinuxCNC host. This is not a hybrid-network demo and not a cloud-oriented IoT endpoint. It is a single primary wired control path for a machine subsystem.

That fit makes sense. A wire-EDM subsystem does not need flashy connectivity. It needs a predictable wired interface while the MCU focuses on sensing, PID, and motion timing. WIZnet’s own positioning for W6100 also highlights factory/building automation and serial-to-Ethernet style embedded control roles, which is very close to how it is being used here. (WIZnet Docs)

Why it matters

SPOOLER is interesting because it focuses on a machine subsystem that is easy to overlook but critical in practice.

A wire EDM machine depends on more than spark generation. It also depends on stable wire transport, spool coordination, tension feedback, and fault detection. The uploaded source turns that subsystem into a clear, inspectable controller instead of leaving it hidden inside a larger proprietary stack.

It also fits naturally with LinuxCNC, which is an open CNC control platform used for milling machines, lathes, robots, hexapods, and other machine types. That makes SPOOLER more relevant for retrofit, experimental, or custom-machine workflows than a closed machine-only solution would be. (LinuxCNC)

Market context

What market does this belong to?

AI-generated image

SPOOLER does not sit in a mass-market embedded category.

The closest fit is the market for wire-EDM machine subsystems, controls, and retrofits — especially machine-side control blocks related to wire feed, wire tension, and controller integration.

A clean public market size for open wire-tension controllers specifically is not clearly available in the public sources reviewed here. Public market reports size the broader EDM machine market, not this exact subsystem niche. One of the clearest broader public market references is from Research and Markets, which estimates the global electrical discharge machines market at USD 4.16 billion in 2026, growing to USD 6.08 billion by 2032. (Research and Markets)

So the most accurate reading is this: SPOOLER is not the whole EDM market, but it clearly sits inside a real industrial market and inside a smaller, credible niche for wire-EDM control and retrofit components.

Is wire tension really a product-level concern?

Yes.

Commercial wire-EDM systems explicitly publish wire tension and wire feed speed as real machine specifications. For example, SPM lists wire tension and feed speed in its wire-cut EDM specifications, and CHMER publishes wire tension and wire feed data for its wire-cut EDM products as well. That validates the core premise of SPOOLER: this project is addressing a subsystem that commercial wire-EDM machines already treat as important to performance and usability. (SPMEDM)

Productization potential

AI-generated image

The available materials do not show that SPOOLER itself is already sold as a commercial product.

What the available materials do show clearly is that the project has product-like characteristics:

• a dedicated machine-side function,
• a wired industrial protocol interface,
• live parameter tuning,
• a host-side monitor,
• and a clear separation between motion, control, and networking.

That makes it most credible as a retrofit controller, a subsystem controller inside a larger machine, or a development platform for a more complete wire-handling module.

Quick notes

The uploaded ZIP snapshot is strong on firmware clarity. It includes a readable README, a detailed spec file, a desktop monitor tool, and a sensible module split.

Two details are worth stating carefully.

First, the README mentions DHCP, but the currently visible src/main.c applies a static network configuration (192.168.100.2/24, gateway 192.168.100.1). So the safest description of the current code is static-IP Modbus TCP, not DHCP-first networking.

Second, the TDS input is exposed in the current code as a raw ADC value, not as a fully converted or compensated water-quality measurement. It is still useful, but it should be described accurately.

FAQ: SPOOLER (W6100-EVB-Pico2 Wire-EDM Tension Controller)

This FAQ covers the technical architecture, operational workflow, and hardware details of the SPOOLER project, an open-source, closed-loop wire tension controller for Electrical Discharge Machining (EDM) systems.

Q1. What is the SPOOLER project?

SPOOLER is a dedicated embedded controller that manages the physical wire path and tension in a wire-EDM (Electrical Discharge Machining) system. Unlike general-purpose motor drivers, it is a purpose-built industrial subsystem that reads sensor data, drives feed and recovery spools, and maintains exact wire tension while exposing real-time machine data to a host controller (like LinuxCNC) over Modbus TCP.

Q2. How does the closed-loop tension control work?

The system uses a 100 Hz PID (Proportional-Integral-Derivative) control loop to keep the wire tension stable, which is critical for precision cutting.

• Sensors: A spring-loaded "dancer" physically moves when the wire tension changes.
• Action: If the wire gets too tight or too loose, the firmware adjusts the speed of the recovery spool relative to the feed spool to pull the dancer back to its target setpoint.
• Fault Detection: If the dancer drops below a minimum limit (wire break) or rises above a maximum limit (slack/over-travel), the controller immediately latches a fault state and halts both motors.

Q3. Why use the WIZnet W6100-EVB-Pico2 board?

This board is chosen for its hardwired industrial networking capabilities rather than consumer IoT features.

• Hardware: It combines an RP2350 microcontroller with a W6100 hardwired TCP/IP Ethernet chip.
• Role: The W6100 provides a strictly wired, highly predictable Ethernet path for the Modbus TCP server.
• Advantage: By offloading the network stack to the W6100 chip, the RP2350 can dedicate its processing power entirely to real-time motion control, I/O polling, and PID calculations without network-induced jitter.

Q4. How is the software architecture structured?

The firmware is cleanly separated into four distinct layers to prevent network traffic from interfering with real-time motion:

1. Machine I/O Layer: Reads the dancer sensor, raw TDS (water quality) input, and manual jog buttons; drives the stepper motors via PIO.
2. Real-Time Control Layer: Runs the 100 Hz PID loop, filters signals, and calculates motor speeds based on auto/manual modes.
3. Shared Machine-State Layer: Maintains a compact register bank dividing data into read-only status (fault codes, dancer position) and writable targets (feed rate, PID gains).
4. Communication Layer: Exposes the shared state registers to the outside world via a Modbus TCP server over the W6100 Ethernet link.

Q5. How does SPOOLER integrate with larger CNC systems?

SPOOLER acts as an independent subsystem rather than requiring the host computer to run the motors directly. Through Modbus TCP, a host system like LinuxCNC (or the included Python desktop monitor) can supervise the controller, read live status, and write new targets. The SPOOLER handles the micro-second, closed-loop motor adjustments locally, making it an ideal drop-in component for custom CNC builds or wire-EDM retrofits.

Q6. Are there any specific technical notes for replicating this project?

If you are deploying or adapting this code, note the following configurations:

• Static IP over DHCP: While documentation may reference DHCP, the core network configuration typically initializes with a static IP (e.g., 192.168.100.2/24) for reliable Modbus TCP targeting.
• Dedicated Pins: GPIO pins 16–21 on the RP2350 are internally routed to the W6100 chip for SPI communication. They cannot be reassigned for motor pulses or sensor inputs.
• TDS Input: The Total Dissolved Solids (TDS) sensor data is exposed as a raw ADC value, meaning any specific water-quality compensations must be calculated on the host side.

References

https://docs.wiznet.io/Product/iEthernet/W6100/w6100-evb-pico2
https://docs.wiznet.io/Product/Chip/Ethernet/W6100
https://linuxcnc.org/
https://www.britannica.com/technology/machine-tool/Electrical-discharge-machining-EDM
https://www.researchandmarkets.com/reports/6015328/electrical-discharge-machines-market-type
https://www.spmedm.com/default/business/business2_eng.php
https://www.chmer.com/en/products/wire-cut-edm/rq-series/rq3625l