시리얼 통신 하기[1]

 

시리얼 통신 하기[1]

출처: melsec PLC 동호회(http://cafe.daum.net/melsec)의 회색늑대 (grizlupo)님의 초보 통신 이야기 연재글 입니다. 

회색늑대 (grizlupo)님의 초보 통신 이야기중 시리얼 통신에 관련하여 전반적으로 이해 할 수 있는 좋은 글입니다. 총 7회 분량의 글 입니다.

우리가 가장 분명하게 이해하고 있는 통신 형태는 전화입니다. 오늘을 살아가는 사람치고, 전화 한다는 것을 이상하게 생각하는 사람은 아무도 없을 겁니다. 실제로 컴퓨터간의 통신도 전화와 전혀 다를 것이 없습니다. 단지 전화는 양쪽에 사람이 있고, 말을 주고 받는 다는 것이고, 컴퓨터간의 통신은 양쪽에 컴퓨터가 있고, 말이 아닌 숫자들을 주고 받는 다는 것입니다.

컴퓨터 통신에 있어 양쪽 컴퓨터가 주고 받는 최소 형태는 바이트입니다. 한 바이트는 0에서 255사이의 숫자를 표현할 수 있습니다. 정리하면 컴퓨터 통신은 한 쪽 컴퓨터가 45 56 72 라고 전달하면 반대편 컴퓨터가 34 44 67 이라고 응답하는 식이라는 것입니다. 이를 다시 전화로 비유한다면 전화기를 들고 있는 양쪽 사람이 난수표 같은 숫자로 서로 얘기하고 있다고 생각하시면 됩니다.

PLC도 컴퓨터입니다. PLC에 PC를 연결해서 통신을 한다는 것도 서로 간에 바이트들을 주고 받는 과정입니다. 멜섹에서는 이 바이트들을 어떻게 주고 받을 것인가에 누가 그것을 처리할 것인가에 따라 세 가지 형태의 통신을 얘기하고 있습니다.

1. 무수순

'無'라는 말이 포함하는 의미처럼 아무 것도 정해진 것이 없는 경우를 말합니다. PC가 어떤 바이트들을 전달할지 그것들에 대해 PLC가 어떤 바이트들로 반응을 할지 정해져 있지 않습니다. 반대도 마찬가지 입니다. 아무것도 정해진 것이 없습니다.

이는 다른 말로 모든 것을 통신을 하고자 하는 양쪽이 정해야 한다는 것입니다. 가령은 PC가 32를 전달할 때 PLC는 현재의 리프트 상태에 따라 상승이면 1을 하강이면 2을 전달하는 것으로 정할 수 있습니다. 이런 규칙들을 일반적으로 프로토콜 혹은 전송규약이라고 표현합니다.

이렇게 되면 PLC측에서도 32가 전달되었다는 것을 판단하는 프로그램 그것에 대해 1혹은 2로 대답하는 프로그램을 래더로 작성해 주어야 합니다. 많은 PLC 프로그래머들은 PC하고 연결될 때 자신이 무슨 프로그램을 해야 한다는 것에 익숙하지 않습니다. 하지만 무수순으로 하겠다고 했다면 프로그램을 하셔야 합니다.

반대로 많은 경우 PLC에 바코드 리더같은 장치가 물리는 경우도 무수순 방식 즉, 통신의 양쪽 주체가 무엇을 어떻게 주고 받을 지 정한 것입니다. 하지만 PC가 연결된 경우에서와는 달리 PLC 프로그래머가 그것을 위한 프로그램을 해야 한다는 것을 당연하게 받아 드립니다. PLC 프로그래머는 해당 장치를 사용해야만 하는 입장에 있기 때문에 바코드 리더기를 만든 업체에서 일방적으로 정한 규칙이기는 하지만 그것에 맞춰주는 프로그램을 할 수 밖에 없는 것이죠

얼마전에 전자저울과 통신을 해야 하는데 어떻게 해야 하는지를 묻는 질문을 본 것 같습니다. 하지만 그 답이라는 것은 전자저울 업체의 관련 프로토콜을 구하셔서 그것이 필요하다는 데로 바이트들을 전달하고, 그것이 준다는 바이트들을 받으면 되는 겁니다. 전자저울이 사용하는 프로토콜은 그 업체에서 다음대로 정한 것이니까 답해 줄 수 있는 것이 아니고, 바이트들을 어떻게 하면 주고 받을 수 있는지는 이미 통신모듈 사용 설명서에 잘 나와 있으니 구구한 설명이 필요없는 것이고, 제가 보기에 이런 류의 질문에 제대로 된 답이 올라온다는 것이 오히려 이상한 것입니다.

2. 쌍방향

기본적으로 무엇을 어떻게 주고 받을지가 정해져 있지 않다는 것에서는 무수순과 동일합니다.

"너 밥 먹었니?"라는 질문에 대해 "예/아니오"라고 대답하는 전화를 비유해서 말씀 드리겠습니다. 우선 무수순인 경우 "너 밥 먹었니?"라고 질문을 한 사람은 반대편 사람이 "예" 혹은 "아니오"라고 대답할 때까지 무한정 기다리거나 성질이 좀 급한 사람 같으면 전화를 끊어 버릴 겁니다. 이 때 질문한 사람은 자기가 한 말을 상대방이 들었는지 아닌지를 알 수가 없습니다. 혹시 잡음이 생겨 질문이 제대로 전달되지 않은 경우에도 질문한 그 사람은 그 사실을 알 수가 없습니다.

반면에 쌍방향은 "너 밥 먹었니?"라고 말하면 반대편 사람이 "예/아니오"라고 대답하는 것과는 상관없이 전화기가 알아서 "삐"하는 소리를 보냅니다. 즉, "너 밥 먹었니?"하는 말이 이 쪽 사람에게 전달되었다는 것을 반대편 사람에게 알려주는 것입니다. 대답을 해야 하는 사람이 자기가 밥을 먹었는지 안 먹었는지 헷갈려서 뜸을 들이는 것과는 상관없이 질문을 한 사람은 그 질문이 반대편 사람에게 전달되었다는 것을 알 수 있는 것입니다.

3. MC프로토콜

MC는 멜섹 커뮤니케이션의 약자입니다. 즉, 멜섹이 정한 통신을 위한 프로토콜입니다. 앞서 무수순이라는 말에서 정해진 것이 없다는 것은 정확하게 다시 말하면 MC프로토콜을 사용하지 않는다는 것입니다.

이 MC프토토콜은 PLC 프로그래머가 굳이 래더 프로그램을 하지 않더라도 통신모듈이 자신이 알아서 처리할 수 있는 프로토콜입니다. 그러니까 MC프로토콜을 사용하는 경우에 PLC는 아무런 래더 프로그램도 할 필요가 없습니다. 대신 MC프로토콜을 사용하는 PLC에 연결되는 PC 프로그램은 이 MC프로토콜 대로 바이트들을 전달하고, 응답을 해석할 수 있어야 하는 것입니다.

MC프로토콜은 PLC의 디바이스를 읽거나 쓸 수 있는 용도를 위한 것입니다. 무수순에서 예로 든 PC가 32를 전달하면 PLC가 1혹은 2로 대답하는 경우를 MC프로토콜로 한다면 PLC는 상승인 경우 M1000을 1로 하강인 경우 M1001을 1로 설정하고 PC는 MC프로토콜로 이 M1000과 M1001의 값을 읽음으로서 동일한 효과를 얻게 되는 것입니다. 이 경우 PLC는 아무런 프로그램도 해 줄 필요가 없습니다. 자신이 늘상 하는 방법대로 그냥 디바이스에 자신의 상태를 기록해 두기만 하면 PC가 MC프로토콜로 통신모듈에게 M1000의 값을 전달해 주도록 할 수 있고, 통신모듈 선에서 M1000값이 PC로 전달되기 때문에 PLC 프로그래머는 통신을 하고 있다는 것 자체를 신경 쓸 필요가 없는 것입니다. 많은 경우 PLC 프로그래머는 이런 형태를 선호합니다.

4. 바이트와 문자

우리는 바이트라는 말과 함께 문자라는 말을 흔하게 사용합니다. 때때로 둘을 구분없이 마구 섞어서 사용하기도 합니다. 하지만 엄밀히 컴퓨터는 문자를 표현할 수 없습니다. 컴퓨터에서의 문자란 숫자의 또 다른 모습일 뿐입니다. 그래서 숫자를 문자인 것처럼 하기 위해, 우리는 ASCII라는 것을 사용합니다. 이 ASCII는 American Standard Code for Information Interchange(미국 정보 교환 표준 코드)의 약자로 말 그대로 미국의 표준 코드입니다. 하지만 지금은 전세계가 사용합니다.

ASCII, 말은 거창하지만 실상 숫자와 문자를 일대일로 대응시켜 놓은 하나의 표입니다. 이 표에서 알파벳 'A'를 찾아보면 65(h41)라고 되어 있습니다. 'a'는 97(h61)이라고 되어 있습니다. 이런 대응 관계를 흔히 'A'의 아스키 코드는 65(h41)라는 식으로 표현하기도 합니다.

우리는 지금 통신에 관한 얘기를 하고 있습니다. 컴퓨터 간의 통신은 서로 간에 바이트들을 주고 받는 일이라고도 했습니다. 이제 바이트가 문자일 수 있다는 것을 말씀 드렸습니다. 다시 말해 컴퓨터 간의 통신은 서로 간에 문자들을 주고 받는 일이기도 한 것입니다. 문자들을 나열한다는 것은 글을 쓰는 것이고, 이는 컴퓨터 간의 통신은 글을 주고 받는 일이기도 한 것입니다. 이것은 오늘을 살아가는 우리들에게 전화 통화만큼이나 익숙한 모습인 채팅과 다르지 않습니다.

5. 제어문자

ASCII 문자표를 보면 0에서 31사이에 좀 색다른 문자들이 포함되어 있는 것을 확인할 수 있을 것입니다. 이들을 제어문자라고 하는데, 말 그대로 제어를 위한 문자들로 문자라는 말이 무색하게 눈에는 보이지 않습니다. 눈에 보이지 않는 문자이기 때문에 이들을 표현할 때는 일반적으로 <CR>, <LF>, <FF> 처럼 꺽쇠 괄호안에 그 문자의 이름을 적습니다.

각각의 제어문자는 일반적인 문자처럼 모양을 가지는 것이 아니라 의미를 가집니다. 

워드 같은 문서 편집기를 예로 들어 보겠습니다. 키보드에서 'a'를 누르면 편집기는 문서 파일에 'a'해당하는 97을 기록하고, 'A'를 누르면 'A'에 해당하는 65를 기록합니다. 그렇다면 Enter 키를 누르면 무엇을 기록해야 하는 걸까요? Enter 키는 입력점을 다음 줄의 맨 앞으로 옮겨 놓습니다. 이것을 모양을 가지는 문자로 표현할 수는 없습니다. 이 때 사용되는 것이 <CR>과 <LF>라는 제어문자입니다. 둘에는 문자에 해당하는 모양이 없습니다. 단지 <LF>는 다음 줄로 줄바꿈이 일어나도록 제어하고, <CR>은 맨 앞으로 이동하도록 제어하는 역할을 합니다.

다른 모든 제어문자에도 나름대로의 표준적인 역할이 부여 되어 있습니다. 하지만 절대적인 것은 아닙니다. 가령 <STX>나 <ETX> 같은 제어 문자는 통신을 위해 만들어진 것이기 때문에 통신이 아닌 다른 곳에서는 특별하게 제어할 것이 없습니다. 때문에 이런 문자들은 비록 제어문자이기는 하지만 화면에 출력되는 경우에는 특별한 모양의 도형으로 나타나도록 되어 있습니다. 심지어 <LF>에도 도형이 활당되어 있습니다. 만약 <LF>를 줄바꿈으로 받아 들이지 않는 상황에서라면 <LF>도 줄바꿈이 아닌 단순한 도형으로 나타나기도 합니다. 그러니까 눈에 보이지 않아야 할 제어문자가 화면에 이상한 도형으로 나타나더라도 이상하게 생각하지는 마십시요.

6. 프로토콜에 대하여

통신을 해야 하는 장치가 있습니까? 먼저 관련 프로토콜 설명서를 구하십시요!

프로토콜이 무엇인지에 대한 감을 잡기 위해 실제로 키엔스 바코드 리더와 통신을 해야 하는 경우를 예로 들어 보겠습니다.

키엔스 바코드 리더(누가 사느냐에 따라 가격 차이가 너무 심해 개인적으로 아주 아주 싫어 합니다)와 통신을 하기 위해서는 장치가 어떤 프로토콜을 사용하는지를 가장 먼저 알아야 합니다. 이는 장치를 만든 사람이 자기 마음대로 정한 것이기 때문에 '까짓 것 대충' 이렇게 할 수는 없습니다. 그리고 대부분의 경우 제품 내용물에 프로토콜에 대한 설명서는 포함되어 있지 않습니다. 그래서 관련 제품의 홈페이지나 제품의 판매상을 통해 따로 구하셔야 합니다.

설명서에서 가장 먼저 전송 형식을 확인 하십시요!

제가 가진 관련 설명서에서는 '6-3 커맨드 통신에 대한 상세 내용'이라는 장에 프로토콜에 대한 설명이 포함되어 있습니다. 이제 설명서를 읽어 보겠습니다. 이런 설명서를 접했을 때 가장 먼저 보아야 하는 것은 '전송 형식' '통신 포맷', '프레임', '패킷' 등의 표현을 사용하는 부분입니다. 역시나 키엔스 설명서에도 가장 먼저 '통신 포맷'이라는 제목으로 나와 있습니다.

어떤 말로 표현을 하든지 간에 이것은 통신을 통해 주고 받는 글의 기본 형식입니다. 이것은 무전기를 사용할 때 할 말을 하고 난 다음에 '오버'라는 말을 붙이는 것과 비교될 수 있습니다. 이런 무전기의 통신 포맷을 '하고 싶은 말' + '오버' 라고 표현해 볼 수 있을 것입니다. 비슷하게 키엔스가 사용하는 통신 포맷은 커맨드 + <CR> 혹은 <STX> + 커맨드 + <ETX> 입니다. 둘 중에 하나를 선택할 수 있도록 되어 있습니다. 즉, 우리가 실제로 장치에 전달하고 싶은 말은 커맨드 뿐이지만 여기에 반드시 <CR>이라는 것을 덧붙이거나, <STX>와 <ETX>로 감싸서 전달해야 한다는 내용입니다.

그렇다면 왜 추가로 뭔가를 덧 붙일까요? 이는 무전기를 사용할 때 끝에 '오버'라는 말을 덧붙이는 것과 같은 맥락입니다. 무전기는 한쪽에서 말을 하고 있을 때 반대편은 듣기만 해야 하는 형태의 장치입니다. 따라서 말을 하고 있는 사람이 이제 말이 끝났다는 것을 명확하게 알려 주어야만 반대편에서 말을 시작할 수 있기 때문입니다. 키엔스의 경우, 통신 포맷을 단지 커맨드 만을 보내는 것으로 한다면 커맨드가 한 문자 일 수도, 두 문자 일 수도, 그 이상일 수 도 있는 상황이라면 반대편에 있는 장치는 어디까지가 커맨드 인지 참으로 아리송하게 됩니다. 하지만 커맨드 + <CR> 이라고 한다면 <CR> 앞까지가 커맨드라는 것이 명확해 집니다. <STX> + 커맨드 + <ETX> 는 좀 더 명확합니다.

보내는 전송 형식이 있다면 받는 전송 형식도 있습니다. 키엔스의 경우 회신 + <CR>이나 <STX> + 회신 + <ETX> 둘 중의 하나입니다. 보내는 형식과 다르지 않습니다.

키엔스의 전송 형식이라는 것을 서술 형태로 말한다면 바코드 리더에 커맨드를 전송하면 리더는 그 커맨드를 실행하고, 그 결과를 회신한다는 것입니다. 이 때 커맨드와 회신은 이렇게 저렇게 포장해야 우체부 아저씨가 전달해 줄 것이라는 것이구요.

하지만 전송 형식이라는 것은 키엔스가 두 가지 형태 중에 하나를 선택할 수 있도록 한 것과 같이 생각하기에 따라 천차만별일 수 밖에 없는 것입니다. 따라서 대부분의 경우 자기 마음대로 프로토콜을 정의 하는 상황에서 통신 포맷 역시 백이면 백 모두 다릅니다. 하지만 비슷 비슷합니다. 필요한 것만 골라 내십시요.

처음 접하는 낯선 프로토콜 설명서를 붙잡고 자신에게 필요로 하는 것을 찾는 일은 모래 사장에서 바늘을 찾는 것 같이 암담한 일입니다. 낯은 용어들에 먼저 익숙해져야 하고, 수십, 재수없으면 수백가지의 기능들 중에서 필요한 것을 골라내야 합니다. 때로는 설명하고 있는 내용이 애매해서 직접 해 봐야 하는 경우가 생길 수도 있습니다.

한마디로 아무리 노련한 프로그래머라 해도 처음 접하는 프로토콜에 익숙해지는 것은 기계치 아줌마가 운전을 배우는 것과 다르지 않습니다. 그 어려움이라는 것은 초보들에게만 느끼지는 것이 절대로 절대로 아닙니다. 화이팅!

결론적으로 키엔스에서 제가 사용할 기능(키엔스에서의 표현으로는 커맨드)은 LON 뿐입니다. 설명서를 열심으로 정말 열심으로 몇날 며칠 동안 읽었는데 결론은 'LON'뿐, 벌러덩 ^^; 정작 내가 필요한 것은 '꼴랑 이거야!' 이게 프로토콜과 관련된 또 하나의 진실입니다. 백발백중 사람을 허탈하게 만듭니다. ^^;