Guide to Modbus TCP ESP32 Communication between W5500 Module and Siemens S7 1200 PLC #factoryautomat

Guide to Modbus TCP ESP32 Communication between W5500 Module and Siemens S7 1200 PLC

COMPONENTS

PROJECT DESCRIPTION

ESP32 + W5500로 만드는 지멘스 PLC Modbus TCP 통신 노드

지멘스 S7-1200 PLC는 이미 웹 서버를 내장하고 있지만, LAN·모바일 원격 제어나 자유로운 데이터 추출, C 기반의 간단한 개발이 필요해지면 별도의 네트워크 창구가 필요해진다. 이 프로젝트는 ESP32에 WIZnet W5500 유선 이더넷을 붙여 PLC의 Modbus TCP 서버(MB_SERVER)와 홀딩 레지스터를 주고받는 방법을, PLC 설정(TIA Portal)부터 ESP32 펌웨어까지 한 흐름으로 보여준다.

COMPONENTS

Hardware components

ESP32 개발 보드 (SPI 마스터, Modbus 애플리케이션 계층 처리)
WIZnet W5500 이더넷 모듈 (하드웨어 TCP/IP, L2~L4 오프로딩)
Siemens S7-1200 PLC — 영상 기준 CPU 1214C (DC/DC/DC 또는 AC/DC/Relay) [확인 필요: 정확한 모델/펌웨어]
RJ45 LAN 케이블, 이더넷 스위치(선택)
점퍼선 (SPI 배선: SCK·MISO·MOSI·CS·RESET)

Software & Tools

Siemens TIA Portal (PLC 측 MB_SERVER·DB 블록 구성)
Arduino IDE (ESP32 펌웨어)
라이브러리: SPI.h, Ethernet.h(W5500), Modbus 라이브러리(예: ArduinoModbus / modbus-esp8266) [확인 필요: 영상에서 사용한 정확한 라이브러리]
Modbus 점검 도구(Modbus Poll 등, 선택)

출처 안내 이 글은 베트남어 YouTube 영상(채널명 factoryauto.vn / "Factory Auto", 영상 ID pEW_pZyJ7hY)의 공개 자막을 바탕으로, 단순 번역이 아니라 "왜 PLC에 웹 서버가 있는데도 ESP32+W5500을 붙이는가" 라는 관점에서 부품 역할과 설정 흐름을 재구성한 편집 콘텐츠입니다. 자막이 음성 인식으로 일부 표기가 흐려져 있어(예: FP32→ESP32, W5000→W5500, BCN/cement→PLC/TIA Portal로 정정), 기술 용어는 표준 표기로 복원했습니다. 영상에 직접 드러나지 않은 모델명·라이브러리·채널 정보 등은 [확인 필요]로 표시했습니다.

작성자 / 출처 신뢰도

재구성(게시) 관점. 본 콘텐츠는 maker.wiznet.io 편집 기준에 따라 W5500의 역할을 중심으로 영상을 재해석했다. 음성 인식 자막의 표기 오류는 Modbus TCP / TIA Portal의 표준 워크플로우와 대조해 복원했으며, 복원에 확신이 없는 부분은 그대로 [확인 필요]로 남겼다.

원 출처 (자막 기준 확인)

형식: 베트남어 산업 자동화 튜토리얼 영상
채널: 자막에서 factoryauto.vn("Factory Auto")로 언급. 운영자 실명·구독자 수·소속 회사 등은 [확인 필요] (영상 페이지 직접 확인 실패, 검색으로도 채널 신원 미확정)
주제: ESP32 + W5500을 이용한 지멘스 PLC Modbus TCP 통신
자료 제공: 영상에서 "블로그/자료 탭에 코드와 문서를 올린다"고 안내 [확인 필요: 실제 URL]

신뢰도 메모: 이 자료는 "개인 교육 채널의 실습 튜토리얼"이라는 출처 특성상, 제도적 권위가 아니라 **재현 가능한 절차(설정 단계·핀맵·레지스터 매핑)**가 신뢰의 근거다. 운영자 신상·회사·조회수 등 비공개/미확인 정보는 추측하지 않았다. 동일 구성(ESP32+W5500+Modbus TCP)은 ESP32 공식 포럼, Arduino 포럼, eModbus 문서 등 다수의 공개 자료에서도 표준적으로 확인되는 패턴이다.

신규 콘텐츠 요약

무슨 프로젝트인가: ESP32+W5500을 **Modbus TCP 클라이언트(마스터)**로 만들어, Modbus TCP 서버(슬레이브)로 동작하는 S7-1200 PLC의 홀딩 레지스터를 읽고 쓰는 산업 통신 노드 구성 튜토리얼.
사용 칩: ESP32(제어·Modbus 애플리케이션), WIZnet W5500(이더넷/TCP-IP), Siemens S7-1200(PLC).
프로토콜: Modbus TCP (포트 502), 하부에 SPI(ESP32↔W5500), 이더넷.
플랫폼: Arduino IDE(ESP32) + TIA Portal(PLC).
핵심 가치: PLC 웹 서버를 직접 손대지 않고도, C로 짠 가벼운 ESP32 노드가 유선으로 PLC 데이터를 양방향 교환하게 만든다. Wi-Fi 대신 W5500 유선을 써서 공장 환경의 결정성·안정성을 확보하는 것이 요점.

유사한 기존 콘텐츠 (WIZnet Projects 내 검색)

선정 기준: 칩(W5500) / 프로토콜(Modbus TCP) / 플랫폼(ESP32) / 응용(산업·PLC) 중 2개 이상이 겹치는 항목.

1. esp32-modbus-w5500 — ESP32+W5500 Modbus TCP 클라이언트 예제 (겹침 4개: W5500 · Modbus TCP · ESP32 · 클라이언트 역할)

링크: https://maker.wiznet.io/lawrence/projects/esp32-modbus-w5500/
유사한 이유: 본 영상과 역할이 정확히 같다 — ESP32+W5500을 Modbus TCP 클라이언트로 만들어 포트 502로 Modbus 슬레이브와 통신한다(영상의 슬레이브 = PLC). PlatformIO/Arduino 프레임워크 기반이라는 점도 동일.
다른 점: 이 프로젝트는 "메이커/입문자가 흐름을 이해하도록" 슬레이브 종류를 특정하지 않은 일반 예제인 반면, 영상은 상대가 실제 지멘스 S7-1200 PLC이며 TIA Portal의 MB_SERVER/DB 설정까지 포함한다.
연결 포인트: 이 예제의 클라이언트 코드를 그대로 두고, 상대를 PLC로 바꾸는 "실전 편"으로 본 영상을 연결할 수 있다.

2. MODBUS over Ethernet with ESP32 & W5500 – TCP/IP + DHCP Test Run (겹침 4개: W5500 · Modbus TCP · ESP32 · 하드웨어 오프로딩 개념)

링크: https://maker.wiznet.io/irina/projects/modbus-over-ethernet-with-esp32-w5500--tcp-ip-dhcp-test-run/
유사한 이유: "MCU는 애플리케이션 계층만, L2~L4는 W5500이 전담(MCU + NIC 구조)"이라는 설명이 영상의 W5500 역할과 정확히 일치한다. 검증용 테스트런이라는 성격도 튜토리얼인 본 영상과 통한다.
다른 점: 이 프로젝트는 DHCP 자동 IP를 검증하지만, 영상은 **고정 IP(PLC와 동일 서브넷 수동 설정)**를 쓴다 — 산업 현장 PLC 연동에서는 고정 IP가 일반적이라는 실무 차이를 보여준다.
연결 포인트: "DHCP 테스트(이 글) → 고정 IP로 PLC 실연동(영상)"으로 이어지는 IP 설정 시리즈를 만들 수 있다.

3. openPLC with W5500 — Arduino+W5500 기반 Modbus TCP PLC 제어 (겹침 3개: W5500 · Modbus TCP · PLC 제어 응용)

링크: https://maker.wiznet.io/jaden/projects/openplc-with-w5500/
유사한 이유: Modbus TCP + W5500으로 PLC 제어라는 응용이 같고, "Wi-Fi 대신 RJ45 유선으로 예측 가능한 PLC 통신 환경"을 강조하는 문제의식이 영상과 동일하다.
다른 점: 이 프로젝트는 OpenPLC(오픈소스 소프트 PLC) + 래더 로직을 Arduino에 올리는 구성이고, 영상은 상용 지멘스 PLC + TIA Portal이 상대다. 즉 "직접 PLC를 만든다 vs 기존 PLC에 붙는다"의 대조.
연결 포인트: 같은 W5500 Modbus TCP 위에서 오픈소스 PLC(jaden) ↔ 상용 PLC(영상) 양쪽을 비교하는 콘텐츠로 묶을 수 있다.

차이점과 확장 가치

기존 콘텐츠 대비 차별점. 위 3건은 대체로 "ESP32+W5500으로 Modbus를 한다"에 초점이 있지만, 본 영상의 차별점은 상대편 PLC(TIA Portal) 설정을 함께 다룬다는 점이다. MB_SERVER 인스트럭션, DB 블록의 Optimized block access 해제, MB_HOLD_REG의 INT 배열[0..19] 매핑, PUT/GET 통신 허용 체크 등 PLC 쪽에서 막히는 실전 함정을 짚는다. 즉 클라이언트 코드만이 아니라 "양 끝을 다 맞춰야 통신이 된다"는 통합 관점을 제공한다.

확장 가치. 영상의 구성은 maker.wiznet.io의 게이트웨이 자산과 자연스럽게 이어진다. 예를 들어 sophia의 Modbus TCP ⇄ RTU Gateway나 Lihan의 듀얼 RS-485 Modbus 게이트웨이와 결합하면, "PLC(TCP) ↔ ESP32+W5500 ↔ RS-485 현장 장비(RTU)"로 확장된다. 또한 ESP32가 PLC 레지스터를 읽어 MQTT/REST로 클라우드에 올리면 IIoT 게이트웨이가 된다. 칩 관점에서는 W5500을 W6100·W55RP20(RP2040)·W6300+RP2350로 올려 TLS·보안 OTA까지 얹는 "Secure 산업 노드" 방향으로 끌고 갈 수 있다.

PROJECT DESCRIPTION

문제 제기. S7-1200 PLC에는 이미 웹 서버가 있는데, 왜 굳이 ESP32와 W5500을 추가할까? 영상은 직접 답한다 — LAN/휴대폰으로 제어하거나, 데이터를 자유롭게 내보내거나, HTML·JS 없이 C로 간단히 다루고 싶을 때가 있기 때문이다. PLC 웹 서버를 만들려면 웹 지식이 필요하지만, ESP32+W5500은 C 코드 몇 줄로 네트워크 입출력을 붙일 수 있다.

이 프로젝트의 답은 — "PLC는 그대로 두고, 옆에 프로그래밍 가능한 가벼운 네트워크 노드를 붙인다" 이다. PLC는 Modbus TCP 서버로 레지스터만 열어두고, ESP32+W5500이 클라이언트로 접속해 값을 읽고 쓴다. 네트워크 스택은 W5500이 전담하므로 ESP32는 Modbus 메시지 처리에만 집중한다.

0. 핵심 기술/부품 — W5500 하드웨어 TCP/IP와 Modbus TCP

이 구성의 두 축은 W5500(전송)과 Modbus TCP(의미)다. W5500은 TCP/IP를 칩 내부 하드웨어로 처리하는 WIZnet 이더넷 컨트롤러로, ESP32는 SPI로 소켓 데이터만 주고받는다(MCU + NIC 구조). Modbus TCP는 산업 표준 통신 프로토콜로, 포트 502 위에서 홀딩 레지스터 같은 데이터를 마스터-슬레이브로 교환한다. 두 요소가 합쳐져 "범용 MCU가 산업 PLC와 표준 방식으로 대화"하게 된다.

1. 개발 도구/플랫폼 — TIA Portal(PLC) + Arduino IDE(ESP32)

양쪽 끝을 각각 다른 툴로 설정한다. PLC는 TIA Portal에서 Modbus 서버 기능과 데이터 블록을 구성하고, ESP32는 Arduino IDE에서 SPI·이더넷·Modbus 라이브러리로 클라이언트를 구현한다. 영상은 PLC를 먼저(서버), ESP32를 나중에(클라이언트) 설정하는 순서를 택한다. 통신이 안 될 때 원인이 양쪽 어디든 있을 수 있으므로, 두 환경을 모두 이해하는 것이 핵심이다.

2. 동작 원리 — 클라이언트가 서버 레지스터를 읽고 쓴다

동작은 "PLC가 레지스터를 열어두면, ESP32가 접속해 쓰고 읽는다"의 단순 반복이다. PLC의 MB_SERVER가 포트 502에서 대기하고, ESP32+W5500이 같은 서브넷에서 접속해 홀딩 레지스터에 10개 값을 쓰고 10개 값을 읽어온다. 이 양방향 교환으로 ESP32가 PLC의 상태를 모니터링하거나 PLC에 명령을 전달할 수 있다.

3. 장치 A 구현 — PLC 측 (TIA Portal MB_SERVER + DB)

PLC는 Modbus TCP 서버로 동작하도록 MB_SERVER와 데이터 블록을 구성한다. 메인 블록에 MB_SERVER 인스트럭션을 넣고, 레지스터를 담을 DB(데이터 블록)를 만든 뒤 반드시 Optimized block access를 해제한다 — 그래야 절대 오프셋이 보여서 Modbus 주소 매핑이 가능하다(영상이 강조하는 핵심 함정). 홀딩 레지스터는 INT 배열 [0..19](20개)로 선언하고, MB_HOLD_REG가 이 배열을 가리키게 한다. 포트는 기본 502, CONNECT ID를 지정하고 NDR/ERROR/STATUS 출력으로 상태를 확인한다.

⚠️ 함정 2가지(영상 강조): ① DB의 Optimized block access 해제 안 하면 오프셋이 안 보임. ② PLC 속성에서 PUT/GET 통신 허용(연결 메커니즘) 체크를 안 하면 외부 접속이 막힘. 설정 후 하드웨어 구성 → 소프트웨어 순서로 다운로드한다.

4. 장치 B 구현 — ESP32 측 (W5500 Modbus 클라이언트)

ESP32는 SPI로 W5500을 잡고, PLC와 같은 서브넷의 고정 IP로 Modbus 클라이언트를 연다. MAC·IP·게이트웨이를 설정하되 IP는 반드시 PLC 설정과 같은 대역(예: 192.168.1.x)이어야 하며 코드와 PLC 설정값이 일치해야 한다(영상이 반복 강조). 데이터 타입은 INT로 통일하고, 포트 502로 접속해 홀딩 레지스터 10개를 쓰고 10개를 읽는다.

cpp

// 의사코드: ESP32 + W5500 Modbus TCP 클라이언트
#include <SPI.h>
#include <Ethernet.h>          // W5500
#include <ArduinoModbus.h>     // 또는 modbus-esp8266 (영상 사용 라이브러리 [확인 필요])

byte mac[] = {0xDE,0xAD,0xBE,0xEF,0xFE,0xED};
IPAddress myIp(192,168,1,20);  // PLC와 동일 서브넷, PLC 설정과 일치
IPAddress plcIp(192,168,1,1);  // S7-1200 (MB_SERVER) 주소

EthernetClient eth;
ModbusTCPClient modbus(eth);

void loop() {
  if (!modbus.connected()) modbus.begin(plcIp, 502);   // 포트 502
  for (int i = 0; i < 10; i++)                          // PLC로 10개 쓰기
    modbus.holdingRegisterWrite(plcIp, i, txBuf[i]);
  if (modbus.requestFrom(plcIp, HOLDING_REGISTERS, 0, 10)) // 10개 읽기
    for (int i = 0; i < 10; i++) rxBuf[i] = modbus.read();
}

5. 핵심 통신/제어 로직 — 홀딩 레지스터 20개의 양방향 매핑

통신의 본질은 "공유 레지스터 묶음(DB INT[0..19])을 양쪽이 같은 주소로 해석"하는 것이다. PLC의 DB 배열 인덱스와 ESP32의 레지스터 주소가 1:1로 맞아야 같은 데이터를 가리킨다. 영상은 앞쪽 10개를 ESP32→PLC 쓰기, 뒤쪽(또는 별도) 10개를 PLC→ESP32 읽기 용도로 나눠 사용한다. 단일 INT 타입으로 통일해 프레이밍·엔디안 혼선을 줄인다.

6. 검증/예외 처리 — 안 될 때 점검 순서

대부분의 실패는 "양 끝 설정 불일치"에서 온다. 영상이 짚는 점검 포인트는 (1) IP 대역/주소가 PLC와 코드에서 동일한가, (2) DB의 Optimized block access를 껐는가, (3) PUT/GET 통신 허용을 켰는가, (4) 하드웨어→소프트웨어 순으로 다운로드했는가, (5) 데이터 타입을 INT로 통일했는가다. MB_SERVER의 STATUS/ERROR 출력과 ESP32 측 연결 반환값으로 어느 끝이 막혔는지 좁혀간다.

7. 서버 & 결과 — 프로그래밍 가능한 PLC 통신 창구

결과물은 "PLC 옆에 붙은, C로 자유롭게 확장 가능한 네트워크 노드"다. ESP32는 PLC 레지스터를 읽어 시리얼/디스플레이로 보여주거나, 값을 써서 PLC 로직을 트리거할 수 있다. 영상은 이를 발판으로 LAN/모바일 제어, 커스텀 데이터 추출 같은 확장을 예고한다. PLC 웹 서버를 건드리지 않고도 동일한 데이터를 더 유연하게 다루게 되는 것이 이 구성의 실질 결과다.

Takeaways

PLC에 웹 서버가 있어도 ESP32+W5500을 붙이는 이유는 "유연성과 단순함"이다. C 코드로 네트워크 입출력을 붙이고, 데이터 추출·원격 제어를 자유롭게 확장한다.
W5500은 ESP32를 "MCU + NIC" 구조로 만든다. 네트워크 스택을 칩이 전담하므로 ESP32는 Modbus 애플리케이션에만 집중한다.
통신은 양 끝 설정의 일치 문제다. IP 대역·Optimized block access 해제·PUT/GET 허용·다운로드 순서·데이터 타입 — 하나만 틀려도 안 된다.
Wi-Fi가 있는 ESP32에 굳이 유선 W5500을 쓰는 것은 결정성 때문이다. 공장 환경에서 무선은 가장 먼저 끊긴다.

개선 여지

고정 IP 수동 관리 → 규모가 커지면 DHCP/예약 IP 또는 mDNS로 관리 단순화 가능(irina 프로젝트의 DHCP 접근 참고).
Modbus TCP 평문 → 산업 외부 노출 구간에서는 VPN/터널 또는 W6100/W6300 + TLS 조합으로 보안 강화 여지.
단일 PLC 클라이언트 → ESP32를 RTU 게이트웨이로 확장하면 RS-485 현장 장비까지 묶어 TCP⇄RTU 변환 가능(sophia/Lihan 게이트웨이 참고).
로컬 모니터링에 그침 → 읽은 레지스터를 MQTT/REST로 올리면 IIoT 대시보드·예지보전으로 확장.

신규 설계 시 참고

기존 상용 PLC에 네트워크 기능을 "비침투적으로" 더하고 싶다면, 본 영상처럼 PLC를 Modbus TCP 서버로 두고 가벼운 MCU 노드를 클라이언트로 붙이는 패턴이 안전하고 빠르다. 처음 설계라면 ESP32+W5500 대신 W55RP20(RP2040 일체형)이나 W6300+RP2350 조합을 택해 동일 구조를 더 여유 있는 메모리·보안 기반에서 구현할 수 있고, TLS·OTA를 얹어 산업용으로 굳히기 좋다. 무엇보다 "양 끝 설정 일치(IP/오프셋/접근 허용)"를 체크리스트로 문서화해 두면 재현성과 디버깅 속도가 크게 올라간다.

Documents

원 영상: https://www.youtube.com/watch?v=pEW_pZyJ7hY (채널 factoryauto.vn, 자료·코드는 채널 블로그 탭 안내 [확인 필요: URL])
유사 콘텐츠 — esp32-modbus-w5500: https://maker.wiznet.io/lawrence/projects/esp32-modbus-w5500/
유사 콘텐츠 — MODBUS over Ethernet (ESP32+W5500, DHCP): https://maker.wiznet.io/irina/projects/modbus-over-ethernet-with-esp32-w5500--tcp-ip-dhcp-test-run/
유사 콘텐츠 — openPLC with W5500: https://maker.wiznet.io/jaden/projects/openplc-with-w5500/
확장 참고 — ESP32+W5500 Modbus TCP⇄RTU Gateway: https://maker.wiznet.io/sophia/projects/bridging-industrial-worlds-esp32-w5500--modbus-tcp--rtu-gateway/

Documents

Comments Write