Wiznet makers

Summary

This project demonstrates how to build a general-purpose I/O Slave device accessible by LabVIEW and other Modbus TCP master software, using an STM32F103 (BluePill) microcontroller and a WIZnet W5500 (WIZ5500) Ethernet controller. Thanks to W5500's hardware TCP/IP offloading, the STM32 can focus entirely on Modbus data handling and I/O control. The result is a practical industrial edge device design that also features a built-in web server for on-site network configuration.

Overview

In industrial automation, Modbus TCP has become the de facto standard protocol for higher-level systems — PLCs, SCADA platforms, and tools like LabVIEW — to remotely control and monitor I/O devices. However, off-the-shelf industrial Arduino-based PLCs such as M-Duino and Controllino, while capable, come with cost premiums and limited customization flexibility.

This project explores implementing a Modbus TCP Slave entirely from discrete components: an STM32F103C8T6 (BluePill) MCU and a WIZnet W5500 NIC. The core goal is to produce a self-contained industrial I/O device — one that a master application can reach directly on port 502, and that field engineers can configure via a browser without recompiling firmware.

System Architecture

The system is built around the STM32F103 (BluePill), with the WIZ5500 (W5500) Ethernet controller connected via SPI. The W5500 handles all Ethernet physical layer and TCP/IP stack processing, while the STM32 manages Modbus frame parsing, I/O mapping, and web server logic.
 

For network configuration, the built-in web server serves a settings page when accessed from a browser. MAC address, IP, subnet mask, and gateway values entered there are written to Flash (EEPROM emulation) and automatically restored on reboot.

Technical Features

Modbus Data Model and I/O Mapping

The implementation covers all four standard Modbus data types using the MgsModbus library.

MgsModbus uses a simple shared WORD memory block as the Modbus data area, keeping the implementation straightforward. However, since the library does not provide direct EEPROM access, retaining values across power cycles requires either STM32duino's EEPROM.h (Flash emulation) or an external I2C EEPROM device such as the 24LC64 or AT24C1024B.

Slave Boundary Handling

One detail worth noting in Modbus Slave implementation is boundary behavior. For example, if the Slave holds 16 Coils but a master issues a ReadCoil request for 100, the device must have a clearly defined response — whether to return only the available 16, or to reply with an exception code. This behavior varies across client software, and must be explicitly defined at the design stage. The original project highlights this as a key consideration for achieving a robust Slave implementation.

Where W5500 Fits

The WIZnet W5500 (WIZ5500) is the critical hardware component in this design. It integrates a full TCP/IP protocol stack, MAC, and PHY into a single chip, connected to the MCU via SPI — offloading all network processing from the STM32.

Roles W5500 performs in this system:

• Modbus TCP port 502: Accepts incoming connections from master software and maintains TCP sessions
• HTTP web server: Hosts the network configuration UI, operating on the same NIC via multiple sockets
• Full network isolation: The STM32 issues only SPI commands; all TCP/IP processing happens inside the W5500

The structural difference from a software TCP/IP approach is significant.

Power supply note: The W5500 can operate on USB power (500mA), but voltage drop may occur when onboard LEDs are active. The original project recommends using a USB 3.0 port during development, and an external regulator for production deployment.

Web-Based Network Configuration

A practical highlight of this design is the built-in web configuration page. While the device is connected to the network, engineers can access it from any browser to set the MAC address, IP, subnet mask, and gateway. Settings are saved to Flash and restored automatically on reboot.

This means the same firmware binary can be deployed across multiple units, with each device configured independently on-site — no recompilation required. For small-scale field deployments, this significantly reduces setup overhead.

Business Value

This architecture goes beyond a maker experiment — it serves as a viable reference design for real industrial applications.

• Small-scale FA line monitoring: Acts as a distributed I/O node for LabVIEW-based measurement systems, providing the same Modbus TCP interface as expensive industrial modules at a fraction of the cost
• Remote environmental monitoring: Connects temperature, light, and pressure sensors via I2C and exposes readings through Modbus Input Registers to upstream systems
• Edge control device: Translates Holding Register writes from a master into Coil outputs to drive field actuators such as relays and solenoids
• Protocol gateway foundation: Can be extended into a conversion node between legacy RS485 equipment and Modbus TCP upper systems

WIZnet perspective: This project validates W5500 as a proven component for Modbus TCP Slave roles in industrial automation. The combination with the STM32duino ecosystem — which offers a rich library environment — demonstrates how W5500 can be adopted with minimal development effort, making it a strong reference for FA and IoT market positioning.

Limitations and Improvements

This project successfully implements core Modbus TCP Slave functionality with low-cost components. The following points are framed not as shortcomings, but as opportunities for the next iteration.

Current limitations:

• Memory constraints: Fitting Ethernet stack, Modbus, and WebServer into 64–128KB Flash is tight; adding features risks linker errors
• No hardware EEPROM: Flash emulation has limited write endurance, making it vulnerable to frequent configuration changes
• No DHCP support: Only static IP is implemented, limiting compatibility with dynamic network environments
• No analog output: BluePill lacks a DAC, so Holding Register-based analog output requires I2C expansion
• Power stability: W5500 current draw creates voltage drop risk on USB power supplies

Recommended improvements:

• MCU upgrade: Moving from STM32F103 to STM32F401/F411 (BlackPill) provides 256KB Flash, enabling DHCP support and room for additional features
• External I2C EEPROM: Adding a 24LC64 or AT24C1024B improves configuration persistence and write durability
• Dedicated power supply: An external regulator (e.g., AMS1117) for the W5500 eliminates voltage drop issues
• I2C DAC integration: Adding a device such as the MCP4725 enables true analog output via Holding Registers

FAQ

Q1. Is Arduino experience sufficient to build this? STM32duino closely mirrors the Arduino IDE workflow, so existing Arduino experience transfers well. However, some RS485/RTU Arduino libraries do not work directly on STM32duino. For Modbus TCP, selecting a TCP-specific library such as MgsModbus from the start avoids compatibility issues.

Q2. What power supply is recommended? USB power (500mA) is sufficient for development, but voltage drop can occur with W5500 LED activity. A USB 3.0 port is recommended during testing. For production environments, an external regulator supplying the W5500 separately is the more stable approach.

Q3. Can this work with Modbus masters other than LabVIEW? Yes. Since the device uses standard Modbus TCP on port 502, it is compatible with any master software that supports the protocol. During development and debugging, Modbus Poll by Witte Software (10-minute free evaluation) is particularly useful. Local loopback testing (IP: 127.0.0.1) with a Modbus Slave simulator on the same PC is also supported.

Q4. Can multiple masters connect simultaneously? The W5500 supports up to 8 hardware sockets, so the underlying architecture allows for multiple concurrent connections. However, the stability of simultaneous multi-master access in the current implementation requires further validation. Single-master operation is the recommended baseline for production use.

Q5. How can the I/O channel count be scaled up? Adding I2C I/O expanders such as the MCP23017 is the most practical expansion path. For larger-scale deployments requiring significant additional functionality, upgrading to an STM32F4-series MCU while retaining the W5500 provides ample Flash and RAM headroom without changing the network architecture.

요약

STM32F103 (BluePill)과 WIZnet W5500 (WIZ5500) 이더넷 컨트롤러를 조합해, LabVIEW를 비롯한 Modbus TCP 마스터 소프트웨어가 직접 접근할 수 있는 범용 I/O Slave 디바이스를 구현한 프로젝트입니다. W5500의 하드웨어 TCP/IP 오프로딩 덕분에 STM32는 Modbus 데이터 처리와 I/O 제어에 집중할 수 있으며, 내장 웹서버를 통한 현장 네트워크 설정 기능까지 갖춘 실용적인 산업 엣지 디바이스 설계 사례입니다.

개요

산업 자동화 현장에서 Modbus TCP는 PLC, SCADA, LabVIEW와 같은 상위 시스템이 I/O 디바이스를 원격으로 제어하는 데 사실상의 표준 프로토콜로 자리잡고 있습니다. 그러나 M-Duino나 Controllino 같은 기성 산업용 Arduino 기반 PLC는 필요한 기능이 패키징되어 있는 대신, 가격과 커스터마이징 자유도 면에서 제약이 따릅니다.

이 프로젝트는 STM32F103C8T6 (BluePill) MCU와 WIZnet W5500 NIC를 이용해 Modbus TCP Slave 기능을 직접 구현하는 방법을 탐구합니다. 핵심 목표는 마스터 소프트웨어에서 포트 502로 바로 접속할 수 있고, 브라우저로 네트워크 설정을 완료할 수 있는 완결된 산업용 I/O 디바이스를 저비용 부품으로 실현하는 것입니다.

시스템 아키텍처

시스템은 STM32F103 (BluePill) 을 중심으로, WIZ5500 (W5500) 이더넷 컨트롤러가 SPI로 연결된 구조입니다. W5500이 Ethernet 물리 계층 및 TCP/IP 스택 처리를 전담하고, STM32는 Modbus 프레임 파싱·I/O 매핑·웹서버 로직을 수행합니다.
 

웹 설정 흐름은 별도로 구성됩니다. 브라우저에서 디바이스 IP로 접속하면 내장 WebServer가 설정 페이지를 제공하며, 입력된 MAC·IP·서브넷 마스크·게이트웨이 값은 Flash(EEPROM 에뮬레이션)에 저장되어 재기동 후에도 자동 복원됩니다.

기술 특징

Modbus 데이터 모델과 I/O 매핑

MgsModbus 라이브러리를 기반으로 Modbus 표준 4종 데이터 타입을 구현했습니다.

MgsModbus는 단순한 WORD형 공유 메모리 블록을 Modbus 데이터 영역으로 사용하는 구조로, 구현이 간결합니다. 다만 EEPROM 직접 접근 기능은 없기 때문에, 전원 차단 후 설정값 유지가 필요한 경우에는 STM32duino의 EEPROM.h(Flash 에뮬레이션) 또는 외부 I2C EEPROM(24LC64, AT24C1024B 등)을 별도 연동해야 합니다.

Modbus Slave 구현 시 주의 사항

Modbus Slave 구현에서 실제로 고민이 필요한 지점이 있습니다. 예를 들어 Slave가 Coil을 16개 보유하고 있을 때, 마스터가 ReadCoil을 100개 요청한 경우의 처리 방침—즉 16개만 반환할지, 예외 코드를 반환할지—은 사양 설계 단계에서 명확히 정의해야 합니다. 클라이언트 소프트웨어에 따라 동작이 달라지기 때문입니다. 원문에서도 이 점을 별도로 언급하고 있으며, Slave 구현의 완성도를 높이려면 Function Code별 경계 처리 로직을 꼼꼼히 정의할 필요가 있습니다.

W5500이 이 구조에서 하는 일

이 프로젝트의 핵심 하드웨어는 WIZnet W5500 (WIZ5500) 입니다. W5500은 TCP/IP 프로토콜 스택, MAC, PHY를 단일 칩에 통합한 하드웨어 오프로딩 방식의 이더넷 컨트롤러로, SPI 인터페이스만으로 MCU에 연결됩니다.

W5500이 담당하는 역할:

• Modbus TCP 포트 502: 마스터 소프트웨어의 접속 요청을 받아 TCP 세션 유지
• HTTP 내장 웹서버: 설정 UI 페이지 호스팅 (동일 NIC에서 멀티 소켓 운용)
• 네트워크 처리 완전 분리: STM32는 SPI 명령 발행만으로 네트워크 I/O를 처리, MCU 부하 최소화

소프트웨어 TCP/IP 방식과의 구조적 차이는 다음과 같습니다.

전원 설계 주의사항: W5500은 USB 전원(500mA)으로도 동작하지만, LED 점등 시 전압 드롭이 발생할 수 있습니다. 원문에서는 USB 3.0 포트 사용을 권장하며, 실 운용 환경에서는 외부 전원 공급을 검토하는 것이 안정적입니다.

웹 기반 네트워크 설정

현장 친화성의 핵심은 내장 웹 설정 페이지입니다. 디바이스가 네트워크에 연결된 상태에서 브라우저로 접속하면 MAC 주소·IP·서브넷 마스크·게이트웨이를 설정할 수 있으며, 저장된 값은 Flash에 기록되어 재기동 후 자동 복원됩니다.

이 기능 덕분에 배포된 바이너리를 그대로 유지하면서 현장별 네트워크 설정만 변경할 수 있습니다. 다수의 디바이스를 서로 다른 네트워크 환경에 배치할 때 코드 재컴파일이 필요 없다는 점은 실제 운용 측면에서 큰 장점입니다.

적용 시나리오와 확장 가능성

이 아키텍처는 다양한 산업 현장에 직접 적용 가능한 참조 설계로서 가치를 지닙니다.

• 소규모 FA 라인 모니터링: LabVIEW 기반 계측 시스템의 분산 I/O 노드로 활용. 고가 산업용 모듈 없이 동일한 Modbus TCP 인터페이스 제공
• 원격 환경 모니터링: I2C 버스를 통해 온도·조도·기압 센서를 연결하고, Modbus Input Register로 상위 시스템에 전달
• 엣지 제어 디바이스: Holding Register에 마스터가 기록한 값을 Coil 출력으로 변환해 현장 릴레이·솔레노이드 구동
• 프로토콜 게이트웨이 기점: 기존 RS485 장비와 Modbus TCP 상위 시스템 사이의 변환 노드로 확장 가능

WIZnet 관점의 인사이트: W5500은 산업 자동화 Slave 구현에서 실증된 제품입니다. STM32duino 에코시스템과의 조합은 라이브러리가 풍부한 개발 환경에서 W5500을 쉽게 도입할 수 있다는 것을 보여주며, FA·IoT 시장 레퍼런스로서 활용 가치가 높습니다.

한계 및 개선 방향

이 프로젝트는 Modbus TCP Slave의 핵심 기능을 저비용으로 구현했다는 점에서 의미 있지만, 실 운용 확장을 위한 개선 포인트도 존재합니다. 아래 사항들은 비판이 아닌 다음 단계로의 발전 방향으로 이해하시기 바랍니다.

현재 한계:

• 메모리 제약: Flash 64~128KB에 Ethernet 스택·Modbus·WebServer를 모두 올리면 공간이 빠듯하며, 기능 추가 시 링크 오류 리스크
• EEPROM 부재: Flash 에뮬레이션 방식은 쓰기 횟수 제한이 있어 빈번한 설정 변경에 취약
• DHCP 미구현: 고정 IP만 지원해 동적 네트워크 환경 대응 불가
• 아날로그 출력 제한: BluePill에 DAC 미내장으로 Holding Register의 아날로그 출력 활용이 제한적
• 전원 안정성: W5500 전류 소비로 인한 USB 전원 전압 드롭 리스크

개선 방향:

• MCU 업그레이드: STM32F103 → STM32F401/F411 (BlackPill) 전환으로 Flash 256KB 확보, DHCP 구현 및 기능 확장 여유 마련
• 외부 I2C EEPROM 추가: 24LC64 또는 AT24C1024B 연결로 설정 영속성 강화, 쓰기 내구성 확보
• 전원 설계 개선: W5500 전용 외부 레귤레이터(AMS1117 등) 도입으로 전압 드롭 문제 해소
• I2C DAC 연동: MCP4725 등 I2C DAC 추가로 Holding Register 기반 아날로그 출력 실현

FAQ

Q1. Arduino 경험만 있어도 이 구조를 구현할 수 있나요? STM32duino 환경은 Arduino IDE와 거의 동일한 방식으로 개발할 수 있습니다. 다만 RS485/RTU용 Arduino 라이브러리 일부는 STM32duino에서 그대로 동작하지 않는 경우가 있어, Modbus TCP 구현에는 MgsModbus처럼 TCP 전용 라이브러리를 선택하는 것이 안전합니다.

Q2. 전원은 어떻게 공급해야 하나요? USB 전원(500mA)으로 동작 가능하지만, W5500의 전류 소비로 인해 LED 점등 시 전압 드롭이 발생할 수 있습니다. 개발·테스트 단계에서는 USB 3.0 포트 사용을 권장하며, 실 운용 환경에서는 AMS1117 등 외부 레귤레이터를 통한 별도 전원 공급이 안정적입니다.

Q3. LabVIEW 외에 다른 마스터 소프트웨어와도 연동할 수 있나요? Modbus TCP 표준 포트 502를 사용하므로, 해당 프로토콜을 지원하는 모든 마스터 소프트웨어와 연동 가능합니다. 개발·디버그 단계에서는 Witte Software의 Modbus Poll(10분 무료 평가판 제공)이 유용하며, PC 1대에서 Modbus Slave 시뮬레이터(IP: 127.0.0.1)와 함께 로컬 테스트도 가능합니다.

Q4. 여러 대의 마스터가 동시에 접속할 수 있나요? W5500은 최대 8 소켓을 하드웨어로 지원하므로 구조적으로는 멀티 마스터 접속이 가능합니다. 다만 현재 구현에서의 동시 접속 안정성은 추가 검토가 필요하며, 실 운용 환경에서는 단일 마스터 접속을 기준으로 설계하는 것을 권장합니다.

Q5. 이 구조를 더 많은 I/O 채널로 확장하려면 어떻게 해야 하나요? I2C 버스를 통한 I/O 익스팬더(MCP23017 등) 추가가 현실적인 확장 방법입니다. 대규모 확장이 필요한 경우에는 Flash·RAM 여유가 큰 STM32F4 계열로 MCU를 업그레이드하고, W5500은 그대로 유지하는 구성이 효율적입니다.