rs485 통신 프로토콜 응답 처리 주의 사항

rs485 통신 특징에 따른 응답 방법

rs485 통신의 특징은 rs232와 rs422과는 달리 반이중(Half Duplex) 통신 방식입니다. 송수신을 동시에 할 수 없고, 물리적으로 두 개의 선을 연결해도 한 개의 통신 라인이라서 rs485가 멀티 드롭(Multi Drop) 다자간 통신이 된다고 해도 규칙을 정하지 않으면 장치 두 대만 물려도 통신을 원활히 할 수 없습니다.

rs485는 대부분의 경우 통신에 물린 장치를 마스터와 슬레이브로 나누고 마스터만이 통신 제어권을 가지고 제어합니다. 마스터의 말이 끝날 때까지 모든 슬레이브는 입을 다물고 있어야 하는데요, 마스터가 요청하는 방법도 중요하지만, 슬레이브가 어떻게 응답해야 하는지도 시스템에 따라서 신중히 선택해야 합니다.

rs485 통신은 외부 영향에 의해 패킷이 손상받을 수 있어서 슬레이브가 마스터의 패킷을 수신하면 이상이 없는지 제일 먼저 확인합니다. 다행히 (1) 손상 없이 패킷을 수신했다면 응답 데이터를 전송해야 하는데요, 준비되는 대로 보내면 될까요? 만일 (2) 수신한 패킷이 깨졌다면 마스터가 마냥 기다릴 텐데 다시 보내 달라고 요청해야 할까요?

rs485는 rs232와 같은 시리얼 통신이지만, 반이중에 멀티드롭이라는 차이가 있어서 rs232처럼 작성하면 안 됩니다. 주의할 점이 비슷하면서도 다른 점도 있어서 어떤 것을 조심해야 하는지 알아보겠습니다. 우선 rs485에서는 아래와 같이 응답할 수 있습니다.

• 슬레이브 구분이 없는 경우 무응답
• 수신 성공 시 요청 데이터 응답, 수신 실패 시 무응답
• 수신 성공 시 수신 확인 응답 후 데이터 전송

rs485 통신은 반이중으로 송수신이 분리되고, 멀티드롭으로 통신할 슬레이브가 여러 개이며, 외부 노이즈로 패킷이 손상될 수 있어서 고려할 것이 참으로 많습니다.

슬레이브 구분이 없는 경우

마스터에 여러 개의 슬레이브를 연결했지만, 모두 똑같이 제어하고 실행 결과나 상태 확인이 필요 없다면 통신 프로토콜을 무응답으로 구성할 수 있습니다. 연결된 장치를 슬레이브 ID로 구분하지 않았다면 절대 응답해서는 안 됩니다. 에러가 발생하든, 고장이 났든 슬레이브는 조용히 듣고만 있어야 합니다.

이런 이유로 마스터와 슬레이브 모두 프로그램이 간단하고 설치하기도 편합니다. 슬레이브가 더 필요하면 통신 전달이 가능한 한 라인에 물리기만 하면 됩니다.

▲ 마스터는 명령만 전송할 뿐입니다. 수신하지 못한 슬레이브를 위해 반복해서 전송하고, 슬레이브가 부담 갖지 않도록 패킷과 패킷 사이에 여유 시간을 갖습니다.

여기에 슬레이브가 작동하는지만이라도 알아야겠다는 생각이 더해지면 이때부터 일이 복잡해집니다. 간단할 것 같지만, 우선 마스터가 패킷을 전송했다고 슬레이브의 응답을 반드시 받을 수 있다고 장담할 수 없습니다. 슬레이브가 무척 바쁠 수 있고요, 심하게는 고장 났거나 꺼져 있을 수 있습니다. 응답을 받았다고 해도 노이즈로 깨진 상태일 수 있는데요, 그래서 다시 요청했는데 또 깨졌다면 몇 번을 시도해야 할까요? 상태 확인할 슬레이브가 한 둘이 아닌데 이러다 언제 한 바퀴 돌아? 갑자기 생각할 것도, 따질 것도 많아집니다.

rs485 수신 성공 시 요청 데이터 응답, 수신 실패 시 무응답

마스터는 응답이 필요하다면 특정 슬레이브 하나만 지정해서 요청해야 합니다. 그렇다고 마스터의 통신 패킷이 해당 슬레이브에만 전달되는 것이 아니라 모든 슬레이브에 전달되므로,

1. 슬레이브는 수신된 패킷에 손상이 있는지 확인하고
2. 이상이 없는 경우 자기 패킷인지 확인해서
3. 요청을 분석하고 결과를 응답합니다.

만일 마스터의 패킷에 CRC 오류가 있다면 어떻게 해야 할까요? 통신 패킷 ID가 나를 가리킨다고 해도 응답해서는 절대 안 됩니다. 이점이 rs232 통신과 큰 차이점인데요, CRC 오류가 발생했다면 ID 값이 틀릴 수 있어서입니다.

▲ 패킷을 확인해 보니 CRC 오류 났지만, ID가 내 번호이어서 마스터에게 다시 보내 달라고 요청하면 올바르게 응답하는 슬레이브의 통신을 방해하게 됩니다.

rs485는 다자간 통신이라서 CRC 오류를 마스터에 알리지 않지만, 1:1 통신인 rs232에서는 바로 알려 주어야 빠르게 다시 수신할 수 있고 처리할 수 있습니다. rs232 통신에 대해서도 정리해서 올려야겠네요.

수신 성공 시 수신 확인 응답 후 데이터 전송

마스터로부터 수신한 패킷이 CRC까지 O.K.입니다. 모터를 켜 달라는 요청이네요. 여기서 슬레이브는 어떻게 응답해야 좋을까요?

• CRC 확인하자마자 패킷 수신을 잘했다는 응답을 전송할까요?
• 아니면 모터를 켜고 제대로 켜졌는지 확인까지 해서 결과를 보내야 할까요?

당연히 마스터의 요청에 실행 결과까지 한 번에 알려주면 좋지요. 그러나 문제는 시간입니다.

마스터는 설치 환경에 따라서 패킷 전송 후에 응답 대기 시간과 전송 실패 시 재 요청하는 횟수 등을 고려해야 합니다. 대기 시간이 길 수록, 전송 실패 시 재 요청하는 횟수가 많을수록 특정 슬레이브를 제어하고 응답받기는 좋겠지만, 모든 슬레이브를 확인하는데 시간이 그만큼 오래 걸립니다.

다른 슬레이브도 확인을 해야 하므로 마스터는 응답 대기 시간을 최대한 줄이려 합니다. 다시 요청하든, 다른 슬레이브로 방향을 바꾸든 판단을 빨리 하기 위해서이죠. 그래서 슬레이브가 명령 수행할 때까지 한적하게 기다릴 수 없습니다.

꼭 명령을 전송하고 수행 결과까지 받아야 하겠다면, (1) 슬레이브는 마스터의 패킷을 이상 없이 수신했음을 마스터에게 바로 알립니다. (2) 그러면 마스터는 대기 시간을 늘려서 기다립니다. 즉, 마스터에 패킷을 잘 받았다는 응답을 먼저 보내는 것은 시간을 달라는 요청과 같습니다.

예를 들어서 마스터의 응답 대기 시간은 50 msec라고 하겠습니다. 슬레이브가 모터를 On·Off를 실행하고 확인하는 데까지 최대 1 sec 정도 걸립니다.

1. 마스터는 모터를 켜라고 슬레이브에 패킷을 전송한 후 50 msec를 기다립니다.
2. 만약 슬레이브가 패킷을 수신했다고 응답하면 마스터는 응답 대기 시간을 1 sec 이상으로 늘려서 기다립니다.

이렇게 슬레이브가 마스터의 패킷을 수신했다는 것을 알려서 시간을 벌면 문제가 시원하게 해결될 것 같은데, 매우 곤란한 문제가 있습니다.

명령 실행과 결과 확인 분리

마스터가 명령을 전송했고 슬레이브도 잘 받아서 O.K. 응답한 후에 명령을 수행하고 있는데, 마스터가 수신한 O.K. 응답이 깨져 버린 것입니다. 그러면 마스터는 슬레이브가 잘못 받은 줄 알고 같은 명령을 다시 전송하게 됩니다. 여기서 두 가지 문제를 예상할 수 있습니다.

• 첫 번째는 마스터가 다시 명령을 전송하려는 순간 슬레이브가 실행을 마치고 결과를 전송하는 바람에 통신 충돌이 날 수 있습니다. 이런 경우 마스터는 슬레이브의 응답을 받지 못했으므로 또다시 요청하거나 다른 슬레이브로 방향을 바꿀 것입니다.
• 두 번째는 슬레이브가 이전에 받은 명령을 처리하고 있는 중인데 또 명령을 받아서 중복 실행하는 오작동이 발생할 수 있습니다.

이 문제는 rs485 통신이 아니어도 시리얼 통신 시스템이라면 예상되는 문제인데요, 해결하기 위해서는 마스터도, 슬레이브도 많은 경우를 대비해야 합니다. 우선 슬레이브는 이번에 수신한 명령이 실행 중인 명령인지 확인해서 중복 실행이 되지 않도록 해야 합니다. 그렇지 않으면 분명히 신호 한 번 보냈는데 두 번, 세 번 걸리는 이상한 상황이 발생할 수 있습니다.

이렇게 처리하기보다는 명령 요청과 상태 확인을 분리하는 것이 안전합니다.

• 마스터가 슬레이브에 명령을 전송합니다.
• 슬레이브는 수신 성공 시 응답하고 명령을 실행합니다.
• 이후에 마스터는 계속해서 상태를 요청해서 명령 실행 여부를 확인합니다.

명령 요청과 모니터링을 따로 하는 것인데요, 대표적인 예가 MODBUS를 이용한 통신 프로그램입니다.

1. 슬레이브에는 기능별로 정리된 어드레스가 있으며,
2. 마스터가 특정 어드레스 값을 변경하면
3. 슬레이브는 주기적으로 어드레스 값을 확인하고
4. 그에 맞추어 기능을 수행한 후
5. 그 결과를 예약된 어드레스에 저장합니다.
6. 마스터는 계속해서 해당 주소의 값을 확인해서 작동 상태를 확인합니다.

마스터가 일이 많아질 수 있지만, 슬레이브의 스펙이 마스터보다는 열악할 수 있으므로 이렇게 분리하는 것이 디버깅하기도, 장비 상태 확인하기도 유리합니다. 또한, 마스터의 대기 시간을 슬레이브의 명령 처리에 따라 조정할 필요가 없습니다. 마스터의 중복 요청으로 슬레이브가 오작동하는 일도 없고요.

다만, 단순한 시스템에 이 방법을 사용하면 배보다 배꼽이 더 커질 수 있습니다. 조금 느려도 되는 시스템이라면 마스터의 대기 시간을 늘려서 슬레이브의 응답을 여유 있게 받아서 처리해도 되는 것을, 명령 따로 확인 따로 나누는 것은 괜히 일을 키우게 됩니다.

그러나 단순하더라도 마지막 방법인 "명령 수행 요청과 결과 확인 분리"로 구성했다면 앞으로 있을 업그레이드 부담을 줄일 수 있습니다. 마스터의 대기 시간을 마냥 늘리는 것보다 능동적으로 대응할 수 있죠.

슬레이브도 마스터의 응답 대기 시간을 준수!!

마스터 프로그램을 작성하는 개발자와 슬레이브 개발자 간에 의견을 나누어서 마스터의 응답 대기 시간을 정하고 확인해야 합니다. 슬레이브는 마스터로부터 패킷을 수신하면 마스터의 응답 대기 시간 내에 응답해야 합니다. 만일 바빠서 시간을 넘겼다면 어떻게 해야 할까요? 결론은 응답하지 말아야 합니다!

▲ C 구간에서 마스터가 Slave 1에 패킷을 전송했는데 Slave 1이 그만 마스터의 대기 시간을 넘어서 D 구간에 응답하고 말았습니다. 마스터는 대기 시간이 넘어서도 응답이 없으니 다시 패킷을 전송하게 되어 통신 충돌이 생깁니다.

▲ 더 늦어서 마스터의 패킷과 충돌이 나지 않았지만, 마스터가 Slave 1으로 재요청이 아닌 Slave 2로 바꾸는 바람에 통신 충돌이 나고 말았습니다.

▲ 차라리 응답하지 않으면 다음 요청 때 응답하면 됩니다.

▲ 마스터가 Slave 2로 바꾸어도 통신을 방해하지 않게 됩니다.

이와 같이 슬레이브도 마스터의 대기 시간을 준수해야 하며 어기는 경우 응답하지 말아야 합니다.

어떻습니까? 간단할 것 같은 rs485 통신, 생각하고 따져야 할 것이 참 많지요? 이외에도 마스터의 대기 시간과 재요청을 몇 번하는 것이 좋은지 따져본 글을 소개합니다.

https://badayak.com/4794

rs485 시리얼 통신 구성 방법 및 주의 사항