A Software EtherCAT Slave on a $5 ESP32 — Spoken Fluently to a Real Beckhoff TwinCAT 3 Master, Over a W5500 in MACRAW

#EtherCAT #IndustrialFieldbus #TwinCAT3 #SoftwareESC #MACRAW #ESP32 #FactoryAutomation #FMMU #ProofOfConcept #PromiscuousCapture

📚 Hobby / educational proof-of-concept — independent implementation, verified against a real Beckhoff TwinCAT 3 master ✅ Verified: device enumerates in TwinCAT as ESP32-DO8, climbs INIT → PreOp → SafeOp → OP, Working Counter valid, 8 GPIO outputs driven live from the master

01 — What is this project?

EtherCAT is the high-speed fieldbus that runs a huge share of the world's factory automation — robot cells, CNC machines, motion control. But getting onto an EtherCAT network as a slave device normally means buying a dedicated EtherCAT Slave Controller (ESC) chip like the Beckhoff ET1100 or Microchip LAN9252. That hardware, and the documentation behind it, is a wall between a curious engineer and the protocol.

This project knocks a hole in that wall. It implements an EtherCAT slave entirely in software on a plain ESP32-WROOM-32, using a WIZnet W5500 as the raw Ethernet front end. The firmware emulates an ESC from scratch — datagram parsing, the register file, Working Counter arithmetic, the AL state machine, SII EEPROM emulation, and FMMU process-data mapping — and it's not a simulation: it was built up in four layers, each one verified against a real Beckhoff TwinCAT 3 master before the next was added.

The reference application is deliberately simple so the protocol is the star: tick a checkbox in TwinCAT, and a physical GPIO on the ESP32 goes high. Eight digital outputs, mapped through real FMMU logical addressing, driven live from an industrial PLC master over a commodity Ethernet chip.

02 — Why software EtherCAT (and where it stops)?

🔷 The honesty is the feature

This curation usually celebrates capability. Here, the limitations section is what earns trust. The author is explicit: the W5500 is a store-and-forward chip, so this slave is a stable but slow node (~5–10 ms cycle times). It cannot do Distributed Clocks (DC) or sub-millisecond cycles — that genuinely requires a hardware ESC like the LAN9252. The Vendor ID is a placeholder (0x0000DEAD), valid for the lab, not for production interoperability. Nothing is oversold. For a learning artifact about a notoriously opaque protocol, that candor is exactly what makes it useful.

🔷 A learning ladder for an opaque protocol

The architecture doc walks the ESC emulation as four verified layers: W5500 MACRAW transport → datagram parser + Working Counter + AL FSM → SII/EEPROM identity handshake → FMMU logical-to-physical mapping. Each layer is the smallest thing that TwinCAT will accept before moving on. That's a roadmap anyone can follow to actually understand EtherCAT, not just use it.

🔷 A portable protocol core

The cleanest design decision: the EtherCAT logic (ecat.c, sii.c, the ESI file) is independent of transport. The author notes that porting to a real LAN9252 for DC-capable timing changes only the W5500 transport layer — the protocol brain carries over. The W5500 is what makes the learning version cheap and accessible.

03 — System architecture

04 — Why W5500? ⭐

🔷 Mode: MACRAW, promiscuous — verified in code

This is the heart of why the W5500 fits. An EtherCAT slave must see every frame on the wire, not just frames addressed to its IP — because EtherCAT doesn't use IP at all; the master sweeps datagrams past every node. The W5500's MACRAW socket mode (Sn_MR_MACRAW, 0x04) does exactly that: raw Layer-2 Ethernet frames, no TCP/IP stack in the way. The firmware opens socket 0 in MACRAW with the MAC filter bit cleared (promiscuous), so the ESP32 captures all of the master's EtherCAT traffic:

/* MACRAW mode.  MF (bit 7) cleared => promiscuous: capture ALL frames. */ w5500_wr8(W5500_BSB_S0_REG, W5500_Sn_MR, W5500_MR_MACRAW); socket_cmd(W5500_CMD_OPEN); /* verifies Sn_SR == 0x42 (SOCK_MACRAW) before proceeding */

This is the rare project where the W5500 is used not for its famous hardware TCP/IP offload (TOE), but for the opposite: getting completely out of the way and handing the CPU raw frames. The same chip that's usually prized for doing the network stack for you is here prized for not doing it — pure L2 access is exactly what a fieldbus needs.

🔷 Why a $5 SPI chip beats a dedicated ESC for learning

A real ESC (ET1100/LAN9252) is a specialized, harder-to-source part with its own steep documentation. The W5500 is cheap, ubiquitous, 3.3 V, and speaks SPI to any MCU. By choosing MACRAW + promiscuous capture, the author turned a commodity Ethernet chip into the physical layer of an industrial fieldbus node — the entry barrier collapses from "buy and learn an ESC" to "wire up a W5500 you probably already own."

🔷 The honest trade-off, stated by the hardware itself

The W5500 is store-and-forward: a frame is fully received into the buffer before the CPU sees it, then fully sent back. That's why DC and sub-ms cycles are off the table — and why the author is upfront about ~5–10 ms operation. The chip's nature defines the project's scope, and the project documents it precisely rather than hiding it.

🔷 Verified evidence ✅

• Boot log confirms the chip: VERSIONR = 0x04, socket reaches Sn_SR = 0x42 (SOCK_MACRAW)
• TwinCAT enumerates the device by name (ESP32-DO8) via the standard SII/EEPROM identity handshake
• AL state machine climbs all the way to OP (AL state -> 0x08)
• WcState = 0 in TwinCAT confirms the Working Counter is being incremented correctly
• Writing an output bit in TwinCAT drives the matching physical GPIO high — closed-loop, master-to-pin

05 — Key components

🌐 WIZnet W5500 — MACRAW (promiscuous) raw-Ethernet front end

Socket 0 opened in Sn_MR_MACRAW with MAC filter disabled; 16 KB RX/TX buffer assigned to the single socket. Native ESP-IDF SPI master driver (no Arduino), VSPI pins, manual CS so each [addr-hi][addr-lo][control][data] frame is atomic. Handles the MACRAW RX quirk where the 2-byte big-endian length header includes itself.

🧠 ESP32-WROOM-32 (original, not S3)

net_task pinned to CPU1 in a busy-poll loop to keep frame turnaround tight and the EtherCAT link stable; CPU0 left for system housekeeping.

⚙️ Software ESC core (ecat.c, 338 lines)

Datagram parser for all four EtherCAT addressing modes (auto-increment AP*, configured FP*, broadcast B*, logical L*), correct Working Counter rules, AL finite state machine, and FMMU logical→physical mapping into process RAM that drives the GPIOs.

💾 SII EEPROM emulation (sii.c)

Emulates the ESC EEPROM register interface with CRC8 so the master reads device identity through the exact standard handshake — including a custom 16×14 device icon embedded in the ESI.

📄 ESI device description (esi/ESP32_DO8.xml)

Installed on the TwinCAT side so the slave appears as a named device with its 8-output I/O map.

06 — Application scenarios

01. Hands-on EtherCAT education

The intended use: a cheap, fully-documented, layer-by-layer way to actually learn how an EtherCAT slave talks to a master — without buying ESC silicon.

02. Rapid fieldbus prototyping

Need a throwaway EtherCAT I/O node on the bench to test a master configuration or an ESI file? An ESP32 + W5500 stands in for a real slave at relaxed cycle times.

03. Bridge to production via LAN9252

Because the protocol core is transport-independent, this is a natural first step before committing to a DC-capable LAN9252 design — the ecat.c/sii.c/ESI work carries straight over.

04. Teaching MACRAW itself

A clean, real-world reference for using the W5500 in promiscuous MACRAW mode — useful to anyone building packet sniffers, custom L2 protocols, or fieldbus front ends on the same chip.

Conclusion

An industrial EtherCAT slave, emulated in firmware on a hobby-grade ESP32, made possible because the W5500 will — when asked — stop being a TCP/IP chip and just hand you raw Ethernet frames.

• ✅ Full software ESC: datagram parser, Working Counter, AL FSM, SII EEPROM, FMMU
• ✅ Verified against a real Beckhoff TwinCAT 3 master — climbs to OP, drives live I/O
• ✅ W5500 in MACRAW promiscuous mode (Sn_MR=0x04, Sn_SR=0x42) confirmed in code and boot log
• ✅ Transport-independent protocol core — portable to a LAN9252 for DC-capable timing
• ✅ Honest, precise limitations (store-and-forward → ~5–10 ms, no DC) that make it trustworthy as a learning artifact
• ✅ Complete docs: wiring map, layer-by-layer architecture, TwinCAT setup walkthrough

From hardware TCP/IP offload to raw Layer-2 industrial fieldbus access — the W5500 turns up wherever Ethernet needs to happen, even inside an EtherCAT node where its usual headline feature is deliberately switched off. The most surprising use of a TOE chip is the one that doesn't use TOE at all.

Q&A

Q. Which W5500 socket mode does this use, and why not TOE? MACRAW (Sn_MR_MACRAW, value 0x04), with the MAC filter disabled for promiscuous capture — verified directly in w5500.c. EtherCAT runs on raw Layer-2 Ethernet with no IP, and the master's datagrams sweep past every node, so the slave must capture all frames. The W5500's hardware TCP/IP (TOE) would actively get in the way; MACRAW is the only correct choice here.

Q. Is it real or simulated? Real, on hardware. The boot log reads back the W5500 VERSIONR and MACRAW socket status, and the device enumerates and reaches OP under an actual TwinCAT 3 master driving physical GPIOs. It is, by the author's own framing, a proof-of-concept — not a certified product.

Q. Why can't it do hard real-time EtherCAT? Because the W5500 is store-and-forward: frames are buffered in full before the CPU sees them and before they're sent back, which precludes Distributed Clocks and sub-millisecond cycles. That's an inherent property of the chip, and the project is explicit about it (~5–10 ms cycle times). For DC-capable timing the author points to a LAN9252 port, reusing the same protocol code.

Q. Is the code complete and buildable? Yes. ESP-IDF project (developed on v6.0.1) with CMakeLists.txt, sdkconfig.defaults, full main/ sources (W5500 driver, ESC core, SII emulation), the ESI file, plus WIRING.md and ARCHITECTURE.md. Build/flash/monitor steps and the complete TwinCAT setup are documented.

5천 원짜리 ESP32 위에 구현한 소프트웨어 EtherCAT 슬레이브 — W5500의 MACRAW로 진짜 Beckhoff TwinCAT 3 마스터와 대화하다

#EtherCAT #산업용필드버스 #TwinCAT3 #소프트웨어ESC #MACRAW #ESP32 #공장자동화 #FMMU #개념검증 #프로미스큐어스캡처

📚 취미/교육용 개념검증(PoC) — 독립 구현, 실제 Beckhoff TwinCAT 3 마스터로 검증 ✅ 검증됨: TwinCAT에서 ESP32-DO8로 인식, INIT→PreOp→SafeOp→OP 단계 진입, Working Counter 정상, 마스터에서 GPIO 8채널 실시간 구동

01 — 어떤 프로젝트인가?

EtherCAT은 전 세계 공장 자동화의 상당 부분 — 로봇 셀, CNC 공작기계, 모션 제어 — 을 돌리는 고속 필드버스다. 그런데 슬레이브 장치로 EtherCAT 네트워크에 올라타려면 보통 Beckhoff ET1100이나 Microchip LAN9252 같은 전용 EtherCAT 슬레이브 컨트롤러(ESC) 칩을 사야 한다. 그 하드웨어와 그 뒤에 숨은 방대한 문서가, 호기심 많은 엔지니어와 이 프로토콜 사이를 가로막는 벽이다.

이 프로젝트는 그 벽에 구멍을 낸다. 평범한 ESP32-WROOM-32 위에서 EtherCAT 슬레이브를 순수 소프트웨어로 구현하고, WIZnet W5500을 생(raw) 이더넷 프런트엔드로 쓴다. 펌웨어가 ESC를 밑바닥부터 에뮬레이션한다 — 데이터그램 파싱, 레지스터 파일, Working Counter 연산, AL 상태머신, SII EEPROM 에뮬레이션, FMMU 프로세스 데이터 매핑까지. 그리고 시뮬레이션이 아니다: 네 개의 계층으로 쌓아 올리되, 각 계층을 실제 Beckhoff TwinCAT 3 마스터로 검증한 뒤에야 다음 계층을 올렸다.

레퍼런스 애플리케이션은 일부러 단순하게 만들어 프로토콜이 주인공이 되게 했다: TwinCAT에서 체크박스 하나를 켜면 ESP32의 물리 GPIO 핀이 High로 올라간다. 진짜 FMMU 논리 주소지정을 거친 디지털 출력 8채널을, 산업용 PLC 마스터가 범용 이더넷 칩 너머로 실시간 구동한다.

02 — 왜 소프트웨어 EtherCAT인가 (그리고 어디서 멈추는가)?

🔷 솔직함이 곧 강점이다

이 큐레이션은 보통 "할 수 있는 것"을 칭송한다. 그런데 이 프로젝트는 한계 섹션이 신뢰를 만든다. 저자는 분명히 못 박는다: W5500은 store-and-forward 칩이라 이 슬레이브는 **안정적이지만 느린 노드(약 5~10 ms 사이클)**라고. Distributed Clocks(DC)나 sub-ms 사이클은 불가능하며, 그건 LAN9252 같은 하드웨어 ESC가 있어야 한다. Vendor ID는 플레이스홀더(0x0000DEAD)로 실험실용일 뿐 양산 상호운용에는 못 쓴다. 무엇 하나 과장하지 않는다. 악명 높게 불투명한 프로토콜을 배우는 학습 자료로서, 이 솔직함이야말로 이 프로젝트를 쓸모 있게 만든다.

🔷 불투명한 프로토콜을 위한 학습 사다리

아키텍처 문서는 ESC 에뮬레이션을 검증된 4계층으로 풀어낸다: W5500 MACRAW 전송 → 데이터그램 파서 + Working Counter + AL FSM → SII/EEPROM 신원 핸드셰이크 → FMMU 논리-물리 매핑. 각 계층은 TwinCAT이 받아들이는 "다음으로 넘어가기 위한 최소 단위"다. EtherCAT을 그냥 쓰는 게 아니라 이해하려는 누구나 따라갈 수 있는 로드맵이다.

🔷 이식 가능한 프로토콜 코어

가장 깔끔한 설계 판단: EtherCAT 로직(ecat.c, sii.c, ESI 파일)이 전송 계층과 독립적이라는 점이다. 저자는 DC 가능한 타이밍을 위해 실제 LAN9252로 포팅할 때 바뀌는 건 W5500 전송 계층뿐이고 프로토콜 두뇌는 그대로 넘어간다고 짚는다. W5500은 학습용 버전을 싸고 접근 가능하게 만드는 역할이다.

03 — 시스템 아키텍처

04 — 왜 W5500인가? ⭐

🔷 모드: MACRAW, 프로미스큐어스 — 코드로 검증됨

W5500이 들어맞는 이유의 핵심이 여기다. EtherCAT 슬레이브는 자기 IP로 온 프레임만이 아니라 회선의 모든 프레임을 봐야 한다 — EtherCAT은 애초에 IP를 쓰지 않고, 마스터가 데이터그램을 모든 노드에 훑고 지나가기 때문이다. W5500의 **MACRAW 소켓 모드(Sn_MR_MACRAW, 0x04)**가 바로 그 일을 한다: TCP/IP 스택이 끼어들지 않는 생 L2 이더넷 프레임. 펌웨어는 소켓 0을 MACRAW로 열되 MAC 필터 비트를 끈(프로미스큐어스) 상태로 두어, ESP32가 마스터의 모든 EtherCAT 트래픽을 캡처한다:

/* MACRAW mode.  MF(bit 7) clear => promiscuous: 모든 프레임 캡처 */ w5500_wr8(W5500_BSB_S0_REG, W5500_Sn_MR, W5500_MR_MACRAW); socket_cmd(W5500_CMD_OPEN); /* 진행 전에 Sn_SR == 0x42(SOCK_MACRAW) 확인 */

이 프로젝트는 W5500을 그 유명한 하드웨어 TCP/IP 오프로드(TOE)로 쓰는 게 아니라, 정반대로 — 완전히 비켜서서 CPU에 생 프레임을 넘기는 용도로 쓰는 드문 사례다. 보통은 네트워크 스택을 대신 처리해줘서 칭송받는 바로 그 칩이, 여기서는 그 일을 안 해주기 때문에 가치가 있다. 순수 L2 접근 — 그것이 필드버스가 필요로 하는 전부다.

🔷 왜 학습용으로는 5천 원짜리 SPI 칩이 전용 ESC를 이기는가

실제 ESC(ET1100/LAN9252)는 구하기 어렵고 자체 문서도 가파른 특수 부품이다. W5500은 싸고, 어디에나 있고, 3.3 V이며, 어떤 MCU와도 SPI로 대화한다. MACRAW + 프로미스큐어스 캡처를 선택함으로써, 저자는 범용 이더넷 칩을 산업용 필드버스 노드의 물리 계층으로 바꿔놓았다. 진입 장벽이 "ESC를 사서 익혀라"에서 "이미 갖고 있을 W5500을 연결하라"로 무너진다.

🔷 하드웨어 스스로가 말하는 솔직한 트레이드오프

W5500은 store-and-forward다: 프레임을 버퍼에 완전히 받은 뒤에야 CPU가 보고, 완전히 받은 뒤에야 회신한다. 그래서 DC와 sub-ms 사이클은 불가능하고, 저자가 약 5~10 ms 동작이라고 미리 밝히는 이유도 그것이다. 칩의 본성이 프로젝트의 범위를 정의하며, 프로젝트는 그것을 숨기지 않고 정확히 문서화한다.

🔷 검증된 증거 ✅

• 부팅 로그가 칩을 확인: VERSIONR = 0x04, 소켓이 Sn_SR = 0x42(SOCK_MACRAW) 도달
• TwinCAT이 표준 SII/EEPROM 신원 핸드셰이크로 장치를 이름(ESP32-DO8)으로 인식
• AL 상태머신이 OP까지 진입 (AL state -> 0x08)
• TwinCAT의 WcState = 0이 Working Counter가 정상 증가함을 확인
• TwinCAT에서 출력 비트를 쓰면 해당 물리 GPIO가 High로 — 마스터에서 핀까지 폐루프

05 — 핵심 구성요소

🌐 WIZnet W5500 — MACRAW(프로미스큐어스) 생 이더넷 프런트엔드

소켓 0을 Sn_MR_MACRAW로 열고 MAC 필터 비활성화, 단일 소켓에 16 KB RX/TX 버퍼 할당. 네이티브 ESP-IDF SPI 마스터 드라이버(Arduino 미사용), VSPI 핀, 수동 CS로 [주소상위][주소하위][제어][데이터] 프레임을 원자적으로 전송. 2바이트 빅엔디언 길이 헤더가 자기 자신을 포함하는 MACRAW RX 특유의 함정도 처리.

🧠 ESP32-WROOM-32 (S3 아님, 오리지널)

net_task를 CPU1에 고정해 busy-poll 루프로 돌려 프레임 왕복을 촘촘히 유지하고 EtherCAT 링크를 안정화; CPU0는 시스템 작업용.

⚙️ 소프트웨어 ESC 코어 (ecat.c, 338줄)

EtherCAT 4가지 주소지정 모드(자동증가 AP*, 설정 FP*, 브로드캐스트 B*, 논리 L*) 데이터그램 파서, 올바른 Working Counter 규칙, AL 유한상태머신, 프로세스 RAM으로의 FMMU 논리→물리 매핑(이게 GPIO를 구동).

💾 SII EEPROM 에뮬레이션 (sii.c)

ESC EEPROM 레지스터 인터페이스를 CRC8과 함께 에뮬레이션해 마스터가 정확히 표준 핸드셰이크로 장치 신원을 읽게 함 — ESI에 임베드한 커스텀 16×14 장치 아이콘 포함.

📄 ESI 장치 기술서 (esi/ESP32_DO8.xml)

TwinCAT 측에 설치해 슬레이브가 8출력 I/O 맵을 가진 이름 있는 장치로 나타나게 함.

06 — 응용 시나리오

01. 실습형 EtherCAT 교육

의도된 용도: ESC 실리콘을 사지 않고도, EtherCAT 슬레이브가 마스터와 어떻게 대화하는지 계층별로 실제로 배우는 싸고 완전히 문서화된 방법.

02. 빠른 필드버스 프로토타이핑

마스터 설정이나 ESI 파일을 테스트하려고 벤치에 버려도 되는 EtherCAT I/O 노드가 필요할 때, ESP32 + W5500이 완화된 사이클 타임에서 실제 슬레이브를 대신한다.

03. LAN9252를 향한 양산 디딤돌

프로토콜 코어가 전송 독립적이라, DC 가능한 LAN9252 설계로 넘어가기 전 자연스러운 첫걸음이다 — ecat.c/sii.c/ESI 작업이 그대로 넘어간다.

04. MACRAW 그 자체의 교본

W5500을 프로미스큐어스 MACRAW 모드로 쓰는 깔끔한 실전 레퍼런스 — 같은 칩으로 패킷 스니퍼, 커스텀 L2 프로토콜, 필드버스 프런트엔드를 만드는 누구에게나 유용.

결론

취미용 ESP32 위에 펌웨어로 에뮬레이션한 산업용 EtherCAT 슬레이브 — W5500이 부탁받으면 TCP/IP 칩이기를 멈추고 그냥 생 이더넷 프레임을 건네주기 때문에 가능했다.

• ✅ 완전한 소프트웨어 ESC: 데이터그램 파서, Working Counter, AL FSM, SII EEPROM, FMMU
• ✅ 실제 Beckhoff TwinCAT 3 마스터로 검증 — OP까지 진입, 실시간 I/O 구동
• ✅ W5500 MACRAW 프로미스큐어스 모드(Sn_MR=0x04, Sn_SR=0x42) 코드·부팅 로그로 확인
• ✅ 전송 독립적 프로토콜 코어 — DC 가능 타이밍을 위해 LAN9252로 이식 가능
• ✅ 솔직하고 정확한 한계 명시(store-and-forward → 약 5~10 ms, DC 불가)가 학습 자료로서의 신뢰를 만듦
• ✅ 완비된 문서: 배선도, 계층별 아키텍처, TwinCAT 설정 가이드

하드웨어 TCP/IP 오프로드에서 생 L2 산업용 필드버스 접근까지 — W5500은 이더넷이 필요한 곳이라면 어디든, 심지어 자기 간판 기능을 일부러 끈 EtherCAT 노드 안에서도 모습을 드러낸다. TOE 칩의 가장 의외의 활용은, TOE를 전혀 쓰지 않는 활용이다.

Q&A

Q. W5500의 어떤 소켓 모드를 쓰며, 왜 TOE가 아닌가요? MACRAW(Sn_MR_MACRAW, 값 0x04), MAC 필터를 끈 프로미스큐어스 캡처입니다 — w5500.c에서 직접 확인됩니다. EtherCAT은 IP 없는 생 L2 이더넷으로 동작하고 마스터의 데이터그램이 모든 노드를 훑고 지나가므로, 슬레이브는 모든 프레임을 캡처해야 합니다. W5500의 하드웨어 TCP/IP(TOE)는 오히려 방해가 되며, 여기서는 MACRAW가 유일하게 올바른 선택입니다.

Q. 실제인가요, 시뮬레이션인가요? 하드웨어 상의 실제입니다. 부팅 로그가 W5500 VERSIONR과 MACRAW 소켓 상태를 읽어 확인하고, 실제 TwinCAT 3 마스터 아래에서 장치가 인식되어 OP에 도달하며 물리 GPIO를 구동합니다. 저자 스스로의 표현대로 개념검증이며 인증 제품은 아닙니다.

Q. 왜 하드 리얼타임 EtherCAT은 안 되나요? W5500이 store-and-forward이기 때문입니다: 프레임을 CPU가 보기 전에, 그리고 회신하기 전에 버퍼에 완전히 받아야 하므로 Distributed Clocks와 sub-ms 사이클이 불가능합니다. 이는 칩 고유의 특성이고, 프로젝트는 이를 명확히(약 5~10 ms 사이클) 밝힙니다. DC 가능 타이밍은 동일 프로토콜 코드를 재사용하는 LAN9252 포팅으로 안내합니다.

Q. 코드는 완전하고 빌드 가능한가요? 네. ESP-IDF 프로젝트(v6.0.1에서 개발)로 CMakeLists.txt, sdkconfig.defaults, 완전한 main/ 소스(W5500 드라이버, ESC 코어, SII 에뮬레이션), ESI 파일, 그리고 WIRING.md·ARCHITECTURE.md를 갖췄습니다. 빌드/플래시/모니터 절차와 전체 TwinCAT 설정이 문서화되어 있습니다.