Principe de fonctionnement du protocole CANopen
Présentation du réseau CANopen
CANopen est un système de mise en réseau basé sur le Controller Area Network (CAN) de bus série. Le profil de communication CANopen (CiA DS-301) prend en charge l’accès direct aux paramètres des équipements ainsi que la communication de données de process sensibles aux délais.
Le profil de l’équipement CANopen pour contrôleurs LTMR est spécifique au fabricant. Il en définit les fonctionnalités de base tout en permettant de prendre en charge de nombreuses fonctions supplémentaires spécifiques aux fournisseurs.
CANopen exploite pleinement le réseau CAN grâce à l’échange de données direct de poste à poste entre les nœuds, de façon organisée et déterministe, si nécessaire.
Protocole CANopen
Le protocole CANopen se base sur la spécification CAN 2.B passive (identifiant codé sur 11 bits).
L’interface CANopen du contrôleur LTMR est conforme aux spécifications CANopen (DS301 V4.02).
Les contrôleurs sont présentés dans des fichiers EDS (Electronic Data Sheet) à intégrer aux outils de configuration.
Trame de message CANopen
Voici la description d’une trame de message CANopen standard :
SOF |
COB-ID |
RTR |
CTRL |
Segment de données |
CRC |
ACK |
EOF |
---|---|---|---|---|---|---|---|
1 bit |
11 bits |
1 bit |
5 bits |
0 à 8 octets |
16 bits |
2 bits |
7 bits |
SOF |
Start of frame (début de trame) |
COB-ID |
Champ d’identification du message CAN, composé d’un code fonction (4 bits) et d’un ID de module (7 bits). Le code fonction détermine la priorité de l’objet, permettant ainsi la communication entre un administrateur réseau et 127 stations. Le code de fonction est défini avec un dictionnaire des objets du profil de l’équipement. La diffusion est indiquée par un ID de module de zéro. |
RTR |
Remote Transmission Request (Requête de transmission distante) |
CTRL |
Control field (Champ de contrôle) (c’est-à-dire longueur des données) |
CRC |
Cyclic Redundancy Check (Contrôle de redondance cyclique) |
ACK |
Acknowledge (Acquittement) |
OEF |
End Of Frame (Fin de trame) |
Services CANopen
Les objets de communication CANopen transmis via le réseau CAN sont décrits par les services suivants :
-
GESTION DE RÉSEAU
Démarrage du bus, définition des paramètres, surveillance.
-
TRANSMISSION HAUT DÉBIT DES DONNÉES DE PROCESS
PDO (Process Data Objects, ou objet données de process) pour la commande de contrôle en temps réel.
-
TRANSMISSION BAS DÉBIT DES DONNÉES DE SERVICE
SDO (Service Data Objects, ou objets de données de service) pour la configuration, le paramétrage et les diagnostics.
Gestion de réseau (NMT)
La gestion de réseau CANopen est une méthode orientée nœud et repose sur une structure client/serveur. Elle nécessite qu’un équipement du réseau joue le rôle de client NMT. Les autres nœuds sont des serveurs NMT.
(1) |
À la mise sous tension, l’équipement passe à l’état d’initialisation. |
(2) |
Une fois l’initialisation terminée, l’équipement passe automatiquement à l’état préopérationnel (il est alors possible d’envoyer des paramètres). Remarque : vous pouvez écrire des paramètres sélectionnés par la configuration en mode préopérationnel. |
(3) (6) |
Start_Remote_Node |
(4) (7) |
Enter_Pre-Operational_State et applique un repli. |
(5) (8) |
Stop_Remote_Node |
(9) (10) (11) |
Reset_Node |
(12) (13) (14) |
Reset_Communication |
Objets de données de process (PDO)
Le transfert en temps réel est effectué par le biais de télégrammes Process Data Object (PDO). Les données Process Data (qui sont dépendantes du temps) permettent de surveiller et de contrôler l’équipement.
Fonctionnalités du module de communication du contrôleur CANopen :
PDO |
Description |
État |
---|---|---|
PDO1 de transmission |
Utilisés pour la surveillance (données transmises par le serveur) |
Préconfigurés et activés |
PDO1 de réception |
Utilisés pour le contrôle (données transmises par le client) |
|
PDO2 de transmission |
Utilisés pour l’échange de données (définis à la configuration) |
À configurer et à activer |
PDO2 de réception |
||
PDO3 de transmission |
||
PDO3 de réception |
||
PDO4 de transmission |
Utilisés pour accéder (en lecture ou écriture) à tout registre via la programmation |
Préconfigurés et activés |
PDO4 de réception |
Les objets RPDO (PDO de réception) et TPDO (PDO de transmission) peuvent être configurés de façon à inclure 8 octets de données (par exemple, composés de quatre registres de 16 bits ou d’un objet de 64 bits).
Les objets RPDO sont accessibles en écriture.
Selon l’application, définissez le mode de communication PDO sur asynchrone, cyclique ou synchrone acyclique.
En mode synchrone, la transmission de PDO dépend de l’objet SYNC, transmis de façon cyclique par le client CANopen. Elle n’inclut aucune donnée. Le réglage d’usine est 0x080.
Le mode de transmission est :
Type de transmission |
Transmission de PDO |
|||
---|---|---|---|---|
Cyclique |
Acyclique |
Synchrone |
Asynchrone |
|
0 PDO envoyés de façon synchrone avec l’objet SYNC ; déclenché par un changement de la valeur des données |
√ |
√ |
||
1-240 PDO envoyés par le module de communication toutes les 240 réceptions de l’objet SYNC |
√ |
√ |
||
255 Réglage d’usine du mode de communication |
√ |
√ |
Pour plus d’informations sur les PDO, consultez la rubrique Using PDOs.
Objets de données de service (SDO)
Les objets de services de données (objets SDO) permettent de configurer l’équipement et de définir le type et le format des informations transmises via les PDO.
Les SDO vous permettent d’accéder à n’importe quel objet du dictionnaire des objets de l’équipement.
Les clients CANopen exécutent des messages acycliques par le biais d’objets SDO. Ils sont également utilisés pour les requêtes asynchrones et apériodiques. Par exemple, un SDO peut être utilisé pour lire l’identification d’une unité de contrôle.
Le module de communication CANopen gère un serveur SDO, qui reçoit deux COB-ID :
-
un pour les requêtes (télégrammes émis par le client et envoyés au LTMR CANopen),
-
un pour les réponses (télégrammes retournés au client par le LTMR CANopen).
Pour plus d’informations sur les SDO, consultez la rubrique Using SDOs.