Les échanges explicites sont des échanges effectués à la demande du programme utilisateur à l'aide des fonctions ci-dessous :
-
READ_STS (lecture des mots d'état)
-
WRITE_CMD (écriture des mots de commande)
-
READ_PARAM (lecture des paramètres de réglage)
-
WRITE_PARAM (écriture des paramètres de réglage)
-
SAVE_PARAM (enregistrement des paramètres de réglage)
-
RESTORE_PARAM (restitution des paramètres de réglage)
-
READ_TOPO_ADDR (lecture d'adresse topologique)
-
TRF_RECIPE (transfert de recette)
Ces échanges s'appliquent à un ensemble d'objets (état, commandes ou paramètres) d'une même voie. Ces paramètres sont des variables du type .
Pour un Quantum de type , utilisez :
Pour une variable de type Modicon M580, utilisez :
-
READ_STS_MX (lecture du rack local (e)X80 par M580 ou des mots d'état du module d'RIO Ethernet)
-
WRITE_CMD_MX (envoi d'une commande au rack local (e)X80 par M580 ou au module RIO Ethernet)
-
READ_PARAM_MX (lecture des paramètres d'un module du rack local)
-
WRITE_PARAM_MX (écriture des paramètres dans un module du rack local)
-
SAVE_PARAM_MX (enregistrement des paramètres d'un module du rack local)
-
RESTORE_PARAM_MX (restauration des paramètres d'un module du rack local)
NOTE : ces objets ne sont pas essentiels pour la programmation d'une fonction métier, mais fournissent des informations supplémentaires (p. ex. : défaut du terminal, absence du module, etc.) et des commandes supplémentaires pour la programmation avancée de fonctions métier (pour plus d'informations sur des objets d'échange explicite de la fonction métier, un chapitre dédié aux objets langage est présent dans chaque manuel métier).
NOTE : les fonctions suivantes réalisent également des échanges explicites, dont le fonctionnement varie selon l'application concernée (paramètres et gestion des différents échanges).
Elles sont détaillées dans les différents manuels métier et une brève vue d'ensemble est disponible dans chaque bibliothèque :
Principe général d'utilisation des instructions explicites
L'illustration ci-dessous affiche les différents types d'échanges explicites qui peuvent avoir lieu entre le processeur automate et le module (ou l'interface intégrée) :
Lors d'un échange explicite, il peut s'avérer intéressant de vérifier son exécution pour s'assurer, par exemple, que seule la lecture de données est prise en compte une fois l'échange terminé.
Pour ce faire, deux types d'informations sont disponibles :
NOTE : vous ne pouvez pas envoyer deux échanges explicites simultanément vers les voies gérées par le même nœud logique LN0 voies 0 et 1 ; LN1 voies 2 et 3 ; LN2 voies 4 et 5 ; LN3 voies 6 et 7. Le nœud logique peut traiter une seule requête ; l'autre requête générera une erreur.
Le synoptique ci-dessous décrit le principe de gestion des échanges :
IODDT ou voie logique %CHr.m.c
Un IODDT associé à une voie %CHr.m.c ou la représentation d'une voie %CHr.m.c constitue une syntaxe générale de mise à jour de tous les objets d'un même type associés à cette voie ou un groupe de voies, à l'aide d'instructions explicites.
Exemple : READ_STS(IODDT_Var)or READ_STS(%CH1.2.3)(lecture des mots d'état de la voie 3 du module 2 du rack 1).
NOTE : Pour un groupe de voies, une voie du groupe peut être utilisée, mais l'échange s'appliquera à toutes les voies (de bit et analogiques) du groupe. READ_STS(%CH3.2.8) aura le même effet que READ_STS(%CH3.2.9).
Le nombre de fonctions d'échange explicite qui peuvent être activées simultanément sur le bus Fipio est limité à 24.
Une demande d'échange adressée au bus Fipio peut prendre plusieurs cycles de tâche maître, nécessitant ainsi la gestion de mots de paramètres de gestion des échanges pour tous les échanges explicites de variable.
