CANopen est un protocole de communication standard ouvert et une spécification de protocole d'équipement (EN 50325-4) qui repose sur le protocole Controller Area Network (CAN). Le protocole de "couche 7" a été développé pour les applications réseau intégrées et définit les fonctions de communication et d'équipement pour les systèmes CAN.
CANopen prend en charge les communications cycliques et pilotées par événement, ce qui vous permet de réduire la charge du bus au minimum tout en continuant de bénéficier de brefs temps de réaction.
Les objets PDO fournissent une interface de communication avec les données de traitement, permettant le transfert de ces données en temps réel. L'ensemble de PDO d'un équipement CANopen décrit les échanges implicites entre cet équipement et ses partenaires de communication sur le réseau. L'échange des PDO est autorisé lorsque l'équipement est en mode OPERATIONAL.
Il existe deux types de PDO :
PDO de transmission (TPDO) : PDO transmis par l'équipement
PDO de réception (RPDO) : PDO reçu par l'équipement
coupleur de bus TM3 CANopen prend en charge trois types de mode de transmission de PDO :
Type de code de transfert |
Mode de transmission |
Description |
---|---|---|
0 |
Acyclique - Synchrone |
Envoyer un PDO au premier message après un événement |
1-240 |
Cyclique - Synchrone |
Envoyer un PDO tous les x messages , où x peut être configré de 1 à 240 |
255 (par défaut) |
Asynchrone |
Envoyer un PDO en cas d'événement |
Deux autres options sont associées aux PDO déclenchés par des événements :
Inhibit Time : L'utilitaire Inhibit Time permet de définir un délai minimum avant la transmission d'un nouveau PDO. Cela évite de surcharger le bus lorsqu'un nombre important d'événements se produisent dans un laps de temps court. La valeur de Inhibit Time est exprimée en multiples de 100 μs.
Cette fonctionnalité est disponible pour le transfert type 255 (asynchrone).
Ce tableau fournit des exemples de valeurs :
Valeur (déc.) |
Durée (ms) |
---|---|
0 |
0 |
10 |
1 |
100 |
10 |
1000 |
100 |
10000 |
1000 |
65535 |
6553,5 |
: Le sert à définir un délai d'expiration au bout duquel la transmission d'un PDO est forcée, même si aucun changement d'état n'a eu lieu. Le est exprimé en millisecondes.
Cette fonctionnalité est disponible pour le type 255 (asynchrone).
Ce tableau fournit des exemples de valeurs :
Valeur (déc.) |
Durée (ms) |
---|---|
0 |
0 (désactive le temporisateur) |
10 |
10 |
100 |
100 |
1000 |
1000 |
10000 |
10000 |
65535 |
65535 |
Les SDO permettent d'accéder aux données d'un équipement à l'aide de requêtes explicites. Le service SDO est disponible lorsque l'équipement est à l'état OPERATIONAL ou PRE-OPERATIONAL.
Il existe deux types de SDO :
SDO en lecture (SDO en téléchargement)
SDO en écriture (SDO en chargement)
Le protocole SDO repose sur un modèle client/serveur. Pour un SDO en téléchargement, le client (généralement le contrôleur) envoie une requête indiquant l'objet à lire. Le serveur (dans le cas présent, le coupleur de bus) renvoie les données contenues dans l'objet. Pour un SDO en chargement, le client (généralement le contrôleur) envoie une requête indiquant l'objet à écrire et la valeur souhaitée. Une fois l'objet mis à jour, le serveur (dans le cas présent, le coupleur de bus) renvoie un message de confirmation.
Si un SDO ne peut pas être traité par le serveur (coupleur de bus), le serveur renvoie un code d'erreur (code d'abandon). Cela s'applique à la fois au SDO en téléchargement et au SDO en chargement. Si le serveur ne répond pas dans une période prédéfinie (délai d'expiration du SDO), le client émet un code d'abandon pour dépassement du délai d'expiration du SDO.
Les protocoles de contrôle d'erreur servent à détecter les erreurs de communication sur le réseau. Il existe deux protocoles : Node Guarding et heartbeat. Ces deux mécanismes de surveillance sont particulièrement importants dans le système CANopen. Les équipements connectés au bus ne signalent pas régulièrement leur présence en mode de fonctionnement, en particulier lorsqu'ils sont commandés par .
Dans ce protocole, le maître NMT (généralement le contrôleur) interroge chaque esclave NMT (un coupleur de bus, par exemple) à intervalles réguliers, appelés 1029H et génère un événement life guarding. Le coupleur de bus passe à l'état configuré dans l'objet (si l'objet est l'objet par défaut), la gestion du repli démarre et un événement de protection est généré. est défini comme suit : = x . L'objet comprend le paramètre Guard Time, exprimé en millisecondes. L'objet comprend le paramètre . Les paramètres et peuvent être configurés différemment pour plusieurs esclaves.
. L'esclave répond en envoyant son état NMT. Si l'esclave ne reçoit pas d'interrogation après une période définie, appelée , il passe à l'état configuré dans l'objetLorsque l'un des deux paramètres
ou est défini sur 0 (configuration par défaut), l'esclave n'effectue aucune surveillance. Pour activer la surveillance, vous devez entrer une valeur (au moins 2) dans l'objet et spécifier une durée en millisecondes dans l'objet .Les valeurs classiques du paramètre
se situent entre 200 ms et 2 s.Afin d'assurer un fonctionnement plus fiable et plus sécurisé, vous devez indiquer un paramètre
(objet ) d'une valeur minimale de 2. Si vous utilisez une valeur de 1, lorsqu'un retard se produit en raison du traitement de messages prioritaires ou du traitement interne sur le maître Node Guarding, l'esclave peut, par inadvertance, passer à l'état configuré dans l'objet .AVERTISSEMENT | |
---|---|
La surveillance est effectuée de la façon suivante :
Phase |
Description |
---|---|
1 |
Le maître définit Guarding-CobID des esclaves à surveiller. (ou les messages de requête ) sur le |
2 |
Les esclaves concernés répondent en envoyant le message . Ce message inclut le de l'esclave et le , qui change après chaque message. |
3 |
Le maître NMT (Network Management Telegram) compare l' et le : s'ils ne sont pas à l'état attendu ou si aucune réponse ne lui parvient, le maître NMT considère qu'une erreur s'est produite sur l'esclave. |
L'état du réseau de l'équipement est indiqué par les sept bits restants :
État du réseau |
Réponse (hex.) |
---|---|
‘STOPPED’ |
04H ou 84H |
‘PRE-OPERATIONAL’ |
7FH ou FFH |
‘OPERATIONAL’ |
05H ou 85H |
Dans ce protocole, le producteur transmet un message CANopen configuré dans l'objet 1029H, la gestion du repli démarre et un événement est généré.
de manière périodique, en fonction du paramètre (en millisecondes) configuré dans l'objet . Les équipements chargés de la surveillance de ce message disposent d'un paramètre (en millisecondes), configuré dans l'objet . Si le message du producteur ne parvient pas à l'équipement consommateur avant l'expiration du délai configuré, cet équipement génère un événement . Le coupleur de bus passe à l'étatLe message
indique l'état de l'équipement sur un octet, composé de :Le bit ayant le poids le plus fort est réservé et sa valeur est toujours 0
Les 7 bits ayant les poids les plus faibles fournissent l'état de l'équipement, en produisant le message
Les valeurs possibles sont les suivantes :
État du producteur |
Valeur (décimale) |
---|---|
BOOT-UP |
0 |
STOPPED |
4 |
OPERATIONAL |
5 |
‘PRE-OPERATIONAL’ |
127 |