본문으로 바로가기
프로토콜
해당되는 글 10건
컴퓨터/프로그래밍
TCP/IP 연결 끊김 해결 방법
TCP/IP 연결 지향 프로토콜 TCP/IP를 연결 지향 프로토콜이라고 합니다. 처음 TCP/IP 소켓 프로그래밍을 학습할 때 "연결 지향 프로토콜"이라는 말이 생소해서 뭔 뜻인가 했습니다. 연결 지향? 통신이라면 당연히 연결되어야 하는 것 아닌가? TCP/IP로 통신한다고 라인을 깔아서 직접 연결한다는 것은 아닐 텐데. 연결 지향 프로토콜이란 그렇습니다. 당연히 연결 지향 프로토콜이라고 물리적으로 선을 깔아서 직접 연결하는 것은 아니고요, TCP 프로토콜이 소프트웨어적으로 상대 시스템과 통신이 끝날 때까지 연결을 유지시켜 줍니다. UDP/IP 프로토콜과 비교하면 이해하기 쉽습니다. UDP/IP는 좀 전에 A 컴퓨터에 데이터를 전송했음에도 이번에도 다음에도 A 컴퓨터로 데이터를 보내려면 매번 A 컴퓨터의..
컴퓨터/프로그래밍
모드버스 프로토콜 작성 방법 및 주의사항
이 글은 모드버스 프로토콜을 처음 접하면서 프로그램을 구현해야 하는 분을 위한 글입니다. 모드버스 질의에 대한 응답을 어떻게 구현하는지에 대한 설명이며, 코드를 작성하기 전에 미리 알고 있으면 헷갈리거나 헛수고를 줄일 수 있을 것으로 생각합니다. 아울러 모드버스 프로그램 작성에 도움이 되는 팁을 소개합니다. 모드버스 프로토콜 작성 시 주의 사항 모든 모드버스 Function Code를 작성해야 하나요? 결론부터 말씀드리면 아닙니다. 만일 내 장비가 온도계이고 어떤 설정도 없이 현재 온도 값만을 제공한다면 읽기 Function code 4만 작성해도 됩니다. 또는 내 장비가 조명 시스템이고 10개의 조명이 달려 있는데, 번호에 따라 On/Off를 할 수 있다면 Function code 6만 작성해도 됩니다..
컴퓨터/프로그래밍
모드버스 통신 오류 시 응답 방법
모드버스 통신 패킷 오류 시 응답? 무시? 한 개의 통신 라인에 여러 개의 디바이스가 물린 rs485에서 통신 패킷이 깨진 데이터를 수신했을 경우 다시 보내 달라고 요청해야 할까요? 아니면 무시하고 기다려야 할까요? 답부터 말씀드리면 요청하거나 응답해서는 안 됩니다. 어? rs485 통신의 대표 프로토콜인 모드버스에는 예외 상황 코드로 응답하는 내용이 있는데?라고 반문하실 수 있습니다. 그러나 모드버스의 예외 상황 코드에는 통신 패킷 오류에 대한 내용이 없습니다. 즉, 수신된 데이터가 올바른지 CRC 값을 확인했더니 틀렸다면 그 통신 패킷은 무시해야 합니다. 1:1 통신인 rs232에서는 다시 보내 달라고 요청할 수 있어도 1:N에서는 걸러내야 합니다. 이유는 통신 패킷에 오류가 있다면 슬레이브 주소가 ..
컴퓨터/프로그래밍
C언어 rs232 시리얼 통신 프로토콜 주의 사항
시리얼 통신 패킷에 데이터 길이? 업체로부터 rs232 시리얼 통신 장비를 받았는데요, 프로토콜 문서에 언급된 패킷 구성을 보니 걱정스러운 부분이 있네요. 바로 데이터의 바이트 개수를 알려 주는 길이(Length) 요소인데요, 외부 영향에 약한 시리얼 통신에서 데이터의 크기를 알려 주고 그만큼 받으라는 것은 옳지 않다고 생각합니다. 시리얼 통신에서 길이를 넣어도 문제없다면 ETX를 사용할 이유가 없습니다. 만일 길이는 데이터 검증용이라고 한다면 CRC가 있으므로 이것도 이유가 못 됩니다. 그러나 LEN을 사용하는 시리얼 장비가 의외로 많습니다. 데이터가 모두 텍스트라면 더욱 이해가 안 되는데요, 이런 경우 굳이 LEN을 알려주지 않아도 ETX까지만 받으면 되거든요. 그렇다면 통신에서는 LEN을 사용해서는..
컴퓨터/프로그래밍
C언어 로그파일 작성 방법
프로그래머의 방패막이 로그 파일의 중요성 프로그램 실행 중에 생성되는 로그 파일은 디버깅에 매우 중요한 자료가 되고 억울함을 풀 수 있는 단초가 되어서 반드시 로그 생성 코드를 작성해야 합니다. 프로그래머라면 로그의 중요함을 잘 알 텐데요, 그럼에도 소홀하게 되고 기능 작성에만 치중하게 됩니다. 바쁘기도 하고 시간이 없을 수도 있지만, 로그 파일을 만드는 것은 습관과도 관계있지 않나 싶습니다. 부지런한 프로그래머라고 해서 로그 파일을 꼭 만들고, 게으른 프로그래머라서 무시하는 것은 아닌 것 같습니다. 번거롭기도 하고 귀찮기도 하지만, 디버깅하는 수고를 덜고 억울한 경험을 피하기 위해서도 로그 파일은 반드시 작성하는 것이 좋은데요, 개인적으로 사용하는 팁 몇 가지를 소개합니다. 로그 생성은 쉬워야 합니다...
컴퓨터/프로그래밍
rs485 통신 프로토콜 응답 처리 주의 사항
rs485 통신 특징에 따른 응답 방법 rs485 통신의 특징은 rs232와 rs422과는 달리 반이중(Half Duplex) 통신 방식입니다. 송수신을 동시에 할 수 없고, 물리적으로 두 개의 선을 연결해도 한 개의 통신 라인이라서 rs485가 멀티 드롭(Multi Drop) 다자간 통신이 된다고 해도 규칙을 정하지 않으면 장치 두 대만 물려도 통신을 원활히 할 수 없습니다. rs485는 대부분의 경우 통신에 물린 장치를 마스터와 슬레이브로 나누고 마스터만이 통신 제어권을 가지고 제어합니다. 마스터의 말이 끝날 때까지 모든 슬레이브는 입을 다물고 있어야 하는데요, 마스터가 요청하는 방법도 중요하지만, 슬레이브가 어떻게 응답해야 하는지도 시스템에 따라서 신중히 선택해야 합니다. rs485 통신은 외부 영..
컴퓨터/프로그래밍
rs485 모드버스 어드레스 맵 정리
Modbus-RTU address map 모드버스는 슬레이브 장치의 메모리 맵 구성에 따라 읽기·쓰기하여 통신하는 방식입니다. 모드버스 메모리 맵은 코일과 레지스터로 구성되며 메모리 번호에 따라 크기와 접근 방법이 다릅니다. 코일은 비트, 레지스터는 2 바이트 워드로 생각하면 이해하기 쉬운데요, 코일과 레지스터는 읽기·쓰기 모두 되는 영역과 읽기만 가능한 영역으로 나뉩니다. ▲ 모드버스 메모리 맵 영역에 따라 코일·레지스터의 번호 구분과 제어 함수 번호를 정리한 테이블입니다. 어드레스 지정 시 주의 사항 ▲ 서버로 요청하는 모드버스 RTU 프로토콜의 패킷 구성입니다. 메모리 맵에 따라 함수 번호와 주소를 지정해야 하는데, Holding Register 값을 읽겠다고 해서 30001, 30002처럼 만 단..
컴퓨터/프로그래밍
아리송한 MODBUS-RTU 특이점
MODBUS-RTU 왜 이렇게 만들었을까? 통신으로 장비를 제어하는 시스템을 개발한다면 모드버스(MODBUS) 프로토콜이 편한데요, 다뤄야 할 장비가 모드버스를 지원한다면 반가울 정도입니다. 그런데 이렇게 편한 모드버스 프로토콜을 처음 접했을 때는 정말이지 왜 이렇게 만들었나 이해가 안 되는 부분이 한둘이 아니었습니다. 정리하면 이렇습니다. 시리얼 통신인데 STX·ETX가 없다? 바이트 순서가 CRC만 다르다? 읽기 함수는 레지스터 개수, 응답은 byte 개수? 레지스터와 어드레스의 시작은 0번? 1번? 32bit 데이터의 바이트 전송 순서는? MODBUS-RTU에 STX·ETX가 없다? 모드버스 통신에는 전송하는 바이트 형식에 따라 MODBUS-RTU와 MODBUS-ASCII가 있습니다. 이름에서 예상..
컴퓨터/프로그래밍
rs485 시리얼 통신 구성 방법 및 주의 사항
rs485 시리얼 통신 구현 방법 비교 요즘처럼 인터넷 시대에도 산업 현장에서는 rs232와 rs485 시리얼 통신을 많이 사용합니다. 거리가 멀거나 1:N 통신이 필요한 경우 rs485 통신을 사용하는데요, 한 개의 통신 라인에 여러 장치와 통신을 해야 하다 보니 다양한 아이디어가 나오고 구현 방식도 여러 가지입니다. rs485 시리얼 통신에서 프로토콜을 어떻게 구현하며 어떤 점을 주의해야 하는지 알아보겠습니다. 마스터·슬래이브 통신 rs485는 두 가닥의 라인에 여러 개의 장치를 연결하고 통신합니다. 그러므로 규칙을 정하지 않으면 장치 두 대를 연결해도 통신이 안 됩니다. 이를 해결하기 위해서는 누가 먼저 통신 라인에 패킷을 올려놓을지 규칙을 정해야 하는데, 가장 쉬운 방법은 어느 한 장치에 주도권을..
컴퓨터/컴퓨터 이야기
프로토콜 이야기
가격이 저렴하고 시스템 구성이 간단해서 아직도 많은 곳에서 사용되고 있는 시리얼 통신. 그러나 저렴하고 구성이 간단한 만큼 외부 영향을 많이 받아 노이즈에 약하고 비동기 통신이라 생각할 것이 의외로 많은 것이 시리얼 통신입니다. 시리얼 통신을 처음 했을 때, 프로토콜에 대한 개념이 없어서 고생했던 기억이 아직도 생생해서 Embedded Linux 포럼을 운영하면서, 꼭 시리얼 통신에 대한 프로토콜에 대한 내용을 꼭 올려야지 하는 생각을 늘 가지고 있다가 이제야 올렸습니다. 동영상을 만들어 편집하다가도 욕심이 나는 부분이 있어서 다시 촬영하기를 반복하고 짜집기하여 겨우 임베디드 리눅스 포럼에 올렸습니다. 여러 번 수정해서 올렸지만 미약한 점이 너무 많네요. 그래도 혹 시리얼 통신 프로토콜에 관심있는 분들께..
