Diagnostic CANopen
Le chapitre décrit les possibilités de diagnostic offertes par le protocole CANopen.
État CANopen
Un réseau CANopen se compose d'un maître NMT (gestion du réseau) et d'esclaves NMT. Dans ce cas, le maître NMT contrôle tous les appareils et peut modifier leurs états de communication. Un équipement CANopen est dans l'un des quatre états possibles :
Initialisation : Après la mise sous tension, le nœud passe par cet état. A ce moment, l'application de l'appareil et la communication de l'appareil (débit binaire et adresse de nœud) sont initialisées. Ensuite, le nœud passe indépendamment à l'état "Pre-Operational".
Pré-opérationnel : la communication avec le nœud est possible via des SDO. Cependant, le nœud n'est pas en mesure d'effectuer une communication PDO.
Opérationnel : le nœud CANopen est entièrement opérationnel. Il peut envoyer et recevoir indépendamment des données de processus.
Arrêté : le nœud est complètement séparé du réseau. Aucune communication SDO ou PDO n'est possible. Le nœud ne peut passer à un autre état de réseau que par une commande réseau correspondante (exemple : start node).
Registre des erreurs
Selon CiA 301, chaque appareil CANopen possède un registre d'erreur (objet 16#1001). Ce registre peut être lu via SDO et, en cas d'erreur, fournit des informations supplémentaires sur l'erreur.
Seul le bit 0 (erreur générique) est requis dans le registre d'erreurs. Les autres bits sont facultatifs et ne sont pas définis par chaque esclave. Dès qu'un équipement détecte une erreur, au moins le bit 0 de cet objet est défini.
Bit | La description |
|---|---|
0 | Erreur générique |
1 | Courant |
2 | Tension |
3 | Température |
4 | Erreur de communication (état d'erreur de dépassement) |
5 | Profil d'appareil spécifique |
6 | Réservé (toujours 0) |
7 | Spécifique au fabricant |
Champ d'erreur d'urgence et prédéfini (EMCY)
CANopen définit le protocole d'urgence optionnel (EMCY) pour indiquer les erreurs. Une urgence est un message CAN qui est transmis selon la connexion prédéfinie définie avec CAN-ID 16#80 + NODE-ID.
Le télégramme a la structure suivante :
La longueur d'un message d'urgence est toujours de 8 octets. Le code d'erreur d'urgence (EEC) respectif est transmis dans les deux premiers octets. Viennent ensuite la valeur actuelle du registre d'erreur 0x1011 (ER : registre d'erreur) et 5 octets spécifiques au fabricant (MEF : champ d'erreur spécifique au fabricant).
L'interprétation respective des codes d'erreur doit être tirée du manuel du fabricant. Le protocole d'urgence n'est pas pris en charge par tous les esclaves et doit être configuré en conséquence par le gestionnaire CANopen.
L'historique des urgences survenues (historique des erreurs) peut être lu à partir de l'objet 16#1003 via SDO. Ici, le sous-index 0 contient le nombre d'erreurs enregistrées et les sous-objets suivants contiennent le contenu des données des urgences transmises.
Pour plus d'informations, voir : Champ d'erreur et registre d'erreur prédéfinis
Mécanismes de surveillance : Heartbeat et Node Guarding
La surveillance d'un nœud CAN est nécessaire s'il n'envoie pas de messages en continu (PDO cycliques). A cet effet, les mécanismes 'heartbeat' et 'node guarding' sont prévus, qui peuvent être utilisés alternativement.
Node guarding : Avec ce protocole, des messages (trames distantes CAN) sont envoyés par le maître NMT aux esclaves CANopen existants. Les esclaves doivent répondre à ces messages dans un délai déterminé. S'il n'y a pas de réponse, celle-ci est enregistrée par le maître NMT. Etant donné que les trames distantes CAN doivent être évitées en général, la surveillance par heartbeat est préférable.
Heartbeat : Le protocole Heartbeat a été publié avec CANopen version 4.0 et est la méthode de surveillance préférée. Ici, chaque nœud envoie indépendamment un message à intervalles cycliques. Ce message peut être surveillé par n'importe quel autre abonné du réseau.