P

1
CANopen

• Chapitre 1 Historique
• Chapitre 2 Couche physique
• Chapitre 3 Couche liaison
• Chapitre 4 Couche application
• Chapitre 5 Résumé caractéristiques principales

2
CANopen
Chapitre 1 Historique
3
Chapitre 1 Historique
Historique
1980-1983 Création de CAN à l initiative de
l équipementier allemand BOSCH pour répondre à
un besoin de l industrie automobile. CAN ne
définit qu une partie des couches 1 et 2 du
modèle ISO.
1983-1987 Prix des drivers et
micro-contrôleurs intégrant CAN très attractifs
car gros volume consommé par l automobile
1991 Naissance du CIA CAN in Automation
http//www.can-cia.de/ pour promouvoir les
applications industrielles
4
Chapitre 1 Historique
Historique
1993 Publication par le CiA des
spécifications CAL CAN Application Layer qui
décrit des mécanismes de transmission sans
préciser quand et comment les utiliser.
1995 Publication par le CiA du profil de
communication DS-301 CANopen
2001 Publication par le CIA de la DS-304
permettant d intégrer des composants de sécurité
de niveau 4 sur un bus CANopen standard (CANsafe).
5
Chapitre 1 Historique
Les spécifications de référence

• CANopen a été bâti chronologiquement à partir de
  plusieurs spécifications
• CAN 2.0 A et B (origine Robert BOSCH)
• Définit précisément la couche liaison et une
  partie de la couche physique
• CAL CAN Application Layer (CiA)
• Fournit des outils permettant de développer une
  application utilisant CAN sans mode d emploi
  précisions sur la couche physique
• CANopen (CiA)
• Définit quels outils CAL utiliser et comment.
• Garantit l interopérabilité des produits par la
  description de profiles.

6
Chapitre 1 Historique
CANopen et le modèle ISO
Device Profile CiA DS-401 I/O modules
Device Profile CiA DS-402 Drives
Device Profile CiA DS-404 Measuring devices
Device Profile CiA DS-4xx
APPLICATION
7
CiA DS-301 Communication profile
CAL CAN Application Layer
Non implémentée
PRESENTATION
6
Non implémentée
SESSION
5
Non implémentée
TRANSPORT
4
RESEAU
3
Non implémentée
CAN 2.0 A et B ISO 11898
LIAISON LLC MAC
2
Spécifications CAN
CAN 2.0 A et B ISO 11898
PHYSIQUE
1
ISO 11898 DS-102 DRP-301-1
7
CANopen
Chapitre 2 Couche physique

• Partie 1 Caractéristiques du médium
• Partie 2 Connectiques recommandées

8
Chapitre 2 Couche physique - Partie 1
Caractéristiques du médium
Couche physiquede CANopen
Device Profile CiA DS-401 I/O modules
Device Profile CiA DS-402 Drives
Device Profile CiA DS-404 Measuring devices
Device Profile CiA DS-4xx
APPLICATION
7
CiA DS-301 Communication profile
CAL CAN Application Layer
Non implémentée
PRESENTATION
6
Non implémentée
SESSION
5
Non implémentée
TRANSPORT
4
RESEAU
3
Non implémentée
CAN 2.0 A et B ISO 11898
LIAISON LLC MAC
2
CAN 2.0 A et B ISO 11898
PHYSIQUE
1
ISO 11898 DS-102 DRP-301-1
9
Chapitre 2 Couche physique - Partie 1
Caractéristiques du médium
Description du médium

• Paire différentielle torsadée 1 paire si CAN-H
  / CAN-L
• 2 paires si CAN-H / CAN-L alim.
• Impédance caractéristique de ligne 120 ohms
  nominal
• Terminaisons de ligne 120 ohms à chaque
  extrémités
• Résistance du fil 70 milli-ohms / mètre
  nominal
• Temps de propagation 5 ns / mètre nominal
• Topologie Type bus avec dérivations les
  plus courtes possibles

10
Chapitre 2 Couche physique - Partie 1
Caractéristiques du médium
Débit - longueur du bus - section câble pour 32
stations maximum
11
Chapitre 2 Couche physique - Partie 1
Caractéristiques du médium
Débit - longueur du bus - section câble pour 100
stations maximum
12
Chapitre 2 Couche physique - Partie 2
Connectiques recommandées
Connectiques recommandées

• Le CiA préconise dans sa recommandation DR-303-1
  une liste de connecteurs classée en 3 catégories.
• Usage général
• SUB D 9 points connector DIN 41652, connecteur
  multipole (cable plat vers SUB-D 9pts), RJ10, et
  RJ45
• Usage industriel
• Mini Style 5 pins, Micro Style 5pins, Open Style
• Usage particulier
• Connecteur rond 7 points, connecteur rond 8
  points, connecteur rond 9 points, connecteur rond
  12 points, Hand Brid Harting.

13
Chapitre 2 Couche physique - Partie 2
Connectiques recommandées
Connecteur SUB D 9 points DIN 41652
Mâle coté produit

• Pin Signal Description
• 1 Reserved
• 2 CAN_L CAN_L bus line dominant low
• 3 CAN_GND CAN Ground
• 4 Reserved
• 5 (CAN_SHLD) Optional CAN Shield
• 6 (GND) Optional Ground
• 7 CAN_H CAN_H bus line dominant high
• 8 Reserved
• 9 (CAN_V) Optional CAN external positive supply

14
Chapitre 2 Couche physique - Partie 2
Connectiques recommandées
Connecteur RJ45

• Pin Signal Description
• 1 CAN_H CAN_H bus line (dominant high)
• 2 CAN_L CAN_L bus line (dominant low)
• 3 CAN_GND Ground / 0 V / V-
• 4 Reserved
• 5 Reserved
• 6 (CAN_SHLD) Optional CAN Shield
• 7 CAN_GND Ground / 0 V / V-
• 8 (CAN_V) Optional CAN external positive
  supply

15
Chapitre 2 Couche physique - Partie 2
Connectiques recommandées
Connecteur 5-pin Mini Style 7/8
Mâle coté produit

• Pin Signal Description
• 1 (CAN_SHLD) Optional CAN Shield
• 2 (CAN_V) Optional CAN external positive
  supply
• 3 CAN_GND Ground / 0V / V-
• 4 CAN_H CAN_H bus line (dominant high)
• 5 CAN_L CAN_L bus line (dominant low)

16
Chapitre 2 Couche physique - Partie 2
Connectiques recommandées
Connecteur Open Style
Mâle coté produit

• Pin Signal Description
• 1 CAN_GND Ground / 0 V / V-
• 2 CAN_L CAN_L bus line (dominant low)
• 3 (CAN_SHLD) Optional CAN Shield
• 4 CAN_H CAN_H bus line (dominant high)
• 5 (CAN_V) Optional CAN external positive
  supply

17
Chapitre 2 Couche physique - Partie 2
Connectiques recommandées
Fournisseurs recommandés

• Câbles
• - U.I.LAPP GmbH Schultze-Delitsch-Str.
  25 D-70565 Stuttgart Germany
• http//www.lappcable.com
• Connecteurs
• - ERNI Elektroapparate GmbH Seestrasse 9 D-73099
  Adelberg Germany
• - ERNI Connectique S.a.r.l, France 27 bis,
  avenue des Sources / CP 638 F-69258 LYON Cedex
  09, http//connect.erni.com/

18
CANopen
Chapitre 3 Couche liaison

• Partie 1 Format des trames
• Partie 2 La sécurisation des échanges

19
Chapitre 3 Couche liaison - Partie 1 Format
des trames
CAN 2.0.A et CAN 2.0.B

• La spécification CAN V2.0 comprend 2 versions
  CAN 2.0.A et CAN 2.0.B
• CAN 2.0.A correspond au format de trame standard
  avec un identifieur codé sur 11 bits est utilisé
  par CANopen et la plupart des couches
  applicatives.
• CAN 2.0.B correspond au format de trame étendue
  avec un identifieur codé sur 29 bits est peu
  utilisé.

20
Chapitre 3 Couche liaison - Partie 1 Format
des trames
Structure de la trame CAN 2.0.A
Champ d arbitrage
Taille de la trame sans bit stuffing 47 à 111
bits
1
11
6
0 à 64
15
7
1
1
1
1
Champ de données
Délimit. CRC
Délimit. ACK
Bit RTR Remote Transmission Request
Début de trame SOF
Séquence de CRC
Slot ACK
Fin de trame EOF
Indentifieur
Champ de commande compatibilité et longueur
21
Chapitre 2 Couche physique - Partie 1
Caractéristiques du médium
Bits dominants et bits récessifs
Identifier
Controlfield
SOF
RTR
10
9
8
7
6
5
4
3
2
1
0
R
Station 1 perd l arbitrage
Station 1
D
Station 2
Station 2 perd l arbitrage
Station 3
Bus
22
Chapitre 3 Couche liaison - Partie 1 Format
des trames
Les 4 types de trames CAN

• Data Frame ces trames transportent des données
  d un producteur vers des consommateurs sans
  garantie de traitement.
• Remote Frame ces trames de polling sont émises
  par un maître vers des esclaves pour requérir la
  transmission d une trame de données.
• (utilisé pour le Node Guarding ou pour la
  transmission des PDOs configurés en polling ).
• Error Frame ces trames sont transmises
  lorsqu une station détecte une erreur de
  transmission sur le bus.
• Overload Frame ces trames sont émises pour
  demander un laps de temps supplémentaire entre
  des trames (de données ou de requête) successives.

23
Chapitre 3 Couche liaison - Partie 1 Format
des trames
Data Frame CAN V2.0 A
Trame de données
SOF
IDENT
RTR
CTR
DATA
CRC
ACK
EOF
Intertrame
0 à 64X
1D
1D
1X1R
5X1R
6X
11X
7R
3R
Remote Frame CAN V2.0 A
Trame de requête
SOF
IDENT
RTR
CTR
DATA
CRC
ACK
EOF
Intertrame
0 à 64X
1D
3R
1X1R
5X1R
6X
11X
7R
1R

• Un trame de donnée (Data frame) est prioritaire
  par rapport à une trame de requête (Remote
  frame).

24
Chapitre 3 Couche liaison - Partie 1 Format
des trames
Error Frame
Erreur détectée
ERROR FLAG
ERROR DELIMITER
Trame en cours de diffusion
ACTIVE ERROR FLAG 6D
8R
PASSIVE ERROR FLAG 6R
Overload Frame
EOF ou ERROR DELIMITER
OVERLOAD FLAG
OVERLOAD DELIMITER
Trame précédente
6D
8R
25
Chapitre 3 Couche liaison - Partie 2 La
sécurisation des échanges
Les mécanismes de sécurisation

• Au niveau du bit lors de la transmission de 5
  bits identiques il est introduit volontairement
  un bit supplémentaire dit de stuffing  de
  valeur opposée. Ce bit est testé et éliminé par
  le récepteur.
• Au niveau de la structure des trames, des
  délimiteurs CRC Delimiter, ACK Delimiter, End
  of Frame, Error Delimiter, Overload Delimiter
  sont intégrés pour permettre la vérification de
  la structure.
• Au niveau de la validité du contenu une
  séquence de CRC permet aux récepteurs de vérifier
  la cohérence des données reçues.
• ACK slot cette fenêtre permet à l émetteur de
  savoir que son message a bien été reçu par au
  moins une station (bit dominant).

26
Chapitre 3 Couche liaison - Partie 2 La
sécurisation des échanges
Compteurs d erreurs

• Chaque noeud comporte obligatoirement deux
  compteurs
• TEC Transmit Error Counter, et REC Receive Error
  Counter.
• Ces compteurs s incrémentent et se décrémentent
  en utilisant un mécanisme de pondération
  sophistiqué gravé dans le silicium.
• Suivant la valeur de ces compteurs, le nœud se
  trouve dans un des 3 états suivant
• Erreurs actives
• Erreurs passives
• Bus OFF (driver d émission déconnecté du bus).

27
Chapitre 3 Couche liaison - Partie 2 La
sécurisation des échanges
Valeur des compteurs / état du noeud
Reset et configuration
Erreurs actives
REC gt 127ou TEC gt 127
REC lt 128et TEC lt 128
128 occurrences de 11 bits récessifs consécutifs
(fin de trames sans erreurs)
Erreurs passives
TEC gt 255
Bus OFF
28
CANopen
Chapitre 4 Couche application

• Partie 1 Concepts de base de CANopen
• Partie 2 Objets et services CANopen

29
Chapitre 4 Couche application - Partie 1
Concepts de base de CANopen
CANopen s appuie sur CAL
Device Profile CiA DS-401 I/O modules
Device Profile CiA DS-402 Drives
Device Profile CiA DS-404 Measuring devices
Device Profile CiA DS-4xx
CiA DS-301 Communication profile
APPLICATION
7
CAL CAN Application Layer
Non implémentée
PRESENTATION
6
Non implémentée
SESSION
5
Non implémentée
TRANSPORT
4
RESEAU
3
Non implémentée
CAN 2.0 A et B ISO 11898
LIAISON LLC MAC
2
PHYSIQUE
1
CAN 2.0 A et B ISO 11898-1 et 2
ISO 11898 DS-102
30
Chapitre 4 Couche application - Partie 1
Concepts de base de CANopen
Couche application

• CANopen définit
• comment les données sont transmises
• Profil communication DS-301 commun à tous les
  produits
• Définit entre autre
  l allocation des identifieurs COB-ID pour chaque
  type de message.
• quelles données sont transmises
• Profils produits DS-4xx propre à chaque
  famille de produit
• (E/S TOR, E/S analogique, variateurs de
  vitesse, encodeurs)
• La description des ces fonctionnalités seffectue
  par l intermédiaire d un dictionnaire d objet
  Device Object Dictionnary (OD).

31
Chapitre 4 Couche application - Partie 1
Concepts de base de CANopen
Object Dictionary OD

• Le dictionnaire d objet OD est un groupement
  ordonné d objets accessibles par
• un index de 16 bits
• et éventuellement un sub-index sur 8 bits
• Il décrit l ensemble des fonctionnalités du
  produit.
• Cette description se matérialise par un fichier
  EDS Electronic Data Sheet.
• de format ASCII respectant une syntaxe stricte
  et exploitable par les logiciels de configuration
  du bus (Sycon etc)

32
Chapitre 4 Couche application - Partie 1
Concepts de base de CANopen
Structure du  Object Dictionary 
33
Chapitre 4 Couche application - Partie 1
Concepts de base de CANopen
Profils CANopen

• Le profil de communication DS-301
• Décrit la structure générale de l OD, et des
  objets se trouvant dans la zone  Communication
  profile area  index 1000 à 1FFF.
• Il sapplique à tous les produits CANopen.
• Les profils équipements DS-4xx
• Décrivent pour les differents types de produit
  (modules E/S TOR, E/S analogiques, variateurs,
  appareil de mesures) les différents objets
  associés.
• Objets standardisés Index 6000 à 9FFF
• Objets spécifiques Index 2000 à 5FFF
• Certains objets sont obligatoires, d autres
  optionnels. Ils sont accessibles soit en lecture,
  soit en lecture et écriture.

34
Chapitre 4 Couche application - Partie 1
Concepts de base de CANopen
Extrait du fichier EDS CANopen ATV58
FileInfo FileNameA58_F.eds FileVersion1 FileRe
vision2 DescriptionCarte Option
ATV58 CreationTime0000AM CreationDate12-05-2000
CreatedByMarie-Annick Menanteau, Schneider
Electric DeviceInfo VendorNameSchneider
Electric ProductNameATV58_F ProductVersion1 Prod
uctRevision1 BaudRate_100 BaudRate_200 BaudRate
_500 BaudRate_1000 BaudRate_1251 BaudRate_2501
BaudRate_5001 BaudRate_8000 BaudRate_10001 Gra
nularity0x8 VendorNumber0x0200005a ProductNumber
0 SimpleBootUpMaster0 ExtendedBootUpMaster0 Sim
pleBootUpSlave1 ExtendedBootupSlave0.
Comments Lines6 Line1Used profile 402
Line2Manufacturer device name
VW3A58306 Line3Hardware version
1.0 Line4Software version
1.0 Line6 This is the EDS file for the CANopen
Schneider Electric ATV58 drive module CAN
Communication Adapter MandatoryObjects Support
edObjects12 10x1000 20x1001 30x6040 40x6041 5
0x6042 60x6043 70x6044 80x6046 90x6048 100x6
049 110x6060 120x6061 1000 ParameterNameDevi
ce Type ObjectType7 DataType0x0007 AccessTypeRO
DefaultValue0x10192 PDOMapping0
35
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Profil de communication CANopen DS-301

• Le profil de communication CANopen définit 4
  fonctions standardisés
• 1 . Administration du réseau démarrage du bus,
  affectation des identifieurs, paramétrage, et
  surveillance NMT Network ManagemenT (modèle
  maître-esclave)
• 2 . Transmission rapide des données de process
  (lt 8octets)
• PDO Process Data Object (modèle
  producteur-consommateur)
• 3 . - Transmission de données de paramétrage
  (peuvent être gt 8 octets par segmentation) sans
  contrainte de temps
• SDO Service Data Object (modèle client-serveur)
• 4 . Messages prédéfinis pour gérer les
  synchronisation, références temporelles, erreurs
  fatales SFO Special Function Object

36
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Administration du réseau NMT
Démarrage du bus
Diagramme d état correspondant au  CANopen
minimum boot-up  (service obligatoire)

• Transitions effectuées par le maître NMT
  Types d objet de communication autorisés
• 1 Start_Remote_Node a. NMT
• 2 Stop_Remote_Node b. Node Guard
• 3 Enter_Pre-Operational_State c. SDO
• 4 Reset_Node d. EMCY
• 5 Reset_Communication e. PDO.
• 6 Initialisation du nœud terminée

37
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Allocation des identifieurs

• L allocation des identifieurs peut s effectuer
  par 3 méthodes
• En utilisant lallocation par défaut CANopen
  Predefined Set
• Cette allocation par défaut est obligatoire et
  disponible dans l état Pre-Opérational.
• Elle permet de réduire la phase de configuration
  du réseau
• Les données de process sont échangées entre le
  manager du bus et les esclaves
• Defini uniquement pour les 4 premiers PDOs
  PDO1 à PDO4
• Par application dans la l état Pre-Operational
  
• Obligatoire pour les PDOs supérieurs à PDO4, ou
  pour le PDO linking (direct exchanges between
  slaves)
• Par application dans la l état Pre-Operational
  
• Ecriture dans les objets correspondant du
  dictionnaire par service SDO

38
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Allocation par défaut des identifieurs

• Dans le but de réduire la phase de configuration
  du réseau un système obligatoire d allocation
  des identifieurs par défaut est défini.
• Cette allocation est effective dans l état  Pre
  operational  juste après la phase
  d initialisation.
• Elle est basée sur un partage de l identifieur
  COB-ID en 2 parties
• Function code permet le codage de 2 PDO en
  réception, 2 PDO en émission, 1 SDO, 1 EMCY
  object, 1 Node Guardind Identifier, 1 SYNC
  object, 1 Time Stamp obect.
• Node ID correspond à l adresse du produit codée
  par exemple par des DIP switchs.

10
9
8
7
6
5
4
3
2
1
0
Function Code
Node ID
39
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Allocation par défaut des identifieurs
L allocation par défaut des identifieurs
n est utilisable que pour les produits
utilisant les 4 premiers PDO (Le cinquième PDO
recouvre la zone réservée aux SDO)
1024 identifieurs maximum résersvés pour les PDO
40
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Allocation par défaut des identifieurs
Esclave 1
Master
Entrées
Esclave 2
Tous les nœuds (esclaves) communiquent avec une
station centale (maître)
Sorties
Esclave 3
41
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Modification de l allocation par défaut
Produit X
Permet d échanger des données directement sans
passer par le maître (PDO linking). Utilisation
du concept producteur-consommateur. Exemple
Commande d axes
Produit Z
Produit Y
42
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Les Process Data Objects PDO

• Ces services sont utilisés pour la transmission
  de données de process de faible taille (lt
  8octets) en temps réel.
• Ils permettent à un équipement producteur de
  mettre à disposition d un ou plusieurs
  consommateurs une variable de taille maximum 64
  bits sans overhead.
• Ce service n est pas confirmé.

43
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Description des PDO

• Chaque PDO en émission ou réception est décrit
  par 2 objets dans le dictionnaire d object
• PDO Communication Parameter indique comment est
  transmis ou reçu
• le PDO
• Le COB-ID utilisé
• Le mode de transmission/réception utilisé
• Pour les PDO en émission, le temps minimum entre
  2 messages (inhibit time)
• PDO Mapping Parameter indique quelles données
  sont transportées
• La liste des objets du dictionnaire d objet OD
• La taille de chaque objet

44
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Objets TxPDO Communication parameter
PDO en émission Index 0x1800 à 0x19FF
45
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Objets TxPDO Mapping parameter
PDO en émission Index 0x1A00 à 0x1BFF
46
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Objets RxPDO Communication parameter
PDO en réception Index 0x1400 à 0x15FF
47
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Objets RxPDO Mapping parameter
PDO en réception Index 0x1600 à 0x17FF
48
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Mode de transmission des PDO

• Synchrone par réception d un message SYNC
• Acyclique - la transmission est pré-déclenchée
  par l occurrence d un événement
• dans léquipement
• - la transmission est pré-déclenchée par une
   Remote request  (polling)
• Cyclique - la transmission est déclenchée
  périodiquement après chaque 1, 2 ou jusqu à
  240 messages SYNC

Asynchrone - la transmission est déclenchée
par l occurrence d un événement dans le
profil de l équipement - la transmission est
déclenchée par une  Remote request
49
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Transmission synchrone acyclique des PDO
Sur événement - Transmission type 0
SYNC
SYNC
SYNC
SYNC
SYNC
TxPDO_PX
Evénement produit X
Sur réception d une Remote Request (polling) -
Transmission type 252
SYNC
SYNC
SYNC
SYNC
Remote request vers produit X
Remote request vers produit X
SYNC
TxPDO_PX
TxPDO_PX
50
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Transmission synchrone cyclique des PDO
Cyclique sur n signaux de synchro - Transmission
type 1 à 240 (nombre de message SYNC)
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
TxPDO_PX
TxPDO_PX
TxPDO_PX
Exemple si n 3
Exemple si n 3
51
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Transmission asynchrone des PDO
Sur événement - Transmission type254 événement
spécifique, 255 événement défini dans profil
SYNC
SYNC
SYNC
SYNC
SYNC
Evénement produit X
TxPDO_PX
Sur réception d une Remote Request (polling) -
Transmission type 253
SYNC
SYNC
SYNC
SYNC
Remote request vers produit X
SYNC
Remote request vers produit X
TxPDO_PX
TxPDO_PX
52
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Transmission des PDO Inhibit time

• Pour garantir que des objets ayant un niveau
  faible de priorité puisse être transmis, il est
  possible d affecter un temps minimum entre 2
  transmission d un même PDO.
• Cette valeur est renseignée dans le paramètre
   Inhibit time  des objets TxPDO communication
  parameters index 0x1800 à 0x19FF.

53
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Réception synchrone acyclique des PDO
Sur événement - Transmission type 0
SYNC
SYNC
SYNC
SYNC
SYNC
Rx_PDO_PX
Tx_PDO_PX
Prise en compte du PDO reçu
54
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Réception synchrone cyclique des PDO
Cyclique sur n signaux de synchro - Transmission
type 1 à 240
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
SYNC
T_PDO_PX
RxPDO_PX
T_PDO_PX
RxPDO_PX
Exemple si n 3
Exemple si n 3
Prise en compte du PDO reçu
Prise en compte du PDO reçu
55
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Réception asynchrone des PDO
Sur événement - Transmission type254
SYNC
SYNC
SYNC
SYNC
SYNC
RxPDO_PX
T_PDO_PX
Prise en compte du PDO reçu
56
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Les Service Data Objects SDO

• Ces services sont utilisés pour la transmission
  en point à point de données de paramétrage
  n ayant pas de contraintes de temps.
• Ils permettent à un équipement client (manager du
  bus) d accéder au dictionnaire d objets d un
  équipement serveur (stations 1 à 127) en écriture
  ou en lecture en l adressant par son Index et
  Sub-index.
• La taille des données peut dépasser 8 octets,
  dans ce cas un système de segmentation des
  données est activé.
• Le résultat d une écriture ou d une lecture est
  confirmé par une réponse.
• Un échange SDO requiert 2 COB-ID un pour la
  requête, l autre pour la réponse.

57
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Les Special Function Objects SFO

• SYNC Synchronization Object
• Cet objets est utilisé pour synchroniser
  l acquisition de données dentrées, ou la mise à
  jour de de données en sorties (commande d axes
  par exemple).
• Le manager du bus émet le message SYNC à une
  période communication (cycle period) définie lors
  de la configuration.

58
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Les Special Function Objects SFO

• Time Stamp Object
• L objet Time-Stamp fournit une référence de
  temps commune à tous les stations.
• Ce temps est codé sur 6 octets et représente un
  temps absolu en ms à partir du 1er janvier
  1984.Il permet de synchroniser l horloge locale
  de toutes les stations.

59
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Les Special Function Objects SFO

• EMCY Object
• Les objets EMCY sont utilisés pour transmettre
  des défauts applicatifs associés à chaque station
  (courant, tension, température, etc)

60
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Les Special Function Objects SFO

• 2 mécanismes permettent de surveiller l état des
  stations présentes sur le bus.
• Le Node guarding
• Fonctionne suivant le concept maître esclave
  (polling) permet au manager du bus de demander
  (Remote request) l état de chaque station à une
  période définie par configuration.
• Le Heartbeat
• Fonctionne suivant le concept producteur
  consommateur.
• L état de la station est produit cycliquement à
  une période définie par configuration.
• Ce mécanisme nouvellement spécifié remplace le
  node guarding sur les nouveaux produits
  (meilleurs utilisation de la bande passante).

61
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Les Special Function Objects SFO

• Node guard Object
• Le maitre NMT surveille l état des esclaves
  connectés sur le bus en émettant périodiquement
  (Guard time) une remote frame Node guard object à
  chaque esclave.
• Dès réception ,l esclave répond au maître.
• Les esclaves peuvent optionnellement surveiller
  le maître NMT Life guarding.
• Life Time Guard Time x Life Time Factor
• Si pendant un temps égal au Life Time un esclave
  ne reçoit pas de polling, il génère un événement
   Life guarding , passe en défaut communication
  et envoie un objet EMCY.

62
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Les Special Function Objects SFO

• Node guard Object
• Le maitre NMT scrute régulièrement l état de
  chacun des esclaves par une Remote Frame et les
  compare aux valeurs précédentes enregistrées dans
  une table.
• Si une différence est détectée, l information
  est remontée à l application par l événement
   Network Event .

63
Chapitre 4 Couche application - Partie 2
Objets et services CANopen
Les Special Function Objects SFO

• Heartbeat
• La fonction Heartbeat nouvellement spécifiée
  permet d économiser la bande passante par
  rapport au node guarding.
• Le producteur de Heartbeat transmet le message
  Heartbeat suivant une période définie dans
  l objet  Heartbeat Producer Time .
• Le consommateur de Heartbeat vérifie qu il
  reçoit le message Heartbeat dans la fenêtre de
  temps défini dans l objet  Heartbeat Consumer
  Time .

64
CANopen
Chapitre 5 Résumé des caractéristiques
principales
65
Chapitre 5 Résumé des caractéristiques
principales
Couche physique

• Medium Paire torsadée blindée 2 ou 4 fils
  (si alimentation)
• Topologie Type bus
• Avec dérivations courtes et résistance fin de
  ligne
• Distance maximum 1000 m
• Débit 9 débits possibles de 10 Kbit/s à
  1Mbits/s Fonction de la longueur du bus et de
  la nature du
• câble 1000 m à 10Kbits/s, 25 m à 1
  Mbits/s,
• Nbre max équipements 127
• 1 maître et 126 esclaves

66
Chapitre 5 Résumé des caractéristiques
principales
Couche liaison

• Méthode d accès au médium CSMA/CA
• Chaque équipement peut émettre dès que le bus est
  libre.
• Un principe de bits dominants ou récessifs permet
  lors d une collision un arbitrage bit à bit non
  destructif.
• La priorité d un message est donné par la valeur
  de l identifieur appelé COB-ID (Communication
  Object IDentifieur) situé en début de trame.
• Le COB-ID est codé sur 11 bits valeurs
  comprises entre 0 et 2047.
• Le COB-ID de valeur la plus faible est
  prioritaire.

67
Chapitre 5 Résumé des caractéristiques
principales
Couche liaison

• Modèle de communication Producteur /
  Consommateur
• Chaque message possède un identifieur unique
  situé en début de trame.
• La valeur de cet identifieur renseigne les
  récepteurs sur la nature des données contenues
  dans chaque message.
• Chaque récepteur en fonction de sa configuration,
  consomme ou non ces données.
• Taille maxi des données utiles 8 octets par
  trame
• Sécurité de transmission
• Parmi les meilleurs sur les réseaux locaux
  industrielsDe nombreux dispositifs de
  signalisation et de détections d erreurs
  permettent de garantir une grande sécurité de
  transmission.

68
Chapitre 5 Résumé des caractéristiques
principales
Couche application

• CANopen définit
• comment les données sont transmises
• Profil communication DS-301 commun à tous les
  produits
• Définit entre autre l allocation des
  identifieurs COB-ID pour chaque type de message.
• quelles données sont transmises
• Profils produits DS-4xx propre à chaque
  famille de produit
• (E/S TOR, E/S analogique, variateurs de
  vitesse, encodeurs)
• La description des ces fonctionnalités seffectue
  par l intermédiaire d un dictionnaire d objet
  Device Object Dictionnary (OD) matérialisé par un
  fichier EDS.

69
Chapitre 5 Résumé des caractéristiques
principales
Couche application

• 4 types de services sont standardisés
• 1 . Administration du réseau paramétrage,
  démarrage, surveillance (maître-esclaves)
• 2 . Transmission rapide des données de process
  (lt 8octets)
• PDO Process Data Object (modèle
  producteur-consommateur)
• 3 . - Transmission de données de paramétrage
  (peuvent être gt 8 octets par segmentation) sans
  contrainte de temps
• SDO Service Data Object (modèle client-serveur)
• 4 . Messages prédéfinis pour gérer les
  synchronisation, références temporelles, erreurs
  fatales SFO Special Function Object