EtherCAT의 MDP(Modular Device Profile) 이해

㈜파익스

김형덕 기술연구소 이사

EtherCAT은 개방형 기술로 시스템 아키텍처에 따라 여러 프로토콜을 사용한다. 그러면 EtherCAT은 어떻게 여러 프로토콜 데이터를 처리하는 것일까? 프로토콜 중 많은 Slave 장치들이 있는 CAN Open을 통해 EtherCAT의 프로토콜 처리 과정을 살펴보도록 하자.

쉬운 설명을 위해 CAN Open을 화물로 EtherCAT을 화물차로 운전자를 Master에 비유하여 설명해 보겠다. 먼저 운전자는 각 Slave에 화물을 보내기 위해서는 마구잡이로 화물을 실어 보낼 수 없으므로 각 Slave들이 제공하는 화물 내역과 크기 등이 담긴 일정한 규격서를 요구하게 된다.

이 문서가 ESI(EtherCAT Slave Information)파일이며 이 규격서를 운전자에게 제공하면 운전자는 이를 해석하여 각 Slave들의 화물들이 한 번에 많고 빈틈없이 적재하는 계획을 만들어 발송한다.
여기서 화물차가 첫 번째 Slave에 도착하였다면 어떤 화물이 첫 번째 Slave 일까? 이를 위해서 운전자는 화물을 보내기 전, 각 Slave가 가지고 있는 지게차와 같은 FMMU(Fieldbus Memory Management Unit)를 설정하여 해당 Slave에 도착하면 화물의 선적과 하역 위치를 알려준다.

이러한 화물들을 실어 나르기 위해 화물차에는 화물칸과 같은 MailBox를 제공하며, 이 MailBox를 이용하여 각 Slave들은 마스터로 부터 보내진 화물을 각자에 맞게 처리하는 것이다.
이 예와 같이 EtherCAT은 화물 내용과 상관없이 화물을 실어 나르는 화물차에 지나지 않는다. 물론 이 화물차의 빠른 속도와 동기화 기술 등이 하찮다는 의미는 아니며, 실제 EtherCAT을 사용하는 관점에서는 화물 자체에 의미가 있다는 뜻이다.

이러한 이유로 실제로 EtherCAT Slave장치의 제조사 매뉴얼을 확인해 보면 EtherCAT 설명보다는 CAN Open 등의 프로토콜 설명이 많은 부분을 차지한다. 그렇다면 사용자 관점에서 주의 깊게 봐야할 부분은 어떤 것일까. 만약 CAN Open 프로토콜 Slave를 사용한다면, 앞서 설명한 것과 같이 많은 이해가 필요하다. 이 화물을 사용할 앤드유저는 화물이 어떻게 왔는지의 과정보다는 이 화물 자체에 의미가 있기 때문이다.

그렇다면 화물의 내용물인 CAN Open을 들여다보자. CAN Open은 Device의 형태에 따라 <표 1>와 같은 Profile로 규정되어 있다. 이 Profile은 CiA협회에 의해 규정된 것이며, 이중 대표적으로 CiA402는 산업자동화에서 가장 많이 사용하고 있는 모터와 모션 컨트럴에 사용된다.

이 CiA402는 현재 시판중인 모터 드라이브나 마스터의 모션 컨트럴러에 대부분을 차지한다. 이에 대해서는 다음 기회에 자세히 들여다보기로 하자.

CiA협회에서 정의한 이 Profile 이외에도 필요에 의해 ETG(EtherCAT Technology Group)에서 규정한 몇 가지 Profile이 있다. 그중에 MDP(Modular Device Profile)를 살펴보도록 하겠다.

그전에 먼저 CANopen의 가장 중요한 특성을 살펴보면, 각 장치는 Object Dictionary를 제공하며 이 Object를 Read/Write 함으로 제어하고, 이 Object의 구성 정보 또한 Read 할 수 있다. 이 과정이 CAN Open에서는 SDO Download/Upload 및 Information 이다. 이러한 기반 지식은 해당 규격서를 참고하기 바란다.

이제 본문에서 말하고자 하는 MDP는 ETG.5001.1의 규격서에 설명되어 있다.

이 Profile(MDP)은 <그림 1><그림 2>과 같이 Module이 가변적으로 결합되어 동작하는 장치에 해당하는 Profile이다.
이러한 Module 구성을 당사의 제품으로 보다 자세히 보면 아래 그림과 같은 구조다. 각 Module의 구성이 동적으로 변경되므로 이 구성을 처리하기 위해서는 일정한 규약이 Master에도 Slave에도 존재해야 한다.

그래야 <그림 3>과 같이 Master인 TwinCAT에서 잘 인식되어 표시되는 것이다. 그러면 이러한 가변적인 Module 구성을 어떻게 인식되고 제어하는 것일까? 이 글에서 설명하고 싶은 내용이 바로 이 부분이다. 이러한 Module의 구성정보는 <그림 4>와 같이

■ Slave

Object 0xF050에 Module의 순서대로 SubIndex에 고유한 식별번호를 제공

■ Master

Slave의 ESI파일을 조회하여 “/EtherCATInfo/Descriptions/Modules/Module/Type/@ModuleIdent”번호와 일치하는 Module의 정보를 로딩하여 처리한다.

이렇게 살펴본 바와 같이 사용자가 편리하게 필요한 Module들을 조합하여 사용할 수 있도록 EtherCAT에서는 MDP를 지원하고 있다. 하지만 다른 Profile과 같이 Object Dictionary의 구성이 정적이지 않다. MDP는 동적이다 보니 많은 Slave와 Master가 아직 미숙한 부분이 있다.

실제로 필자도 개발 중 여러 국내에 시판중인 Master나 Slave를 테스트 해봤으나 아직은 MDP 처리에 미비한 부분이 있었다. EtherCAT은 다양한 장점을 가지고 있지만, 반면에 사용자로 하여금 높은 수준의 EtherCAT 이해도를 요구하기 때문에 실제 사용자들은 어려움을 겪고 있다.

또한 Master와 Slave 제조사와의 유기적인 결합이 부족하여 실사용에 많은 문제점이 야기되고 있고, 이 또한 실 사용자에게 높은 수준의 이해도를 요구하는 요인이 되고 있다. 이 글이 사용자들이 EtherCAT 프로토콜 처리과정을 좀 더 이해하는데 도움이 되기를 바란다. 마지막으로 당사의 MDP가 적용된 NMF-EC 제품에는 보다 쉽고 깊이 있는 내용의 매뉴얼과 Application Note 등이 제공되고 있다. EtherCAT을 보다 자세히 들여다보고 싶은 독자라면 참고하기 바란다.

자료 제공: ㈜파익스(www.paix.co.kr)