[카테고리:] PLC/Automation

PLC/자동제어 카테고리는 산업 자동화 현장에서 사용하는 PLC 제어, 전장 설계, 산업용 통신, 서보·모션, 제어반 제작과 관련된 실무 내용과 자동화 산업 현장 인사이트를 정리합니다. 현장 시운전과 유지보수 과정에서 자주 발생하는 문제, 전시회와 설비 트렌드에서 확인한 내용을 기준으로 작성합니다.

  • [실전] 미쓰비시 PLC 소켓통신 로직, 왜 송신·수신 포트를 분리할까?

    미쓰비시 PLC 이더넷 소켓통신에서 Ping이 정상이고 연결 상태가 ESTABLISH로 표시되어도 데이터 누락이 발생할 수 있습니다. 이 경우 단순 네트워크 연결 문제가 아니라 송신과 수신의 처리 구조, 포트 구성, 버퍼 초기화, 완료 플래그 처리 방식까지 함께 확인해야 합니다. 특히 한 포트에 송신과 수신을 모두 집중시키면 통신량 증가 시 타이밍 충돌과 데이터 누락이 발생하기 쉽습니다.

    연결 상태와 데이터 안정성은 별개다

    이더넷 통신에서 Ping이 정상이라는 것은 네트워크 경로가 살아 있다는 의미입니다. ESTABLISH 상태는 TCP 연결이 성립되었다는 의미입니다. 그러나 이 두 가지가 곧 데이터 처리가 안정적이라는 뜻은 아닙니다.

    현장에서 문제는 보통 연결 이후에 발생합니다. 접속은 되어 있지만 수신 버퍼를 제때 읽지 못하거나, 송신 처리 중 수신 데이터가 밀리거나, 이전 데이터가 초기화되지 않아 다음 처리에 영향을 주는 경우가 있습니다.

    구분해서 보면 다음과 같습니다.

    상태의미추가 확인 항목
    Ping 정상IP 경로 확인포트, 프로토콜, 방화벽 별도 확인 필요
    ESTABLISHTCP 연결 성립송신·수신 데이터 처리 확인 필요
    SD/RD 반응데이터 송수신 시도버퍼 처리와 완료 플래그 확인 필요
    값 누락처리 구조 문제 가능포트 분리, 수신 타이밍, 초기화 확인 필요

    따라서 소켓통신에서는 연결 여부뿐 아니라 데이터가 언제 들어오고, 언제 읽히며, 처리 후 어떻게 정리되는지를 함께 봐야 합니다.

    한 포트에 송신과 수신을 몰아넣을 때의 문제

    하나의 IP와 하나의 포트로 송신과 수신을 모두 처리하면 설정은 단순해 보입니다. 그러나 통신량이 늘어나거나 상대 장비 응답 타이밍이 일정하지 않으면 문제가 발생할 수 있습니다.

    대표적인 문제는 다음과 같습니다.

    문제설명
    타이밍 충돌PLC 송신 시점과 상대 장비 송신 시점이 겹칠 수 있음
    수신 지연송신 처리 중 수신 데이터 처리가 늦어질 수 있음
    원인 구분 어려움송신 실패인지 수신 대기 문제인지 분리하기 어려움
    버퍼 관리 복잡송신 데이터와 수신 데이터를 같은 흐름에서 관리해야 함
    재접속 처리 복잡연결 이상 발생 시 복구 조건이 복잡해짐

    통신 장애가 발생했을 때 송신 문제와 수신 문제를 구분할 수 있어야 원인 추적이 빠릅니다. 한 포트에 기능을 집중시키면 이 구분이 어려워집니다.

    송신 포트와 수신 포트를 분리하는 이유

    송신 포트와 수신 포트를 분리하면 데이터 흐름을 명확하게 나눌 수 있습니다.

    수신 포트는 상대 장비에서 들어오는 데이터를 기다리는 역할을 담당하고, 송신 포트는 PLC가 필요할 때 상대 장비로 명령이나 데이터를 보내는 역할을 담당합니다.

    구분역할
    수신 포트외부 장비가 보내는 데이터를 대기 및 수신
    송신 포트PLC가 외부 장비로 명령 또는 데이터 송신
    수신 로직완료 플래그 기준으로 버퍼 읽기
    송신 로직요청 조건 기준으로 1회성 송신 처리
    유지보수송신 이상과 수신 이상을 분리 진단 가능

    포트 분리는 단순히 포트 번호를 나누는 작업이 아닙니다. 통신 역할을 분리하고, 로직 흐름을 분리하며, 장애 발생 시 진단 범위를 줄이는 설계 방식입니다.

    수신 채널은 상시 대기 구조가 적합하다

    상대 장비가 언제 데이터를 전송할지 알 수 없는 구조라면 수신 채널은 항상 대기 상태를 유지하는 것이 좋습니다.

    예를 들어 바코드 리더기, 검사 장비, 비전 장비, 상위 PC가 특정 이벤트 시점에 PLC로 데이터를 보내는 경우가 있습니다. 이때 PLC 수신 포트가 열려 있지 않으면 데이터가 누락되거나 상대 장비에서 전송 실패가 발생할 수 있습니다.

    수신 채널 구성 시 확인할 항목은 다음과 같습니다.

    확인 항목설명
    포트 오픈 상태수신 포트가 정상적으로 열려 있는지 확인
    접속 상태상대 장비와 연결 상태가 유지되는지 확인
    수신 완료 플래그데이터 수신 완료 조건이 명확한지 확인
    수신 카운터실제 수신 발생 여부를 카운터로 확인
    미수신 감시일정 시간 수신이 없을 때 알람 또는 상태 표시

    수신 완료 신호가 들어올 때마다 카운터를 증가시키면 실제 데이터 수신 여부를 확인하기 쉽습니다. 단순히 연결 상태만 보는 것보다 수신 이벤트가 발생하는지 확인하는 것이 통신 진단에 더 유용합니다.

    수신 완료 후 버퍼를 읽는 순서

    수신 데이터는 수신 완료 조건을 기준으로 읽어야 합니다. 데이터가 들어오는 중간에 버퍼를 읽으면 일부 데이터만 처리되거나 이전 데이터와 새 데이터가 섞일 수 있습니다.

    일반적인 수신 처리 흐름은 다음과 같습니다.

    순서처리 내용
    1수신 포트 오픈 및 대기
    2수신 완료 플래그 확인
    3수신 버퍼에서 데이터 읽기
    4PLC 내부 D 영역으로 데이터 이동
    5데이터 길이와 형식 확인
    6필요한 값 파싱
    7처리 완료 후 수신 영역 초기화
    8다음 수신 대기 상태로 복귀

    수신 완료 플래그 없이 상시 조건으로 버퍼를 읽으면 데이터 누락이나 깨짐이 발생할 수 있습니다. 반드시 완료 조건을 기준으로 읽는 구조가 필요합니다.

    데이터 처리 후 초기화가 필요한 이유

    수신 데이터를 정상적으로 읽었더라도 처리 후 초기화가 빠지면 이전 데이터가 다음 사이클에 영향을 줄 수 있습니다.

    예를 들어 이전 수신값이 D 영역에 남아 있는 상태에서 새 데이터 수신이 지연되면, PLC가 이전 값을 새 데이터처럼 다시 사용할 수 있습니다. 이 경우 통신은 정상이나 제어 로직에서는 한 박자 늦거나 중복 처리된 것처럼 보일 수 있습니다.

    처리 후 초기화가 필요한 영역은 다음과 같습니다.

    영역초기화 목적
    수신 원본 영역이전 수신 데이터 잔류 방지
    파싱 임시 영역다음 데이터 변환 시 혼입 방지
    수신 완료 플래그동일 데이터 반복 처리 방지
    처리 요청 플래그중복 실행 방지
    에러 상태이전 에러와 현재 에러 구분

    수신 데이터는 읽는 것만큼 정리하는 과정도 중요합니다. 특히 문자열, 바코드, 검사 결과처럼 길이가 변할 수 있는 데이터는 이전 데이터 잔류 여부를 반드시 확인해야 합니다.

    송신 채널은 필요할 때만 실행한다

    송신 채널은 PLC가 외부 장비로 요청이나 데이터를 보내는 역할을 담당합니다. 수신 채널과 달리 상시 실행보다 요청 조건에 따른 1회성 실행 구조가 적합합니다.

    송신 로직은 다음 흐름으로 구성하는 것이 좋습니다.

    순서처리 내용
    1송신 요청 조건 발생
    2송신 데이터 영역 작성
    3송신 명령 1회 실행
    4송신 완료 플래그 확인
    5송신 에러 여부 확인
    6필요 시 수신 대기 또는 재시도
    7송신 요청 플래그 초기화

    송신 명령을 매 스캔 반복 실행하면 상대 장비가 중복 명령을 받거나, 응답 데이터가 꼬일 수 있습니다. 따라서 송신은 상승엣지 또는 상태 단계 방식으로 제어하는 것이 안전합니다.

    송신과 수신을 분리하면 진단이 쉬워진다

    송신 포트와 수신 포트를 분리하면 장애 발생 시 원인을 나누어 볼 수 있습니다.

    예를 들어 수신 카운터는 증가하지 않지만 송신 완료는 정상이라면 상대 장비가 데이터를 보내지 않거나 수신 포트 쪽에 문제가 있을 수 있습니다. 반대로 수신은 정상인데 송신 완료가 발생하지 않으면 PLC 송신 조건이나 상대 장비 응답 구조를 확인해야 합니다.

    증상우선 확인 방향
    수신 카운터 증가 없음수신 포트, 상대 송신, 방화벽, 포트 번호
    송신 완료 없음송신 조건, 상대 IP, 상대 포트, 접속 상태
    수신값이 이전 값 반복수신 영역 초기화, 처리 완료 플래그
    데이터 일부 누락수신 완료 기준, 데이터 길이, 버퍼 읽기 타이밍
    간헐적 끊김재접속 조건, 네트워크 부하, 상대 장비 응답 시간

    포트와 로직이 분리되어 있으면 문제 발생 시 송신 계통과 수신 계통을 따로 확인할 수 있습니다.

    같은 IP에 여러 포트를 사용하는 구조

    같은 상대 IP라도 포트를 여러 개 사용할 수 있습니다. 이는 중복 설정이 아니라 데이터 역할 분리일 수 있습니다.

    예를 들어 한 포트는 PLC가 상대 장비의 데이터를 수신하는 용도, 다른 포트는 PLC가 상대 장비로 요청을 보내는 용도로 사용할 수 있습니다. 또는 상태 데이터, 검사 결과, 제어 명령을 각각 다른 포트로 나누어 관리할 수도 있습니다.

    구성목적
    수신 전용 포트외부 장비의 비동기 데이터 수신
    송신 전용 포트PLC 요청 또는 명령 전송
    상태 전용 포트주기적인 상태 데이터 교환
    결과 전용 포트검사 결과 또는 판정값 수신
    명령 전용 포트제어 명령 송신

    포트를 나누면 설정은 늘어나지만 데이터 흐름이 명확해지고, 유지보수 시 어떤 포트에서 문제가 발생했는지 추적하기 쉬워집니다.

    포트 분리 시 주의할 항목

    송신·수신 포트를 분리할 때는 포트 번호만 나누면 끝나는 것이 아닙니다. Open Setting, 상대 장비 설정, PLC 로직, 방화벽 정책이 모두 일치해야 합니다.

    확인해야 할 항목은 다음과 같습니다.

    확인 항목설명
    포트 번호송신용과 수신용 포트가 상대 장비와 일치하는지 확인
    TCP/UDP각 포트의 프로토콜이 상대 장비와 일치하는지 확인
    Active/Unpassive각 포트의 접속 주체가 맞는지 확인
    상대 IPActive 송신 구조에서 상대 IP가 정확한지 확인
    수신 완료 플래그수신 포트별 완료 신호를 구분하는지 확인
    에러 코드송신·수신 포트별 에러를 별도로 관리하는지 확인
    재접속 조건연결 해제 시 복구 조건이 있는지 확인
    방화벽각 포트가 네트워크 정책에서 허용되는지 확인

    포트를 분리한 뒤에도 플래그와 에러 코드를 하나로 묶어 관리하면 진단 효과가 떨어집니다. 포트별 상태를 따로 확인할 수 있어야 합니다.

    수신 카운터와 상태 플래그를 남긴다

    통신 진단을 위해서는 수신 완료 카운터, 송신 완료 카운터, 에러 카운터를 남기는 것이 좋습니다.

    이 값들은 HMI나 모니터링 화면에서 통신 상태를 빠르게 확인하는 데 도움이 됩니다.

    진단 항목목적
    수신 완료 카운터실제 데이터 수신 발생 여부 확인
    송신 완료 카운터송신 명령 정상 완료 여부 확인
    수신 에러 카운터수신 이상 발생 빈도 확인
    송신 에러 카운터송신 실패 발생 빈도 확인
    마지막 수신 시간통신 정지 여부 판단
    마지막 에러 코드원인 추적 기준 확보

    연결 상태만으로는 실제 데이터 흐름을 확인하기 어렵습니다. 수신 완료와 송신 완료를 카운터로 남기면 간헐적 문제를 추적하기 쉽습니다.

    소켓통신 포트 분리 설계 체크리스트

    송신·수신 포트를 분리할 때는 다음 항목을 점검합니다.

    점검 항목확인 내용
    수신 포트상대 장비가 보내는 데이터를 항상 받을 수 있는지
    송신 포트PLC 요청 조건에 따라 1회성으로 송신되는지
    포트 번호상대 장비 설정과 일치하는지
    접속 방식Active와 Unpassive가 역할에 맞는지
    수신 완료완료 플래그 기준으로 버퍼를 읽는지
    초기화처리 후 수신 영역과 플래그를 정리하는지
    중복 송신송신 명령이 매 스캔 반복되지 않는지
    진단 카운터송신·수신 완료 횟수를 확인할 수 있는지
    에러 분리송신 에러와 수신 에러를 따로 볼 수 있는지
    재접속연결 해제 후 복구 조건이 있는지

    이 항목을 기준으로 보면 포트 분리 구조가 실제로 안정성을 높이는 방향으로 설계되었는지 확인할 수 있습니다.

    송신·수신 포트 분리 정리

    미쓰비시 PLC 소켓통신에서 Ping과 ESTABLISH 상태가 정상이어도 데이터 누락은 발생할 수 있습니다. 연결은 네트워크 경로와 접속 상태를 의미할 뿐, 데이터 처리 로직이 안정적이라는 의미는 아닙니다.

    한 포트에 송신과 수신을 모두 집중시키면 타이밍 충돌, 수신 지연, 버퍼 처리 혼선, 디버깅 어려움이 발생할 수 있습니다. 송신 포트와 수신 포트를 분리하면 데이터 흐름이 명확해지고, 송신 문제와 수신 문제를 따로 진단할 수 있습니다.

    수신 포트는 상대 장비의 데이터 전송에 대비해 대기 상태를 유지하고, 수신 완료 플래그 기준으로 버퍼를 읽어야 합니다. 처리 후에는 수신 데이터 영역과 완료 플래그를 정리해 이전 데이터가 다음 처리에 영향을 주지 않도록 해야 합니다.

    송신 포트는 PLC가 필요할 때만 요청 조건에 따라 1회성으로 실행하는 것이 좋습니다. 송신 완료, 송신 에러, 재접속 조건을 별도로 관리하면 간헐적 통신 문제를 추적하기 쉽습니다.

    소켓통신은 연결보다 구조가 중요합니다. 포트 분리는 설정을 복잡하게 만드는 작업이 아니라, 데이터 흐름을 분리하고 유지보수성을 높이는 설계 방식입니다.

  • [실무] 미쓰비시 PLC 이더넷 통신에서 상대는 값을 쓰는데 내 주소에 값이 안 들어올 때 확인 순서

    이더넷 통신 시운전 중 상대 PC나 HMI에서는 데이터를 보냈다고 하는데 PLC 디바이스 값은 바뀌지 않는 경우가 있습니다. Ping은 정상이고 접속 상태도 이상 없어 보이지만 D, M, W 같은 PLC 주소에는 값이 들어오지 않는 상황입니다. 이때는 통신 전체가 안 되는 문제로 보기보다, 쓰기 권한, 데이터 형식, 주소 지정, 파라미터 반영 여부를 순서대로 확인해야 합니다.

    통신은 되는데 값만 안 들어오는 상황

    현장에서 “통신이 안 된다”고 말하는 경우가 많지만, 실제로는 통신이 완전히 끊긴 상태가 아닐 수 있습니다.

    예를 들어 상대 장비가 PLC 데이터를 읽는 것은 되는데, PLC에 값을 쓰는 것만 안 되는 경우가 있습니다. 이 경우에는 배선이나 IP 설정보다 쓰기 허용 조건, 데이터 코드, 디바이스 주소, 프로토콜 설정을 먼저 보는 것이 빠릅니다.

    상태를 구분하면 다음과 같습니다.

    증상우선 확인 항목
    Ping이 안 됨IP, 서브넷, 케이블, 허브, 방화벽
    접속이 안 됨포트 번호, TCP/UDP, Active/Unpassive
    읽기는 됨기본 통신 연결은 성립 가능
    쓰기만 안 됨쓰기 허용 설정, 주소, 권한, 데이터 코드
    값이 들어왔다가 사라짐PLC 내부 로직에서 덮어쓰기 여부
    값이 이상하게 들어옴Binary/ASCII, 워드 순서, 데이터 타입

    통신 연결과 PLC 디바이스 값 반영은 같은 문제가 아닙니다. 연결이 정상이어도 PLC가 외부 쓰기를 허용하지 않거나, 상대가 잘못된 주소로 쓰고 있으면 값은 들어오지 않습니다.

    1단계 주소와 디바이스 종류를 다시 맞춘다

    가장 먼저 확인할 것은 상대 장비가 쓰는 주소와 내가 보고 있는 PLC 주소가 같은지입니다.

    현장에서는 상대가 D100에 쓴다고 했는데 PLC에서는 D1000을 보고 있거나, 상대는 M 영역에 쓰고 있는데 PLC에서는 D 영역만 확인하는 경우가 있습니다.

    또한 미쓰비시 PLC는 디바이스 종류에 따라 주소 체계가 다를 수 있습니다. X, Y, B, W처럼 16진수 주소 체계를 쓰는 영역과 D, M처럼 10진수 기준으로 보는 영역을 혼동하면 서로 다른 주소를 보고 있을 수 있습니다.

    확인할 항목은 다음과 같습니다.

    확인 항목설명
    디바이스 종류D, M, W, B 중 어느 영역인지 확인
    시작 주소상대 장비가 쓰는 시작 주소와 PLC 모니터 주소 일치 확인
    주소 진수10진수와 16진수 표기 혼동 여부 확인
    데이터 길이1워드인지, 여러 워드인지 확인
    비트·워드 구분M 같은 비트 영역인지, D 같은 워드 영역인지 확인

    주소가 하나만 틀려도 통신은 정상인데 값이 안 들어오는 것처럼 보입니다. 그래서 가장 먼저 같은 주소를 보고 있는지부터 확인해야 합니다.

    2단계 데이터 코드 Binary와 ASCII를 확인한다

    미쓰비시 이더넷 통신에서는 데이터 코드 설정을 확인해야 합니다. 상대 장비가 Binary 방식으로 데이터를 보내는데 PLC 설정이 ASCII 기준이거나, 반대로 PLC는 Binary로 기다리는데 상대가 ASCII로 보내면 값이 정상적으로 해석되지 않을 수 있습니다.

    이 경우 통신 패킷은 들어오지만 PLC에서 기대한 값으로 반영되지 않거나, 이상한 값으로 보일 수 있습니다.

    구분의미
    Binary데이터를 바이너리 값으로 처리
    ASCII숫자나 문자를 ASCII 코드 형태로 처리
    불일치 시값 깨짐, 해석 오류, 쓰기 실패처럼 보일 수 있음

    특히 PC 프로그램에서 직접 MC 프로토콜이나 Socket 데이터를 구성하는 경우에는 Binary/ASCII 설정을 반드시 맞춰야 합니다. 상대 담당자에게 실제 송신 프레임이 Binary인지 ASCII인지 확인하는 것이 좋습니다.

    3단계 Enable Online Change 설정을 확인한다

    읽기는 되는데 쓰기만 안 되는 상황이라면 Enable Online Change 설정을 확인해야 합니다.

    이 설정은 외부 장비가 PLC 디바이스 값을 변경할 수 있는지와 관련된 항목입니다. 읽기만 허용되고 쓰기가 막힌 상태라면 상대 장비는 정상적으로 접속해도 PLC 내부 값은 바뀌지 않을 수 있습니다.

    확인할 내용은 다음과 같습니다.

    확인 항목설명
    Enable Online Change외부 쓰기 허용 여부 확인
    쓰기 대상 디바이스해당 디바이스가 외부 쓰기 가능한 영역인지 확인
    PLC 운전 상태RUN 중 쓰기 허용 조건 확인
    보안 설정쓰기 제한 또는 보호 설정 여부 확인
    상위 프로그램 권한PC/HMI 쪽 쓰기 명령 권한 확인

    외부 장비에서 PLC 값을 쓴다는 것은 단순 통신보다 위험도가 높은 동작입니다. 따라서 쓰기 허용 설정이 막혀 있으면 읽기는 되지만 쓰기만 안 되는 상황이 발생할 수 있습니다.

    4단계 PLC 내부 로직이 값을 덮어쓰는지 확인한다

    외부에서 값이 실제로 들어오지만 PLC 로직에서 바로 0으로 덮어쓰는 경우도 있습니다.

    예를 들어 상위 PC가 D100에 값을 쓰는데, PLC 프로그램 어딘가에서 매 스캔 MOV K0 D100을 실행하고 있다면 모니터에서는 값이 안 들어오는 것처럼 보입니다. 실제로는 들어왔다가 바로 지워지는 상태입니다.

    확인할 항목은 다음과 같습니다.

    확인 항목설명
    해당 주소 검색D100, M100 등 쓰기 대상 주소를 전체 검색
    MOV 초기화매 스캔 0 또는 기본값을 쓰는 로직 확인
    BMOV/FMOV넓은 범위 복사로 해당 영역이 덮이는지 확인
    자동 초기화운전 시작, 알람, 리셋 조건에서 초기화되는지 확인
    HMI 쓰기HMI나 다른 장비가 같은 주소를 쓰는지 확인

    값이 순간적으로 들어왔다가 사라지는 증상이라면 통신보다 PLC 내부 로직을 먼저 의심해야 합니다.

    5단계 쓰기 영역을 따로 분리한다

    외부 장비가 쓰는 영역은 PLC 내부에서 사용하는 영역과 분리하는 것이 좋습니다.

    예를 들어 PC에서 쓰는 영역을 D1000~D1099로 정하고, PLC 내부 연산 영역은 D2000 이후로 나누는 방식입니다. 외부 입력값은 바로 출력 조건에 사용하지 말고, 검증 후 내부 사용 영역으로 옮기는 구조가 안전합니다.

    영역용도
    외부 쓰기 영역PC, HMI, 상위 장비가 값을 쓰는 영역
    검증 영역범위, 형식, 변경 여부 확인
    내부 사용 영역PLC 시퀀스에서 실제 사용하는 값
    결과 응답 영역PLC가 상위 장비에 돌려주는 상태값
    에러 영역통신 이상, 범위 오류, 쓰기 오류 표시

    외부에서 들어온 값이 바로 동작 출력으로 이어지면 위험할 수 있습니다. 쓰기 영역과 실제 제어 영역 사이에는 확인 로직을 두는 것이 좋습니다.

    6단계 포트와 프로토콜을 다시 확인한다

    값이 안 들어오는 문제는 Open Setting의 포트와 프로토콜 설정에서도 발생할 수 있습니다.

    접속은 되었지만 상대 장비가 기대한 프로토콜과 PLC 설정이 다르면 데이터가 정상 반영되지 않습니다. 예를 들어 상대는 MC 프로토콜로 D 영역을 쓰고 있는데 PLC 설정이나 포트 용도가 Socket 수신용으로 구성되어 있다면 의도대로 처리되지 않을 수 있습니다.

    확인할 항목은 다음과 같습니다.

    확인 항목설명
    TCP/UDP상대 장비와 동일한 방식인지 확인
    Active/Unpassive접속 주체가 맞는지 확인
    MC Protocol상대가 MC 프로토콜로 쓰는지 확인
    Socket 통신사용자 정의 데이터라면 수신 처리 로직 확인
    포트 번호상대가 접속한 포트와 PLC Open Setting 포트 일치 확인
    진수 표기포트 번호 10진수/16진수 혼동 여부 확인

    연결 상태만 보고 정상이라고 판단하지 말고, 그 연결이 어떤 프로토콜을 처리하는 포트인지 확인해야 합니다.

    7단계 방화벽과 보안 정책을 확인한다

    PC나 상위 시스템에서 데이터를 보냈다고 해도 실제 패킷이 PLC까지 도달하지 않을 수 있습니다.

    특히 회사 노트북, 보안 프로그램, 산업용 방화벽, 네트워크 정책이 적용된 환경에서는 특정 포트나 쓰기 방향 패킷이 차단될 수 있습니다.

    확인할 항목은 다음과 같습니다.

    확인 항목설명
    PC 방화벽송수신 포트 허용 여부 확인
    보안 프로그램산업용 통신 차단 여부 확인
    네트워크 장비라우터, 방화벽, VLAN 정책 확인
    포트 허용실제 사용하는 TCP/UDP 포트 허용 여부 확인
    테스트 도구포트 연결, 패킷 송수신 여부 확인

    Ping이 된다고 모든 통신이 허용되는 것은 아닙니다. Ping은 되지만 특정 포트 데이터는 차단될 수 있습니다.

    8단계 파라미터 반영과 재기동 여부를 확인한다

    미쓰비시 PLC 설정은 화면에서 값을 바꿨다고 바로 적용되는 것이 아닐 수 있습니다. PLC Write를 했는지, 파라미터가 실제 PLC에 반영되었는지, 전원 재투입이나 리셋이 필요한지 확인해야 합니다.

    현장에서는 설정을 바꿨는데도 이전 설정으로 동작하는 경우가 있습니다. 이때는 통신 조건을 계속 수정하기보다 적용 절차를 먼저 확인해야 합니다.

    확인 항목설명
    PLC Write변경된 파라미터를 PLC에 전송했는지 확인
    전원 재투입전원 OFF/ON 또는 리셋 필요 여부 확인
    모듈 재시작이더넷 모듈 설정 반영 여부 확인
    설정값 재확인온라인 상태에서 실제 설정을 다시 확인
    접속 재시도상대 장비 프로그램도 재접속했는지 확인

    설정 변경 후에는 PLC뿐 아니라 상대 PC 프로그램도 재접속이 필요할 수 있습니다. 기존 연결이 이전 설정으로 유지되는 경우가 있기 때문입니다.

    9단계 상대 장비가 실제로 쓰고 있는지 확인한다

    상대방은 보냈다고 하지만 실제로는 읽기만 하고 있거나, 쓰기 명령이 실패하고 있을 수도 있습니다.

    PC 프로그램이나 HMI 쪽에서 쓰기 성공 응답을 확인해야 합니다. 단순히 버튼을 눌렀다는 것과 PLC에 쓰기 명령이 성공했다는 것은 다릅니다.

    확인할 항목은 다음과 같습니다.

    확인 항목설명
    쓰기 명령 실행 여부실제 Write 명령이 나가는지 확인
    쓰기 성공 응답상대 프로그램에서 성공 응답을 받았는지 확인
    쓰기 주소상대 프로그램의 대상 주소 확인
    데이터 길이쓰는 워드 수 또는 비트 수 확인
    에러 로그상대 장비의 통신 에러 코드 확인

    상대 프로그램 로그를 확인하면 PLC 문제인지 PC 프로그램 문제인지 빠르게 나눌 수 있습니다.

    현장 체크리스트

    값이 안 들어올 때는 다음 순서로 확인하는 것이 좋습니다.

    순서점검 항목
    1상대가 쓰는 디바이스 종류와 주소 확인
    2주소 진수와 데이터 길이 확인
    3Binary/ASCII 데이터 코드 확인
    4Enable Online Change 또는 쓰기 허용 설정 확인
    5PLC 내부에서 해당 주소를 덮어쓰는 로직 확인
    6Open Setting의 포트, TCP/UDP, 프로토콜 확인
    7PC 방화벽과 보안 정책 확인
    8PLC Write와 전원 재투입 여부 확인
    9상대 프로그램의 쓰기 성공 응답 확인
    10실제 PLC 모니터에서 값 변화 확인

    이 순서대로 보면 불필요하게 배선이나 전체 네트워크 설정을 다시 건드리는 시간을 줄일 수 있습니다.

    값이 안 들어올 때의 판단 기준

    이더넷 통신에서 상대는 값을 썼다고 하는데 PLC 주소가 바뀌지 않는다면, 먼저 통신 연결과 쓰기 반영을 분리해서 봐야 합니다.

    Ping이 되고 접속 상태가 정상이라면 배선이나 IP 문제보다는 주소, 데이터 형식, 쓰기 권한, 내부 로직 덮어쓰기, 파라미터 반영 문제일 가능성이 높습니다.

    읽기는 되는데 쓰기만 안 된다면 Enable Online Change 같은 쓰기 허용 설정을 먼저 확인해야 합니다. 값이 순간적으로 들어왔다가 사라진다면 PLC 내부에서 해당 주소를 초기화하거나 다른 값으로 덮어쓰는 로직을 찾아야 합니다.

    또한 상대가 쓰는 주소와 PLC에서 보는 주소가 같은지, D와 M 같은 디바이스 종류가 맞는지, Binary/ASCII 데이터 코드가 맞는지 확인해야 합니다. 포트 번호와 프로토콜이 맞더라도 데이터 형식이나 쓰기 권한이 틀리면 값은 정상 반영되지 않습니다.

    시운전은 가능한 원인을 하나씩 제거하는 과정입니다. 통신 연결이 확인되었다면 그다음은 쓰기 권한, 데이터 주소, 데이터 코드, 내부 로직, 설정 반영 여부를 순서대로 확인하는 것이 가장 빠릅니다.

  • [실전] GX Works2 Open Setting 사례 분석: 설계 의도를 읽는 법

    GX Works2 Open Setting의 기본 항목을 알고 있어도 실제 현장 설정표를 보면 다시 막히는 경우가 많습니다. 같은 상대 IP가 여러 줄에 반복되고, TCP와 UDP가 함께 사용되며, 어떤 항목은 Send이고 어떤 항목은 Receive로 나뉘어 있기 때문입니다. 이때는 설정값을 외우는 것보다 각 줄이 왜 그렇게 구성되었는지 설계 의도를 읽는 것이 중요합니다.

    Open Setting 사례를 볼 때 먼저 확인할 항목

    Open Setting 표를 해석할 때는 한 줄씩 따로 보기보다 전체 통신 구조를 먼저 봐야 합니다.

    가장 먼저 확인할 항목은 다음과 같습니다.

    확인 항목보는 이유
    ProtocolTCP인지 UDP인지 확인
    Open MethodPLC가 접속하는지, 상대 장비가 접속하는지 확인
    Fixed BufferSend인지 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로 들어오는 데이터
    SendPLC에서 외부로 보내는 데이터
    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연결형 통신
    UnpassivePLC가 포트를 열고 대기
    상대 주체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연결형 통신
    ActivePLC가 상대 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상대 장비와 같은 방식인지
    상대 IPActive 구조에서 상대 IP가 맞는지
    PairingSend/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 내부 로직까지 함께 확인해야 합니다.