RS-485 통신 장애를 현장에서 추적하는 방법

RS-485 통신 장애를 현장에서 추적하는 방법#

1장 먼저 증상을 세 가지로 나눈다#

현장에서:

RS-485 통신이 안 됩니다.

라는 말을 들었다면 곧바로 Cable이나 Controller를 교체해서는 안 됩니다.

먼저 증상을 구분합니다.

1. 통신이 전혀 되지 않는다.

2. 가끔 되다가 끊긴다.

3. 데이터는 들어오지만 깨진다.

이 세 가지는 서로 다른 원인을 가질 가능성이 높습니다.

1.1 완전히 무응답#

대표적인 원인 후보:

전원 불량

Cable 단선

A/B 배선 오류

잘못된 Interface

Baud Rate 불일치

Driver Enable 문제

Address 오류

입니다.

1.2 간헐적으로 끊긴다#

대표적인 원인 후보:

Connector 접촉 불량

Cable 손상

Noise

Ground Potential Difference

Termination

긴 Stub

Bus Collision

등입니다.

1.3 데이터가 깨진다#

대표적으로:

Baud Rate

Parity

Stop Bits

A/B Polarity

Reflection

Noise

Collision

을 확인합니다.

즉 증상부터 정확히 분류해야 진단 방향이 잡힙니다.

2장 첫 번째는 Software가 아니라 전원이다#

통신 장애를 만나면 Application Log부터 보기 쉽습니다.

하지만 장비가 정상적으로 동작하지 않는다면 통신 분석 자체가 의미가 없습니다.

먼저 확인합니다.

전원 LED

입력 전압

전원 Connector

Fuse

Power Supply 상태

2.1 LED가 켜져 있다고 모든 전원이 정상인 것은 아니다#

전원 LED가 들어왔다고 해서 내부 전압까지 완전히 정상이라는 뜻은 아닙니다.

예:

Controller Power
24V 정상

내부 5V Rail
불안정

이라면 CPU는 부분적으로 동작하면서 RS-485 Transceiver만 오작동할 수도 있습니다.

필요하다면 제조사의 측정 절차에 따라 전원 상태를 확인합니다.

3장 Interface부터 다시 확인한다#

두 장비 모두 DB9나 Terminal Block을 사용한다고 해서 동일한 Interface라는 보장은 없습니다.

확인:

RS-232?

RS-422?

RS-485?

2-Wire?

4-Wire?

TTL UART?

입니다.

예를 들어:

RS-232
↔
RS-485

를 직접 연결하면 정상적으로 통신할 수 없습니다.

4장 A/B 배선을 확인한다#

2-Wire RS-485에서는 일반적으로 하나의 Differential Pair를 사용합니다.

A
B

그러나 제조사마다 다음과 같은 Label을 사용할 수 있습니다.

A / B

D+ / D-

485+ / 485-

+ / -

따라서 단순히:

A ↔ A
B ↔ B

만 확인해서는 충분하지 않을 수 있습니다.

양쪽 장비의 Electrical Signal Definition을 확인해야 합니다.

5장 특정 장비만 안 된다면 Local Wiring부터 본다#

다음과 같은 Bus가 있다고 하겠습니다.

Master
 │
 ├─ Device 1 정상
 ├─ Device 2 정상
 ├─ Device 3 장애
 └─ Device 4 정상

이 경우 전체 RS-485 Bus가 완전히 고장났을 가능성은 낮아집니다.

먼저 Device 3의:

전원

A/B

Connector

Address

Baud

Termination

Local Cable

을 확인합니다.

6장 특정 지점 이후 장비가 모두 안 된다면#

다음과 같은 증상:

Master
↓
Device 1 정상
↓
Device 2 정상
↓
Junction
↓
Device 3 장애
↓
Device 4 장애

가 나타난다면 Junction 이후의:

Cable 단선

Pair 반전

Connector 불량

Short

Ground 문제

를 의심할 수 있습니다.

장애가 어느 지점부터 시작되는가는 매우 중요한 단서입니다.

7장 Cable 연속성을 확인한다#

전원을 차단하고 안전 절차를 따른 상태에서 Multimeter나 Cable Tester를 이용하면 다음을 확인할 수 있습니다.

단선

Short

A/B Pair 추적

Connector 연결

중간 Junction

특히 여러 Junction Box를 통과하는 장거리 Bus에서는:

A가 중간에서 B로 바뀌었는가?

다른 Pair와 섞였는가?

까지 확인해야 합니다.

8장 Daisy Chain인지 Star인지 확인한다#

일반적인 RS-485 Bus는 다음과 같은 Linear Topology가 유리합니다.

Master ─ Device 1 ─ Device 2 ─ Device 3

반면:

              Device 1
                 │
Device 2 ─── Junction ─── Device 3
                 │
              Device 4

처럼 긴 Branch가 여러 개 존재하면 Reflection이 복잡해질 수 있습니다.

따라서 장애가 반복된다면 Logical Diagram이 아니라 실제 Cable Route를 확인해야 합니다.

9장 Stub 길이도 확인한다#

Main Bus에서 Device까지 갈라지는 짧은 Branch를 Stub라고 합니다.

Main Bus ========================

                  │
                  │ Stub
                  │
               Device

Stub가 길어질수록 Signal Reflection 문제가 커질 수 있습니다.

특히:

Baud Rate가 높음

Cable이 김

Branch가 많음

조건에서는 영향을 더 크게 받을 수 있습니다.

10장 종단저항을 확인한다#

RS-485 Bus의 Communication Error에서 매우 중요한 점검 항목입니다.

일반적인 Linear Bus에서는 물리적인 양 끝에 Termination을 두는 구성이 흔합니다.

120Ω                                 120Ω
 │                                     │
Device ─ Device ─ Device ─ Device ─ Device

하지만 실제 저항값은 Cable과 장비 제조사 권장사항을 확인합니다.

10.1 종단저항이 없는 경우#

다음 증상이 나타날 수 있습니다.

장거리에서 오류

Baud를 높이면 CRC Error

간헐적 Frame Error

특정 Node에서만 불안정

Reflection이 원인 중 하나일 수 있습니다.

10.2 종단저항이 너무 많은 경우#

모든 장비의 내장 Termination이 활성화되어 있다고 하겠습니다.

Device 1 120Ω

Device 2 120Ω

Device 3 120Ω

Device 4 120Ω

Bus Load가 과도하게 커질 수 있습니다.

결과:

Differential Voltage 감소

Driver 부담 증가

통신 불안정

이 발생할 수 있습니다.

11장 장비 내부 Termination도 반드시 확인한다#

산업 장비에는 다음 설정이 있을 수 있습니다.

TERM ON

TERM OFF

또는:

120Ω Enable

DIP Switch나 Jumper로 설정하는 경우도 있습니다.

따라서 외부 저항만 보고:

종단이 없다.

고 판단하면 안 됩니다.

12장 Bias 상태를 확인한다#

모든 Driver가 High Impedance 상태일 때 Bus가 안정적인 Idle 상태를 유지해야 합니다.

이를 위해 Bias Network를 사용하는 시스템이 있습니다.

대표적으로:

Pull-up

Pull-down

을 이용합니다.

12.1 Bias가 없으면 어떤 증상이 나타날까#

특히 Bus가 Idle일 때:

Random Byte

Framing Error

의미 없는 데이터

간헐적 수신

등이 발생할 수 있습니다.

이 경우:

Bias

Receiver Fail-Safe

Noise

를 확인합니다.

12.2 Bias가 너무 많아도 문제다#

여러 장비가 모두 Bias를 제공하면 전체 Bus의 Electrical Load가 변합니다.

따라서:

Master Bias

Device Bias

Converter Bias

가 동시에 활성화되어 있지 않은지 확인합니다.

13장 60Ω이 보이면 무조건 정상일까#

Bus 양 끝에 각각 약 120Ω Termination이 있고 다른 영향이 없다면 전원을 끈 상태에서 특정 측정 위치의 A-B Resistance가 약:

60Ω

부근으로 나타날 수 있습니다.

두 개의 120Ω이 병렬이기 때문입니다.

하지만 실제 Bus에는:

Bias

Receiver Input

내부 회로

다른 Termination

가 존재할 수 있습니다.

따라서:

60Ω = 무조건 정상

이라는 공식으로 사용해서는 안 됩니다.

참고값으로만 활용합니다.

14장 Baud Rate를 확인한다#

배선이 완벽해도 Serial Setting이 다르면 통신하지 않습니다.

예:

Master
19200-8-N-1

Device
9600-8-N-1

라면 정상적인 Byte 해석이 어렵습니다.

확인 항목:

Baud Rate

Data Bits

Parity

Stop Bits

입니다.

15장 데이터가 깨질 때 가장 먼저 볼 항목#

Terminal이나 Serial Analyzer에서 다음처럼 보인다고 하겠습니다.

▒?A▒▒

먼저 확인합니다.

Baud Rate

Data Bits

Parity

Stop Bits

A/B Polarity

이 항목들이 정상이라면 다음으로:

Noise

Reflection

Collision

을 살펴봅니다.

16장 CRC Error는 원인이 아니라 결과일 수 있다#

상위 Protocol:

Address
Command
Data
CRC

가 있다고 하겠습니다.

Cable Noise 때문에 한 Bit가 바뀝니다.

송신
0x35

수신
0x34

그러면 CRC가 맞지 않는 것은 당연합니다.

따라서:

CRC ERROR

를 보고 바로 CRC Algorithm을 의심하면 안 됩니다.

먼저:

Physical Signal
↓
UART
↓
Byte
↓
Frame
↓
CRC

순으로 확인합니다.

17장 Address를 확인한다#

RS-485 자체에는 Device Address가 없습니다.

Address는 Modbus RTU 또는 제조사 Protocol 같은 상위 Protocol이 정의합니다.

여러 Device가 있는 Bus에서는 Address 중복을 확인해야 합니다.

예:

Device A
Address 5

Device B
Address 5

이면 Master가 Address 5에 요청할 때 두 장비가 동시에 응답할 수 있습니다.

18장 Address 충돌은 어떤 증상을 만들까#

대표적으로:

가끔 정상

가끔 CRC Error

응답이 섞임

Timeout

특정 Address만 불안정

등입니다.

두 장비의 Response Timing이 완전히 같지 않으면 증상이 매번 다르게 나타날 수도 있습니다.

그래서 상당히 까다로운 장애가 됩니다.

19장 Address 충돌을 어떻게 찾을까#

가능한 방법 중 하나는 Bus를 Segment별로 분리해 장비를 하나씩 확인하는 것입니다.

예:

Master + Device 1
확인

Master + Device 1 + Device 2
확인

Device 추가
확인

또는 장비 설정 메뉴와 DIP Switch를 비교합니다.

운영 시스템에서는 Bus를 임의로 분리하기 전에 반드시 운영 영향과 안전 절차를 확인해야 합니다.

20장 Driver Enable Timing을 확인한다#

2-Wire RS-485에서는 송신 시 Driver를 활성화하고 송신 후 다시 해제해야 합니다.

Receive
↓
Driver ON
↓
Transmit
↓
TX Complete
↓
Driver OFF
↓
Receive

이 Timing이 잘못되면 통신 장애가 발생할 수 있습니다.

20.1 너무 빨리 Driver를 끄는 경우#

마지막 Byte가 아직 Wire에 나가는 중인데 Driver를 Disable하면:

마지막 Bit 손실

Stop Bit 손상

CRC Error

가 발생할 수 있습니다.

20.2 너무 늦게 Driver를 끄는 경우#

Slave가 Response를 시작해야 하는데 Master가 계속 Bus를 Drive하고 있다면 두 Transceiver가 충돌할 수 있습니다.

증상:

응답 앞부분 손상

CRC Error

Timeout

등입니다.

21장 USB-to-RS485 Adapter도 확인한다#

최근 현장에서는 PC에 직접 RS-485 Port가 없는 경우가 많습니다.

구조:

Application
↓
USB Driver
↓
USB-to-RS485 Adapter
↓
A/B
↓
Device

따라서 확인 대상에:

USB Driver

COM Port

Adapter 전원

Auto Direction

Isolation

Termination

Bias

도 포함됩니다.

22장 Converter 교체 후 장애가 생겼다면#

기존 Converter:

Auto Direction

Bias 없음

신규 Converter:

Auto Direction

Bias 내장

Termination ON

일 수도 있습니다.

Cable은 그대로인데 Converter 하나 바꾼 뒤 전체 Bus가 불안정해지는 이유가 될 수 있습니다.

따라서 Converter Spec도 전체 시스템의 일부입니다.

23장 Noise가 의심될 때는 시간 패턴을 본다#

예:

낮
정상

18:00 이후
CRC Error 증가

또는:

Motor OFF
정상

Motor ON
통신 장애

같은 패턴이 있다면 주변 Electrical Equipment와 상관관계를 확인합니다.

24장 어떤 장비가 Noise를 만들 수 있을까#

대표적으로:

Motor

Inverter

Relay

Contactor

LED Power Supply

SMPS

대전류 Cable

등이 있습니다.

단순히 장비 근처에 있다는 이유만으로 범인이라고 단정하지 말고 장애 시간과 실제 Waveform을 비교합니다.

25장 Cable Route를 확인한다#

통신 Cable이 다음과 같이 장거리로 Power Cable과 나란히 간다고 하겠습니다.

Power Cable ==================

RS-485      ==================

환경에 따라 Noise Coupling이 증가할 수 있습니다.

현장 Cable Route와 배선 규정을 확인하고 적절한 Separation과 EMC 지침을 따릅니다.

26장 Ground Potential Difference를 확인한다#

RS-485가 Differential 방식이라고 Ground 문제에서 완전히 자유로운 것은 아닙니다.

장거리에서는 두 장비의 Ground Potential이 달라질 수 있습니다.

Controller Ground
0V

Remote Ground
+8V

같은 차이가 발생할 수 있습니다.

Receiver에는 허용 가능한 Common-Mode Voltage 범위가 있으므로 이를 벗어나면 통신 불량이나 장비 손상이 발생할 수 있습니다.

27장 절연형 RS-485를 고려할 상황#

다음과 같은 환경에서는 Isolated RS-485를 검토할 수 있습니다.

서로 다른 건물

긴 실외 Cable

Ground Potential Difference

Motor·Inverter 환경

Surge 위험

구조:

Controller
↓
Isolation
↓
RS-485 Bus
↓
Isolation
↓
Remote Device

절연은 Ground Loop와 일부 Surge 영향을 줄이는 데 도움이 될 수 있습니다.

28장 Shield를 무조건 한쪽만 연결하지 않는다#

현장에서는:

Shield는 무조건 한쪽 접지

라는 규칙을 쉽게 듣습니다.

하지만 적절한 Shield 처리 방식은:

EMC 환경

Cable 구조

Bonding

Grounding System

주파수

장비 제조사 지침

에 따라 달라집니다.

따라서 기존 Shield를 임의로 끊거나 연결하지 않습니다.

29장 간헐적 장애는 Connector도 의심한다#

Cable 자체뿐 아니라:

Terminal Block

Screw

Crimp

Connector Pin

납땜

중간 Splice

의 접촉 불량이 간헐 장애를 만들 수 있습니다.

특히 진동·온도 변화가 있는 환경에서는 시간이 지나면서 증상이 달라질 수 있습니다.

30장 온도나 습도와 장애의 관계도 기록한다#

다음과 같은 패턴:

낮에는 정상

새벽에 오류

비 오는 날 오류

겨울에만 장애

가 있다면:

Connector 부식

수분 유입

Cable 절연

온도에 따른 접촉 변화

전원 상태

등을 함께 확인합니다.

현장 장애는 통신 Protocol만의 문제가 아닐 수 있습니다.

31장 Multimeter는 어디에 사용할까#

Multimeter는 다음 항목에 유용합니다.

전원

Cable 연속성

Short

A/B DC 상태

저항

Ground Potential Difference

하지만 빠르게 움직이는 RS-485 Data Signal을 Multimeter만으로 분석하는 데는 한계가 있습니다.

32장 Oscilloscope는 무엇을 보여줄까#

Oscilloscope를 사용하면:

A Waveform

B Waveform

Differential Voltage

Common-Mode Voltage

Noise

Ringing

Reflection

Driver Release Timing

을 관찰할 수 있습니다.

간헐적인 Physical Layer 장애를 찾는 데 매우 유용합니다.

33장 Logic Analyzer는 어디에 유용할까#

RS-485 Transceiver 뒤쪽의 TTL/UART Logic Signal을 볼 수 있다면 Logic Analyzer로:

UART Byte

Baud

Frame

Timing

을 확인할 수 있습니다.

하지만 A/B Line 자체의:

Differential Amplitude

Common-Mode

Reflection

문제는 충분히 볼 수 없습니다.

34장 Serial Analyzer는 무엇을 보여줄까#

적절한 Serial Analyzer를 사용하면 실제 Byte Stream을 확인할 수 있습니다.

예:

TX
01 03 00 00 00 02 C4 0B

RX
01 03 04 ...

이를 통해:

실제로 요청이 나가는가?

응답이 있는가?

응답이 어디서 끊기는가?

를 확인할 수 있습니다.

35장 Frame 분석은 Physical Layer 확인 뒤에 한다#

순서를 뒤집지 않는 것이 중요합니다.

Cable 단선

상태에서 Modbus CRC를 계산해 봐야 의미가 없습니다.

권장 순서:

전원
↓
Cable
↓
Signal
↓
UART
↓
Byte Stream
↓
Protocol Frame
↓
Application

입니다.

36장 Modbus RTU라면 무엇을 볼까#

대표적인 요청 Frame:

01 03 00 00 00 02 C4 0B

처럼 보일 수 있습니다.

여기서 확인합니다.

Slave Address

Function Code

Register Address

Length

CRC

하지만 실제 CRC 값은 Frame 내용에 따라 계산되는 값이므로 임의의 예시 Frame을 실제 장비에 그대로 사용하는 것은 피해야 합니다.

37장 요청은 보이는데 응답이 없다#

이 경우 다음을 확인합니다.

Address가 맞는가?

Command가 지원되는가?

Slave가 요청을 정상 수신했는가?

Master Driver가 Bus를 놓았는가?

Slave TX가 동작하는가?

Timeout이 너무 짧지 않은가?

즉 요청이 실제 Wire에 나간다는 사실만으로 Master 측 전체가 정상이라고 단정할 수 없습니다.

38장 응답은 나오는데 Master가 못 읽는다#

Slave 쪽에서는 Response가 송신됩니다.

그런데 Master에서는 Timeout이 발생합니다.

가능한 원인:

Master Receiver 문제

A/B Local Wiring

Driver Enable 전환

Baud 설정

Noise

Application Buffer

Protocol Parser

등입니다.

가능하다면 양쪽에서 Capture해 비교합니다.

39장 Timeout을 원인으로 생각하지 않는다#

Timeout

은 Root Cause가 아닙니다.

뜻은 단순히:

정해진 시간 안에
기대한 응답을 받지 못했다.

입니다.

원인은:

Cable

Address

Noise

Protocol

Device

Timing

중 어디에든 있을 수 있습니다.

40장 Timeout을 너무 짧게 설정하지 않는다#

Slave가 정상적으로 50ms 후 응답한다고 하겠습니다.

Master Timeout:

20ms

라면 정상적인 Response도 실패로 처리됩니다.

그 뒤 Retry가 발생하면서 Bus Traffic이 증가할 수 있습니다.

41장 Timeout을 너무 길게 해도 문제다#

반대로 Timeout:

5 seconds

인데 장비가 20대라고 하겠습니다.

한 Device가 Offline이면 전체 Polling Cycle이 크게 느려질 수 있습니다.

따라서 실제 Response Time을 측정해 합리적인 값을 정해야 합니다.

42장 Retry를 늘리는 것은 근본 해결이 아니다#

CRC Error가 발생하자:

Retry 3회
→
Retry 20회

로 바꾸면 성공률이 올라갈 수 있습니다.

하지만 Physical Layer 문제가 원인이라면:

Bus Traffic 증가

Latency 증가

장애 은폐

만 생길 수도 있습니다.

Retry는 복원력 기능이지 잘못된 Wiring을 고치는 기능이 아닙니다.

43장 실습할 때 A/B를 직접 Short하지 않는다#

RS-485에서 단순히:

A ↔ B 연결

하여 Loopback을 만드는 것은 RS-232의 TX-RX Loopback과 같은 개념으로 사용할 수 없습니다.

2-Wire RS-485 Transceiver는 하나의 Differential Bus를 송수신에 공유하기 때문입니다.

Loopback을 시험하려면 적절한 RS-485 Test Setup이나 두 Transceiver를 사용해 송수신 경로를 구성하는 것이 좋습니다.

44장 안전한 Test Bench 구성#

예:

PC A
↓
USB-RS485
↓
A/B Bus
↓
USB-RS485
↓
PC B

양쪽 Serial 설정을 동일하게 맞춥니다.

19200

8 Data Bits

No Parity

1 Stop Bit

그리고 단순한 Test Data부터 확인합니다.

45장 Test Bench에서는 하나씩 조건을 바꾼다#

예:

정상 상태 기록
↓
Termination 제거
↓
결과 기록
↓
원복
↓
Baud 변경
↓
결과 기록

여러 항목을 동시에 변경하면 무엇이 원인이었는지 알기 어렵습니다.

46장 운영 장비에서는 먼저 증거를 남긴다#

현장 도착 직후:

전원 OFF

Cable 교체

장비 Reset

부터 해버리면 중요한 증거를 잃을 수 있습니다.

가능하다면 먼저:

발생 시각

장비 Address

오류 Log

Serial 설정

현재 Wiring

LED 상태

통신 Capture

를 기록합니다.

그 다음 조치합니다.

47장 장애 발생 시간을 반드시 기록한다#

예:

09:10 정상

09:23 CRC Error 증가

09:25 Gate Motor 동작

09:27 통신 단절

처럼 시간축으로 정리하면 Electrical Event와 통신 장애의 관계를 찾을 수 있습니다.

48장 변경 이력도 확인한다#

장애가 갑자기 시작됐다면 질문합니다.

최근 장비를 추가했는가?

Converter를 바꿨는가?

Cable 공사를 했는가?

Baud 설정을 변경했는가?

Firmware를 업데이트했는가?

전기 공사가 있었는가?

새로운 변화가 장애 원인을 좁히는 가장 강력한 단서일 수 있습니다.

49장 증상별 진단표#

증상 우선 확인
전체 Bus 무응답 전원·Master·A/B·Cable
특정 Device만 무응답 Address·Local Wiring·Power
Junction 이후 무응답 Cable·Pair·Connector
문자 깨짐 Baud·Parity·A/B
CRC Error Noise·Reflection·Collision
Idle Random Data Bias·Fail-Safe
장비 추가 후 불안정 Termination·Bias·Address
가까운 Device만 정상 Cable·Termination·Ground
Motor 작동 때 오류 EMI·Ground
요청은 가지만 응답 없음 Address·Driver Release·Slave
응답은 있지만 Master Timeout RX Path·Timing·Parser

50장 현장 진단 순서#

전체 과정을 하나로 정리하면 다음과 같습니다.

증상 분류
↓
전원
↓
Interface
↓
Cable
↓
A/B
↓
Topology
↓
Termination
↓
Bias
↓
Ground
↓
Baud / Parity / Stop Bit
↓
Address
↓
Driver Enable
↓
Noise
↓
Raw Byte
↓
Frame
↓
CRC
↓
Application

이 순서의 핵심은 Physical Layer에서 Application으로 올라가는 것입니다.

51장 현장 점검 체크리스트#

□ 증상이 완전 무응답·간헐 오류·데이터 깨짐 중 무엇인지 구분했는가?

□ 장비 전원이 정상인가?

□ 실제 Interface가 RS-485인가?

□ 2-Wire·4-Wire를 확인했는가?

□ A/B Signal Definition을 확인했는가?

□ Cable 단선과 Short를 확인했는가?

□ 실제 Topology를 확인했는가?

□ Stub가 지나치게 길지 않은가?

□ Termination 위치를 확인했는가?

□ 장비 내장 Termination을 확인했는가?

□ Bias가 중복되지 않았는가?

□ Receiver Fail-Safe 기능을 확인했는가?

□ Baud·Data Bit·Parity·Stop Bit가 일치하는가?

□ Device Address가 중복되지 않았는가?

□ Driver Enable Timing이 정상인가?

□ Ground Potential Difference를 확인했는가?

□ Noise 발생 시간과 장애 시간이 연관되는가?

□ 실제 Raw Byte를 확인했는가?

□ CRC Error를 원인이 아닌 결과로도 검토했는가?

□ 변경 전 현재 상태를 기록했는가?

52장 흔히 하는 잘못된 진단#

52.1 통신이 안 되면 장비부터 교체한다#

Cable과 설정 문제일 수 있습니다.

52.2 CRC Error면 Protocol Code가 잘못됐다#

Physical Layer에서 Data가 손상되어도 CRC Error가 발생합니다.

52.3 RS-485는 Noise에 강하므로 Noise 문제는 없다#

상대적으로 강할 뿐 Noise에 면역인 것은 아닙니다.

52.4 종단저항은 많을수록 좋다#

과도한 Termination은 Bus를 과부하할 수 있습니다.

52.5 32대 이하면 Electrical 문제는 없다#

Node 수 외에도 Cable·Topology·Termination·Unit Load 등의 영향을 받습니다.

52.6 Timeout을 늘리면 해결된다#

증상을 숨길 수 있을 뿐 Physical Problem을 해결하지 않습니다.

52.7 일부 장비가 정상이라면 Cable 전체가 정상이다#

특정 Junction 이후나 특정 Stub에만 장애가 존재할 수 있습니다.

53장 자기 점검#

53.1 완전히 무응답이면 어디부터 확인해야 하는가#

전원과 Interface, Cable, A/B를 먼저 확인합니다.

53.2 CRC Error가 반복되면 무엇을 확인해야 하는가#

Serial 설정뿐 아니라 Noise, Reflection, Collision 같은 Physical Layer 문제도 확인합니다.

53.3 특정 장비 하나만 안 되면 무엇을 확인해야 하는가#

해당 장비의 Power, Local Wiring, Address, Serial 설정을 우선 확인합니다.

53.4 Address가 중복되면 어떤 문제가 발생할 수 있는가#

여러 장비가 동일 요청에 동시에 응답해 Collision과 CRC Error가 발생할 수 있습니다.

53.5 Timeout은 장애 원인인가#

아닙니다.

정해진 시간 안에 응답을 받지 못했다는 결과이며 실제 원인은 별도로 찾아야 합니다.

54장 이 글을 마치며#

RS-485 장애를 해결할 때 가장 피해야 할 방법은:

일단 이것저것 바꿔본다.

입니다.

먼저 증상을 분류합니다.

완전 무응답

간헐적 오류

데이터 깨짐

그 다음 아래에서 위로 올라갑니다.

전원
↓
Cable
↓
Differential Signal
↓
Termination·Bias
↓
UART 설정
↓
Address
↓
Protocol
↓
Application

이렇게 접근하면:

장비 문제인가?

배선 문제인가?

전기적 문제인가?

설정 문제인가?

Protocol 문제인가?

를 하나씩 제거할 수 있습니다.

특히 다음 다섯 가지를 기억하면 됩니다.

RS-485 장애는 가장 먼저 증상을 구분해야 합니다.

CRC Error와 Timeout은 원인이 아니라 하위 계층 장애의 결과일 수도 있습니다.

특정 장비만 안 되는지, 특정 지점 이후가 안 되는지, 전체 Bus가 안 되는지를 구분하면 장애 범위를 크게 줄일 수 있습니다.

Termination·Bias·Ground·Noise는 정상 동작과 간헐적 장애를 가르는 중요한 Physical Layer 요소입니다.

설정을 변경하거나 장비를 Reset하기 전에 현재 상태와 Log를 먼저 남기는 것이 재현하기 어려운 현장 장애를 해결하는 데 매우 중요합니다.

결국 RS-485 장애 진단의 핵심은 특별한 장비나 명령어 하나가 아닙니다.

전원에서 시작해 Cable과 전기 신호, Byte와 Frame, 마지막 Application까지 데이터가 이동하는 길을 순서대로 따라가는 것입니다.

이 페이지의 목차