GX Works2 Open Setting의 기본 항목을 알고 있어도 실제 현장 설정표를 보면 다시 막히는 경우가 많습니다. 같은 상대 IP가 여러 줄에 반복되고, TCP와 UDP가 함께 사용되며, 어떤 항목은 Send이고 어떤 항목은 Receive로 나뉘어 있기 때문입니다. 이때는 설정값을 외우는 것보다 각 줄이 왜 그렇게 구성되었는지 설계 의도를 읽는 것이 중요합니다.
Open Setting 사례를 볼 때 먼저 확인할 항목
Open Setting 표를 해석할 때는 한 줄씩 따로 보기보다 전체 통신 구조를 먼저 봐야 합니다.
가장 먼저 확인할 항목은 다음과 같습니다.
| 확인 항목 | 보는 이유 |
|---|---|
| Protocol | TCP인지 UDP인지 확인 |
| Open Method | PLC가 접속하는지, 상대 장비가 접속하는지 확인 |
| Fixed Buffer | Send인지 Receive인지 확인 |
| 상대 IP | 같은 장비인지, 다른 장비인지 확인 |
| Port No. | 용도별로 포트가 분리되었는지 확인 |
| Pairing | 송신과 수신이 한 세트로 묶였는지 확인 |
Open Setting은 단순한 설정표가 아니라 설비 안에서 데이터가 어떤 방향으로 흐르는지 보여주는 통신 구조표에 가깝습니다.
UDP Pairing은 빠른 신호 교환 목적일 수 있다
실제 설정에서 UDP Receive와 UDP Send가 Pairing으로 묶여 있는 경우가 있습니다. 이런 구조는 PC와 PLC가 빠르게 데이터를 주고받아야 하는 상황에서 사용될 수 있습니다.
예를 들어 PC와 PLC가 매 스텝마다 ON/OFF 신호, 상태 플래그, 간단한 워드 데이터를 주기적으로 교환하는 구조입니다.
UDP는 TCP처럼 연결 상태를 세밀하게 확인하는 절차가 약한 대신 구조가 단순합니다. 데이터가 계속 반복 송신되는 구조라면 일부 데이터 누락보다 갱신 속도와 반응성을 우선하는 설계가 가능할 수 있습니다.
| 항목 | 해석 |
|---|---|
| UDP | 연결 확인보다 빠른 송수신 목적 |
| Receive | 외부에서 PLC로 들어오는 데이터 |
| Send | PLC에서 외부로 보내는 데이터 |
| Pairing Enable | 송신과 수신을 한 세트처럼 연동 |
| 사용 목적 | 상태 신호, 간단한 데이터의 빠른 교환 |
다만 UDP를 선택했다고 해서 항상 좋은 것은 아닙니다. 데이터 누락이 문제가 되는 공정이라면 TCP나 별도 확인 로직을 검토해야 합니다.
MELSOFT Connection은 전용 연결로 본다
Open Setting에 MELSOFT Connection이 설정된 경우가 있습니다. 이는 미쓰비시 전용 소프트웨어나 전용 장비와의 연결을 위한 설정으로 볼 수 있습니다.
예를 들어 HMI, 엔지니어링 툴, 미쓰비시 계열 장비가 PLC와 정해진 방식으로 통신하는 경우입니다.
이런 연결은 사용자가 직접 Send/Receive 구조를 세세하게 만들기보다, 제조사에서 정한 통신 절차에 따라 연결되는 경우가 많습니다.
| 항목 | 해석 |
|---|---|
| MELSOFT Connection | 미쓰비시 전용 연결 목적 |
| 주요 용도 | HMI, 엔지니어링 툴, 전용 장비 연동 |
| 특징 | 사용자 정의 프레임보다 설정이 단순한 경우가 많음 |
| 주의점 | 일반 Socket 통신과 혼동하지 않아야 함 |
전용 연결이 가능한 장비라면 굳이 사용자 정의 Socket 구조로 복잡하게 만들 필요가 없는 경우가 많습니다.
TCP Unpassive는 PLC가 대기하는 구조다
TCP Unpassive 설정은 PLC가 포트를 열고 상대 장비의 접속을 기다리는 구조로 이해할 수 있습니다.
상위 PC, HMI, 서버 프로그램이 PLC IP와 포트 번호로 접속해 데이터를 읽거나 쓰는 경우에 자주 사용됩니다.
이 구조에서는 PLC가 먼저 상대방에게 접속하지 않습니다. 상대 장비가 접속을 주도하고, PLC는 정해진 포트에서 대기합니다.
| 항목 | 해석 |
|---|---|
| TCP | 연결형 통신 |
| Unpassive | PLC가 포트를 열고 대기 |
| 상대 주체 | PC, HMI, 서버 등이 PLC로 접속 |
| 주요 용도 | PLC 데이터 읽기·쓰기, 상위 시스템 연동 |
| 장점 | PLC 쪽 접속 로직이 단순해질 수 있음 |
상대방이 PLC 쪽 포트를 열어두면 접속하겠다고 말한다면 이 구조를 먼저 검토하게 됩니다.
Receive만 열려 있다면 데이터 수신 전용일 수 있다
Open Setting에서 어떤 채널이 Receive만 설정되어 있다면 외부 장비가 PLC로 데이터를 보내는 용도일 수 있습니다.
예를 들어 바코드 리더기, 검사 장비, PC 프로그램이 특정 이벤트가 발생했을 때 PLC로 데이터를 보내는 구조입니다. 이 경우 PLC는 해당 포트에서 데이터를 받을 준비만 하면 됩니다.
| 설정 형태 | 설계 의도 |
|---|---|
| Receive만 사용 | 외부 장비가 PLC로 데이터를 보냄 |
| Send만 사용 | PLC가 외부 장비로 데이터를 보냄 |
| Send/Receive 분리 | 송신과 수신 경로를 명확히 분리 |
| Procedure Exist | 정해진 절차로 읽기·쓰기 처리 |
Receive만 있다고 해서 설정이 빠진 것은 아닙니다. 실제 설계 의도상 수신 전용 포트일 수 있습니다.
TCP Active는 PLC가 먼저 접속하는 구조다
TCP Active는 PLC가 상대 장비 IP와 포트로 먼저 접속하는 구조입니다.
상대 장비가 서버처럼 대기하고 있고, PLC가 필요할 때 접속해서 요청을 보내야 하는 경우에 사용됩니다. 예를 들어 측정 장비, PC 서버, 일부 바코드 리더기, 검사 장비가 이런 구조로 동작할 수 있습니다.
| 항목 | 해석 |
|---|---|
| TCP | 연결형 통신 |
| Active | PLC가 상대 IP로 먼저 접속 |
| 상대 역할 | 서버 또는 대기 장비 |
| PLC 역할 | 필요 시 접속 및 요청 송신 |
| 주의점 | 상대 IP와 포트 번호가 정확해야 함 |
Active 구조에서는 상대 장비 IP, 상대 포트, 재접속 조건, 접속 실패 시 처리 로직을 함께 확인해야 합니다.
Send와 Receive 포트를 분리한 이유
현장 설정에서 같은 상대 장비와 통신하면서도 Send와 Receive 포트를 따로 구성하는 경우가 있습니다.
이 구조는 송신 데이터와 수신 데이터를 명확히 분리하기 위한 의도일 수 있습니다. 특히 사용자 정의 Socket 통신에서는 요청 프레임을 보내는 포트와 응답 또는 별도 데이터를 받는 포트를 분리해 관리하는 경우가 있습니다.
| 분리 이유 | 설명 |
|---|---|
| 데이터 혼선 방지 | 송신 데이터와 수신 데이터를 구분 |
| 처리 로직 분리 | 송신 완료와 수신 완료 조건을 따로 관리 |
| 장비 요구사항 | 상대 장비가 포트 분리를 요구 |
| 유지보수 편의 | 어떤 포트가 어떤 데이터인지 추적 가능 |
다만 불필요하게 포트를 많이 열면 설정이 복잡해지고 연결 자원을 낭비할 수 있습니다. 포트 분리는 상대 장비 요구사항과 데이터 흐름을 기준으로 판단해야 합니다.
같은 IP에 여러 포트가 있는 경우
Open Setting에서 같은 상대 IP가 여러 줄에 반복되는 경우가 있습니다. 이때는 중복 설정이라고 바로 판단하면 안 됩니다.
같은 장비라도 데이터 종류에 따라 포트를 나누어 쓰는 경우가 있습니다. 예를 들어 상태 신호, 검사 결과, 바코드 데이터, 제어 명령을 각각 다른 포트로 구분할 수 있습니다.
| 같은 IP 여러 포트의 가능성 | 설명 |
|---|---|
| 용도별 포트 분리 | 상태, 명령, 결과 데이터를 구분 |
| 송수신 방향 분리 | Send와 Receive를 별도 관리 |
| 프로토콜 분리 | 일부는 UDP, 일부는 TCP 사용 |
| 장비 내부 서버 구조 | 상대 장비가 여러 서비스 포트를 제공 |
| 유지보수 목적 | 트러블 발생 시 데이터 흐름 추적 용이 |
같은 IP가 반복되면 왜 같은 장비에 포트가 여러 개 필요한지 먼저 해석해야 합니다. 이 질문에 답하면 설계 의도가 보입니다.
TCP와 UDP가 섞여 있는 이유
하나의 설비 안에서 TCP와 UDP가 함께 사용될 수 있습니다.
모든 데이터가 같은 성격은 아니기 때문입니다. 반드시 도착해야 하는 설정값, 결과값, 레시피 데이터는 TCP가 적합할 수 있고, 빠르게 반복 갱신되는 상태 신호는 UDP로 구성할 수도 있습니다.
| 데이터 성격 | 적합한 방식 |
|---|---|
| 설정값, 레시피, 결과값 | TCP 검토 |
| 상위 시스템 읽기·쓰기 | TCP 검토 |
| 빠른 상태 신호 반복 전송 | UDP 검토 |
| 일부 누락되어도 다음 주기에 갱신되는 데이터 | UDP 검토 |
| 누락되면 공정 문제가 되는 데이터 | TCP 또는 확인 로직 필요 |
따라서 TCP와 UDP가 섞여 있다고 해서 잘못된 설정은 아닙니다. 데이터 성격에 따라 통신 방식을 나누어 설계한 결과일 수 있습니다.
설계 의도를 읽는 세 가지 질문
Open Setting 사례를 볼 때는 다음 세 가지 질문을 기준으로 보면 좋습니다.
| 질문 | 확인 내용 |
|---|---|
| 누가 먼저 접속하는가 | Active인지 Unpassive인지 판단 |
| 누가 데이터를 먼저 보내는가 | Send인지 Receive인지 판단 |
| 어떤 데이터인가 | TCP인지 UDP인지, MC인지 Socket인지 판단 |
이 세 가지를 정리하면 복잡한 Open Setting 표도 구조적으로 볼 수 있습니다.
예를 들어 상대 장비가 먼저 접속해 PLC 값을 읽는다면 TCP Unpassive 구조일 가능성이 높습니다. PLC가 먼저 장비에 요청을 보내야 한다면 TCP Active 구조를 봅니다. 주기적으로 빠른 신호를 주고받는다면 UDP Pairing 구조를 검토할 수 있습니다.
시운전 중 먼저 확인할 항목
Open Setting대로 통신이 붙지 않을 때는 설정값을 전체적으로 바꾸기보다 다음 항목부터 확인해야 합니다.
| 점검 항목 | 확인 내용 |
|---|---|
| 포트 번호 | 10진수와 16진수 입력 혼동 여부 |
| 접속 주체 | Active와 Unpassive 선택이 맞는지 |
| TCP/UDP | 상대 장비와 같은 방식인지 |
| 상대 IP | Active 구조에서 상대 IP가 맞는지 |
| Pairing | Send/Receive Pairing 설정이 의도와 맞는지 |
| 프로토콜 | MC, MELSOFT, Socket 구조가 맞는지 |
| 설정 반영 | PLC Write 후 재기동 또는 재접속 여부 |
| 접속 상태 | 상대 장비에서 실제 접속이 들어오는지 |
특히 포트 번호 진수 문제와 설정 반영 누락은 현장에서 자주 발생합니다. 설정 화면의 값만 보고 끝내지 말고, 실제로 PLC에 반영되었는지 확인해야 합니다.
데이터가 안 들어올 때는 연결과 값을 분리해서 본다
이더넷 통신에서 연결은 되었는데 값이 안 들어오는 경우가 있습니다. 이때는 네트워크 연결 문제와 데이터 처리 문제를 분리해서 봐야 합니다.
| 상태 | 확인 방향 |
|---|---|
| 접속 자체가 안 됨 | IP, 포트, TCP/UDP, Active/Unpassive 확인 |
| 접속은 됨 | 프로토콜, 데이터 주소, 쓰기 권한 확인 |
| 값이 들어왔다가 사라짐 | PLC 로직에서 덮어쓰기 여부 확인 |
| 상대는 보냈다고 함 | 수신 버퍼, 완료 비트, 데이터 길이 확인 |
| 쓰기만 안 됨 | 온라인 쓰기 허용, 디바이스 범위, 인터락 확인 |
연결이 된 것과 PLC 주소에 값이 정상 반영되는 것은 다른 문제입니다. 접속 상태가 정상이라면 그다음은 프로토콜과 데이터 주소, 버퍼 처리, PLC 내부 로직을 확인해야 합니다.
Open Setting 사례 해석 정리
GX Works2 Open Setting 실제 사례를 볼 때는 설정값을 외우는 것보다 각 줄의 목적을 해석해야 합니다. UDP Pairing은 빠른 신호 교환 목적일 수 있고, MELSOFT Connection은 미쓰비시 전용 연결로 볼 수 있습니다. TCP Unpassive는 PLC가 대기하는 구조이며, TCP Active는 PLC가 상대 장비로 먼저 접속하는 구조입니다.
같은 IP에 여러 포트가 있어도 반드시 중복 설정은 아닙니다. 데이터 종류, 송수신 방향, 프로토콜, 장비 요구사항에 따라 포트를 나누어 설계했을 수 있습니다. TCP와 UDP가 섞여 있는 것도 데이터 성격에 따라 안정성과 반응성을 구분한 결과일 수 있습니다.
Open Setting을 해석할 때는 누가 먼저 접속하는지, 누가 데이터를 먼저 보내는지, 어떤 데이터를 주고받는지를 먼저 확인해야 합니다. 이 세 가지가 정리되면 복잡해 보이는 설정표도 설계 의도에 따라 읽을 수 있습니다.
통신 트러블이 발생했을 때도 전체 설정을 무작정 바꾸기보다 포트 번호, 접속 주체, TCP/UDP, 상대 IP, 프로토콜, 설정 반영 여부를 순서대로 확인하는 것이 효율적입니다. 연결이 된 뒤 값이 들어오지 않는 문제는 Open Setting뿐 아니라 데이터 주소, 쓰기 권한, 수신 버퍼, PLC 내부 로직까지 함께 확인해야 합니다.