Publicité
3-8
EXPANSION MODULE - CANOpen
Deux mécanismes décrits en détail dans les paragraphes qui suivent sont prévus pour accéder aux données susmentionnées.
PDO - Process Data Object
Canal utilisé pour le transfert des données relatives au process,
en temps réel.
Messages synchrones, asynchrones et pilotés par évènements. Messages asynchrones
Identifiants à haute priorité (CAN-ID bas)
Optimisés pour échanger des données rapidement et
efficacement
Correspondance directe avec un objet du dictionnaire
Transfert en un seul message
3.3
Modèle de communication
Bien que l'architecture CAN soit de type multi-maître, l'implémentation du CANOpen prévoit une stracture hiérarchique de
type multi-esclave, afin de simplifier la configuration du système et la gestion du réseau. Ce qui signifie que, même si l'on conserve
un fieldbus CAN (bus de terrain CAN) dans lequel, au niveau de la couche physique et de la couche liaison de données, chaque
nœud reste maître à toutes fins utiles, l'interface avec la couche application requiert le choix d'un Maître d'Application pour chacun
des services fournis. Un même nœud peut être le maître de diverses fonctions ou il peut y avoir autant de maîtres que de fonctions.
En outre, il est possible de changer de maître à chaque cycle de système, selon l'algorithme programmé pour le choix du maître
(par exemple : le maître pour le service en question doit être le nœud ayant actuellement l'identifiant (ID) le plus bas parmi les nœuds
en mode d'erreur active. Il n'est pas dit et il est même improbable, qu'à chaque cycle, la même station puisse toujours satisfaire les
caractéristiques requises, soit parce qu'elle peut tomber en panne et passer à l'état d'erreur passive ou soit parce qu'un autre nœud
avec un indentifiant inférieur peut recommencer à fonctionner correctement et passer au mode d'Erreur Active. En tout état de
cause, cette hiérarchie reste toujours totalement transparente pour les couches inférieures.
Chaque maître peut avoir jusqu'à 127 esclaves : chaque nœud est identifié par une adresse unique sur 7 bits (ID), dans une plage
de 1 à 127.
NOTE
L'application IVECO prévoit uniquement l'utilisation d'un maître et d'un seul esclave.
3.3.1
Objets de communication COB-ID
Le CANOpen permet l'échange d'informations par l'intermédiaire de Communication Objects (COB) : le modèle de communication
CANOpen précise quels sont les différents COB, les services de communication et les modes possibles de " triggering " (déclenchement)
pour l'envoi des données. Chaque COB (objet de communication) est identifié, de façon univoque, par un identifiant faisant partie du
COB lui-même. La spécification CAN 2.0A prend en charge jusqu'à 2048 COB, identifiés par des identifiants codés sur 11 bits.
Il assure la transmission de messages synchrones et asynchrones. Les premiers indiquent que la saisie et " l'exécution " d'informations
peuvent être réalisées de façon coordonnée dans tout le réseau. Les objets de communication prédéfinis dédiés à ce type de
messages sont dénommés "Syn Message" (message de synchronisation) et "Time Stamp Message" (Message timbre horodateur).
Par contre, les messages asynchrones peuvent être envoyés n'importe quand, précisément parce qu'ils ne doivent respecter aucune
synchronisation prédéfinie du réseau complet.
La table qui suit contient le schéma d'assignation prédéfinie des identifiants.
CANOpen
Base - 12/2010
Tableau 4
SDO - Service Data Object
Canal utilisé pour le transfert de données de service ayant des
impératifs très serrés en termes de temps.
Identifiants à basse priorité (CAN-ID haut)
Optimisés pour plusieurs applications et transfert de grosses
quantités de données mais non critiques dans le temps.
Accès à un objet indirectement par un index et sous-index.
Transfert en plusieurs messages
D
AILY MY 2009
Printed 603.95.234
Publicité
