SDO 를통한디바이스구성 특수통신오브젝트, 소위 "service data objects" (SDO) 는 CANopen 장치에대한직접적인액세스에사용됩니다. 이러한 "service data objects" 로, 객체사전엔트리들은읽거나기록될수있으며, 반면두개의노드 ( 예. 구성되는노드와구성될노드 ) 들사이는논리적 1:1 연결 (peerto-peer) 이므로통신이항상발생합니다. 데이터전송이승인된서비스로이와같은연결을통해실행된다는것은, 연결마다두개의 CAN 메시지들이필요하다는의미이기도합니다 : 네크워크노드에요청할메시지 (SDO request 또는 "Client SDO") 와노드의응답용메시지 (SDO response 또는 "Server SDO"). 여기에포함된두개의네트워크노드들은 SDO client 나또는 SDO server 라일컬어집니다 ; 여기서서버는객체사전 (object dictionary) 을통해데이터를제공하거나수용하는것이고클라이언트는데이터를요청 (read) 하거나전송 (write) 하는것입니다. 이두개의파트너들사이에논리적연결이있는데, 이를 "SDO channel" 이라칭합니다. SDO 전송을위한개시는항상클라이언트에서비롯됩니다. SDO 전송이승인되면, 장치가의미있는데이터를제공할수없거나요청자체가이미오류가있을지라도, 모든요청이응답되어야합니다. 이와같은부정적응답 (negative response) 을 abort 라부릅니다. 이와같은응답에서는, abort 의원인을명시한, 4- long error code (abort code) 외에도, 비성공적인 SDO 전송을언급한객체사전엔트리의주소또한전송됩니다. 이미설명한대로, SDO 전송은항상별도의프로토콜에따라요청-응답순서로실행되며, 서비스데이터오브젝트의첫번째데이터바이트에명기됩니다. 따라서메시지식별자는 SDO 자체를지정하며 SDO 의첫번째데이터바이트는특정프로토콜을지정합니다. 이러한이유로첫번째데이터바이트는 protocol 또는 command 라부르기도합니다. SDO-message 는항상 8 길이이며, 필요하지않은데이터필드의비트는 0 으로설정되어야합니다. 어떤길이의데이터필드나 순서라도객체사전액세스를이용하여전송될수있습니다. 이러한이유로 SDO 프로토콜을통해전송될수있는정보의길이는이론적으로는무제한입니다. SDO 프로토콜은두단계로실행됩니다 : 초기단계에서객체사전엔트리는주소가지정되고전송될데이터길이가공개됩니다. 그러면두번째단계는세그먼트에서유틸리티데이터가전송됩니다 ( 각각 7 s). 이에따라, DS-301 은 4 개의서로다른 SDO 서비스들을구별합니다 : Initiate SDO Upload, Upload SDO Segment, Initiate SDO Download, Download SDO Segment. 매우흔히작은유틸리티데이터바이트만전송될경우도있기때문에, SDO 전송은단축될수있으며최대 4 s 까지초기화단계에서이미전송될수있습니다. 이것을 "expedited SDO transfer" 라부릅니다. Initiate SDO Download 서비스의메시지는, CANopen 노드의객체사전엔트리에대한 write 액세스가동시에일어나며, 다음과같은구조로되어있습니다.
mainindex subindex Data (max. 4 s) SDO 서버는프로토콜 0x60 으로응답합니다 : 0x60 mainindex subindex Empty (4 ) bit-coded 명령바이트에서는서비스가 3 bit (command specifier) 코드로되어있습니다. 또다른 bit 는 expedited 또는 non-expedited 전송이실행될것인지를지정합니다. 추가 bit 는전송될데이터크기가통신오브젝트의마지막 4 에지정될것인지를알려줍니다 ; 그러나, 이 bit 는 non-expedited 전송에만사용됩니다. expedited transfer 에서, 한편으로, 사용자데이터는이러한최종 4 내에서직접전송됩니다. 프로토콜바이트의추가 2 bit 는이러한 들이실제로얼마나할당되는지를명시합니다 ( 사용자데이터의단 1 전송도가능합니다 ). 따라서사용자데이터는반드시 SDO 오브젝트의데이터영역에서왼쪽-정렬에위치해있어야합니다. 일반적으로 CANopen 에서데이터는 "Little Endian" 규칙, 즉관련 INTEL 프로세서의형태에따라전송된다는것에유의해야합니다. 이는낮은값의 가먼저전송된다는것을뜻합니다. 이것은인간이측정된 SDO 프로토콜순서를따라가는것을약간어렵게만들지만결국은습관화의문제입니다. 이제까지설명한프로토콜바이트의 bit 를세어보면, 7 bit 들이있습니다. 8 번째 bit 는따로남겨둡니다. entry [1017] 에대한 SDO 다운로드는, heartbeat producer 의 hearbeat 간격으로, 4 초 (in ms as an UNSIGNED16 value, i.e. 0x0F A0) 로설정되므로다음과같이나타납니다 : 2B 17 10 00 A0 0F 00 00 그런후노드 (SDO 서버 ) 는메시지로성공적인완료를인지합니다 60 17 10 00 00 00 00 00
초기의 SDO Upload service 로, CANopen 노드의객체사전엔트리가읽혀지면서, 데이터영역의동일한 division 이유효하게되고, 단이곳에서의요청과응답정보들은어느정도달라집니다 (reverse). 여기서클라이언트요청의명령바이트는 0x40 입니다 : (0x40) Main Sub Empty (4 s) SDO 서버는다음으로응답합니다 : Main Sub Data (4 s) SDO 서버는디바이스제조사 (vendor ID; found under subindex 1 of the identity object [1018]) 를읽기위한일반적인요청에항상응답해야하는데, 그것은이 -entry 가강제적인것이기때문입니다. 여기의예에서, 이디바이스는 IXXAT 사 (vendor no.: 00 00 00 04) 것입니다. 따라서 SDO 응답메시지는다음과같습니다 : 43 18 10 01 04 00 00 00 "expedited transfer" 가사용되지않는다면, Initiate SDO service 의 4 개 data 는전송될사용자데이터의길이 () 를지정하는데사용될수있습니다. 그러면실제전송은, Download SDO Segment 또는 Upload SDO Segment service 와같이발생합니다. 세그먼트마다사용자데이터의 7 가전송될수있습니다. 이러한서비스들의 command 는, 최종세그먼트를제외하고, service-id (command specifier) 의 3 bit, 한개의 toggle bit 와네개의 unused bit 를포함합니다. 또한세그먼트사이즈 7 의배수가아닌사용자데이터를안전하게전송하기위해서 unused (6 과 0 사이의값 ) 의수는최종 SDO 세그먼트의 3 bit 에코딩됩니다. 마지막으로 command LSB 는데이터전송의끝을표시합니다. 세그먼트순서는 SDO 요청과 SDO 응답메시지가순환적으로변환 (toggle) 되는 toggle bit 에의해관찰됩니다. 아래에 non-expedited segmented SDO upload 의코멘트순차가설명되어있습니다. 40 08 10 00 00 00 00 00 // Initiate req: Read Device Name [1008] 41 08 10 00 1A 00 00 00 // Initiate resp: Fine. It's 26 s long 60 00 00 00 00 00 00 00 // Upload segment req, Toggle = 0 00 54 69 6E 79 20 4E 6F // Upload segment resp, Toggle = 0 70 00 00 00 00 00 00 00 // Upload segment req, Toggle = 1 10 64 65 20 2D 20 4D 65 // Upload segment resp, Toggle = 1
60 00 00 00 00 00 00 00 // Upload segment req, Toggle = 0 00 67 61 20 44 6F 6D 61 // Upload segment resp, Toggle = 0 70 00 00 00 00 00 00 00 // Upload segment req, Toggle = 1 15 69 6E 73 20 21 00 00 // Last segment, 2 s free, Toggle = 1 CANopen specification DS-301 의버전 4 에서는, 새로운, 상당히더욱효과적이면서도한층정교해진 SDO 모드가소개되어있는데, 그것이바로 SDO block transfer 입니다. 위에서설명한세그먼트전송과는대조적으로, 여기서의세그먼트들은더이상개별적으로인지되지않으며, 함께블록으로들어가는데, 이것들은하나씩각각전송됩니다. 그러면파트너가그블록을인지합니다. 29 의사용자데이터크기에서, 프로토콜오버헤드관점에서는블록전송이더좋습니다. 블록전송에서, 프로토콜바이트는각블록의개별세그먼트의수를세는데, 블록당최대 127 세그먼트가가능합니다. 전송은초기 (initialization) 단계에서, 양쪽파트너들의유틸리티데이터크기와블록사이즈가서로맞게만들어지고, 종료 (termination) 단계에서, 초기화동안에통신파트너들이이에동의했다면, 전체전송에관한 CRC check sum 이기록됩니다. 그러나 SDO 블록전송은현재몇몇디바이스들만지원하고있습니다. 객체사전엔트리 [1008] 에대한 SDO read 액세스, 디바이스이름은, 블록전송이므로다음과같습니다 : A4 08 10 00 21 00 00 00 // Initiate req: Read [1008], Blocksize 33, CRC supported C2 08 10 00 1A 00 00 00 // Initiate resp: It's 26 s long, no CRC A3 00 00 00 00 00 00 00 // Initiate block req: Let's go 01 54 69 6E 79 20 4E 6F // Upload block resp, Segment = 1 02 64 65 20 2D 20 4D 65 // Upload block resp, Segment = 2 03 67 61 20 44 6F 6D 61 // Upload block resp, Segment = 3 84 69 6E 73 20 21 00 00 // Last segment, Segment = 4 A2 04 21 00 00 00 00 00 // Upload block req: 4 segments received, Blocksize 33 C9 00 00 00 00 00 00 00 // End resp: 2 s free A1 00 00 00 00 00 00 00 // End req: Thank you 중요한 SDO 서비스는 "Abort SDO Transfer" (command : 0x80) 입니다. 이는정확히한개의 CAN 메시지로구성되며, 정기적인 SDO 프로토콜메시지대신, 두개의파트너들가운데어느쪽에의해서도아무때나전송될수있으며 SDO 전송의즉각적인종료를가져옵니다. 가장흔한상황은주소가매겨진객체사전엔트리가존재하지않을때초기 SDO 요청에대한응답으로써의 SDO-Abort 입니다. Abort SDO 메시지의구조는다음과같습니다 : 0x80 main- sub- Abort code index index
이 SDO 서비스의데이터영역은 dword 로오류원인 (abort code) 을포함하고있습니다. CANopen specification 에는정의되어있는모든 abort code 리스트가있습니다. 총 30 여개정도입니다. 독자적인 abort code 또는비-정의된코드의사용은허용되지않습니다. 가장중요한 abort code 는다음과같습니다. 0x05030000 Toggle bit not alternated 0x05040001 Invalid SDO specifier 0x0601000x Unsupported access to an object 0x06010002 Attempt to write a read only object 0x06020000 Object does not exist in the object dictionary 0x0607001x Data type does not match 0x06090011 Subindex does not exist 0x08000000 General error 모든디바이스는적어도한개의서버 SDO 채널을지원해야합니다. 추가로더많은 SDO 채널들이객체사전엔트리 (object dictionary entry) 를통해설정될수있습니다. pre-defined record SDO 파라매터를이용하여 [1201] 부터 [127F] 까지의 엔트리들이서버 SDO 채널의정의를위해준비되어있습니다.