견고한 통신 프로토콜과 인터페이스는 산업용 모터 제어 애플리케이션에서 중요한 역할을 한다. 여러 프로세서 요소가 복잡한 작업을 수행하기 위해 지속적으로 통신해야 하는 상황에서, 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 프로토콜의 다양한 활용 원칙에 대해 설명한다.

 

1. 네트워크 관리(NMT)

NMT는 모든 CANopen 호환 장치가 준수해야 하는 중요한 통신 원칙이다. 이는 상태 머신(State Machine)으로 동작하며, CANopen 프레임워크 내의 애플리케이션을 조정하는 데 중요한 역할을 한다.

 

2. 네트워크 관리 상태 머신 아키텍처

NMT 상태 머신은 그림 1과 같이 다음과 같은 3가지 상태로 구성된다.

 

· 초기화 상태(Initialization State)

· 사전 동작 상태(Preoperational State)

· 동작 상태(Operational State)

 

 

클라이언트 노드는 다양한 동작 상태에서 서버 노드의 통신 상태를 관리 및 감독하는 중요한 역할을 한다. 이는 NMT 메커니즘을 통해 구현된다. 클라이언트 노드는 ‘하트비트(Heartbeat)’와 ‘노드 가드(Node Guarding)’라는 두 가지 독특한 방법을 통해 서버 노드의 통신 무결성을 평가한다. TMCM-6212의 경우 하트비트 기술을 사용하여 적절한 통신을 검증한다. 각 노드는 객체 1017h를 사용해 밀리초(ms) 단위로 측정되며 사용자 설정이 가능한 시간 주기의 하트비트 신호를 방출한다. 이를 통해 모든 노드가 활성화되고 통신 가능한 상태임을 보장한다.

 

표 1은 서로 다른 다양한 통신 상태에서 사용되는 모든 통신 객체의 조합을 보여준다. 장치가 전원을 켜거나 재설정한 후 초기화 상태에 들어가면 부팅 메시지가 생성된다. 이후 장치는 작업 준비가 된 사전 동작 상태로 전환된다. 사전 동작 상태에서는 네트워크의 모든 노드가 SDO, 하트비트/노드 보호, 비상 상황 및 시간/동기화와 관련된 모든 객체를 전송할 수 있다. 동작 상태에서는 PDO 객체를 사전 동작 상태에서 사용할 수 있는 모든 객체에 추가하여 매핑할 수 있다. 마지막으로 중지 상태에서는 장치가 모든 SDO 및 PDO 객체의 통신을 비활성화하고 NMT 명령만 허용한다.

 

 

2. 서비스 데이터 객체(SDO)

SDO 통신 프로토콜은 주로 NMT 상태 머신의 사전 동작 상태에서 사용된다. 이 프로토콜은 클라이언트가 연결된 모든 서버 노드의 객체 사전(Object Dictionary)에 있는 모든 객체에 액세스할 수 있는 클라이언트-서버 구성으로 작동한다. 클라이언트는 항상 특정 노드와의 읽기/쓰기 트랜잭션을 시작하며, 서버는 작업 완료를 확인한다. 이 과정은 모든 SDO 트랜잭션이 정상적으로 확인되었음을 보장한다.

 

그림 2는 멀티노드 네트워크에서 SDO 프로토콜의 클라이언트-서버 기반 구성을 보여준다. 각 노드에는 클라이언트와 통신할 수 있는 채널이 할당된다. 이 경우 Trinamic TMCM-6212 6축 스테퍼 모터 드라이버/컨트롤러가 서버 역할을 하고, 연결된 PC가 클라이언트 역할을 하여 특정 노드(노드-1)와의 읽기/쓰기 트랜잭션을 시작한다. 모든 노드가 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개의 비트(75)는 메시지의 성격에 대한 주요 정보를 제공한다. 클라이언트 명령 지정자는 읽기, 쓰기, 분할/신속 전송 또는 트랜잭션 오류 등 클라이언트의 작동에 따라 구성이 달라진다. 서버의 응답에서는 지정자의 3개 비트(서버 명령 지정자: Server Command Specifier, SCS)가 트랜잭션의 성공 여부를 결정한다. 표 2는 다양한 작업에 대한 CCS와 SCS 비트의 조합을 보여준다. 지정자 데이터그램의 비트 4는 4바이트를 초과하는 데이터 전송에 사용되는 토글 비트(Toggle Bit)이다. 비트 32는 어떠한 데이터도 포함하지 않으며, 비트 0~1이 설정된 경우에만 유효하다. 비트 1은 SDO 채널을 통해 전송되는 메시지의 유형을 결정하여 메시지가 분할 전송인지 신속 전송인지를 나타낸다.

 

그림 3에 표시된 것처럼 SDO 데이터그램의 마지막 4개 바이트는 전송될 데이터를 위한 공간으로 할당된다. 만약 데이터가 4바이트를 초과하면 분할 전송된다. SDO 데이터그램이 전체 데이터를 포함하고 있는 경우 신속 전송으로 간주된다. 비트 1이 높으면 신속 전송을, 낮으면 분할 전송을 나타낸다. 분할 전송에서는 데이터가 패킷 단위로 전송된다. 서버는 데이터 필드에 데이터 크기를 제공해 클라이언트의 초기 읽기/쓰기 요청에 응답하고, 네 번째 비트(토글 비트)를 이용해 각 데이터 패킷을 전송하면서 토글한다. 마지막으로, 지정자 데이터그램의 비트 0이 설정되면 비트 3~2에서 데이터 크기를 나타낸다.

 

SDO 데이터그램의 바이트 2~3과 바이트 4는 그림 3과 같이 각각 인덱스 및 서브 인덱스 바이트에 해당한다. 이 바이트들은 디바이스의 객체 사전에 있는 모든 객체에 액세스하는 데 사용된다. 객체 사전에는 모든 디바이스 매개변수가 포함되어 있어 사용자는 실시간 애플리케이션 요구 사항에 따라 디바이스의 기능을 구성할 수 있다. 이러한 디바이스 프로파일링 개념은 드라이브 같은 제어 장치든, 간단한 I/O 구성 요소든 관계없이 디바이스에 표준화된 동작을 제공한다. 앞서 설명한 바와 같이 SDO 데이터그램의 마지막 4개 바이트는 SDO 계층을 통해 전송될 데이터를 위한 공간으로 할당된다.

 

오류가 발생하면 SDO 전송이 중단되며, 그 이유는 타깃 디바이스의 매뉴얼에 제공된 오류 코드 설명을 통해 확인할 수 있다. 이 경우 CCS 비트 값은 4이고, 인덱스 및 서브 인덱스는 전송 중 디바이스에 영향을 주는 매개변수를 지정하며, 마지막 4개 바이트는 오류 코드를 나타낸다.

 

실시간 통신 분석

 

이 섹션에서는 머신이 사전 동작 상태에 있는 동안 실시간 통신 로그 창을 사용해 SDO 데이터그램을 설명한다. ADI Trinamic TMCM-6212 6축 스테퍼 모터 드라이버/컨트롤러는 QSH4218-35-10-027 스테퍼 모터와 함께 사용된다. 이 설정에서는 모터의 최대 전류(Object 2003h)가 200으로 설정된다. 클라이언트와 서버 간의 업로드 및 다운로드 트랜잭션은 그림 4와 같이 타깃 설정의 소프트웨어 인터페이스 로그 창에 강조된 메시지를 사용해 추가로 설명된다.

 

 

사례 ①-클라이언트와 서버 간의 다운로드 동작

 

· 클라이언트에 의해 시작: 0x601: 2f 03 20 c8 00 00 00 (그림 5)

 

 

· 서버의 응답: 0x581: 60 03 20 00 00 00 00 (그림 6)

 

 

그림 6에 표시된 작업에서 CCS와 SCS 비트의 조합은 클라이언트의 성공적인 쓰기 작업과 서버의 응답을 보여준다. 이는 표 2에서도 확인할 수 있다.

 

 

사례 ②-클라이언트와 서버 간의 업로드 동작

 

· 클라이언트에 의해 시작됨: 0x601: 40 03 20 00 00 00 00 (그림 7)

 

 

· 서버의 응답: 0x581: 4f 03 20 00 c8 00 00 00 (그림 8)

 

 

결론

 

CCS 및 SCS 비트의 조합은 클라이언트와 서버 간의 성공적인 업로드 동작을 나타낸다. 이 글에서 언급된 예제는 디바이스의 객체 사전에 있는 다른 객체에도 적용될 수 있으며, 이는 머신의 상태에 대한 인사이트를 제공한다. 이번 시연의 주요 목적은 사용자가 통신 로그를 해독하고 드라이브의 상태를 모니터링할 수 있도록 돕는 것이다. 사용자는 실시간으로 오류를 해결하고 ADI Trinamic CANopen의 첨단 기능을 보다 효율적으로 탐색할 수 있다.

 

ADI 제품에 CANopen 프로토콜을 통합하면 사용자는 자신의 PLC와 ADI Trinamic 모듈을 유연하게 통합해 멀티벤더 시스템을 개발할 수 있다. 이러한 인터페이스는 실험실 자동화, 로봇 공학, 용액 처리, 반도체 처리 등 복잡한 애플리케이션을 담당하는 작업자들에게 특히 유용하다.