De gegevensoverdracht in CANopen is gepasseerd op het gestandaardiseerd uitlezen of schrijven van data, die in een standaard structuur in nodes beschikbaar is.
Object Dictionary (OD)
Een van de belangrijkste eigenschappen van CANopen is de gestandaardiseerd apparaat-beschrijving de zogenaamde "Object Directory" (OD). Het is een database die dezelfde structuur heeft voor alle soorten van apparaten. Zo is het mogelijk om toegang te krijgen van de "buiten", dat wil zeggen via de CAN-bus, tot alle belangrijke gegevens, parameters en functies van een apparaat middels een logisch adressysteem. De adressering naar een object in de OD bestaat uit een index en sub-index.
De OD bevat niet alleen de applicatiedata die via CAN uitgewisseld (kan) worden. De gehele administratie van een node is in de OD opgeslagen. Zo kan een Master ook een node configureren door de juiste waardes in de OD aan te passen.
Naast de gestandaardiseerde beschrijving van de communicatie-eigenschappen van apparaten volgens CiA 301, definieert CANopen zogenaamde "Device Profiles" voor typische apparaten met onderscheidend toepassingsgebieden. Deze profielen specifiëren de belangrijkste parameters, data en functies per type apparaat. Zo zijn er profielen voor bijvoorbeeld I/O-apparaten, motordrives en encoders. De profielen leggen gestandaardiseerd de inhoud van het OD vast.
Electronic Data Sheet (EDS)
Het mag duidelijk zijn dat de inhoudt van de OD belangrijk voor de Master is. Omdat een OD heel groot kan zijn - het OD kent max 65000 Indexen met iedere 255 sub-indexen - is het onmogelijk om het via CAN met de Master uit te wisselen. Daarom wordt het OD van een node in een zogenaamde Electronic Data Sheet (EDS) vastgelegd. Dit bevat het data type en de functie van elk item van de OD.
Oorspronkelijk was de EDS een ASCII-bestand. Om een meer flexibele en uitbreidbare verwerking van de CANopen-gegevens mogelijk te maken, is het formaat veranderd in XML.
Gegevensoverdracht via SDO en PDO
In principe zijn er twee verschillende manieren om gegevens over te brengen. De eerste, de Service Data-Objecten (SDO) zijn gebaseerd op een client/server-communicatie. Hierbij vindt directe adressering plaats van een CANopen object in een node met behulp van de index en sub-index. Er is dus altijd sprake van 1:1-communicatie, peer-to-peer tussen de client en de server. Een SDO bestaat altijd uit twee (of meer) berichten. Na een leesverzoek, volgt het antwoord. Na eens schrijfverzoek, volgt de bevestiging.
Het wordt bijvoorbeeld gebruikt voor de configuratie van een apparaat, het ad-hoc opvragen van informatie, of het up-en downloaden van grotere data blokken.
De tweede manier, Proces Data Objects (PDO) maken een efficiënte overdracht van CANopen gegevens mogelijk op basis van het producent/consument model. Hierbij wordt dus de gegevens ontvangen door alle overige nodes, mits geconfigureerd. De datalengte is beperkt tot maximaal acht data byte's, maar bevat geen protocol overhead. Een PDO kan de waarden van meer dan één item uit de Object Directory bevatten. De inhoud van een PDO moeten tijdens de initialisatie worden vastgelegd, en enkel voor de nodes die de inhoud van die specifieke PDO gaan gebruiken.
Ieder apparaat kan theoretisch tot 512 Receive en Transmit PDOs specificeren. Het werkelijke maximaal aantal is daarbij afhankelijk van de beperkingen van het systeem (geheugen, processorkracht) of het netwerk (aantal beschikbare CAN-ID's).
Een PDO wordt verstuurd als gevolg van een verzoek op afstand (Remote Request), door een interne gebeurtenis zoals bijvoorbeeld een trigger resp. een timer, of wanneer een (cyclische) synchrone bericht (SYNC) wordt ontvangen. Alle CANopen nodes in het netwerk zijn in staat zijn om het bericht te ontvangen (PDO-consumenten). Tijdens de initialisatie bepaalt de Master welke nodes een specifieke PDO gaan ontvangen.
Noodoproep
Omdat CAN (en dus CANopen) geen hiërarchisch master/slave systeem is, en de monitoring van nodes alleen de CAN-communicatie betreft en niet de eigenlijke node status, benodigd iedere node een hoge prioriteit CAN-ID om foutsituaties te melden. Dit mechanisme wordt aangeduid als "Emergency Messaging" en het bijbehorende communicatie-object "Emergency Message". Een dergelijk CANopen noodoproep-bericht bestaat uit acht data bytes met het volgende formaat:
De foutcodes worden gespecificeerd in CANopen specificatie DS-301. Gelijktijdig met de overdracht van de noodoproep, schrijft het apparaat de fout code ook in de fouthistorie. Het fout-register is onderdeel van de Object Directory met bit-gewijze codering van de foutoorzaak.
