PLC & Industrial Automation Field Notes

미쓰비시 PLC에서 D메모리 값이 갑자기 음수로 보이거나, 옆 주소의 값까지 같이 변하는 경우가 있습니다. 이런 현상은 PLC 고장보다 데이터 크기, 주소 점유 범위, 표시 형식이 맞지 않아서 발생하는 경우가 많습니다.

GX Works로 모니터링을 하다 보면 분명히 양수 값을 넣었는데 값이 음수로 바뀌거나, 건드리지 않은 D메모리 값이 함께 변하는 경우가 있습니다. 처음 보면 프로그램이 이상해 보이지만, 실제로는 데이터 해석 기준을 잘못 잡은 경우가 많습니다.

D메모리는 숫자를 저장하는 워드 디바이스입니다. 하지만 D 하나가 항상 모든 숫자를 안전하게 담는 것은 아닙니다. 16비트로 볼 것인지, 32비트로 볼 것인지, 부호 있는 값으로 볼 것인지, 부호 없는 값으로 볼 것인지에 따라 같은 데이터도 다르게 보입니다.

이 글에서는 미쓰비시 PLC D메모리에서 값이 깨지거나 음수로 튀는 대표적인 원인을 GX Works 기준으로 정리합니다.

D메모리는 16비트 워드 단위다

미쓰비시 PLC에서 D메모리는 기본적으로 16비트 워드 단위로 사용됩니다. D10 하나는 16비트 데이터를 저장할 수 있는 공간입니다.

16비트 데이터는 저장할 수 있는 범위가 제한되어 있습니다. 부호 있는 정수로 보면 -32768부터 32767까지 표현할 수 있고, 부호 없는 정수로 보면 0부터 65535까지 표현할 수 있습니다.

문제는 같은 D10 값을 어떤 형식으로 해석하느냐에 따라 화면에 보이는 숫자가 달라진다는 점입니다. PLC 내부 데이터는 같아도 GX Works에서 표시 형식을 다르게 보면 전혀 다른 값처럼 보일 수 있습니다.

그래서 D메모리를 사용할 때는 단순히 주소만 볼 것이 아니라 데이터 크기와 해석 방식을 함께 봐야 합니다.

32767을 넘으면 음수로 보일 수 있다

가장 흔한 현상은 값이 32767까지 올라가다가 그다음 값에서 -32768처럼 음수로 보이는 경우입니다.

이 현상은 16비트 부호 있는 정수 범위를 넘었을 때 발생합니다. 16비트 Signed 기준에서는 32767이 최대 양수이고, 이 범위를 넘으면 음수 영역으로 넘어가 보입니다.

예를 들어 카운터 값이나 위치 값이 계속 증가하는데 D 하나만 사용하면 32767 이후부터 값이 이상하게 보일 수 있습니다. 실제 데이터가 사라진 것이 아니라 16비트 기준으로 해석 가능한 범위를 넘은 것입니다.

값이 32767을 넘을 가능성이 있다면 16비트 명령이 아니라 32비트 명령을 사용해야 합니다.

16비트와 32비트 명령어를 구분해야 한다

미쓰비시 PLC에서는 일반 명령과 32비트 명령을 구분해서 사용해야 합니다. 16비트 명령어로 큰 값을 처리하면 범위 초과나 값 깨짐이 발생할 수 있습니다.

예를 들어 MOV는 16비트 데이터를 이동하는 명령이고, DMOV는 32비트 데이터를 이동하는 명령입니다. 덧셈도 +와 D+처럼 데이터 크기에 따라 명령을 구분해야 합니다.

중요한 점은 데이터 저장만 32비트로 한다고 끝나는 것이 아니라는 점입니다. 이동, 비교, 사칙연산, 표시 형식까지 모두 같은 기준으로 맞아야 합니다.

한쪽에서는 32비트로 저장하고 다른 곳에서는 16비트로 비교하면 값이 맞지 않거나 조건이 엉뚱하게 동작할 수 있습니다.

32비트 데이터는 D 두 개를 사용한다

32비트 데이터를 사용할 때 가장 많이 하는 실수가 주소 점유 범위를 놓치는 것입니다. 32비트 데이터는 D 하나만 쓰는 것이 아니라 연속된 D 두 개를 사용합니다.

예를 들어 D10을 시작 주소로 32비트 데이터를 저장하면 실제로는 D10과 D11을 함께 사용합니다. 이때 D11을 다른 용도로 사용하면 데이터가 서로 겹치게 됩니다.

그래서 D10에 값을 넣었는데 D11 값이 같이 바뀌거나, D11에 다른 값을 넣었더니 D10의 32비트 값이 깨지는 현상이 발생합니다.

32비트 데이터를 사용할 때는 D10, D12, D14처럼 주소를 한 칸씩 띄워서 잡는 것이 관리하기 쉽습니다. 핵심은 시작 주소와 점유 범위를 명확히 관리하는 것입니다.

옆 D메모리 값이 바뀌는 이유

D10에만 값을 넣었다고 생각했는데 D11이 같이 변한다면 32비트 명령어 사용 여부를 확인해야 합니다. DMOV, D+, D-, D*, DDIV 같은 32비트 계열 명령은 지정한 주소와 다음 주소를 함께 사용합니다.

예를 들어 DMOV K100000 D10을 실행하면 D10 하나에만 값이 들어가는 것이 아니라 D10과 D11이 하나의 32비트 데이터로 사용됩니다.

이 상태에서 D11을 다른 용도로 사용하면 32비트 데이터의 상위 워드 또는 하위 워드를 덮어쓰게 됩니다. 그러면 D10 기준으로 보던 값도 갑자기 깨집니다.

D메모리 값이 갑자기 이상해졌다면 Cross Reference로 해당 D주소와 그 다음 주소가 어디서 사용되는지 함께 확인해야 합니다.

시작 주소가 틀리면 값이 다르게 보인다

32비트 데이터는 시작 주소가 중요합니다. D10과 D11을 묶어서 만든 값을 D10 기준으로 보면 정상일 수 있지만, D11 기준으로 보면 전혀 다른 값으로 해석될 수 있습니다.

D10 기준 32비트 값은 D10과 D11을 한 세트로 봅니다. 그런데 D11 기준으로 모니터링하면 D11과 D12를 한 세트로 다시 묶어서 해석합니다.

이 경우 D12가 다른 데이터라면 D11 기준 값은 완전히 엉뚱하게 보입니다. 실제 데이터가 바뀐 것이 아니라 보는 기준점이 달라진 것입니다.

32비트 데이터를 모니터링할 때는 반드시 설계한 시작 주소를 기준으로 확인해야 합니다. D10부터 쓰기로 했다면 D10 기준으로 봐야 하고, D11부터 보면 안 됩니다.

32비트 곱셈은 결과 영역을 더 크게 사용한다

곱셈 연산은 특히 주의해야 합니다. 32비트 데이터끼리 곱셈을 하면 결과가 더 커질 수 있고, 결과 저장 영역도 더 많은 워드를 사용할 수 있습니다.

일부 더블워드 곱셈 명령은 결과 저장 영역으로 4워드를 사용할 수 있습니다. 예를 들어 결과 시작 주소를 D10으로 지정했다면 D10부터 D13까지 사용되는 구조가 될 수 있습니다.

이 점을 모르고 D12나 D13을 다른 용도로 사용하면 곱셈 결과가 다른 데이터를 덮어쓰거나, 반대로 다른 데이터가 곱셈 결과를 깨뜨릴 수 있습니다.

곱셈은 단순히 값이 커지는 문제가 아니라 메모리 점유 범위가 넓어지는 문제로 봐야 합니다. 연산 결과가 몇 워드를 사용하는지 반드시 확인해야 합니다.

Display Format 때문에 값이 이상하게 보일 수 있다

GX Works에서 값이 이상하게 보일 때 실제 데이터가 틀린 것이 아니라 표시 형식이 맞지 않는 경우도 있습니다.

같은 D메모리라도 10진수, 16진수, Signed, Unsigned, 32비트 표시 기준에 따라 화면에 보이는 값이 달라질 수 있습니다.

예를 들어 H8000이라는 값은 16진수로 보면 단순한 비트 패턴입니다. 하지만 16비트 Signed로 보면 -32768로 해석될 수 있습니다. Unsigned로 보면 32768로 볼 수도 있습니다.

HMI에서는 정상으로 보이는데 GX Works에서는 음수로 보인다면 Display Format을 먼저 확인해야 합니다. 데이터가 틀린 것이 아니라 표시 기준이 다른 것일 수 있습니다.

HMI와 PLC 모니터 값이 다르게 보이는 이유

HMI와 GX Works에서 같은 주소를 보고 있는데 값이 다르게 보이는 경우도 있습니다. 이때는 HMI 태그 설정과 PLC 모니터 표시 형식을 비교해야 합니다.

HMI에서는 해당 주소를 Unsigned 32bit로 보고 있는데 GX Works에서는 Signed 16bit로 보면 값이 다르게 나옵니다.

또는 HMI는 D10부터 32비트로 읽고 있는데 GX Works에서는 D11부터 32비트로 보고 있다면 완전히 다른 값이 표시됩니다.

통신 문제가 아닌데 값이 다르게 보인다면 데이터 타입, 시작 주소, 워드 순서, 표시 형식을 먼저 확인해야 합니다.

16비트와 32비트 혼용 시 주의할 점

프로그램 안에서 16비트 명령과 32비트 명령을 섞어 쓰면 값 깨짐이 발생하기 쉽습니다. 저장은 DMOV로 해놓고 비교는 16비트 비교로 하면 조건 판단이 틀어질 수 있습니다.

예를 들어 위치값, 누적 카운트, 생산 수량, 거리값처럼 큰 숫자가 들어갈 수 있는 데이터는 처음부터 32비트 기준으로 설계하는 것이 좋습니다.

반대로 작은 설정값이나 ON/OFF 상태를 숫자로 저장하는 정도라면 16비트로 충분할 수 있습니다. 모든 데이터를 32비트로 만들 필요는 없습니다.

중요한 것은 데이터 성격에 맞는 크기를 정하고, 해당 데이터에 접근하는 모든 명령어와 표시 형식을 같은 기준으로 맞추는 것입니다.

D메모리 주소 설계 기준

D메모리를 사용할 때는 주소표를 만들어 관리하는 것이 좋습니다. 특히 32비트 데이터는 시작 주소와 점유 주소를 함께 기록해야 합니다.

예를 들어 D100부터 D101까지는 현재 위치, D102부터 D103까지는 목표 위치처럼 2워드 단위로 배치하면 중복을 줄일 수 있습니다.

32비트 데이터 사이에 16비트 데이터를 섞어 넣으면 나중에 유지보수가 어려워질 수 있습니다. 가능하면 16비트 영역과 32비트 영역을 구분해두는 것이 좋습니다.

데이터가 깨지는 문제는 로직 오류보다 주소 관리 오류에서 발생하는 경우가 많습니다. D메모리는 값 자체보다 점유 범위 관리가 중요합니다.

GX Works에서 확인할 항목

D메모리 값이 이상할 때는 PLC 고장부터 의심하지 말고 GX Works에서 기본 항목부터 확인해야 합니다.

먼저 해당 데이터가 16비트인지 32비트인지 확인합니다. 값이 32767을 넘는다면 16비트 Signed 기준으로는 정상 표시가 어렵습니다.

다음으로 해당 주소와 다음 주소가 어디서 사용되는지 확인합니다. 32비트 데이터라면 D+1 주소까지 같은 데이터 영역으로 봐야 합니다.

그다음 Display Format을 확인합니다. Signed, Unsigned, Hex, Decimal, 32bit 표시 기준이 맞는지 확인해야 합니다.

확인 항목	점검 기준
데이터 범위	32767 또는 65535를 넘는지 확인
데이터 크기	16비트인지 32비트인지 확인
주소 점유	32비트 사용 시 D와 D+1 사용 확인
시작 주소	설계한 시작 주소 기준으로 모니터링
곱셈 결과	결과 저장 영역이 몇 워드인지 확인
표시 형식	Signed, Unsigned, Hex, Decimal 확인
중복 사용	Cross Reference로 주소 중복 확인

D메모리 트러블 점검 순서

D메모리 값이 깨지거나 음수로 보이면 먼저 값의 범위를 확인합니다. 16비트 Signed 범위를 넘는 값이라면 음수로 보이는 것이 이상 현상이 아닐 수 있습니다.

두 번째로 명령어를 확인합니다. MOV, +, -, 비교 명령을 사용했는지, DMOV, D+, D-, 32비트 비교 명령을 사용했는지 확인해야 합니다.

세 번째로 주소 점유 범위를 확인합니다. 32비트 데이터는 D와 D+1을 함께 사용하고, 곱셈 결과는 더 넓은 영역을 사용할 수 있습니다.

네 번째로 GX Works의 Display Format을 확인합니다. 데이터가 실제로 깨진 것인지, 화면에서 다르게 해석하고 있는지 구분해야 합니다.

순서	확인 내용	판단 기준
1	값 범위	16비트 한계 초과 여부
2	명령어	16비트와 32비트 명령 혼용 여부
3	주소 범위	D+1 또는 결과 영역 침범 여부
4	시작 주소	32비트 데이터 시작 주소 일치 여부
5	표시 형식	Signed, Unsigned, 32bit 설정 확인
6	중복 사용	다른 로직에서 같은 D주소 사용 여부

미쓰비시 PLC D메모리 값 깨짐 정리

미쓰비시 PLC에서 D메모리 값이 음수로 튀거나 옆 주소까지 같이 변하는 것은 대부분 데이터 크기와 주소 점유 범위를 잘못 이해해서 발생합니다.

D메모리 하나는 기본적으로 16비트 워드입니다. 32767을 넘는 값을 Signed 16비트로 보면 음수처럼 표시될 수 있습니다. 더 큰 값을 안정적으로 사용하려면 32비트 명령과 32비트 표시 기준을 함께 적용해야 합니다.

32비트 데이터는 D와 D+1을 함께 사용합니다. D10을 시작 주소로 사용했다면 D11은 같은 데이터의 일부입니다. D11을 별도로 사용하면 값이 깨질 수 있습니다.

곱셈 같은 연산은 결과 영역이 더 커질 수 있으므로 저장 주소 범위를 반드시 확인해야 합니다. GX Works에서 값이 이상하게 보일 때는 Display Format도 함께 확인해야 합니다.

D메모리 문제는 결국 데이터가 몇 비트인지, 몇 워드를 점유하는지, 어디서부터 읽는지를 확인하는 문제입니다. 이 기준을 잡아두면 값 깨짐과 음수 표시 문제를 훨씬 빠르게 해결할 수 있습니다.