Qu’est-ce que le CANopen?

5. Qu’est-ce que le CANopen?#

CANopen est un protocole de communication (couche supérieur) basé sur le réseau bus CAN. La norme CANopen permet l’interopérabilité entre les dispositifs (nœuds) et fournit des méthodes standard pour configurer les appareils, y compris après leur installation.

Aujourd’hui, CANopen est largement utilisé dans la commande de moteurs (moteurs pas à pas/servomoteurs) et dans un large éventail d’autres applications, notamment l’automobile.

Le réseau CANOpen est constitué de nœuds (équipements) reliés entre eux par un même bus CAN terminé par deux résistances de 120 Ohm.

Trois modèles de réseau sont possibles :

  • Maître / Esclave

  • Client / Serveur

  • Producteur / Consommateur

la norme CiA 301 stipule que CANopen est basé sur des ID CAN de 11 bits.

5.1. Fonctionnement général#

5.1.1. Liaison physique#

Le format standard CANopen ne spécifie pas de connecteurs particulier. Toutefois les connecteurs DB9 sont couramment employés suivant le câblage illustré ci-dessous:

DB9 connector

5.1.2. La trame CANopen#

Les messages transmis sur le bus CAN obéissent à une trame détaillée ci-dessous:

trame CANopen

La trame est composée de 11 bits en tête appelé le Communication Object Identifier COB-ID, lui-même composé de deux parties:

  • le code de fonction Code Function : 4 bits reflètent la « fonctionnalité » du message

  • ID du nœud : 7 bits reflètent l’ID (identifiant) du nœud (entre 1 et 127). 127 équipements maximum peuvent donc être reliés sur le bas CAN.

Il existe un ensemble de “Code function” prédéfinis regroupés ci-après.

5.1.3. En résumé#

Le standard CANOpen possède 7 protocoles de communication :

  • Network Management (NMT) : permet de contrôler l’état des différents appareils connectés sur le bus CANOpen,

  • Synchronization (SYNC) : permet de synchroniser les différents appareils et notamment l’échange de données via PDO,

  • Emergency (EMCY) : permet à un appareil de signaler une erreur fatale aux autres appareils du réseau,

  • Timestamp (TIME) : message PDO permettant de transmettre l’information d’heures et de dates d’un appareil aux autres,

  • Process Data Object (PDO) : permet de transmettre des données temps-réel d’un appareil à l’autre de manière synchrone (SYNC) ou sur événement,

  • Service Data Object (SDO) : permet d’accéder et de modifier les valeurs du dictionnaire d’objets (OD) d’un appareil sur le réseau,

  • Node Monitoring (Heartbeat) : permet à chaque appareil du réseau d’émettre périodiquement un message de vie et de confirmer l’état de l’appareil (NMT)

Ces messages sont identifiés par leur ID :

Objets de diffusion prédéfinis (envoi à tous les nœuds)
Object Function Code Décimal Héxadécimal paramètres de communication
NMT 0000 0 0 -
SYNC 0001 128 80 (1005)
TIME 0010 256 100 non supporté
Objets prédéfinis peer-to-peer (1 nœud envoie à 1 nœud)
Object Function Code Décimal Héxadécimal paramètres de communication priorité
EMERGENCY 0001 129..255 81..FF — high
TxPDO 1 0011 385..511 181..1FF 1800 -
RxPDO 1 0100 513..639 201..27F 1400 -
TxPDO 2 0101 641..767 281..2FF 1801 -
RxPDO 2 0110 769..895 301..37F 1401 -
TxPDO 3 0111 897..1023 381..3FF 1802 -
RxPDO 3 1000 1025..1151 401..47F 1402 -
TxPDO 4 1001 1153..1279 481..4FF 1803 -
RxPDO 4 1010 1281..1407 501..57F 1403 -
SDO (tx*) 1011 1409..1535 581..5FF - -
SDO (rx*) 1100 1537..1663 601..67F - -
HEARTBEAT 1110 1793..1919 701..77F (100E) low
Définitions des Function Code
Function Code Définition
NMT
(Network Management Objects)

Les objets NMT suivent le protocole master/slave.
Un maître NMT contrôle l'« état » des esclaves par le biais de commandes NMT.
Pour modifier l'état d'un appareil, le maître NMT envoie un message avec le COB-ID 0x0, que tous les nœuds esclaves traitent. Le premier octet de données contient l'état demandé, tandis que le deuxième octet de données CAN contient l'ID du nœud ciblé.
L'ID de nœud 0 indique une commande de diffusion.
Les valeurs de demande d'état comprennent

NMT table
SYNC
(Synchronization Object)

Le message SYNC suit le protocole producer/consumer.
Un producteur (généralement le maître CANopen) diffuse périodiquement le message SYNC avec un ID de haute priorité (COB-ID 0x80). Cela permet aux consommateurs CANopen SYNC de synchroniser le moment où ils doivent, par exemple, diffuser des données via des PDO d'émission.

TIME
(Timestamp Object)

Le message TIME suit le protocole producer/consumer et fournit une horloge à distribuer à l'échelle du réseau.
Le producteur diffuse le message TIME avec le COB_ID 0x100 et une charge utile de 6 octets : 4 octets de données contiennent l'heure en ms après minuit et les 2 octets suivants contiennent le nombre de jours écoulés depuis le 1er janvier 1984.

EMCY
(Emergency Object)

L'objet emergency suit le protocole producer/consumer et est utilisé lorsqu'un dispositif subit une erreur fatale (par exemple, une défaillance de capteur), ce qui lui permet de l'indiquer au reste du réseau. Le nœud concerné envoie un seul message EMCY avec COB-ID 0x80 + ID du nœud (par exemple 0x85 pour le nœud 5). Les octets de données contiennent des informations sur l'erreur, un registre d'erreur de 1 octet et jusqu'à 5 octets d'informations d'erreur spécifiques au fabricant.

HEARTBEAT
(Heartbeat Object)

Le message de battement de cœur suit le protocole producer/consumer. Les esclaves CANopen peuvent diffuser périodiquement un message de battement de cœur (par exemple toutes les 100 ms) avec COB-ID 0x700 + ID du nœud (c'est-à-dire 0x705 pour le nœud 5). La charge utile contient l'état du nœud dans le premier octet de données (démarrage, préopérationnel, opérationnel, arrêté). Cela permet à un consommateur (par exemple le maître) de réagir rapidement si un nœud ne diffuse pas son battement de cœur dans un délai donné.

SDO
(Service Data Object)

Configurer le réseau CANOpen.
Les demandes/réponses SDO sont envoyées via le protocole « client/server ». Un « client » SDO initie la communication avec un « server » SDO. L'objectif peut être de mettre à jour une entrée du OD Object Dictionary (« SDO download ») ou de lire une entrée (« SDO upload »). Cela permet, par exemple, la configuration et le diagnostic des nœuds.

PDO
(Process Data Object)

Exploiter le réseau CANOpen.
Le PDO est utilisé pour le transfert efficace de données opérationnelles en temps réel entre les nœuds CANopen.
Le protocole « consumer/producer » est utilisé. Un producteur « produit des données » qu'il transmet à un ou plusieurs « consommateurs » à l'aide d'un PDO de transmission (TxPDO). Inversement, il peut recevoir des données du consommateur via un PDO de réception (RxPDO).
Les PDO peuvent être envoyés par transmission synchrone (en réponse à un SYNC) ou par transmission événementielle (par exemple, périodiquement).
NB: Le SDO pourrait être utilisé pour la même fonction mais avec beaucoup plus de surcharge. Un PDO peut contenir 8 octets de données et plusieurs valeurs de paramètres d'objet dans une seule trame.
CANopen ID

Certains protocoles sont désactivés suivant l’état de la machine d’état de l’appareil :

function mode

5.1.4. Object Dictionary (OD)#

Le dictionnaire d’objet d’un appareil contient l’ensemble des paramètres d’un appareil. Ces paramètres sont accessibles via une adresse constituée d’un index (16 bits) et d’un sous-index (8 bits). Ce dictionnaire prend la forme d’un fichier Electronic Data Sheet (EDS), spécifique à chaque appareil, qui permet à l’utilisateur d’identifier les paramètres et leur adresse.

OD Index

5.1.5. Protocole SDO#

Le protocole SDO sert principalement à configurer les appareils CANOpen en modifiant les entrées du dictionnaire d’objet. Cette étape se fait généralement lorsque l’appareil est en mode pré-opérationnel. Les messages SDO utilisent les identifiants suivants (ID) en se positionnant du point de vue de l’appareil :

SDO

Le message est constitué du COB-ID suivi de 64 bits :

  • 8 bits de commande :

0x40 Lecture d’une entré de l’OD
0x23 Écriture de 32 bits (SDO receive)
0x27 Écriture de 24 bits (SDO receive)
0x2B Écriture de 16 bits (SDO receive)
0x2F Écriture de 8 bits (SDO receive)
0x43 Réponse de l’appareil cible sur 32 bits (SDO transmit)
0x47 Réponse de l’appareil cible sur 24 bits (SDO transmit)
0x4B Réponse de l’appareil cible sur 16 bits (SDO transmit)
0x4F Réponse de l’appareil cible sur 8 bits (SDO transmit)

  • 16 bits d’index et 8 bits de sous-index : adresse du paramètre dans l’OD

  • 32 bits de données : les données non utilisées sont inactivées,l’écriture est réalisée en « little endian » (le dernier bit transmis est le premier lu)

5.1.6. Protocole PDO#

Le protocole PDO possède trois modes de configurations :

  • Static PDO : la configuration des PDO est fixée par le fabricant et non modifiable,

  • Variable PDO : la configuration est modifiable en mode pré-opérationnel,

  • Dynamic PDO : la configuration est modifiable en mode pré-opérationnel et opérationnel.

Chaque message PDO est configuré par deux entrées : ses paramètres de communication et ses paramètres de mapping (configuration). On définit deux catégories de PDO : les RPDO pour les messages reçus et les TPDO pour les messages envoyés.

Les messages PDO sont configurés sur 4 listes d’entrée du OD :

  • 0x1400 à 0x15FF : paramètres de communication pour les RPDO,

  • 0x1600 à 0x17FF : paramètres de mapping pour les RPDO,

  • 0x1800 à 0x19FF : paramètres de communication pour les TPDO,

  • 0x1A00 à 0x1BFF : paramètres de mapping pour les TPDO.

Les paramètres de communication sont configurés par les sous-index :

COB-ID

Le type permet de spécifier les détails de la communication :

PDO

Lorsque l’utilisateur souhaite modifier les paramètres d’un PDO, plusieurs étapes doivent être respectées :

  1. Invalider le PDO en écrivant 1 dans le 32ème bit sur l’adresse de communication choisie en sous-index 1 (ex : 0x1802sub1),

  2. Invalider le PDO mapping en écrivant 0x00 à l’adresse de mapping correspondante en sous-index 0 (ex : 0x1A02sub0),

  3. Ajuster les objets souhaités dans le mapping correspondant (ex : 0x1A02sub1…40),

  4. Rétablir le PDO mapping en indiquant le nombre d’objet dans le mapping (ex : 0x1A00sub0),

  5. Rétablir le PDO en écrivant 0 dans le 32ème bit sur l’adresse de communication correspondant en sous-index 1.

Contents