BonniePlantsArduino
Automated conveyor-line controller for plant production using AutomationDirect P1AM-100 Arduino CPU with Productivity1000 I/O modules and CM5-T15W C-more HMI.
BonnieConveyor는 AutomationDirect P1AM-100 (SAMD21) CPU와 WIZnet W5500 이더넷 칩을 기반으로, 공장 컨베이어 라인을 Modbus TCP로 완전 자동 제어하는 헤드리스 산업용 컨트롤러입니다.
배경 & 동기
공장 생산 라인에서 컨베이어를 제어할 때 가장 흔히 맞닥뜨리는 문제는 무선 통신의 불안정성입니다. Wi-Fi는 전자기 노이즈가 심한 산업 현장에서 접속 끊김이 잦고, 보안 정책상 아예 사용이 금지된 공장도 많습니다.
이 프로젝트는 그 대안으로 **유선 이더넷(Ethernet)**을 선택했습니다. WIZnet W5500 칩은 하드웨어 TCP/IP 스택을 내장하고 있어 MCU의 CPU 부담 없이 안정적인 네트워크 통신이 가능합니다. HMI(터치스크린)와 컨트롤러 사이의 모든 데이터를 Modbus TCP 프로토콜 하나로 통일함으로써, 복잡한 시리얼 배선 없이 깔끔한 산업용 통신 구조를 실현했습니다.
또한 기존에 Qt 데스크탑 앱으로 관리하던 방식에서 벗어나, P1AM-100 단독으로 헤드리스(headless) 동작이 가능하도록 설계하여 PC 없이도 라인을 완전 자동 운용할 수 있게 했습니다.
기존에는 Qt 데스크탑 앱으로 컨베이어를 관리했는데, 공장 환경에서 Wi-Fi 연결이 불안정하고 보안상 사용이 제한되는 문제가 있었습니다. 이를 해결하기 위해 WIZnet W5500 유선 이더넷 칩을 선택했습니다. W5500은 하드웨어 TCP/IP 스택을 내장하고 있어, MCU 부담 없이 안정적인 통신이 가능합니다.
시스템 구조 & 동작 원리
전체 시스템은 크게 세 레이어로 구성됩니다.
[HMI 레이어] CM5-T15W 터치스크린 → Modbus TCP → P1AM-100 이더넷 포트
[제어 레이어] P1AM-100 (SAMD21) — 6-상태 스테이트 머신 실행
[I/O 레이어] SPI 백플레인 → P1-16ND3 (입력) / P1-16TR (릴레이) / P1-08DAL-2 (0~10V 아날로그)
터치스크린 HMI가 Modbus TCP로 명령을 보내면, P1AM-100 컨트롤러가 이를 받아 모터, 릴레이, 경광등을 직접 제어합니다. 내부적으로는 Stop, Run, E-Stop 등 6개 상태로 구성된 스테이트 머신이 동작하며, 비상정지 발생 시에도 안전하게 이전 상태로 복귀합니다.
스테이트 머신 흐름은 다음과 같습니다.
STOP → (Start) → BUZZER_DELAY → RUN1 → (지연 버튼) → TIME_DELAY
→ (타이머 완료) → RUN2 → (지연 버튼) → TIME_DELAY → …
모든 상태 → (E-Stop) → ESTOP → (해제) → BUZZER_DELAY → 이전 상태 복귀
모든 상태 (ESTOP 제외) → (Stop) → STOP통신 방식:
- SPI — P1AM-100 ↔ I/O 모듈 백플레인 (P1AM 라이브러리)
- SPI — P1AM-100 ↔ W5500 이더넷 칩 (P1AM-ETH 쉴드)
- Modbus TCP (Port 502) — W5500 ↔ CM5-T15W HMI (Holding Register 기반)
모터 제어는 6가지 속도(Speed) × 6가지 트레이(Tray) 조합에 따라 각 모터별 보정 계수(calibration factor)를 곱해 DAC 출력값을 계산하며, **하드웨어 워치독(5초 타임아웃)**이 항상 백그라운드에서 안전을 보장합니다.
구현 세부사항
하드웨어 연결
- P1-16ND3 (Slot 1) — Start/Stop/E-Stop 등 물리 버튼 및 안전 입력 신호 수신
- P1-16TR (Slot 2) — 모터 릴레이, 경광등(적/황/녹), 버저 제어 (16비트 비트마스크로 원자적 출력)
- P1-08DAL-2 (Slot 3) — 모터별 0–10V 속도 신호 출력 (12-bit DAC)
- P1AM-ETH 쉴드 — SPI로 W5500에 연결,
Ethernet.init(ETH_CS_PIN)으로 초기화
소프트웨어 구조
Modbus 레지스터 맵은 크게 4영역으로 구성됩니다.
| 레지스터 | 기능 | 권한 |
|---|---|---|
| 0–11 | 상태값 (state, counter, timer, heartbeat) | R |
| 100–105 | HMI 명령 (start/stop, 속도/트레이 선택) | W |
| 200–335 | 모터/트레이 캘리브레이션 계수 (×1000 정규화) | R/W |
| 400 | 캘리브레이션 플래시 저장 트리거 | W |
FlashStorage를 사용해 캘리브레이션 데이터와 누적 생산 카운터를 SAMD21 내장 플래시에 영속 저장합니다. 카운터는 매 COUNTER_BATCH_SIZE회마다 배치로 저장해 플래시 쓰기 횟수를 최소화했습니다.
생산 로그는 시리얼 포트로 CSV 형식(LOG, 타임스탬프, 트레이, 속도, 배치카운트, 누적카운트)으로 출력되어, 터미널 캡처나 외부 로거로 수집할 수 있습니다.
빌드 & 설치
git clone https://github.com/YOUR_USERNAME/BonnieConveyor.git
cd BonnieConveyor
pio run --target upload
pio device monitor --baud 115200네트워크 설정은 include/Config.h에서 IP/서브넷/게이트웨이를 수정하고, P1AM-ETH 쉴드의 MAC 주소 스티커 값을 반드시 일치시켜야 합니다.
주의사항
- **워치독(5초)**이 활성화되어 있으므로 루프 사이클이 지나치게 길어지면 강제 리셋됩니다.
P1.petWD()를 루프 최상단에서 항상 호출해야 합니다. - E-Stop은 NC(Normally Closed) 방식이므로 배선이 끊겨도 안전하게 정지하도록 설계되어 있습니다.
- Modbus 클라이언트는 동시에 1개만 허용하므로, HMI 접속 중 추가 클라이언트 연결 시 자동 차단됩니다.
결과 & 마무리
BonnieConveyor는 실제 공장 생산 라인에 배포되어 헤드리스 자동 운전, HMI 기반 실시간 모니터링 및 파라미터 조정, 플래시 기반 생산 데이터 보존을 모두 안정적으로 수행하고 있습니다.
6-상태 스테이트 머신 구조 덕분에 예기치 않은 E-Stop 발생 시에도 이전 상태로 안전하게 복귀하며, 버저 경보 후 재기동하는 안전 절차가 자동으로 실행됩니다.
향후에는 MQTT 브리지 추가를 통해 클라우드 기반 생산 데이터 수집 및 원격 모니터링으로 확장할 계획입니다.
🔗 Original Link: GitHub — BonnieConveyor
이 프로젝트가 WIZnet Maker 커뮤니티에 갖는 가치
이 프로젝트는 WIZnet W5500이 단순한 IoT 연결 모듈을 넘어 실제 산업 자동화 현장에서 Modbus TCP 서버의 핵심 통신 엔진으로 활용될 수 있음을 보여주는 실증 사례입니다. W5500의 하드웨어 TCP/IP 오프로드 기능은 SAMD21처럼 자원이 제한된 MCU에서도 안정적인 이더넷 통신을 가능하게 하며, 이는 W5100S, W5300, W6100 등 다른 WIZnet 칩을 사용하는 메이커들에게도 그대로 적용할 수 있는 설계 패턴입니다. 특히 유선 이더넷 + Modbus TCP 조합은 Wi-Fi가 금지된 공장, 물류센터, 농업 자동화 환경에서 즉시 채택 가능한 검증된 아키텍처로, WIZnet 칩 기반의 산업용 컨트롤러, PLC 대체 프로젝트, 스마트 팩토리 게이트웨이 개발에 직접적인 참고 레퍼런스가 됩니다. BonnieConveyor의 오픈소스 Modbus 레지스터 맵, 스테이트 머신 구조, 플래시 캘리브레이션 패턴은 모두 그대로 재사용하거나 자신의 프로젝트에 응용할 수 있습니다.
FAQ
1) 왜 이 프로젝트에서 W5500가 적합한가요?
HMI는 주기적으로 레지스터를 읽고 명령을 쓰기 때문에, 제어 루프가 네트워크 처리에 흔들리지 않는 것이 중요합니다. W5500는 하드웨어 TCP/IP 오프로딩으로 MCU의 부담을 줄이고, 상태 머신/I/O 스캔/인터록 같은 제어 작업의 시간 예측성을 높이는 방향에 유리합니다.
2) W5500는 P1AM-100과 어떻게 연결되나요?
이 구성에서는 P1AM-ETH 실드에 W5500가 탑재되어 있고, P1AM-100(SAMD21)이 SPI로 통신합니다. 펌웨어에서 IP/서브넷/게이트웨이와 MAC을 설정하고, HMI는 해당 IP로 Modbus TCP 연결을 수행합니다(예: include/Config.h에 네트워크 기본값이 있다고 설명되어 있음).
3) 이 프로젝트에서 W5500의 구체적 역할은 무엇인가요?
W5500는 HMI와 컨트롤러 사이의 Modbus TCP 트래픽을 운반합니다. 상태 레지스터(상태/타이머/카운터/하트비트)는 읽기 중심이고, 명령/보정/저장 레지스터는 쓰기 중심입니다. 핵심은 “네트워크 쓰기”를 곧바로 출력에 연결하지 않고, 검증 후 상태 머신을 통해 제어 흐름에 반영하는 것입니다.
4) 초보자도 W5500 + Modbus TCP를 따라 할 수 있나요?
가능합니다. 다만 (1) 고정 IP/서브넷 같은 기본 네트워크 설정, (2) Modbus 레지스터 개념(읽기/쓰기, 스케일링 ×1000), (3) SPI 기반 실드 사용에 익숙해야 합니다. W5500 자체는 비교적 단순하지만, 안전한 쓰기 처리와 상태 머신 통합이 난이도를 결정합니다.
5) Wi-Fi로 HMI를 붙이는 것과 비교하면 어떤 차이가 있나요?
Wi-Fi는 현장 환경에서 지연 변동, 간섭, 로밍/재연결 문제로 폴링 기반 HMI가 “가끔 멈추는” 현상을 만들 수 있습니다. 반면 W5500 기반 유선 이더넷은 통신 경로가 단순하고 예측 가능해, Modbus TCP 폴링/명령 쓰기 동작이 더 안정적으로 유지되는 경우가 많습니다.
BonnieConveyor is a headless industrial conveyor-line controller built on the AutomationDirect P1AM-100 (SAMD21) CPU and WIZnet W5500 Ethernet chip, delivering fully automated conveyor control over Modbus TCP without requiring a host PC.
Background & Motivation
One of the most persistent challenges in factory conveyor control is unreliable wireless communication. Wi-Fi suffers from frequent dropouts caused by electromagnetic noise common in industrial environments, and many facilities prohibit wireless connectivity entirely due to security policies.
This project addresses that problem by choosing wired Ethernet as the sole communication medium. The WIZnet W5500 chip features a hardware-offloaded TCP/IP stack, enabling stable network communication without burdening the MCU. By standardizing all data exchange between the HMI and the controller over a single Modbus TCP protocol, the design eliminates complex serial wiring and achieves a clean, industrial-grade communication architecture.
Additionally, the system moves away from a legacy Qt desktop application, replacing it with a fully standalone P1AM-100 headless controller capable of running the production line autonomously — no host PC required.
System Architecture & How It Works
The system is organized into three layers:
[HMI Layer] CM5-T15W Touchscreen → Modbus TCP → P1AM-100 Ethernet Port
[Control Layer] P1AM-100 (SAMD21) — Executes the 6-state state machine
[I/O Layer] SPI Backplane → P1-16ND3 (inputs) / P1-16TR (relays) / P1-08DAL-2 (0–10V analog)
State machine flow:
STOP → (Start) → BUZZER_DELAY → RUN1 → (delay btn) → TIME_DELAY
→ (timer done) → RUN2 → (delay btn) → TIME_DELAY → …
Any state → (E-Stop) → ESTOP → (cleared) → BUZZER_DELAY → prior state
Any state (except ESTOP) → (Stop) → STOPCommunication stack:
- SPI — P1AM-100 ↔ I/O module backplane (P1AM library)
- SPI — P1AM-100 ↔ W5500 Ethernet chip (P1AM-ETH shield)
- Modbus TCP (Port 502) — W5500 ↔ CM5-T15W HMI (Holding Register-based)
Motor speed is calculated by multiplying a base speed percentage by per-motor calibration factors across 6 speed levels × 6 tray types. A hardware watchdog (5-second timeout) runs continuously in the background to guarantee safe-state behavior.
Implementation Details
Hardware Wiring
- P1-16ND3 (Slot 1) — Receives physical Start/Stop/E-Stop button and safety interlock signals
- P1-16TR (Slot 2) — Controls motor relays, stack lights (red/yellow/green), and buzzer via 16-bit bitmask written atomically
- P1-08DAL-2 (Slot 3) — Outputs per-motor 0–10V speed signals (12-bit DAC)
- P1AM-ETH Shield — Connected to W5500 over SPI, initialized with
Ethernet.init(ETH_CS_PIN)
Software Structure
Modbus register map is divided into four zones:
| Register | Function | Access |
|---|---|---|
| 0–11 | Status (state, counters, timer, heartbeat) | R |
| 100–105 | HMI commands (start/stop, speed/tray select) | W |
| 200–335 | Motor/tray calibration factors (×1000 normalized) | R/W |
| 400 | Save calibration to flash trigger | W |
FlashStorage persists both calibration data and the lifetime production counter to SAMD21 internal flash. Counters are written in batches every COUNTER_BATCH_SIZE increments to minimize flash wear.
Production logging outputs CSV records over the serial port (LOG, timestamp, tray, speed, batchCount, totalCount), ready for capture by a terminal or external data logger.
Build & Installation
git clone https://github.com/YOUR_USERNAME/BonnieConveyor.git
cd BonnieConveyor
pio run --target upload
pio device monitor --baud 115200Edit include/Config.h to configure your plant network IP/subnet/gateway, and ensure the MAC address matches the sticker on your P1AM-ETH shield.
Notes & Troubleshooting
- The 5-second watchdog is always active —
P1.petWD()must be called at the top of every loop iteration or the system will reset. - E-Stop inputs are NC (Normally Closed), so a broken wire safely triggers an emergency stop by design.
- Modbus accepts only one client at a time — additional connection attempts while the HMI is connected are automatically rejected.
Results & Conclusion
BonnieConveyor has been deployed on a live factory production line, reliably delivering headless autonomous operation, real-time HMI monitoring, remote parameter adjustment, and flash-persistent production data — all without a host PC.
The 6-state machine architecture ensures that even an unexpected E-Stop results in a safe, controlled return to the prior state after an audible buzzer warning, satisfying industrial safety requirements.
Future plans include adding an MQTT bridge to enable cloud-based production data collection and remote monitoring.
🔗 Original Link: GitHub — BonnieConveyor
Value for the WIZnet Maker Community
BonnieConveyor is a real-world proof of concept demonstrating that the WIZnet W5500 is far more than a simple IoT connectivity module — it can serve as the core communication engine of an industrial Modbus TCP server in a live production environment. The W5500's hardware TCP/IP offload capability allows even resource-constrained MCUs like the SAMD21 to sustain stable, deterministic Ethernet communication, a design pattern directly transferable to other WIZnet chips such as the W5100S, W5300, and W6100. The wired Ethernet + Modbus TCP combination is an immediately adoptable, battle-tested architecture for factories, warehouses, and agricultural automation facilities where Wi-Fi is prohibited or unreliable. The project's open-source Modbus register map, state machine structure, and flash calibration pattern are all ready to be reused or adapted for your own industrial controllers, PLC replacement projects, or smart factory gateway builds.
FAQ
1) Why use the WIZnet W5500 here instead of a software TCP/IP stack?
A conveyor controller needs predictable behavior: the W5500 offloads TCP/IP handling so the MCU spends more time on I/O scan, safety interlocks, and the state machine. For Modbus TCP polling from an HMI, that typically means fewer timing surprises under load and fewer “network work” spikes in the control loop.
2) How does the W5500 connect to the P1AM-100 platform?
In this setup the W5500 is on the P1AM-ETH shield, and the P1AM-100 (SAMD21, MKR-form-factor) communicates with it over SPI. Your network configuration (IP/subnet/gateway) and MAC address are set in firmware (for example in include/Config.h per your description), and the HMI connects over Ethernet to the controller’s Modbus TCP server endpoint.
3) What role does the W5500 play in THIS project’s control flow?
The W5500 is the Ethernet transport for the HMI link: it carries the Modbus TCP transactions that read status registers (state, counters, timers, heartbeat) and write command/calibration registers (start/stop, speed/tray select, save-to-flash). The firmware should treat those writes as inputs to the state machine rather than letting network traffic directly toggle outputs.
4) Can beginners follow this build, or is W5500 + Modbus TCP too advanced?
Beginners can follow it if they are comfortable with three things: (1) basic Ethernet addressing (static IP, subnet, gateway), (2) Modbus register concepts (read vs write blocks, scaling like ×1000), and (3) SPI-based shields. The W5500 part is usually straightforward once SPI and network settings are stable; most difficulty comes from making the Modbus write handling safe and integrating it with the state machine.
5) How does this compare to using Wi-Fi for the HMI link?
Wi-Fi can work, but in plant environments it often introduces variable latency, roaming issues, and interference that show up as sporadic HMI disconnects or delayed command writes. A W5500-based wired link is typically more predictable for continuous Modbus TCP polling, and it avoids the extra complexity of Wi-Fi provisioning and RF troubleshooting in an industrial cabinet.
