설비 하나를 만들려면 제어 로직과 조작 화면 2가지가 필요합니다. PLC는 로직을, HMI가 화면이죠.

센브릭스와 센바스가 각각을 담당하는데, 둘 다 AI와 대화하며 만드는 방식을 갖고 있습니다.

AI가 PLC와 HMI를 다룬다면

AI와 대화하는 작업 흐름은 5가지입니다.

인터뷰 → 설계 → 계획 → 구현 → 검증

문제는 인터뷰 단계가 생각보다 시간을 잡아먹습니다.

말로 설명하다 보니 질문이 많아지고 답변도 계속 쌓이는 구조죠. 게임기를 만들 때도 “토글 스위치”로 시작했던 인터뷰가 아날로그 레버로 바뀌었고, 한 가지 기능이 10가지 기능과 + 순위표가 됐습니다.

환장할 노릇이죠.

그래서 단계마다 확인을 받았습니다.

한 번에 다 만들어놓고 “나 다 했어요!” 가 되면, 잘못된 내용을 되돌리는 비용이 큽니다.

PLC 쪽 — 래더로 로직을

순서 제어와 인터록은 래더로 씁니다. 주소가 아니라 이름으로 씁니다 — M33 이 아니라 St30, P0 이 아니라 BtnPlay 입니다. 이름과 설명이 붙어 있으면 사람이 읽기 쉬워지고, AI와 대화할 때도 “따르기 상태에서” 같은 말이 그대로 통합니다.

래더로 쓰기 불편한 것 — 카드 셔플, 점수 집계 — 은 C# 으로 씁니다. 래더와 C#은 같은 메모리를 보고, 핸드셰이크 비트로 서로를 깨웁니다.

현장 입출력은 확장 보드로 늘립니다. CAN 한 쌍에 아날로그 입력(AD-4)·출력(DA-4)· 디지털 IO(IO-8)를 물립니다.

HMI 쪽 — UI로 화면을

HMI 화면은 SENVAS라는 디자인 툴로 그려서 실제 환경에 배포합니다.

드래그&드롭으로도 되고(WIZWIG방식), AI와 MCP가 연동되어 프롬프트 작성만으로

빈 화면을 원하는 형태로 바로 볼 수 있게 됩니다.

사실 이 부분이 가장 큰 체감입니다.

빈 화면에서 시작하는 부담이 줄어드니 내가 작성하고 싶은 것들이 더 많아지죠.

심지어 원격에서 화면을 보고 터치까지 할 수 있습니다.

둘이 붙는 지점 — Modbus TCP 주소 공유

PLC와 HMI는 같은 주소 공간을 봅니다. PLC의 D 영역을 HMI가 Modbus TCP로 읽고, 명령은 정해진 구간에 씁니다.

이 구조에서 중요한 원칙이 하나 있습니다. 판정의 출처를 한 곳에 둡니다 — 값은 PLC에 살고, HMI는 읽어서 그리기만 합니다. 그러면 화면과 기록이 어긋날 수 없습니다. 설비에서든 게임에서든 같습니다.

검증은 아케이드 게임기로 했다

PLC와 HMI 검증은 만들어놓고 나면 뭘로 할지가 바로 문제가 됩니다. 실제 설비에 넣어보는 게 제일 정확한데 그러기엔 위험하고 기회도 적습니다.

그래서 아케이드 게임기를 만들었습니다. 게임은 설비보다 까다로운 구석이 있습니다 — 사람이 손으로 조작하고 눈으로 보니 늦으면 바로 느껴지고, 아날로그가 필수고, 여러 종류 IO가 한 프로그램에서 동시에 돌고, 며칠 켜두면 누적 오류가 드러납니다.

게임 네 종(맥주 따르기·블랙잭·슈팅·낚시)이 한 프로젝트에서 돌아갑니다. 전 과정은 맥주 게임기 시리즈 일곱 편에 적어뒀습니다.

그 과정에서 실제로 잡은 것들이 있습니다. 아날로그 출력의 비선형성, 통신 갱신 간격이 만드는 화면 끊김, 확장 보드 주소 공간이 부족해 전체를 이사한 일 — 게임기가 아니었으면 납품 현장에서 만났을 문제들입니다.

값은 PLC에 두고 HMI는 읽어서 그리기만 하면, 화면과 기록이 어긋날 수 없습니다.

문의