직렬 통신 문제

직렬 회선에서 수신 측은 CRC나 LRC가 맞지 않는 프레임을 버리고 응답하지 않습니다. 그래서 대부분의 직렬 문제는 클라이언트에서 Timeout 하나로 보입니다. 원인은 서버 쪽 진단 카운터와 양쪽 trace로 좁힙니다.

응답이 전혀 없을 때

다음 순서로 확인합니다. 앞에서 원인이 나오면 거기서 멈춥니다.

포트: connect가 성공했는지 봅니다. 다른 프로그램이 포트를 쓰면 Unable to acquire exclusive lock on serial port입니다.
전송 모드: 양쪽이 모두 RTU이거나 모두 ASCII인지 봅니다.
속도와 문자 형식: baud, parity, stop_bits가 장비와 같은지 봅니다. 8N1 장비는 PDComm에서 쓸 수 없으므로 장비를 8E1이나 8N2로 바꿉니다.
주소: 요청의 유닛이 장비의 국번과 같은지 봅니다. 주소가 다른 장비는 응답하지 않습니다.
배선: RS-232는 송수신이 정확히 한 번 엇갈리는지, RS-485는 D0/D1 극성과 종단, 공통선을 봅니다. RS-232 어댑터를 RS-485 포트에 직접 연결하지 않았는지 봅니다.
장비 설정 적용: 장비의 통신 설정을 바꿨다면 설정을 저장하고 필요하면 통신 모듈을 재시작했는지 봅니다.
장비 상태: 장비가 청취 전용 모드라면 어떤 요청에도 응답하지 않습니다. 진단 하위 기능 1(Restart Communications Option)로 복구합니다. 이 요청에도 응답은 없습니다.

trace로 실제로 무엇이 오갔는지 봅니다.

`trace`의 모습	뜻
`tx`만 있고 `rx`가 없음	요청은 나갔지만 아무것도 오지 않았습니다. 배선, 주소, 장비 전원을 봅니다.
`rx`가 있지만 `rx_discarded`로 버려짐	다른 주소의 응답이거나 손상된 바이트입니다. 주소와 패리티를 봅니다.
`rx`가 뒤섞인 바이트	속도나 문자 형식이 맞지 않습니다.

CRC·LRC 오류

수신 측이 CRC(RTU)나 LRC(ASCII)가 맞지 않는 프레임을 받은 경우입니다.

서버 쪽: 프레임을 버리고 응답하지 않습니다. diagnostics의 communication_errors가 늘고, 이벤트 로그에 통신 오류 이벤트가 남습니다.
클라이언트 쪽: 응답이 손상되면 Protocol(Checksum)이나 Timeout으로 실패합니다. 손상된 첫 바이트가 주소라면 다른 장비의 응답으로 보고 버리므로 Timeout이 됩니다.

흔한 원인은 잡음, 종단·바이어스 문제, 긴 케이블, 속도나 패리티 불일치입니다. 간헐적이라면 케이블과 접지를 먼저 봅니다.

가상 시리얼 포트로 재현할 수 있습니다. RTU와 ASCII 통신에서 문자 하나를 손상시키면 클라이언트는 Timeout, 서버의 communication_errors는 1이 됩니다.

받은 원시 바이트를 직접 검사하려면 fault에 넣어 봅니다.

{"action":"fault","transport":"rtu","bytes":"01030000000AC5CC"}

{"ok":true,"result":{"errors":["Checksum"],"frames":[],"source":"synthetic"}}

ASCII 모드의 오류

`fault`나 응답의 오류	원인
`Encoding`	16진 문자가 아닌 글자, 또는 소문자 16진 문자(`a`~`f`)가 있습니다. ASCII 모드는 대문자만 받습니다.
`Checksum`	LRC가 맞지 않습니다.
`Timing`	문자 사이 간격이 `ascii_timeout_ms`(기본 1000ms)를 넘었습니다.
`Length`	`:`와 CR LF 사이의 내용이 너무 짧습니다.

장비가 기능 08/03으로 종료 문자를 바꿨다면, PDComm은 응답 뒤부터 새 종료 문자를 씁니다.

RTU 문자 간격

명세는 프레임 사이에 t3.5 이상의 침묵을, 프레임 안 문자 사이에 t1.5 이하의 간격을 요구합니다. 다중 접속 RS-485 버스에서 각 서버는 t3.5 침묵으로 프레임을 나누고, 자기 주소의 요청에만 응답합니다. 주소 0의 브로드캐스트 쓰기는 모든 서버가 적용하고 아무도 응답하지 않습니다.

PC에서 본 바이트 간격은 USB 어댑터와 드라이버가 묶어 전달한 결과이므로 회선의 실제 간격이 아닙니다. 회선의 문자 간격을 확인하려면 오실로스코프나 직렬 분석기를 씁니다. fault의 gap_us로 디코더의 간격 판정을 시험할 수 있습니다(주소와 프레임 관찰).

브로드캐스트와 무응답

상황	결과	확인
유닛 0으로 쓰기	`no_response`가 정상입니다.	각 장비에서 읽기로 적용됐는지 확인합니다.
유닛 0으로 읽기	`InvalidConfig`	브로드캐스트는 쓰기 전용입니다.
청취 전용 장비	`Timeout`	재시작 요청 뒤 읽기로 확인합니다.
없는 주소	`Timeout`	국번을 확인합니다.

브로드캐스트 직후 다음 요청을 보내기 전에 turnaround_ms만큼 기다립니다. 느린 장비가 있으면 값을 늘립니다.

가상 시리얼 포트

macOS의 의사 터미널은 PDComm이 속도를 설정하지 않으므로 가상 연결 쪽 속도로 동작합니다.
가상 연결이 끝나면(터미널을 닫거나 stop) 포트가 사라지고 이후 요청은 실패합니다.

아직 해결되지 않으면

실패 진단과 문의에 따라 양쪽의 trace, 서버의 diagnostics, 진단 로그, 장비 모델과 어댑터, 배선 정보를 모아 문의합니다.