2. 통신 에러의 확인

[자손]

일반적으로 보면 시스템 트러블의 70~80% 이상이 통신 문제입니다. 나머지 20~30%는 시스템 다운과 관련이 있습니다. 이 외에 소프트웨어에서 발생하는 문제는 별로 많지 않습니다. 기능 구현 상의 버그는 사실 트러블 슈팅이라고 하기에는 차원이 다릅니다.

만약 시스템에서 통신에 이상이 발생한 경우에는 다음의 절차로 확인을 하여 통신의 이상 유무를 검사할 수 있습니다

1. 싸이텍 커널에서 에러 메시지를 확인합니다.
만약 통신 에러가 발생하였다면 커널 Main 창에 표시되고 있을 것입니다. 이 에러 메시지는 매우 중요하며 Syslog.dat 파일에도 기록이 됩니다. 커널에서 에러 메시지를 확인하는 것은 앞절에서 상세하게 설명하였으므로 여기서는 생략하도록 하겠습니다.

2. 커널의 IODevcie 또는 Driver 창으로부터의 정보를 확인합니다.
어차피 Main 창에서 에러 메시지를 확인하였다면 IODevice 또는 Driver 창에서도 에러가 표시되고 있을 것입니다. 이곳으로부터 얻을 수 있는 가장 중요한 데이터는 Generic Error 코드와 Driver Error 코드입니다. 이 코드 값에 대해서는 싸이텍 도움말을 참조하시기 바랍니다. 또한 이 창에서는 어느 포트, 어느 IODevice에서 에러가 발생하는지도 확인할 수 있습니다.

3. 사용이 가능한 다른 유틸리티로 통신 상태를 확인합니다.
TCP/IP 통신을 하는 경우에는 ping 명령을 사용할 수도 있을 것이며, OPC를 사용하는 경우라면 삼사의 OPC Client 프로그램을 사용하여 통신을 확인할 수 있을 것입니다. 또한 만약 메이커에서 제공하는 통신 테스트 프로그램이 있다면 그것을 통하여 통신 상태를 확인할 수 있을 것입니다.

4. 제어기에서의 통신 램프를 확인합니다.
일반적으로 통신 카드에는 Tx 램프와 Rx 램프가 있으며, 이 LED로 통신 상태를 나타냅니다. 이 램프를 통하여서 제어기에서는 통신 응답을 제대로 하는지, 데이터는 받고 있는지를 확인할 수 있습니다. 만약 RX 램프만 깜빡이고 TX 램프가 깜빡이지 않으면 제어기의 통신 카드가 응답을 하지 않는 경우이므로 이 때는 제어기 통신 모듈에 대한 트러블 슈팅을 해야 합니다.

5. 필요하다면 커널의 Main 창에서 Debug 명령을 사용합니다.
지금까지 보면 주로 Debug 명령은 출력이 잘 나가는지 확인할 때 사용하였었습니다. 그 외에도 필요한 경우가 발생할 수도 있으니 Debug 명령의 사용 방법은 숙지하여 두시는 것도 좋을 것 같습니다. 또한 필요한 경우에는 삼사의 Protocol Analyzer를 사용할 수도 있습니다.

기본적으로 통신은 제공된 드라이버와 제어기를 사용하는 것이기 때문에 거의 대부분이 별다른 문제 없이 통신이 되어야 합니다.  문제가 발생을 해도 싸이텍의 커널 메시지 만으로도 분석이 가능한 경우가 많습니다.  하지만 때로는 Protocol Analyzer로 실제 통신을 덤프하여 분석하여야 하는 경우도 발생을 합니다.  아래 사례들은 통신 디버깅이 쉽지 않았던 경우들에 대해서 수록을 하였습니다.  각 사례들을 통해서 디버깅 방법을 배우고, 비슷한 문제가 발생하였을 때 조치를 할 수 있는 기술을 배우도록 합니다.

아래 사례들 중에서 사례1~4는 모두 통신이 전혀 안되었던 것이 아니라 통신이 되다가 어느 순간부터가 통신이 두절되는 문제들에 대한 것입니다.  이들 중 어떤 것들은 싸이텍 커널에서 Debug 명령으로도 충분한 분석이 가능한 것도 있었고, 어떤 것들은 Protocol Analyzer 프로그램에서 TCP 수준까지를 분석해야 하는 경우도 있었습니다.  Protocol Analyser 프로그램으로는 윈도에서 기본적으로 제공하는 Netmon 프로그램을 사용하도록 하겠습니다. 이 프로그램은 윈도 운영 시스템에 기본적으로 제공되는 프로그램이기 때문입니다. 이 프로그램은 네트워크 전체에 대한 통계 및 분석은 할 수 없지만 자신의 PC에서 참조되는 모든 송수신 데이터에 대한 통계 및 분석은 가능합니다.

사례 보기 :

사례1. TCP 응답만 하고 실제 데이터는 송신하지 않는 경우
사례2. 재접속이 안되는 경우
사례3. 응답을 하지만 에러 코드를 반환하는 경우
사례4. 응답은 하지만 잘못된 수순으로 응답을 하는 경우

사례들을 통하여 본 문제들은 처음에는 통신을 잘 하기 때문에 기본적인 통신 설정이나 환경 설정에는 문제가 거의 없다고 보여집니다.  하지만 무엇인가 버그가 있기 때문에 이러한 문제가 발생하는 것입니다.  이러한 문제가 발생하였을 때 우선적으로 어느 쪽이 문제인지를 쉽게 알 수 있는 방법은 어느 쪽을 리셋해야 통신이 재개가 되는가입니다. 왜냐하면, 버그로 인한 문제가 리셋으로 해소가 되기 때문입니다.

그런데 이러한 문제는 왜 발생을 하고, 해결할 방법이 없는가?  문제의 분석이 되고, 원인을 알면 해결이 가능합니다.  물론 정확한 것은 제작자가 아니면 말하기가 어렵습니다.  하지만 수많은 사례를 통하여 예상할 수 있는 것은 다음과 같이 몇 가지로 정리를 할 수가 있습니다.

- 프로그램이 고속 통신을 할 때 놓치는 데이터가 있거나 처리를 못하는 데이터가 있다.
- 접속 관리가 잘못되어 있거나 불필요한 처리를 하는 경우가 있다.