QUESTION:
Pourquoi n'est-il pas judicieux d'instancier
des blocs BRCV ou URCV quand on a plusieurs liaisons de
communications?
REPONSE:
Les services de communication BSEND/BRCV et
USEND/URCV sont des fonctions de communication bilatérales qui
entrent en liaison ensemble 1:1. C'est la raison pour laquelle un
BSEND est toujours assigner à un BRCV via une liaison S7. Les
fonctions S7 de communication (SFB) pour les contrôleurs S7 400
sont conçus de tel sorte que les paramètres ID et R_ID ne peuvent
pas être modifiés dynamiquement par programme, mais seulement par
le biais d'un seul DB d'instance.
Le principe de fonctionnement des fonctions de communication
pour un automate S7 300 est différent: une instance (d'un DB) est
établie pour une tache de communication, ensuite elle peut être
utilisé pour d'autres partenaires, ex: Liaisons S7. Ceci est
particulièrement pratique avec les fonction S7 PUT/GET car il est
par exemple possible d'adresser plusieurs partenaire à partir d'une
seule instance.
C'est un peu plus compliqué avec les fonction S7 BSEND/BRCV et
USEND/URCV. Il est ici possible de dynamiser l'utilisation des bloc
d'émission BSEND/USEND par des DB d'instances. Cependant, il n'en
est pas de même pour les blocs de réceptions, car il est impossible
de prévoir exactement quelle communication S7 vous voulez
envoyer.
Ceci s'applique aussi aux fonctions de communications
simultanées via une seule liaison S7 réalisé par le paramètre R_ID
(référence de commande). Il n'y a aucun sens à utiliser une
instance simple dans cette variante de communication S7.
Mots Clés:
Communication chargeable, URCV, BRCV,
SFB8, FB8, SFB9, FB9, SFB12, FB12, SFB13, FB13, SFB14, FB14, SFB15,
FB15
| 
allemand
