Apparaat Configuratie via SDO's

Service Data Objects (SDO's)

Specifieke communicatie-objecten, de zogenaamde "Service Data Objects" (SDO's) worden gebruikt voor directe toegang tot CANopen apparaten. Met deze "Service Data Objecten" kunnen Object Directory items worden gelezen en geschreven, waarbij de communicatie altijd plaatsvindt als een 1:1-verbinding (peer-to-peer) tussen twee nodes (bijvoorbeeld een configuratie node en een node die geconfigureerd wordt ). De overdracht van gegevens vindt plaats met ontvangst bevestiging, en dat betekent dat er twee CAN-berichten per aansluiting zijn vereist: een bericht voor het verzoek aan de netwerk node (SDO aanvraag of "Client SDO") en een tweede voor de reactie (SDO reactie of "Server SDO") van de node.

CANopen SDO verzoek gevolgd door een SDO reactie
SDO Verzoek & Reactie
CANopen SDO verzoek gevolgd door een SDO reactie
SDO Verzoek & Reactie

De twee betrokken netwerk nodes worden aangeduid als SDO client en / of SDO-server. Hierbij is het de server-ID degene die de gegevens aanlevert of accepteert, via de Object Directory en de client is degene die de gegevens verzoekt (leest) of oplevert (schrijft). Er is een logische verbinding tussen beide nodes, die ook wordt aangeduid als een “SDO Channel". Het initiatief voor een SDO overdracht komt altijd van de client. Iedere SDO overdracht wordt beantwoord met een ontvangstbevestiging, zelfs als het apparaat niet in staat is hiertoe zinvolle gegevens te leveren, of het oorspronkelijke overdracht was foutief. Zo'n negatieve reactie heet "Abort" (afgebroken). In dergelijke reactie wordt, naast de 4-byte foutcode (“Abort Code”), tevens het adres van de Object Directory waarnaar de mislukte SDO-overdracht refereerde verzonden. Zoals reeds vermeld, een SDO overdracht loopt altijd als een verzoek/reactie sequentie volgens een apart protocol, dat wordt vermeld in het eerste data byte van het Service Data Object. Daarvoor specificeert het bericht-ID (CAN-ID) de SDO zelf en het eerste data byte van dit SDO het specifieke protocol. Daarom wordt dit eerste data byte in een SDO ook het protocol- of commando-byte genoemd. Een SDO-bericht bevat altijd acht data bytes, bits van deze byte’s die niet benodigd zijn moeten op 0 worden gezet. Het is mogelijk om data-velden van iedere lengte, of opeenvolgende byte-sequenties, naar een Object Directory item te zenden. Hierdoor is de hoeveelheid informatie die via het SDO protocol verzonden kan worden theoretisch onbeperkt. Het SDO protocol wordt uitgevoerd in twee fasen: In de initialisatiefase wordt en Object Directory item geadresseerd en de lengte van de data over te dragen gemeld. In de tweede fase worden de daadwerkelijke informatie verzonden in segmenten (steeds zeven bytes groot). Dienovereenkomstig maakt DS-301 hierbij een onderscheid tussen vier verschillende SDO diensten: Initiate SDO upload (=Start), Upload SDO Segment, Initiate SDO Download (=Start) en Download SDO Segment.

Versnelde SDO transfer

Omdat vaak slechts enkele informatie bytes behoeven te worden verzonden, kan de SDO overdracht worden verkort en kunnen tot maximaal vier informatie- bytes reeds in de initialisatiefase verzonden worden. Dit wordt aangeduid als een "Expedited SDO Transfer “ (=versnelde SDO transfer). Het bericht “Initiate SDO Download” om het downloaden te starten, waarmee tegelijkertijd schrijftoegang tot een Object Directory item van een CANopen node ontstaat, heeft het volgende formaat:

CANopen SDO bericht: initieer download

De SDO-server antwoordt met commando byte 0x60:

CANopen SDO bericht: server reactie op initieer download

In het bit-gecodeerde commando-byte is de SDO-dienst gecodeerd met behulp van drie bits (Command Specifier). Een ander bit geeft aan of een versnelde of een niet-versnelde overdracht (Expedited SDO Transfer) moet worden uitgevoerd. Een volgend bit geeft aan of de omvang van de te uit te wisselen informatie wordt aangeduid in de laatste vier bytes van dit object, maar dit bit wordt enkel gebruikt bij niet-versnelde overdracht. Bij een versnelde overdracht wordt de daadwerkelijke informatie direct verzonden in de laatste vier bytes. Twee andere bits van het commando byte hoeveel van deze bytes daadwerkelijk gebruikt zijn. Zodoende is de overdracht van slechts één informatie byte ook mogelijk. De informatie byte’s moeten daarbij links uitgelijnd worden geplaatst in het data-veld van het SDO object. In het algemeen kan worden opgemerkt dat in CANopen gegevens worden verzonden volgens de "Little Endian" regel ook bekend als de Intel-vorm. Dit betekent dat informatie die uit meervoudige databyte’s bestaat eerst de lage waarde byte (LSB) wordt uitgezonden en de hoogste waarde als laatste (MSB). Dit maakt het iets moeilijker voor een mens om een gemonitorde SDO-stroom te volgen, wij lezen immers van hoog (MSB) naar laag (LSB), maar uiteindelijk is dit een kwestie van gewenning. Hierboven zijn 7 bits van het command-byte besproken, het achtste bit is gereserveerd. Als voorbeeld een SDO download naar het Object Directory-item [1017], waarmee de hartslag interval van een hartslag generator geconfigureerd wordt, moet worden ingesteld op 4 seconden. Deze waarde wordt in ms uitgedrukt, dat wil zeggen 0x0FA0 (400). Dit CANopen bericht ziet er als volgt uit:

CANopen SDO bericht: initieer download naar object 1017

De geadresseerde node (SDO server) bevestigt de succesvolle afronding met de boodschap:

CANopen SDO bericht: server reactie op initieer download naar object 1017

Met het starten van een “SDO Upload service”, waarmee een Object Directory-item uitgelezen kan worden, is dezelfde berichtindeling geldig. Alleen is hierbij natuurlijk de datastroom (en datavelden) tot op zekere hoogte omgekeerd. Hier is het commando byte van de klant verzoek 0x40:

CANopen SDO bericht: Service verzoek

De SDO-server reageert met:

De SDO-server moet, als voorbeeld, altijd op een verzoek tot het uitlezen van het unieke fabrikant-ID van het apparaat (Vendor-ID; subindex 1 van object [1018]) reageren, omdat deze OD-entry verplicht is. In dit voorbeeld, meldt het apparaat fabrikant IXXAT (Vendor-ID = 00 00 00 04) het volgende Vendor-ID:

CANopen SDO bericht: server reactie op service verzoek object 1018

Standaard transfer

Als er geen "versnelde SDO transfer" wordt gebruikt, kunnen de vier databytes van het “Initiate SDO”-bericht gebruikt worden om de lengte (in bytes) van de daadwerkelijke informatie aan te geven. De feitelijke overdracht vindt vervolgens plaats met de “Download SDO Segment” of “Upload SDO Segment” berichten. Dergelijke berichten bestaan (ok) uit een commando bericht en er kunnen 7 informatiebytes per segment worden overgedragen. Het commando byte van deze diensten bevat drie bits van de service-ID (command specificatie), een togglebit en vier ongebruikte bits behalve in het laatste segment. Omdat het laatste segment niet geheel met informatie gevuld behoeft te zijn wordt het aantal gebruikte informatiebytes (tussen 6 en 0) gecodeerd in drie bits van het laatste SDO segment-bericht. Ten slotte markeert het commando bytes LSB het einde van de gegevensoverdracht. De segment volgorde wordt gecontroleerd via het toggle bit, dat per SDO verzoek- / SDO antwoordberichtencombinatie wordt omgeschakeld. De sequentie van een niet-versnelde gesegmenteerde SDO upload wordt geïllustreerd in het volgende voorbeeld:

40 08 10 00 00 00 00 00   // Start aanvr: Lees Apparaatnaam [1008]
41 08 10 00 1A 00 00 00   // Start resp: Fine. Het is 26 bytes lang
60 00 00 00 00 00 00 00   // Upload segment req, Schakelen = 0
00 54 69 6E 79 20 6F 4E   // Upload segment resp, Toggle = 0
70 00 00 00 00 00 00 00   // Upload segment req, Schakelen = 1
10 64 65 20 2D 20 4D 65   // Upload segment resp, Schakelen = 1
60 00 00 00 00 00 00 00   // Upload segment req, Schakelen = 0
00 67 61 20 44 6F 6D 61   // Upload segment resp, Schakelen = 0
70 00 00 00 00 00 00 00   // Upload segment req, Schakelen = 1
15 69 6E 73 20 21 00 00   // Laatste segment, 2 bytes beschikbaar, Toggle = 1

Met versie 4 van de CANopen-specificatie DS-301 is een nieuwe, aanzienlijk effectiever, maar ook ingewikkelder SDO-modus ingevoerd, de zogenaamde SDO Block Transfer. In tegenstelling tot de segmentoverdracht hierboven beschreven, wordt niet meer per segment een ontvangstbevestiging verstuurd , maar zijn deze samengevoegd in blokken die in één keer verzonden worden. De andere kant verstuurt dan enkel een ontvangstbevestiging voor het gehele blok. Indien de daadwerkelijke informatiegrootte groter is dan 29 bytes, dan is deze Block Transfer efficiënter gelet op de protocol-overhead. Bij Block Transfer nummert het commando-byte de afzonderlijke segmenten van elk blok, zodat één blok maximaal 127 segmenten kan bevatten. De transmissie bestaat uit een initialisatiefase, waarbij de blokgrootte en de hoeveel informatiebytes wordt uitgewisseld en met een eindfase, waarin een controlesom (CRC)over de volledige overdracht plaatsvind, als dit tijdens de initialisatie is afgesproken. Omdat niet alle apparaten aan DS-301 v4 voldoen is het raadzaam om te checken of Block Transfer ondersteund wordt. Een SDO leestoegang tot Object Directory item [1008], het opvragen van de zogenaamde apparaat naam, ziet er in Block Transfer als volgt uit:

A4 08 10 00 21 00 00 00   // Start aanvr: Lees [1008], Blocksize 33, CRC ondersteund
C2 08 10 00 1A 00 00 00   // Start resp: Het is 26 bytes lang, geen CRC
A3 00 00 00 00 00 00 00   // Start blok aanvr: Let's go
01 54 69 6E 79 20 6F 4E   // Upload blok resp, Segment = 1
02 64 65 20 2D 20 4D 65   // Upload blok resp, Segment = 2
03 67 61 20 44 6F 6D 61   // Upload blok resp, Segment = 3
84 69 6E 73 20 21 00 00   // Laatste segment Segment = 4
A2 04 21 00 00 00 00 00   // Upload blok aanvr: 4 segmenten ontvangen, Blocksize 33
C9 00 00 00 00 00 00 00   // Einde resp: 2 bytes beschikbaar
A1 00 00 00 00 00 00 00   // Einde aanvr: Dank u

Abort

Een belangrijke SDO service is de "Abort SDO Transfer" (commando 0x80). Het bestaat uit precies één CAN bericht en kan te allen tijde worden gezonden door een van beide partners. Dit gebeurd dan in plaats van een normale SDO protocol bericht en leidt tot directe beëindiging van het SDO transmissie. De meest voorkomende situatie is de SDO-Abort als een reactie op een afgewezen SDO verzoek indien het geadresseerde Object Directory item niet bestaat. De structuur van het Abort SDO bericht is:

CANopen SDO abort bericht

De gegevensveld van deze SDO bevat de oorzaak van de fout (Abort code). De CANopen-specificatie bevat een overzicht van alle gedefinieerde Abort codes. Er zijn ca. 30 in totaal. Het gebruik van eigen Abort Codes of niet-gedefinieerde codes is niet toegestaan. De belangrijkste codes zijn:

Abort Codes
0x05030000 Toggle bit niet afgewisseld
0x05040001 Ongeldige SDO Command specifier
0x0601000x ondersteunde toegang tot een object
0x06010002 Poging om een alleen-lezen object te schrijven
0x06020000 Object bestaat niet in het object woordenboek
0x0607001x Data type komt niet overeen
0x06090011 Subindex bestaat niet
0x08000000 Algemene fout

SDO kanalen

Ieder apparaat moet ten minste een server SDO kanaal ondersteunen. Aanvullende SDO kanalen kunnen worden ingesteld via de Object Directory. De OD items [1201] t/m [127F] met de vooraf gedefinieerde SDO bestandsparameter s zijn gereserveerd voor de definitie van de server SDO kanalen.