[실무] 미쓰비시 PLC D메모리: 값이 깨지거나 음수로 튀는 이유 (16비트 vs 32비트 + GX Works 체크)

GX Works로 모니터링을 하다 보면 기가 막힌 상황이 생깁니다. 분명히 양수(+)를 더했는데 갑자기 값이 마이너스(-) 3만 얼마로 변하거나, 건드리지도 않은 옆 동네 D메모리 값이 같이 변하는 현상입니다. 이건 PLC 고장이 아니라 데이터 바구니(Bit/Word) 설정 문제입니다. 오늘 GX Works에서 이 ‘데이터 오염’을 잡는 핵심 포인트를 정리합니다.

[한 줄 직설] “모니터링 화면의 파란 숫자를 믿지 마십시오. 당신이 지정한 D메모리가 몇 비트인지, 그리고 어디서부터 보느냐가 핵심입니다.”

1. 값이 32,767에서 갑자기 음수로 튀는 경우

가장 흔한 케이스입니다. 카운터나 위치 값을 D메모리 하나(16비트)에 담으려 할 때 발생합니다.

※ D, W, R, Z 같은 워드 디바이스 구조 자체가 헷갈린다면 아래 글부터 먼저 보세요.

👉 [실무] D·W·R·Z 데이터 구조와 용도 제대로 이해하기

현상: 32,767까지 잘 올라가다가 1만 더해지면 갑자기 -32,768이 됩니다.
원인: 16비트 정수는 표현할 수 있는 범위가 제한되어 있기 때문입니다. PLC가 데이터를 어떻게 해석하느냐에 따라 결과가 달라집니다.
- 부호 있는 정수(Signed): 범위가 -32,768 ~ 32,767입니다. 최대치인 32,767을 넘기는 순간 음수 영역인 -32,768로 튀어버립니다. (가장 일반적인 케이스)
- 부호 없는 정수(Unsigned): 범위가 0 ~ 65,535입니다. 이 경우 65,535에서 1을 더하면 음수가 아니라 0으로 다시 돌아갑니다. (오버플로우)
해결: 숫자가 해당 범위를 넘을 것 같다면 명령어와 연산자 앞에 ‘D’를 붙여 32비트(Double Word)로 처리하십시오.
- (예) + → D+, MOV → DMOV 등 연산/비교 명령어를 모두 32비트용으로 맞춰야 합니다.

2. 32비트 명령어 사용 시 옆집 데이터가 깨지는 경우

32비트 명령어를 쓰면서 주소 할당을 16비트처럼 촘촘하게 했을 때 터지는 사고입니다.

현상: D10에 값을 넣었는데, 아무 상관 없는 D11 값이 같이 변하거나 0이 됩니다.
원인: 32비트 명령어는 지정한 번호와 그다음 번호(D+1)를 세트로 점유합니다. D10을 쓰는 순간 D11은 자동으로 ‘사용 중’이 됩니다.
해결: 32비트 데이터를 설계할 때는 주소가 중복되지 않도록 D10, D12, D14… 처럼 짝수 단위로 간격을 두고 사용하는 것이 실무적인 정석입니다.

3. 같은 데이터인데 값이 다르게 보이는 경우 (시작 주소 기준)

데이터는 정상인데 ‘보는 기준점’이 틀린 경우입니다. 이거 모르면 멀쩡한 로직 하루 종일 수정하게 됩니다.

현상: D10부터 보면 정상인데, D11부터 보면 전혀 엉뚱한 숫자로 보입니다.
원인: 32비트 데이터는 시작 주소 기준으로 2워드를 묶어서 해석합니다.
- D10을 기준으로 만든 데이터를 D11부터 보면, 옆에 있는 다른 워드와 다시 조합되면서 값이 완전히 달라집니다.
해결: 32비트 데이터를 모니터링할 때는 반드시 설계 시 지정한 시작 주소(시작 워드)를 기준으로 확인해야 합니다.

[현장 증명] 아래 예시를 보면 같은 데이터를 보고 있음에도 불구하고, 시작 주소를 D10으로 볼 때와 D11로 볼 때 값이 완전히 다르게 해석되는 것을 확인할 수 있습니다.

GX Works D메모리 모니터링 화면에서 D10과 D11 시작 주소에 따라 동일한 32비트 데이터가 다르게 해석되는 예시 — [Fig. 1] D10 기준 vs D11 기준: 같은 데이터, 완전히 다른 값으로 해석됨

4. 곱셈 연산 시 데이터가 연쇄적으로 깨지는 경우

32비트 데이터끼리 곱셈을 수행하면 결과가 64비트(4워드)로 확장된다는 점을 주의해야 합니다.

현상: 특정 D메모리 계산만 했는데, 옆집을 넘어 뒷집(D+2, D+3)까지 데이터가 날아갑니다.
원인: GX Works에서 더블워드 기준 곱셈 연산 등을 사용하면 결과 저장 영역이 총 4워드를 점유하게 됩니다. 만약 결과 주소를 D10으로 지정했다면, 실제로는 D10~D13까지 모두 사용합니다.

[현장 증명] 아래처럼 32비트 데이터에 곱셈을 수행하면 결과는 D10부터 저장되지만, 실제로는 뒤쪽 워드까지 함께 점유하게 됩니다. 이 상태에서 뒤쪽 주소를 다른 용도로 사용하면 연산 결과가 데이터를 덮어쓰며 값이 깨집니다. 곱셈은 “결과가 커진다”가 아니라, “메모리를 더 먹는다”로 이해해야 합니다.

미쓰비시 PLC GX Works에서 32비트 곱셈 연산 시 결과가 D10부터 D13까지 4워드를 점유하는 메모리 구조 예시 — [Fig. 2] 32비트 곱셈 결과는 D10 하나가 아니라 D10~D13까지 4워드를 점유한다

같은 데이터 이동 명령어라도 점유 범위가 다릅니다. MOV, BMOV, FMOV 차이는 아래 글에서 정리했습니다.

👉 [실무] MOV·BMOV·FMOV로 래더 줄이는 방법

5. 숫자가 이상하게 보일 때 (Display Format 설정)

모니터링하다 보면 값은 멀쩡한데 화면에서만 이상하게 보일 때가 있습니다.
GX Works에서는 음수로 보이는데, HMI 에서는 정상 값으로 표시되는 경우도 있습니다.

이럴 때 PLC 고장이나 연산 오류부터 의심하면 시간을 많이 쓰게 됩니다.
실제 원인은 데이터가 아니라 표시 방식(Display Format)인 경우가 많습니다.

현상: 숫자가 H00A1처럼 16진수로 보이거나, 알아볼 수 없는 문자로 깨져 보입니다.
해결: GX Works 하단 모니터링 창이나 Device Test 화면에서 Display Format을 확인하십시오.

[현장 증명] 아래처럼 동일한 D메모리 데이터라도 Display Format 설정에 따라 전혀 다른 값으로 보일 수 있습니다. 16비트 기준으로 음수(-)로 보이던 데이터가 32비트로 변경하면 정상적인 정수 값으로 해석됩니다. 즉, 데이터가 잘못된 것이 아니라 ‘어떤 기준으로 보느냐’의 문제입니다.

미쓰비시 PLC GX Works에서 Display Format 설정에 따라 동일한 D메모리 값이 음수 또는 정상 정수로 다르게 표시되는 예시 — [Fig. 3] Display Format에 따라 같은 데이터도 음수 또는 정상 값으로 완전히 다르게 보인다

💡 GX Works 데이터 체크리스트

데이터가 이상하면 PLC 고장부터 의심하지 말고, 아래 5가지를 먼저 확인하십시오.

[ ] 데이터 범위 확인: 사용하는 값이 16비트 한계(32,767 또는 65,535)를 넘는가?
[ ] 주소 중복 확인: 32비트 사용 시 D11(D+1)을 비워두었는가?
[ ] 모니터링 기준 주소: 32비트 데이터를 정확한 시작 주소(D10 등)에서 보고 있는가?
[ ] 곱셈 결과 점유: 32비트 곱셈 시 결과값이 4워드(D10~D13)를 침범하지 않았는가?
[ ] Display Format: 모니터링 형식이 데이터 타입(Signed/Unsigned/32bit 등)에 맞는가?

결론: 바구니의 크기와 위치를 아는 것이 실력입니다

데이터가 깨지는 건 대부분 엔지니어의 ‘바구니 계산’ 실수입니다. 내가 쓰는 데이터가 몇 칸을 먹는지, 그리고 어디서부터 읽어야 하는지만 정확히 알아도 트러블슈팅 시간의 80%는 줄어듭니다.

이제 D메모리 같은 ‘숫자 바구니’ 외에, PLC 내부에서 쓰이는 다양한 ‘보직’들을 한꺼번에 정리해 볼 차례입니다. 어떤 디바이스(M, D, X, Y 등)에 저장하느냐에 따라 역할과 동작 방식이 완전히 달라지기 때문입니다.

[다음 포스팅 예고]
PLC 로직의 기본은 ON/OFF 신호를 다루는 비트 디바이스입니다.
X, Y, M, L, B는 각각 쓰임새가 달라, 정확히 구분해서 써야 합니다.

다음 글에서는 현장에서 가장 많이 쓰는
X·Y·M·L·B 비트 디바이스의 역할과 차이를
실무 기준으로 정리합니다.

👉 [실무] X·Y·M·L·B 트러블 없이 구분하는핵심 기준