Proces informatie-uitwisseling met PDO

Broadcasting

De belangrijkste taak van een CANopen systeem is natuurlijk de uitwisseling van procesgegevens. Hiervoor worden niet alleen de meeste van de CAN-ID’s gereserveerd, maar ook het grootste deel van de Object Directory. Voor de transmissie van procesgegevens gebeurt dit zonder extra protocol overhead en verloopt volgens het zogenaamde "producent / consumenten principe". Dit betekent dat een bericht verzonden door een CAN node (de "producent") kan worden ontvangen door alle andere CAN nodes (de "consumenten"). Dit principe wordt aangeduid als "broadcasting" en is een zeer effectieve manier van datatransmissie, vooral als een bericht (bijvoorbeeld een synchronisatie-bericht) wordt verzonden aan alle procesdeelnemers tegelijkertijd.

Process Data Object (PDO)

Een CANopen-bericht dat proces gegevens bevat heet "Process Data Object" (PDO). Zoals reeds beschreven, de overdracht van PDO's is enkel mogelijk in de "Operational" status. PDO's hebben geen vaste indeling. Het dataveld van een PDO kan één tot acht data bytes groot zijn. De inhoud van een PDO kan ook niet gemakkelijk zomaar geïnterpreteerd worden. Het basisidee is dat zowel de zender als de ontvanger weet hoe de inhoud van een PDO gedefinieerd is. Daarom is het voldoende om de PDO te identificeren enkel aan het COB-ID (CAN Object Identifier). De zogenaamde "PDO mapping" beschrijft welke individuele procesvariabelen in het dataveld van een PDO zijn opgenomen, hoe ze zijn gearrangeerd en welke datatype en –lengte ze hebben. Daarvoor is de inhoud en de betekenis van ieder dataveld van elk gedefinieerd PDO is beschreven in de vorm van een PDO-mapping record in de Object Directory van zowel de CANopen zender als de ontvanger(s). De PDO producent stelt het dataveld van een PDO samen overeenstemming haar TxPDO-mapping. Hiervoor kopieert deze de actuele gegevens van de variabelen uit de Object Directory en kopieert deze in het dataveld van de PDO voordat het CAN-bericht (PDO) verzonden wordt. Hetzelfde gebeurt aan de consumentzijde: op basis van de RxPDO-mapping record, worden de databytes van de ontvangen PDO's gekopieerd naar het lokale Object Directory. De apparaat besturingssoftware zal vervolgens deze informatie gebruiken om apparaat-specifieke acties in gang te zetten. Bijvoorbeeld het schakelen van digitale uitgangen. Een CANopen node dat een bepaalde PDO wenst te ontvangen hoeft enkel de ontvangst van het bijbehorende CAN-bericht te activeren. Dit gebeurt met "set valid" van de desbetreffende COB-ID item in de OD. Maar terug naar de PDO-mapping. Het principe van de inrichting (mapping) van procesvariabelen wordt uitgelegd in de volgende figuur. De variabelen in de vorm van Object Directory items in het toepassing profiel). De mapping van de afzonderlijke CANopen proces variabelen in het dataveld van een PDO is beschreven in de vorm van een tabel. Dit wordt ook gegeven als een Object Directory item, en wel voor iedere zend- en ontvang-PDO in [16xx] of [1Axx]. Deze tabellen, en de mapping van de proces variabelen in het dataveld van een PDO kan worden geconfigureerd via SDO schrijftoegang.

PDO Mapping voorbeeld

In dit voorbeeld zijn er precies twee objecten links: van object (proces variabele) [2345sub67] van de PDO producent naar object [5432sub10] van de PDO consument en van het object [6000sub01] van de producent naar object [6200sub02] van de consument. Het derde zend object [2001sub00] is niet gedefinieerd aan de ontvangerszijde en derhalve afgedekt via een zogenaamde dummy object. De mapping tabellen zijn van type "PDO Mapping", en bevatten in subindex 0 het aantal toegewezen objecten en in subindex 1 tot 8 de mapping Object Directory items zelf als DWORD. Dit bevat het 24-bit lange OD adres (index subindex) en de 8-bits gecodeerd lengte van het OD item. Een CANopen apparaat dat 8 mappings ondersteunt heeft een gevoeligheid van 8 en kan byte-gewijs mapping uitvoeren. CANopen apparaten met een gevoeligheid van 1 aan de andere kant ondersteunen mapping van elk PDO bit ("bit-mapping"). In dat geval komen er 64 vermeldingen in de mapping tabel.

Communicatie parameters(PDO)

Echter een PDO is niet alleen door de mapping beschreven maar ook door de CANopen communicatie parameters. Deze zijn: COB-ID, dat wil zeggen de CAN-ID, "transmissie type", "inhibit time", en kunnen allemaal worden geconfigureerd via overeenkomstige Object Directory items. De plaats van dit extra Object Directory item heeft een offset van 0x200 vóór het oorspronkelijke mapping item, dat wil zeggen voor transmit PDO [18xx] en voor ontvangst PDO [14xx]. Elke PDO wordt dan ook beschreven door twee verschillende OD items, die hecht bij elkaar horen. Beiden worden geconfigureerd door de systeem integrator. De volgende tabel toont het record "PDO parameter":  

Subindex 1 bevat de CAN-identifier van de PDO als DWORD. De MSB bit geeft aan of de PDO actief (geldig) of inactief (ongeldig) is. Een set MSB ongeldig betekent een waarde van 0x80000199 bijvoorbeeld beschrijft een ongeldige eerste TxPDO van de node met het nummer 25. De transmissie type van een PDO kan worden ingesteld via de tweede subindex. Het is noodzakelijk om eerst synchrone en asynchrone PDO te onderscheiden:  

Asynchrone PDO's

Asynchrone PDO's zijn event-gestuurde en vertegenwoordigen de normale transmissie type PDO's. Dit betekent dat wanneer tenminste één van de proces variabelen, die in de PDO gedefinieerd zijn, wordt veranderd (bijvoorbeeld de verandering van een ingangswaarde), de PDO onmiddellijk verzonden wordt. Voor deze, de waarden 255 of 254 moeten worden ingevoerd als PDO type.

Synchrone PDO's

Synchrone PDO's worden alleen verzonden na voorafgaande ontvangst van een synchronisatie-bericht (Sync Object). De PDO informatieoverdracht wordt daarmee synchroon gerealiseerd in het totale netwerk, min of meer tegelijk. Veel belangrijker is echter dat alle ingangen dienen te worden bemonsterd bij de ontvangst van de sync object, zodat een uniforme momentopname van de procesgegevens ontstaat. Met het volgende synchronisatie-bericht, worden de geregistreerde gegevens dan verzonden in de synchrone PDO’s. Daarom is er een vertragingstijd die overeenkomt met de cyclustijd van het synchronisatie-bericht, omdat de consument de procesvariabelen ontvangt op het tijdstip van de vorige Sync bericht. Ook in de uitgangrichting worden de gegevens via de ontvangen synchrone PDO's pas geldig bij de ontvangst van het volgende synchronisatie bericht. Zodoende lopen in- en uitgangsgegevens ongeveer in de pas.

Sync-interval

Om te voorkomen dat de bus geblokkeerd kan worden door een groot aantal synchrone PDO’s, die ten gevolge van ieder Sync bericht verzonden worden, werken de waarden 1 t/m 240 van het synchrone PDO-type als de cyclische tellers voor de zendinterval. Bijvoorbeeld [18xxsub02] = 4 betekent dat de synchrone PDO alleen wordt verzonden na elk vierde Sync bericht. Los daarvan moet het apparaat altijd ingangen bij ieder Sync-bericht bemonsteren, omdat het kan gebeuren dat synchroon opgenomen procesvariabelen in een PDO worden opgevraagd door RTR. In dit geval dient het CANopen-apparaat de overeenkomstige PDO, met synchroon geregistreerde waarden, direct te verzenden. In [1006], de parameter "Communication Cycle Periode", kan de Sync-interval voor nodes worden ingesteld in microseconden.

Uitstel

Tot slot, in subindex 3 kan een "inhibit time" kan worden ingesteld voor asynchrone PDO’s. De waarde dient als een veelvoud van 100 microseconden. Deze uitstel (inhibit) is handig als frequent ongecontroleerde wijzigingen van een CANopen apparaat ingangswaarden voorkomen, bijvoorbeeld bij een open analoge ingang. Als de inhibit tijd geconfigureerd, is zal de node de relevante PDO gedurende deze tijd niet opnieuw verzenden, hetgeen ervoor zorgt dat er geen ontoelaatbaar CAN busbelasting door een zogenaamde ‘brabbelende’ ingang ontstaat. De inhibit tijd wordt natuurlijk alleen gebruikt voor TxPDOs . Het heeft geen betekenis voor RxPDOs.

Cyclisch verzenden

Asynchrone TxPDOs kunnen cyclisch worden verzonden met de event timer, subindex 5. Als de waarde groter is dan 0, wordt het een timer in milliseconden. Wanneer deze is verlopen, wordt de PDO verzonden. Transmissie vindt dus plaats zowel bij de wijzing van een CANopen apparaat ingang en wanneer de timer is verstreken. Deze subindex is ook alleen van belang voor verzend PDO’s.

CANopen resources

Een CANopen node heeft meestal vier verzend-PDO's en vier ontvangen-PDO's, waar voor iedere PDO een COB-ID is gereserveerd. Dit neemt dus in totaal 127 * 4 * 2 = 938 COB-ID’s in beslag, dat wil zeggen bijna de helft van de totale identificatie ruimte. Echter, als gevolg van de zogenaamde "Object Linking", dat wil zeggen de vaststelling van de communicatie tussen een zend- en een ontvangst-PDO, komen er COB-ID’s vrij. Immers door het koppelen van de producent aan de consument(en) moet de COB-ID worden aangepast aan die van de communicatie-partner en komt er dus een eigen gereserveerde COB-ID vrij. Daarom is in de praktijk, voor een netwerk met 127 netwerk nodes, een gemiddelde van acht COB-ID's beschikbaar per apparaat voor TxPDOs. Voor netwerken met een lager aantal nodes, kunnen de ongebruikte COB-ID's ook gebruikt worden natuurlijk. De systeem integrator moet altijd een overzicht behouden over de verdeling van de identifierruimte en de COB-id's die worden gebruikt. Voor meer complexe systemen is een software tool - bijvoorbeeld de CANopen ConfigStudio aan te bevelen. Deze tool, bijvoorbeeld, verzorgt PDO-mapping en-linking automatisch.