저전력, 산업용 모터 컨트롤을 위한 CANopen 프로토콜 고찰
저전력, 산업용 모터 컨트롤을 위한 CANopen 프로토콜 고찰
글: 아툴 쿠마르(Atul Kumar) 애플리케이션 엔지니어 / 아나로그디바이스(Analog Devices, Inc.)
개요
견고한 통신 프로토콜과 인터페이스는 산업용 모터 컨트롤 애플리케이션에서 중요한 역할을 한다. 여러 프로세서 요소들이 복잡한 작업을 수행하기 위해 지속적으로 통신해야 하는 경우, CANopen®은 손쉬운 통합과 같은 특성으로 인해 산업용 드라이브 애플리케이션 엔지니어들 사이에서 인기 있는 기술로 자리 잡았다. 이는 우수한 구성 가능성을 제공하며, 효율적이고 안정적인 실시간 데이터 교환을 가능케 한다. 이 글에서는 CANopen을 저전력 모터 컨트롤 애플리케이션 관점에서 깊이 있게 살펴본다.
CAN의 배경 정보
로버트 보쉬(Robert Bosch Gmbh)에서 1983년에 개발한 제어장치 영역 네트워크인 CAN(Controller Area Network)은 매우 견고한 통신 프로토콜과 인터페이스다. 이 네트워크는 RS232와 같이 여러 컨트롤러 간의 실시간 통신이 용이하지 못했던 기존 직렬 통신 네트워크의 한계를 극복하기 위해 고안됐다. 자동차 업계에서는 여러 센서들의 연속적이고도 동시적인 데이터 전송이 필요했기 때문에 CAN을 처음 채택했다. CAN은 여러 노드들이 짧은 메시지를 사용해 서로 통신할 수 있게 하므로 자동차 애플리케이션에 매우 적합하다.
시간이 지날수록 CAN은 신뢰성과 여러 이점들이 입증되면서 다양한 산업 분야에서 인기를 얻었다. 그러나 CAN 프로토콜을 사용하여 서로 다른 제조회사의 여러 기기들을 하나의 시스템으로 통합하는 것은 꽤나 어려운 작업이었으며, 제조사마다 독자적인 코딩 규칙을 사용하기 때문에 때로는 불가능한 일이기도 했다. 이러한 한계를 극복하기 위해, CiA(CAN in Automation)의 국제적 사용자들과 제조사 협회는 CANopen이라는 상위 계층 프로토콜을 개발했다.
다음 섹션에서는 CANopen 프로토콜 아키텍처와 다축 모터 드라이버를 제어하는 애플리케이션에 대해 살펴볼 것이다. 이 글에서는 이 상위 계층 통신 프로토콜의 복잡성과 이것이 모터 및 모션 제어 도메인에 미치는 영향에 대해 자세히 살펴보고자 한다. 이 글의 목적은 QSH4218-35-10-027 스테퍼 모터를 사용하는 ADI Trinamic™TMCM-6212다축 모터 컨트롤러/드라이버 모듈의 실시간 통신 로그를 분석함으로써 사용자들에게 CANopen 프로토콜에 대한 이해를 제공하는 것이다. 특히 네트워크 관리 (network management, NMT) 상태와 클라이언트-서버 기반 CANopen 프로토콜에 중점을 둘 것이다. 또한, 통신 로그를 해독하고 드라이브의 상태를 결정하는 방법을 시연하기 위한 사례 연구도 제공할 것이다.
CANopen 아키텍처
이 섹션에서는 NMT와 SDO(service data objects)를 포함한 CANopen 프로토콜의 다양한 활용 원칙에 대해 설명한다.
네트워크 관리(NMT): NMT는 모든 CANopen 호환 장치들이 준수해야 하는 중요한 통신 원칙이다. 이는 상태 머신(state machine)으로서 동작하며, CANopen 프레임워크 내의 애플리케이션을 조정하는 데 있어서 중요한 역할을 수행한다.
네트워크 관리 상태 머신 아키텍처: NMT 상태 머신은 그림 1과 같으며, 다음과 같은 3가지 상태들로 구성된다;
- 초기화 상태 (Initialization State)
- 사전 동작 상태 (Preoperational State)
- 동작 상태 (Operational State)
그림 1. NMT 상태 머신
클라이언트 노드는 다양한 동작 상태에서 관련된 서버 노드의 통신 상태를 관리 감독하는 중요한 역할을 수행한다. 이는 NMT 메커니즘의 구현을 통해 달성된다. 클라이언트 노드는 이른 바 ‘하트비트(heartbeat)’와 ‘노드 가드(node guarding)’라는 두 가지 독특한 방법론을 통해 서버 노드의 통신 무결성을 평가한다. TMCM-6212의 경우, 하트비트 기술이 적절한 통신을 검증하는 데 사용된다. 각 노드는 객체 1017h를 사용하여, 밀리초(ms) 단위로 측정되고 사용자 설정이 가능한 시간 주기 간격의 하트비트 신호를 방출한다. 이를 통해 모든 노드가 활성화되고 통신을 위한 상태에 있음을 보장한다.
표 1은 서로 다른 다양한 통신 상태에서 사용되는 모든 통신 객체의 조합을 보여준다. 장치가 전원을 켜거나 재설정한 후 초기화 상태에 들어가면 부팅 메시지가 생성된다. 그런 다음, 장치는 원하는 작업을 수행할 준비가 된 사전 동작 상태로 전환된다. 사전 동작 상태에서는 네트워크의 모든 노드가 SDO, 하트비트/노드 보호, 비상 상황 및 시간/동기화와 관련된 모든 객체를 전송할 수 있다. 동작 상태에서는 PDO 객체들을 사전 동작 상태에서 사용할 수 있는 모든 객체들에게 추가하여 매핑되도록 할 수 있다. 마지막으로, 중지 상태에서는 장치가 모든 SDO 및 PDO 객체의 통신을 비활성화하여 NMT 명령만 허용한다.
초기화 | 사전 동작 | 동작 | 중지 | |
부팅 | • | |||
SDO | • | • | ||
비상상황 | • | • | ||
동기화/시간 | • | • | ||
하트비트/노드 가드 | • | • | • | |
PDO (Process Data Object) | • |
서비스 데이터 객체(Service Data Object, SDO):SDO 통신 프로토콜은 주로 NMT 상태 머신의 사전 동작 상태에서 사용된다. 이 프로토콜은 클라이언트가 연결된 모든 서버(node)의 객체 사전(object dictionary)에 있는 모든 객체에 액세스가 가능한 클라이언트-서버 구성으로 작동한다. 이 프로토콜에서는 클라이언트가 항상 특정 노드와 읽기/쓰기 트랜잭션을 시작하며 서버는 작업 완료를 확인한다. 이 과정은 SDO 내의 모든 트랜잭션이 확인되었음을 보장한다.
그림 2는 멀티노드 네트워크에서 SDO 프로토콜에 대한 클라이언트-서버 기반 구성을 보여준다. 각 노드에는 클라이언트와 통신할 수 있는 채널이 할당된다 이 경우 Trinamic TMCM-6212 6축 스테퍼 모터 드라이버/컨트롤러가 서버 역할을 하고, 연결된 PC가 클라이언트 역할을 하여 특정 노드 즉, 여기서는 노드-1과 읽기/쓰기 트랜잭션을 시작한다. 모든 노드가 SDO 클라이언트 메시지를 수신하는 동안에도 의도한 노드만 응답하며, 그 밖에 다른 서버들은 클라이언트 요청을 무시한다.
그림 2. 멀티노드 SDO 구성
서비스 데이터 객체(SDO) 데이터그램
그림 2는 SDO 데이터그램의 포괄적인 구조를 보여준다. SDO 헤더는 읽기 및 쓰기 기능과 같은 특정 작업에 할당된 고유 번호인 COB-ID(connection object ID)로 구성된다. 따라서 SDO 통신에는 두 개의 COB-ID가 필요하다. 첫 번째 COB-ID는 클라이언트의 업로드/다운로드 요청을 위한 NODE-ID+ 함수 코드인 600h + NODE-ID이다. 두 번째 COB-ID인 580h+ NODE-ID는 서버의 응답에 사용된다.
SDO 메시지의 첫 번째 바이트는 ‘지정자(specifier)’로 알려져 있으며, 메시지의 성격을 결정하는 데 중요한 역할을 한다. 이는 클라이언트가 데이터를 쓰기(다운로드)를 할지 아니면 읽기(업로드)를 할지를 나타내며, 트랜잭션에 발생한 오류를 중단 메시지를 통해 알려주기도 한다. 지정자 바이트는 그림 3과 같이 8비트로 나뉜다.
클라이언트 명령 지정자(client command specifier, CCS)로 알려진 3개의 비트(7~5)는 메시지의 성격에 대한 주요한 정보를 제공한다. 클라이언트 명령 지정자는 읽기, 쓰기, 분할/신속 전송 또는 트랜잭션 오류와 같은 클라이언트의 작동에 따라 다른 구성을 갖는다. 서버의 응답에서 지정자의 3개 비트(서버 명령 지정자: sever command specifier, SCS)는 트랜잭션의 성공 여부를 결정한다. 표 2는 다양한 작업에 대한 CCS와 SCS 비트의 다양한 조합을 보여준다. 지정자 데이터그램의 비트 4는 4바이트를 초과하는 데이터 전송에 사용되는 토글 비트(toggle bit)이다. 비트 3~2는 어떠한 데이터도 포함하지 않으며 비트 0~1이 설정된 경우에만 유효하다. 비트 1은 SDO 채널을 통해 전송되는 메시지의 유형을 결정하며, 메시지가 분할 전송인지 또는 신속 전송인지를 나타낸다. 그림 3에 표시된 것처럼 SDO 데이터그램에서 마지막 4개 바이트는 전송될 필요가 있는 데이터 전용으로 할당된다. 만약 해당 데이터가 4바이트를 초과하면 분할 전송된다.
만약 SDO 데이터그램이 전체 데이터를 포함하고 있는 경우라면, 이는 신속 전송으로 간주된다. 따라서 비트 1이 높으면 신속 전송을 나타내고, 비트가 낮으면 분할 전송을 나타낸다. 분할 전송에서는 데이터가 패킷으로 전송된다. 서버는 데이터 필드에 데이터 크기를 제공함으로써 클라이언트의 초기 읽기/쓰기 요청에 응답한 다음, 네 번째 비트(토글 비트)가 각 데이터 패킷을 클라이언트로 전송하면서 토글하기 시작한다. 마지막으로 지정자 데이터그램의 비트 0이 설정되면 앞서 언급한 것처럼 비트 3~2에서 데이터 크기를 나타낸다.
그림 3. SDO 데이터그램 구조.
동작 | 클라이언트 요청(CCS) | 서버 응답 (SCS) |
SDO 다운로드 | 1 | 3 |
SDO 업로드 | 2 | 2 |
SDO 분할 다운로드 | 0 | 1 |
SDO 분할 업로드 | 3 | 0 |
SDO 데이터그램의 바이트 2~3과 바이트 4는 그림 3과 같이 각각 인덱스 및 서브 인덱스 바이트에 해당한다. 이 바이트들은 디바이스의 객체 사전에 있는 모든 객체에 액세스하는 데 사용된다. 객체 사전에는 모든 디바이스 매개변수가 포함되어 있어 사용자는 실시간 애플리케이션 요구 사항을 바탕으로 디바이스의 기능을 구성할 수 있다. 이 디바이스 프로파일링 개념은 드라이브와 같은 제어 장치이든, 간단한 I/O 구성 요소이든 관계없이 디바이스에 표준화된 동작을 제공한다. 앞서 설명한 대로 SDO 데이터그램의 마지막 4개 바이트는 SDO 계층을 통해 전송되어야 하는 데이터에 할당된다.
오류가 발생하면 SDO 전송이 중단되는데, 전송이 중지된 이유는 타깃 디바이스의 매뉴얼에 제공된 오류 코드 설명을 참조하여 파악할 수 있다. 이 경우 CCS 비트 값은 4이며, 인덱스 및 서브 인덱스는 전송 중 디바이스의 영향을 받는 매개변수를 지정하고, 마지막 4개 바이트는 오류 코드를 나타낸다.
실시간 통신 분석
이 섹션에서는 머신이 사전 동작 상태에 있는 동안 실시간 통신 로그 창을 사용하여 SDO 데이터그램을 설명한다. ADI Trinamic TMCM-6212 6축 스테퍼 모터 드라이버/컨트롤러는 QSH4218-35-10-027 [5] 스테퍼 모터와 함께 사용된다. 이 설정의 경우, 모터의 최대 전류(Object 2003h)는 200으로 설정된다. 클라이언트와 서버 간의 업로드 및 다운로드 트랜잭션은 그림 4와 같이 타깃 설정의 소프트웨어 인터페이스 로그 창에 강조된 메시지를 사용하여 추가로 설명한다.
그림 4. CANopen IDE
사례 1: 클라이언트와 서버 간의 다운로드 동작
클라이언트에 의해 시작: 0x601: 2f 03 20 c8 00 00 00 (그림 5)
그림 5. 클라이언트의 요청에 의해 다운로드 시작
서버의 응답: 0x581: 60 03 20 00 00 00 00 (그림 6)
그림 6. 서버에 의한 다운로드 응답.
그림 6에 표시된 작업에서 CCS와 SCS 비트의 조합은 클라이언트의 성공적인 쓰기 작업과 서버의 응답을 보여준다. 이는 표 2에서도 확인할 수 있다.
사례 2: 클라이언트와 서버 간의 업로드 동작
클라이언트에 의해 시작: 0x601: 40 03 20 00 00 00 00 (그림 7)
그림 7. 클라이언트의 요청에 의해 업로드 시작
서버의 응답: 0x581: 4f 03 20 00 c8 00 00 00 (그림 8)
그림 8. 서버의 업로드 응답
결론
CCS 및 SCS 비트의 조합은 클라이언트와 서버 간의 성공적인 업로드 동작을 나타낸다. 이 글에서 언급된 예제는 디바이스의 객체 사전에 있는 다른 객체에도 적용될 수 있으며, 이는 머신의 상태에 대한 인사이트를 제공한다. 이 시연의 주요 목적은 사용자가 통신 로그를 해독하고 드라이브의 상태를 모니터링 할 수 있도록 하는 것이다. 사용자는 실시간으로 오류를 해결하고 ADI Trinamic CANopen의 첨단 기능을 보다 효율적으로 탐색할 수 있다. ADI 제품에 CANopen 프로토콜을 통합하면 사용자는 자신의 PLC와 ADI Trinamic 모듈을 통합할 수 있는 유연성을 확보하여 멀티벤더 시스템을 개발할 수 있다. 이 인터페이스는 실험실 자동화, 로봇 공학, 용액 처리, 반도체 처리 등 복잡한 애플리케이션을 담당하는 작업자들에게 특히 유용하다.
참고 문헌
Olaf Pfeiffer, Andrew Ayre, and Christian Keydel. “Embedded Networking with CAN and CANopen.” Copperhill Technologies Corporation, 2008.
“TMCM-6212 CANopen Firmware Manual.” Trinamic Motion Control, 2018.
저자 소개
아툴 쿠마르(Atul Kumar)는 더블린 소재 센트럴 애플리케이션(Central Applications Dublin)의 애플리케이션 엔지니어로서, 모터 컨트롤, 저전력 스테퍼 모터에 대한 폐쇄 루프 제어 아키텍처, BLDC/PMSM 모터 부문을 주로 담당한다. 더블린 시립 대학교에서 대학원 과정을 마쳤으며, 2022년 2월 맥심 인터그레티드(Maxim Integrated, 현재 ADI의 일부)에 보조 애플리케이션 엔지니어로 합류했다