Présentation. Division - Name - Date - Language 2 Chapitre 1 :Connaissances de base Chapitre 2 : Couche physique Chapitre 3 : Couche liaison Chapitre

Présentation

Division - Name - Date - Language 2

Chapitre 1 : Connaissances de base

Chapitre 2 : Couche physique

Chapitre 3 : Couche liaison

Chapitre 4 : Couche application

CANopen


Partie 1 : Historique

Partie 2 : Caractéristiques principales

Chapitre 1 : Connaissances de base

CANopen


1980-1983Création de CAN à l ’initiative de l’équipementier allemand BOSCH pour répondre à un besoin de l’industrie automobileCAN ne définit qu’une partie des couches 1 et 2 du modèle ISO (ISO 11898)

1983-1987Attractivité en prix des drivers et micro-contrôleurs intégrant CAN,du fait des gros volumes consommés par l’industrie automobile

1991Naissance du groupement d’utilisateurs CIA = CAN in Automation : http://www.can-cia.de/ destiné à promouvoir les applications industrielles

Historique

Chapitre 1 : Connaissances de base - Partie 1 : Historique


1995 Publication par le CiA du profil de communication DS-301 : CANopen

2001Publication par le CIA de la DS-304 permettant d’intégrer des composantsde sécurité de niveau 4 sur un bus CANopen standard (CANsafe).

1993 Publication par le CiA des spécifications CAL = CAN Application Layer Celles-ci décrivent les mécanismes de transmission, mais sans préciser quand ni comment les utiliser

Historique

Chapitre 1 : Connaissances de base - Partie 1 : Historique


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

Chapitre 1 : Connaissances de base - Partie 2 : Caractéristiques principales

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 commentGarantit l’interopérabilité des produits par la description de profiles

Les spécifications de référence


APPLICATION

PRESENTATION

SESSION

TRANSPORT

RESEAU

LIAISON = LLC + MAC

PHYSIQUE

7

6

5

4

3

2

1


Modèle OSI


Device ProfileCiA DS-401I/O modules

Device ProfileCiA DS-402

Drives


Measuring devices

Device ProfileCiA DS-4xx

CiA DS-301 = Communication profile

Non implémentée

Non implémentée

Non implémentée

Non implémentée

CAN 2.0 A et B + ISO 11898

CAN 2.0 A et B + ISO 11898

ISO 11898 + DS-102 + DRP-301-1

CAL= CAN Application Layer APPLICATION

PRESENTATION

SESSION

TRANSPORT

RESEAU

LIAISON = LLC + MAC

PHYSIQUE

7

6

5

4

3

2

1

Spé

cifi

cati

ons

CA

N


CANopen et le modèle OSI



Les spécifications de référence


Medium : Paire torsadée blindée2 ou 4 fils (si alimentation)

Topologie : Type busAvec dérivations courtes et résistance fin de ligne

Distance maximum 1000 m

Débit 9 débits possibles de 1Mbits/s à 10 Kbit/sFonction de la longueur du bus et de la nature ducâble : 25 m à 1 Mbits/s, 1000 m à 10Kbits/s

NB maxi équipements 1281 maître et 127 esclaves


Couche physique


Méthode d ’accès au médium : CSMA/CR

(Carrier Sense Multiple Access / Collision Recovery)

Chaque équipement peut émettre dès que le bus est libre

Lors d’une collision, un principe de bits récessifs/dominants permet un arbitrage

bit à bit non destructif (si on "néglige" le temps de

propagation d’un bit, si 2 abonnés

parlent en même temps, celui qui

a mis un ‘1’ sur le bus, alors que

l’autre aura mis un ‘0’, verra que le

bus est occupé, et il s’arrêtera

d’émettre, sans détruire la trame

de l’autre)


Couche liaison


10 9 8 7 6 5 4 3 2 1 0SO

F

RT

R Champ decommande

Identificateur

Station 2perd l ’arbitrage

et arrête d ’émettre

Station 1perd l ’arbitrage

et arrête d ’émettreStation 1

Station 2

Station 3

D

R

S1 S2 S3

Station 3continue d ’émettre,

sa trame n ’est pas modifiée


Couche liaison : Bits dominants et bits récessifsCouche liaison : Bits dominants et bits récessifs


Méthode d ’accès au médium : CSMA/CR

(Carrier Sense Multiple Access / Collision Recovery)

La priorité d ’un message est donné par la valeur de l’identificateur appelé COB-ID

(Communication Object IDentifier) 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


Couche liaison


Modèle de communication : Producteur / Consommateur

Chaque message possède un identificateur unique situé en début de trame

La valeur de cet identificateur 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 industriels

De nombreux dispositifs de signalisation et de détections d’erreurs

permettent de garantir une grande sécurité de transmission


Couche liaison


CANopen définit :

comment sont transmises les données :

Profil communication DS-301 commun à tous les produits

Définit entre autre l’allocation des identificateurs (COB-ID)

pour chaque type de message

quelles sont les données transmises

Profils produits DS-4xx propres à chaque famille de produit

(E/S TOR, E/S analogique, variateurs de vitesse, encodeurs…)

La description de ces fonctionnalités s’effectue par l ’intermédiaire d’un dictionnaire

d ’objet : Device Object Dictionnary (OD), matérialisé par un fichier EDS


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 (<= 8octets) :PDO = Process Data Object (modèle producteur-consommateur)

3 . - Transmission de données de paramétrage sans contrainte de temps (peuvent être > 8 octets par segmentation) : 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


Couche application


Partie 1 : Caractéristiques du médium

Partie 2 : Connectiques recommandées

CANopen

Chapitre 2 : Couche physique



Non implémentée

Non implémentée

Non implémentée

Non implémentée

CAN 2.0 A et B + ISO 11898

CAN 2.0 A et B + ISO 11898

ISO 11898 + DS-102 + DRP-301-1



Drives


Measuring devices



PRESENTATION

SESSION

TRANSPORT

RESEAU

LIAISON = LLC + MAC

PHYSIQUE

7

6

5

4

3

2

1

Chapitre 2 : Couche physique - Partie 1 : Caractéristiques du médium

Couche physiquede CANopen


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 dérivations les plus courtes possibles


Description du médium


Débit Longueur du bus Section câbles

1 Mbit/s 25 m 0,25 mm2 AWG 23

800 Kbit/s 50 m 0,34 mm2 AWG 22

500 Kbit/s 100 m 0,34 mm2 AWG 22

250 Kbit/s 250 m 0,34 mm2 AWG 22

125 Kbit/s 500 m 0,5 mm2 AWG 20

50 Kbit/s 1000 m 0,75 mm2 AWG 18

20 Kbit/s 1000 m 0,75 mm2 AWG 18

10 Kbit/s 1000 m 0,75 mm2 AWG 18


Débit - longueur du bus - section câble pour 32 stations maximum


Débit Longueur du bus Section câbles

1 Mbit/s 25 m 0,34 mm2 AWG 22

800 Kbit/s 50 m 0,6 mm2 AWG 20

500 Kbit/s 100 m 0,6 mm2 AWG 20

250 Kbit/s 250 m 0,6 mm2 AWG 20

125 Kbit/s 500 m 0,75 mm2 AWG 18

50 Kbit/s 1000 m 1 mm2 AWG 17

20 Kbit/s 1000 m 1 mm2 AWG 17

10 Kbit/s 1000 m 1 mm2 AWG 17


Débit - longueur du bus - section câble pour 100 stations maximum


Le CiA préconise dans sa recommandation DR-303-1 une liste de connecteurs classée en 3 catégories :

Usage généralconnecteur SUB-D 9 points, connecteur DIN 41652, connecteur multipôles (câble plat vers SUB-D 9 points), connecteur RJ10, et connecteur RJ45

Usage industrielconnecteur Mini Style 5 points, connecteur Micro Style 5 points, connecteur Open Style

Usage particulierConnecteur rond 7 points, connecteur rond 8 points, connecteur rond 9 points, connecteur rond 12 points, connecteur Hand Brid Harting

Connectiques recommandées

Chapitre 2 : Couche physique - Partie 2 : Connectique recommandée


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

Mâle coté produit

Connecteur SUB D 9 points DIN 41652



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

Connecteur RJ45



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)

Mâle coté produit

Connecteur 5-pin Mini Style : 7/8



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

Mâle coté produit

Connecteur Open Style



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/

Fournisseurs recommandés



Partie 1 : Format des trames

Partie 2 : La sécurisation des échanges

CANopen

Chapitre 3 : Couche liaison


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 identificateur sur 11 bits

utilisée par CANopen et la plupart des couches applicatives

CAN 2.0.B

correspond au format de trame étendue avec un identificateur sur 29 bits

peu utilisée

CAN 2.0.A et CAN 2.0.B

Chapitre 3 : Couche liaison - Partie 1 : Format des trames


Séquence deCRC

Début de trame SOF

Indentifieur

Bit RTR RemoteTransmission

Request

Champ dedonnées

Délimit.CRC

SlotACK

1 11 6 0 à 64 15 71 111

Délimit.ACK

Fin detrameEOF

Champd ’arbitrage

Champ decommande :compatibilitéet longueur

Taille de la trame sans bit stuffing : 47 à 111 bits

Structure de la trame CAN 2.0.A



Data Frame

trames transportant des données d’un producteur vers des consommateurs, sans

garantie de traitement

Remote Frame

trames de requête en polling émises par un maître vers un ou des esclaves, pour

demander le renvoi d ’une trame de données (utilisées pour le Node Guarding, ou

pour l ’émission des PDOs si ceux-ci sont configurés en polling)

Error Frame

trames émises lorsqu’une station détecte une erreur de transmission sur le bus

Overload Frame

trames émises pour demander un laps de temps supplémentaire entre des trames

(de données ou de requête) successives

Les 4 types de trames CAN



SOF IDENT RTR CTR DATA CRC ACK EOF

1D 0 à 64X 1X+1R5X+1R6X11X 1D 7R

SOF IDENT RTR CTR DATA CRC ACK EOF

1D 0 à 64X 1X+1R5X+1R6X11X 7R1R

Trame de données

Trame de requête

Intertrame

3R

Intertrame

3R

Une trame de Donnée (Data frame) est prioritaire sur une trame de Requête (Remote frame)

Data Frame CAN V2.0 A

Remote Frame CAN V2.0 A



ERROR FLAG ERROR DELIMITER

ACTIVE ERROR FLAG : 6D 8R

Trame en cours de diffusion

Erreur détectée

PASSIVE ERROR FLAG : 6R

OVERLOAD FLAG OVERLOAD DELIMITER

6D 8R

Trame précédente

EOF ou ERROR DELIMITER

Error Frame

Overload Frame



Au niveau du bit lors de l ’émission de 5 bits consécutifs identiques, 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 sont intégrés pour permettre la vérification de la structure CRC Delimiter, ACK Delimiter, End of Frame, Error Delimiter, Overload Delimiter .

Au niveau de la validité du contenu un 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 si son message a bien été reçu par au moins une station (bit dominant)

Les mécanismes de sécurisation

Chapitre 3 : Couche liaison - Partie 2 : La sécurisation des échanges


Chaque noeud comporte obligatoirement deux compteurs

TEC : Transmit Error Counter

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).

Compteurs d’erreurs



Erreurs actives

Erreurs passives

Bus OFF

Reset et configuration

REC > 127ou TEC > 127

REC < 128et TEC < 128

TEC > 255

128 occurrences de 11 bits récessifs

consécutifs (fin de trames sans erreurs)

Valeur des compteurs / état du noeud



Etat Erreurs actives dès la détection du défaut, le nœud émet une trame Error Frame,

avec un champ ACTIVE ERROR FLAG les 6 bits dominants émis transgressent la loi de bit stuffing, et provoquent une

réaction en chaîne des autres nœuds qui détruit la trame en cours

Etat Erreurs passives Dès la détection du défaut, le nœud émet une trame Error Frame avec un

champ PASSIVE ERROR FLAG Les bits récessifs émis n ’ont aucune influence sur la trame en cours

d ’émission

Etat Bus OFF : Le nœud est déconnecté et surveille le bus

Comportement en cas d’erreur de communication détecté



Partie 1 : Concepts de base de CANopen

Partie 2 : Objets et services CANopen

CANopen

Chapitre 4 : Couche application



Non implémentée

Non implémentée

Non implémentée

Non implémentée

CAN 2.0 A et B + ISO 11898

CAN 2.0 A et B = ISO 11898-1 et 2

ISO 11898 + DS-102



Drives


Measuring devices



PRESENTATION

SESSION

TRANSPORT

RESEAU

LIAISON = LLC + MAC

PHYSIQUE

7

6

5

4

3

2

1

CANopen s’appuie sur

CAL

Chapitre 4 : Couche application - Partie 1 : Concepts de base de CANopen


CANopen définit :

comment sont transmises les données :

Profil communication DS-301 commun à tous les produits

– Définit entre autre l’allocation des identificateurs COB-ID pour chaque

type de message.

quelles sont les données 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 s’effectue par l’intermédiaire d ’un

dictionnaire d ’objet Device Object Dictionnary (OD)

Couche application



Le Dictionnaire d’Objets (OD) est un groupement ordonné des objets accessibles

sur un type de nœud donné, via :

un index, sur 16 bits

éventuellement un sous-index, sur 8 bits

Le Dictionnaire d’Objets (OD) contient l’ensemble des paramètres décrivant un

produit, ainsi que son comportement vis à-vis du réseau

Cette description est matérialisée 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…)

Dictionnaire d’Objets [Object Dictionary]



Index Objects Description

0x0000 Reserved

0x0001 – 0x009F Data Types Area Définit les différents types de variablesutilisées : octets, mots, doubles mots,signés, non signés etc…

0x00A0 – 0x0FFF Reserved

0x1000 – 0x1FFF Communication profile Area Décrit les objets liés à la communication

(ex : Type d'équipement, Registred'erreur, Nombre de PDOs admis,…)

0x2000 – 0x5FFF Manufacturer Specific Profile Area Décrit les objets ‘’métier’’ spécifiques aufabriquant.

0x6000 – 0x9FFF Standardized Device Profile Area Décrit les objets ‘’métiers’’ normalisés parun profil normalisé CiA (ex DSP-401)

0xA000 – 0xFFFF Reserved

Structure du Dictionnaire d’Objets [Object Dictionary]



Profil de communication DS-301 Décrit la structure générale de l’Object Dictionary, et des objets se trouvant

dans la zone "Communication profile area" : index 1000 à 1FFF Applicable à tous les produits CANopen

Profils équipements DS-4xx Décrivent pour les différents 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

Profils CANopen



[FileInfo]FileName=A58_F.edsFileVersion=1FileRevision=2Description=Carte Option ATV58CreationTime=00:00AMCreationDate=12-05-2000CreatedBy=Marie-Annick Menanteau, Schneider Electric

[DeviceInfo]VendorName=Schneider ElectricProductName=ATV58_FProductVersion=1ProductRevision=1BaudRate_10=0BaudRate_20=0BaudRate_50=0BaudRate_100=0BaudRate_125=1BaudRate_250=1BaudRate_500=1BaudRate_800=0BaudRate_1000=1Granularity=0x8VendorNumber=0x0200005aProductNumber=0SimpleBootUpMaster=0ExtendedBootUpMaster=0SimpleBootUpSlave=1ExtendedBootupSlave=0….

[Comments]Lines=6Line1=Used profile: 402 Line2=Manufacturer device name: VW3A58306Line3=Hardware version: 1.0Line4=Software version: 1.0Line6= This is the EDS file for the CANopen Schneider Electric ATV58 drive module CAN Communication Adapter

[MandatoryObjects]SupportedObjects=121=0x10002=0x10013=0x60404=0x60415=0x60426=0x60437=0x60448=0x60469=0x604810=0x604911=0x606012=0x6061

[1000]ParameterName=Device TypeObjectType=7DataType=0x0007AccessType=RODefaultValue=0x10192PDOMapping=0

Extrait du fichier EDS CANopen ATV58



[1400]SubNumber=0x03ParameterName=receive PDO1 parameterObjectType=6

[1400sub0]ParameterName=number of entriesObjectType=7AccessType=CONSTDataType=0x0005PDOMapping=0LowLimit=2HighLimit=4DefaultValue=0x2

[1400sub1]ParameterName=COB-IDObjectType=7AccessType=RWDataType=0x0007PDOMapping=0LowLimit=HighLimit=DefaultValue=$NODEID+0x200

[1400sub2]ParameterName=transmission typeObjectType=7AccessType=CONSTDataType=0x0005PDOMapping=0LowLimit=HighLimit=DefaultValue=0xFF




[1600]SubNumber=0x03ParameterName=receive PDO mappingObjectType=6

[1600sub0]ParameterName=number of mapped objectsObjectType=7AccessType=RWDataType=0x0007PDOMapping=0LowLimit=0HighLimit=2DefaultValue=0x2

[1600sub1]ParameterName=1.mapped objectObjectType=7AccessType=RWDataType=0x0007PDOMapping=0LowLimit=HighLimit=DefaultValue=0x60400010

[1600sub2]ParameterName=2.mapped objectObjectType=7AccessType=RWDataType=0x0007PDOMapping=0LowLimit=HighLimit=DefaultValue=0x60420010




Chaque type de message CANopen possède un identificateur COB-ID unique, codé sur 11 bits : valeurs comprises entre 0 et 2047

Chaque nœud peut envoyer un message dès que le réseau est libre

Les collisions sont résolues suivant la priorité de chaque message

L ’identificateur de valeur la plus basse est prioritaire

Un message CAN peut transporter au maximum 8 octets de données utiles

Résumé des concepts de base



Le profil de communication CANopen définit 4 fonctions standardisés :

1 . Administration du réseau : démarrage du bus, affectation des identificateurs, paramétrage, et surveillance NMT = Network ManagemenT (modèle maître-esclave)

2 . Transmission rapide des Données de Process (<= 8 octets) :

PDO = Process Data Object (modèle producteur-consommateur)

3 . Transmission de Données de Paramétrage sans contrainte de temps SDO = Service Data Object (modèle client-serveur)(peuvent être > 8 octets par segmentation)

4 . Messages prédéfinis pour gérer les synchronisation, références temporelles, erreurs fatales : SFO = Special Function Object

Profil de communication CANopen DS-301

Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen


Transitions effectuées Types d ’objet

par le maître NMT 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

Diagramme d ’état correspondant au « CANopen minimum boot-up » *

(service obligatoire)

NOTA : Il existe un autre diagramme d ’état

« Extended boot-up »

Administration du Réseau : NMT

Démarrage du bus



L ’allocation des identificateurs peut s’effectuer par 3 méthodes :

En utilisant l’allocation par défaut : CANopen Predefined Set

– existence de ce mode d ’allocation obligatoire

– disponible dans l’état Pre-Opérationnel

– permet de réduire la phase de configuration du réseau

– données de process échangées suivant un mode maître esclaves

Par application, dans l’état Pre-Operationnel

– Ecriture dans les objets correspondant du dictionnaire via le service SDO

En utilisant le service DBT (DistriBuTor)

– possible sur les produits qui supportent la fonction « Extended boot up »

– affectation des identificateurs effectuée automatiquement par ajout d’étapes

supplémentaires entre l’état Pre-Operationnel et Operationnel

Allocation des Identificateurs



Pour réduire la phase de configuration du réseau a été défini un système obligatoire d’allocation des identificateurs par défaut

Ce mode d’allocation est effectif dans l’état "Pré-Operationnel", juste après la phase d ’initialisation

Elle est basée sur un partage de l’identificateur COB-ID en 2 parties :

Code Fonction : permet le codage de 4 PDOs en réception, 4 PDOs en émission, 1 SDO (occupant 2 Identificateurs), 1 EMCY object, 1 Node Guardind Identifier, 1 SYNC object, 1 Time Stamp object

Node ID : correspond à l’adresse du nœud, codée par exemple par DIP switches

10 9 8 7 6 5 4 3 2 1 0

Code Fonction Node ID

Allocation par défaut des Identificateurs



Objets en diffusion générale

Objet Code FonctionBits ID 10 – 7

(Bin)

COB-ID(Hexa)

COB-ID(Dec)

NMT 0000 0x000 0

SYNC 0001 0x080 128

TIME STAMP 0010 0x100 256




Objets en diffusion point à point

Objet Code FonctionBits ID 10 – 7

(Bin)

COB-ID(Hexa)

COB-ID(Dec)

Emergency 0001 0x081à 0x0FF 129 à 255

PDO 1 en émission 0011 0x181 à 0x1FF 385 à 511

PDO 1 en réception 0100 0x201 à 0x27F 513 à 639

PDO 2 en émission 0101 0x281 à 0x2FF 641 - 767


PDO 3 en émission 0111 0x381 à 0x3FF 897 à 1023


PDO 4 en émission 1001 0x481 à 0x4FF 1153 - 1279


SDO en Tx/serveur 1011 0x581 à 0x5FF 1409 à 1535

SDO en Rx/client 1100 0x601 à 0x67F 1537 à 1663

NMT Error Control 1110 0x701 à 0x77F 1793 à 1919

L ’allocation des identificateurs par

défaut n’est utilisable que pour les nœuds

n ’utilisant que les 4 premiers PDO

(Le cinquième PDO recouvre la zone

réservée aux SDO)

10

24

id

en

tifi

ca

teu

rsm

ax

imu

m

r és

ers

vé

s p

ou

r le

s P

DO

s




RxPDO_1_SL1RxPDO_2_SL1RxPDO_1_SL2RxPDO_2_SL2RxPDO_1_SL3RxPDO_2_SL3

TxPDO_1_SL1TxPDO_2_SL1TxPDO_1_SL2TxPDO_2_SL2TxPDO_1_SL3TxPDO_2_SL3

TxPDO_1_SL1TxPDO_2_SL1

RxPDO_1_SL1RxPDO_2_SL1





MasterMaster

Esclave 1Esclave 1

Esclave 2Esclave 2

Esclave 3Esclave 3

Tous les nœuds (esclaves)

communiquent avecune station centale

(maître)

Ent

rées

Ent

rées

Sort

ies

Sort

ies




TxPDO_1_PXTxPDO_2_PX

RxPDO_1_PXRxPDO_2_PX

TxPDO_1_PYTxPDO_2_PY

RxPDO_1_PYRxPDO_2_PYRxPDO_3_PY

TxPDO_1_PZTxPDO_2_PZ

RxPDO_1_PZRxPDO_2_PZRxPDO_3_PZ

Produit XProduit X

Produit YProduit Y Produit ZProduit Z

Permet d ’échangerdes données directement sans passer par le maître

(PDO linking)

Utilisation du concept producteur-consommateur

Exemple : Commande d’axes

Modification de l’allocation par défaut



Services utilisés pour l ’émission en temps réel

de données de process de faible taille (<= 8 octets)

Ils permettent à un équipement producteur

de mettre à disposition d’un ou plusieurs consommateurs

une variable de taille maximum de 64 bits sans overhead

Ce service est est un service non confirmé

Process Data Objects = PDOs



Chaque PDO en émission ou réception est décrit par 2 objets dans le Dictionnaire

d’Objets :

le PDO Communication Parameter, qui indique comment est transmis ou reçu

un PDO :

COB-ID utilisé par le PDO

mode de transmission/réception utilisé

durée minimale entre 2 messages (inhibit time) pour les PDOs en émission

le PDO Mapping Parameter indique quelles sont les données transportées :

liste des objets du dictionnaire d’objet (OD) mappés dans le PDO

taille de chaque objet en bits

Description des PDOs



IndexSub-Index

Nom FormatValeur par

défautDescription

0 Nombred’éléments Octet 3 Nombre d’éléments suivant

1 COB-IDDouble

mot

Fonction dunuméro dePDO et du

node ID

11 bits de poids faibble = COB-IDBit 31 = indique si PDO actif ou nonBit 30 = Indique si accès par Remote frameest supporté ou pas.

2 Transmissiontype Octet

Dépend duproduit

Décrit comment est transmis le PDO :synchrone ou asynchrone, sur changementd’état, cycliquement, sur polling…

0x1800à

0x19FF

3 Inhibit time Mot 0 Temps minimum entre 2 transmission dumême PDO (occupation bande passante)

Objets TxPDO Communication parameter

PDO en émission : Index 0x1800 à 0x19FFExemple : TxPDO1 = 0x1800, TxPDO2 = 0x1801, TxPDO3 = 0x1802, TxPDO4 = 0x1803



IndexSub-Index


défautDescription

0 Nombred’éléments Octet

Dépend duproduit

Nombre d’objets mappés

11er objetmappé

Doublemot

Dépend duproduit

Byte 3 et 2 (octets poids fort) = IndexByte 1 = Sub-IndexByte 0 = Longueur en bitsExemple : 0x64010110

2 2ème objetmappé

Doublemot

Dépend duproduit


… … … … …

0x1A00à

0x1BFF

8 8ème objetmappé

Doublemot

0 Idem ci-dessus

Objets TxPDO Mapping parameter

PDO en émission : Index 0x1A00 à 0x1BFF



IndexSub-Index


défautDescription

0 Nombred’éléments Octet 2 Nombre d’éléments suivant

1 COB-IDDouble

mot

Fonction dunuméro dePDO et du

node ID

11 bits de poids faibble = COB-IDBit 31 = indique si PDO actif ou nonBit 30 = Indique si accès par Remote frameest supporté ou pas.

0x1400à

0x15FF

2 Transmissiontype Octet

Dépend duproduit

Décrit comment est traité le PDO reçu.

Objets RxPDO Communication parameter

PDO en réception : Index 0x1400 à 0x15FF



IndexSub-Index


défautDescription

0 Nombred’éléments Octet

Dépend duproduit

Nombre d’objets mappés

11er objetmappé

Doublemot

Dépend duproduit


2 2ème objetmappé

Doublemot

Dépend duproduit


… … … … …

0x1600à

0x17FF

8 8ème objetmappé

Doublemot

0 Idem ci-dessus

Objets RxPDO Mapping parameter

PDO en réception : Index 0x1600 à 0x17FF



Synchrone : sur réception d’un message SYNC Acyclique :

émission pré-déclenchée par l’occurrence d’un événement sur le nœud (événement spécifié dans le profil du nœud)

émission pré-déclenchée sur réception d’une trame "Remote Request" (polling) émise depuis un autre nœud

Cyclique émission déclenchée périodiquement, après réception de 1,

2, ... jusqu’à 240 messages SYNC

Asynchrone

transmission déclenchée par l’occurrence d ’un événement sur l’équipement (événement spécifié dans le profil du nœud )

transmission déclenchée sur réception d’une trame "Remote Request" émise depuis un autre nœud

Modes d’émission des PDOs



Evénementsur Nœud X

SYNC SYNC SYNC SYNC

TxPDO

SYNC SYNC SYNC SYNC

TxPDO

Remoterequest vers

Nœud X

SYNC

SYNC

TxPDO

Remoterequest vers

Nœud X

Sur événement - Transmission Type = 0

Sur réception d ’une Remote Request (polling) - Transmission Type = 252

Emission synchrone acyclique des PDOs



SYNC

TxPDO

SYNC SYNC SYNC SYNC SYNC SYNC SYNC SYNC

TxPDO TxPDO

Exemple si n = 3 Exemple si n = 3

Cyclique sur n signaux de synchro - Transmission Type = 1 à 240 (nombre de messages SYNC)

Emission synchrone cyclique des PDOs



Evénementsur Nœud X

TxPDO

TxPDO TxPDO

SYNC SYNC SYNC SYNC SYNC

SYNC SYNC SYNC SYNC SYNCRemoterequest vers

Nœud X

Remoterequest vers

Nœud X

Sur événement - Transmission Type : 254 = événement spécifique; 255 = événement défini dans profil

Sur réception d’une Remote Request (polling) - Transmission type = 253

Emission asynchrone des PDOs



Pour garantir que des objets ayant un niveau faible de priorité puisse être transmis,

il est possible d’affecter un temps minimum entre 2 émissions d’un même PDO.

Cette valeur est renseignée dans le paramètre «Inhibit time» des objets TxPDO,

communication parameters index 0x1800 à 0x180F.

Emission des PDOs : Inhibit time



SYNC SYNC SYNC SYNC

Rx_PDO

SYNC

Prise en compte du PDO reçu

Tx_PDO

Sur événement - Transmission Type = 0

Réception synchrone acyclique des PDOs



SYNC

RxPDO

SYNC SYNC SYNC SYNC SYNC SYNC SYNC SYNC

T_PDO T_PDORxPDO

Exemple si n = 3 Exemple si n = 3



Cyclique sur n signaux de synchro - Transmission Type = 1 à 240

Réception synchrone cyclique des PDOs



SYNC SYNC SYNC SYNC SYNCRxPDO


T_PDO

Sur événement - Transmission type=254

Réception asynchrone des PDOs



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 (gestionnaire du bus) d’accéder en écriture ou en lecture au dictionnaire d’objets d’un équipement serveur (stations 1 à 127), 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-IDs : un pour la requête, l ’autre pour la réponse

Service Data Objects = SDO



SYNC = Synchronization Object :

Objets utilisés pour synchroniser l’acquisition de données d’entrées, ou la mise à jour de de données en sorties (commande d ’axes par exemple).

Le Gestionnaire du bus émet le message SYNC selon la période de communication (cycle period) définie lors de la configuration

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.




EMCY Object :

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




2 mécanismes permettent de surveiller l’état des stations présentes sur le bus

Node guarding

Fonctionne suivant un concept maître esclave (polling)

permet au manager du bus de demander (Remote request) l ’état de

chaque station, selon une période définie en configuration

Heartbeat

Fonctionne suivant un concept producteur consommateur.

L’état de la station est produit cycliquement sur le réseau, à une période

définie en configuration

Ce mécanisme, nouvellement spécifié, remplace le node guarding sur les

nouveaux produits (meilleurs utilisation de la bande passante)




Node guard Object :

Le maitre NMT surveille l’état des esclaves connectés sur le bus en émettant périodiquement (Guard time) une trame ‘ remote frame ’ demandant son Node guard object à chaque esclave

Dès réception, l’esclave répond au maître Les esclaves peuvent éventuellement surveiller le maître NMT : il s ’agit alors du

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




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"




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 ».



Documents

Présentation. Division - Name - Date - Language 2 Chapitre 1 :Connaissances de base Chapitre 2 : Couche physique Chapitre 3 : Couche liaison Chapitre