Une trace CANopen brute n’est qu’une suite d’identifiants et d’octets en hexadécimal. L’outil la traduit : collez des lignes copiées depuis candump, il reconnaît le type de chaque trame (NMT, SYNC, urgence, PDO, SDO, heartbeat), le nœud concerné et décode le contenu. Les deux autres onglets construisent une requête SDO prête à envoyer et décodent le mot d’état d’un variateur au profil DS402.
Une ligne peut être copiée telle quelle depuis candump can0, écrite au format de cansend (604#4017100000000000) ou simplement « COB-ID octets » en hexadécimal.
| COB-ID | Données | Type | Nœud | Interprétation |
|---|
Requête (cansend)
–
Réponse attendue
–
Commande canopencomm
–
passerelle de CANopenNode (canopend)
Cliquer sur un état pour charger son mot d’état, ou sur une transition pour charger la commande correspondante et le mot d’état obtenu.
État du variateur
–
Mot de contrôle
–
| Bit | Mot d’état | Valeur |
|---|
Le COB-ID, ou qui parle à qui
Sans configuration particulière, CANopen attribue les identifiants selon le predefined connection set : les 4 bits de poids fort de l’identifiant de 11 bits donnent la fonction, les 7 bits de poids faible le numéro de nœud (1 à 127). Plus l’identifiant est petit, plus la trame est prioritaire sur le bus.
| Objet | COB-ID | Sens |
|---|---|---|
| NMT | 0x000 | maître → nœuds |
| SYNC | 0x080 | producteur SYNC → tous |
| EMCY | 0x080 + nœud | nœud → tous |
| TIME | 0x100 | producteur → tous |
| TPDO1 à TPDO4 | 0x180, 0x280, 0x380, 0x480 + nœud | émis par le nœud |
| RPDO1 à RPDO4 | 0x200, 0x300, 0x400, 0x500 + nœud | reçus par le nœud |
| SDO réponse | 0x580 + nœud | serveur (nœud) → client |
| SDO requête | 0x600 + nœud | client → serveur (nœud) |
| Heartbeat, node guarding | 0x700 + nœud | nœud → tous |
TPDO et RPDO sont nommés du point de vue du nœud : le TPDO1 d’un variateur est ce que le maître reçoit, et c’est dans le RPDO1 du variateur que le maître écrit.
L’octet de commande SDO
Une trame SDO fait toujours 8 octets : un octet de commande, l’index de l’objet sur 2 octets (poids faible en premier), le sous-index, puis 4 octets de donnée. Pour les objets de 4 octets au plus, le transfert « accéléré » (expedited) tient en un seul échange :
| Octet | Signification |
|---|---|
| 0x40 | requête de lecture |
| 0x4F, 0x4B, 0x47, 0x43 | réponse de lecture avec 1, 2, 3 ou 4 octets de donnée |
| 0x2F, 0x2B, 0x27, 0x23 | requête d’écriture de 1, 2, 3 ou 4 octets |
| 0x60 | écriture acceptée |
| 0x80 | abandon : les 4 derniers octets donnent le code d’erreur |
Dans l’octet de commande, les 3 bits de poids fort donnent le type de requête, les bits 3 et 2 le nombre d’octets inutilisés, le bit 1 indique un transfert accéléré et le bit 0 que la taille est précisée. Les objets plus longs (chaînes, tableaux) passent par un transfert segmenté, 7 octets à la fois, avec un bit de bascule qui alterne à chaque segment.
NMT et heartbeat
| Commande NMT (octet 0) | Effet |
|---|---|
| 0x01 | Start : passage en Operational, les PDO circulent |
| 0x02 | Stop : seuls NMT et heartbeat restent actifs |
| 0x80 | Pre-operational : SDO autorisés, PDO coupés |
| 0x81 | Reset node |
| 0x82 | Reset communication |
Le second octet est le numéro du nœud visé, 0 pour tous. Chaque nœud publie ensuite son état en heartbeat (0x700 + nœud) : 0x00 au démarrage, 0x04 Stopped, 0x05 Operational, 0x7F Pre-operational. La période est réglée par l’objet 0x1017, en millisecondes.
Pour aller plus loin
La machine d’états DS402 et une mise en œuvre complète sous LabVIEW sur Raspberry Pi sont détaillées dans l’article CANopen sous LabVIEW avec un Raspberry Pi.

Laisser un commentaire
Vous devez vous connecter pour publier un commentaire.