Bus de terrain – Partie générale
Terminologie
Le télégramme de sortie est le télégramme spécifique au protocole (PDO de sécurité) envoyé par le contrôleur de sécurité à l'appareil de terrain sûr. Ce télégramme contient les données de sortie vers l'appareil de terrain sûr. | |
Le télégramme d'entrée est le télégramme spécifique au protocole (PDO de sécurité) envoyé par l'appareil de terrain sûr au contrôleur de sécurité. Ce télégramme contient les données d'entrée de l'appareil de terrain sûr. | |
Instance de pilote : pour chaque E/S logique configurée, le code est créé pour une instance de pilote du type de protocole pris en charge (par exemple, une instance de pilote de type |
Description de l'interface
Le contrôleur de sécurité surveille la transmission des données d'E/S vers et depuis l'appareil de terrain sécurisé. Une E/S logique est générée par le système de développement pour chaque appareil de terrain sécurisé. Une instance de pilote est créée automatiquement pour chaque appareil logique.
Avec la création de l'instance du pilote, un code implicite est généré, ce qui donne les résultats suivants pour les variables d'entrée ou de sortie :
Phase 1 (phase d'entrée) : Traitement des télégrammes d'entrée (implicite)
L'instance du pilote reçoit le télégramme d'entrée et le vérifie conformément à sa spécification de protocole, par exemple PROFIsafe.
Les données d'entrée ou, en cas d'erreur, les valeurs de remplacement sont copiées dans les variables d'entrée mappées de l'application.
Phase 2 : Traitement de la demande de l'utilisateur
Les données de sortie sont générées en fonction des données d'entrée et de l'état de l'application.
Phase 3 (phase de sortie) : Traitement des télégrammes de sortie (implicite)
Les données de sortie mappées de l'application sont transmises à l'instance du pilote. L'instance du pilote génère le télégramme de sortie conformément à sa spécification de protocole et l'envoie à l'appareil de terrain sécurisé.
Comportement par défaut du pilote
Avis Drv_1 (début de l'application)
Lors du démarrage de l'application, il peut arriver dès le premier cycle que des données de processus soient échangées entre le terrain et l'application. L'utilisation de FB avec un verrouillage de démarrage (S_StartReset = FALSE) ou la mise en œuvre d'autres mesures système et applicatives (voir Manuel d'utilisation de sécurité. « Règles d'utilisation des blocs fonctionnels conformes à PLCopen ») garantit qu'aucun démarrage inattendu (ou involontaire) de la machine ne se produise au démarrage de l'application.
Avis Drv_2 (erreur de communication au démarrage)
Par défaut, les erreurs de communication habituelles au démarrage n'empêchent pas le démarrage automatique de la communication des données de processus. Au lieu de cela, elle est seulement retardée. Voir Entrée pour la reconnaissance automatique des erreurs de démarrage (erreur de démarrage automatique).
Le comportement par défaut du pilote pour le démarrage après une réinitialisation ou pour le redémarrage après une erreur de communication est défini par la valeur initiale de l'entrée correspondante. Pour écraser le comportement par défaut, le bloc de fonction de l'application doit être appelé et l'entrée correspondante doit être définie en conséquence :
Le démarrage automatique de la transmission des données de processus après le démarrage est empêché par le programme en appelant le bloc fonctionnel dans l'application et en définissant l'entrée erreur de démarrage automatique à FALSE (voir. Entrée pour la reconnaissance automatique des erreurs de démarrage).
La reprise automatique de la transmission des données de processus est activée par le programme en appelant le bloc fonction dans l'application et en définissant l'entrée interruption d'accusé de réception automatique entrée à TRUE (voir. Entrée pour acquittement automatique après interruption).
Entrée pour la reconnaissance automatique des erreurs de démarrage
Nom | Type de données | Valeur initiale | Description, valeurs des paramètres |
|---|---|---|---|
<erreur de démarrage automatique> |
|
| Comportement au démarrage après une réinitialisation (commandes : Réinitialisation à froid – Sécurité et Redémarrage) de l'application, par exemple PowerON.
|
Important
Veuillez noter Avis Drv_2 (erreur de communication au démarrage):La valeur initiale de l'entrée pour le comportement de démarrage après une réinitialisation est TRUEToutes les erreurs de comportement au démarrage sont reconnues après une réinitialisation.
La communication des données de processus commence alors dès que l’erreur de communication initiale a disparu.
Important
Veuillez noter Avis Drv_1 (début de l'application): Paramètre erreur de démarrage automatique à FALSE n'empêche pas le démarrage automatique de la communication des données du processus. Si aucune erreur ne se produit lors du démarrage, la pile peut démarrer automatiquement, même si erreur de démarrage automatique est réglé sur FALSEL'utilisateur doit en tenir compte dans la candidature.
Entrée pour acquittement automatique après interruption
Nom | Type de données | Valeur initiale | Description, valeurs des paramètres |
|---|---|---|---|
<interruption d'accusé de réception automatique> |
|
|
|
Avis Drv_3 (entrée pour acquittement automatique après interruption)
Attention
Si <erreur de démarrage automatique> et <interruption d'accusé de réception automatique> sont TRUE, alors toutes les erreurs sont reconnues. Cela n'est judicieux que dans certains cas exceptionnels.
Comportement de redémarrage suite à une erreur de communication
La valeur initiale de l'entrée pour le comportement de redémarrage après une erreur de communication est FALSE; l'erreur relative à la transmission de la communication n'est pas automatiquement reconnue.
Un appel explicite de l'instance du bloc fonctionnel avec connexion correspondante des entrées est nécessaire.
Entrée pour front d'acquittement (acquittement manuel)
Les erreurs peuvent être reconnues avec un front positif sur l'entrée pour la reconnaissance, à condition que le (sortie pour la demande d'accusé de réception) est défini.
Si toutes les erreurs sont reconnues automatiquement (ce qui n'est judicieux que dans des cas exceptionnels), cette entrée n'est pas nécessaire et peut rester non connectée.
Si aucun accusé de réception n'est actuellement demandé, l'entrée est ignorée : le même signal peut donc être connecté à l'entrée pour le bord d'accusé de réception de toutes les instances de pilote afin de réaliser un accusé de réception non spécifique des problèmes de communication.
Nom | Type de données | Valeur initiale | Description, valeurs des paramètres |
|---|---|---|---|
<ack-edge> |
|
| La reprise de la fonction de sécurité est acquittée après une erreur par un front montant sur l'entrée. |
Avis Drv_4 (ack-edge)
Attention
Le <ack-edge> L'entrée est utilisée pour l'acquittement par l'utilisateur. Elle ne doit pas être définie par le programme, mais connectée à un signal d'entrée.
Astuce
Le <ack-edge> l'entrée nécessite un front montant. Une fois que l'utilisateur a arrêté l'accusé de réception, il doit passer FALSE à nouveau pour conclure l'accusé de réception. Ce n'est qu'alors que l'accusé de réception suivant est demandé à l'entrée <requête d'accusé de réception> à la prochaine erreur de communication.
Sortie pour demande d'accusé de réception
La sortie est TRUE si une erreur de communication s'est produite (erreur de démarrage ou interruption) et qu'il suffit de l'acquitter manuellement pour reprendre la communication.
Si la sortie <requête d'accusé de réception> est TRUE, la connexion nécessite alors un acquittement de la part de l'utilisateur. Normalement, l'utilisateur est informé que son acquittement est requis (par exemple à l'aide d'une variable d'échange vers le contrôleur standard et d'un affichage dans la visualisation)
Si la sortie est définie, l'erreur peut être acquittée à l'entrée pour acquittement.
Nom | Type de données | Valeur initiale | Description, valeurs des paramètres |
|---|---|---|---|
<requête d'accusé de réception> |
|
|
Astuce
L'affichage à la sortie demande d'accusé de réception ne peut avoir lieu que si :
L'erreur de communication n'est pas reconnue automatiquement, c'est-à-dire si <erreur de démarrage automatique> ou <interruption d'accusé de réception automatique> est
FALSE.Le <ack-edge> l'entrée est actuellement
FALSE, c'est-à-dire si un accusé de réception manuel a été lancé mais pas encore terminé.
Par conséquent, si un nouveau problème de communication survient alors que l'utilisateur est encore en train de reconnaître un problème survenu précédemment, le nouveau problème de communication n'est affiché et traité qu'une fois que l'utilisateur a terminé de reconnaître le problème précédent.
Appel explicite du bloc fonction
Si le bloc de fonction est appelé explicitement par l'utilisateur dans l'application (phase 2), les entrées du bloc de fonction peuvent être définies et les sorties du bloc de fonction peuvent être lues, bien que le bloc de fonction lui-même n'exécute aucune opération. Pour chaque instance de pilote, il ne peut y avoir qu'un seul appel dans l'application.
Les sorties du bloc fonctionnel de l'instance du pilote peuvent être lues indépendamment d'un appel.