Skip to main content

Règles d'observation

Dans CODESYS, vous êtes généralement autorisé à utiliser le même identifiant pour différents éléments. Par exemple, une POU et une variable peuvent porter le même nom. Cependant, vous devriez éviter cette pratique afin d'éviter toute confusion.

Exemple 306. Exemple

Exemple négatif : dans l'extrait de code suivant, une instance de bloc fonction local porte le même nom qu'une fonction :

Dans un cas comme celui-ci, il n'est pas clair si l'instance ou la fonction est appelée dans le programme.

FUNCTION YYY : INT
;
END_FUNCTION

FUNCTION_BLOCK XXX
;
END_FUNCTION_BLOCK

PROGRAM PLC_PRG
VAR
    YYY : XXX;
END_VAR
YYY();
END_PROGRAM


Comportement du compilateur lors de l'observation

Le compilateur ne signale aucune erreur ou avertissement si le même identifiant est utilisé pour différents éléments. Au lieu de cela, le compilateur recherche dans le code dans un ordre spécifique la déclaration de l'identificateur. Si une déclaration est trouvée, le compilateur ne recherche aucune autre déclaration ailleurs. Si d'autres déclarations existent, alors elles sont "masquées" pour le compilateur. La section suivante décrit les règles d'occultation (c'est-à-dire l'ordre de recherche utilisé par le compilateur lors de la recherche de la déclaration des identificateurs). La section "Accès ambigu et accès qualifié" fournit des moyens d'empêcher l'accès ambigu et de contourner les règles d'observation.

Comment empêcher l'ombrage

Pour vous assurer que les noms sont toujours uniques, vous devez suivre les conventions de dénomination, telles que certains préfixes pour les variables.

Pour plus d'informations, consultez : Identifiant Désignation

Les conventions de nommage peuvent être vérifiées automatiquement à l'aide de l'analyse de code statique de CODESYS. L'analyse de code statique pourrait également détecter l'utilisation en double du nom YYY et signalez-le comme une erreur.

Également, grâce à l'utilisation cohérente de l'attribut qualified_only pour les énumérations et les listes de variables globales et en utilisant des bibliothèques qualifiées, des situations non uniques peuvent être évitées.

Pour s'assurer qu'un POU du même nom dans le Dispositifs la vue n'est pas appelée lorsqu'un POU dans le POU vue est appelée, l'opérateur __POOL doit être ajouté au début lorsque le nom de la POU est appelé.

Exemple: svar_pou := __POOL.POU();

Ordre de recherche dans l'application

Lorsque le compilateur rencontre un identifiant unique dans le code d'une application, il recherche la déclaration correspondante dans l'ordre suivant :

  1. Variables locales

    1. Variables locales d'une méthode

    2. Variables locales dans le bloc fonctionnel, le programme ou la fonction, et dans tous les blocs fonctionnels de base

    3. Méthodes locales du POU

  2. Variables globales dans l'application, si le qualified_only l'attribut n'est pas défini dans la liste des variables où les variables globales sont déclarées

    1. Variables globales dans l'application, si le qualified_only l'attribut n'est pas défini dans la liste des variables où les variables globales sont déclarées

    2. Variables globales dans une application mère, si le qualified_only l'attribut n'est pas défini dans la liste des variables où les variables globales sont déclarées

    3. Variables globales dans les bibliothèques référencées lorsque ni la bibliothèque ni la liste de variables ne nécessitent un accès qualifié

  3. POU ou noms de type

    1. POU ou noms de type de l'application (c'est-à-dire, noms de listes de variables globales, blocs de fonction, etc.)

    2. POU ou noms de type d'une application parente

    3. POU ou noms de type d'une bibliothèque

  4. Bibliothèques

    1. Espaces de noms de bibliothèques référencées localement et de bibliothèques publiées par des bibliothèques

  5. Variables globales dans le POU vue, à moins que le qualified_only l'attribut est défini dans la liste des variables où elles sont déclarées

    1. Variables globales dans le POU vue, à moins que le qualified_only l'attribut est défini dans la liste des variables où elles sont déclarées

    2. POU ou noms de type du POU vu (c'est-à-dire les noms des listes de variables globales, des blocs fonctionnels, etc.)

    3. Bibliothèques de POU

Astuce

Les bibliothèques qui sont insérées dans le Gestionnaire de bibliothèques du POU sont reflétées dans le gestionnaire de bibliothèque dans toutes les applications du projet avec la résolution d'espace réservé appropriée. Ces bibliothèques forment alors un espace de noms commun avec les bibliothèques de l'application. Par conséquent, il n'y a pas d'observation des bibliothèques du pool par les bibliothèques de l'application.

Ordre de recherche dans la bibliothèque

Lorsque le compilateur rencontre un identifiant unique dans le code d'une bibliothèque, il recherche la déclaration correspondante dans l'ordre suivant :

  1. Variables locales

    1. Variables locales d'une méthode

    2. Variables locales dans le bloc fonctionnel, le programme ou la fonction, et dans tous les blocs fonctionnels de base

    3. Méthodes locales du POU

  2. Variables globales

    1. Variables globales dans la bibliothèque locale, si le qualified_only l'attribut n'est pas défini dans la liste des variables où les variables globales sont déclarées

    2. Variables globales dans les bibliothèques référencées lorsque ni la bibliothèque ni la liste de variables ne nécessitent un accès qualifié

  3. Bibliothèques

    1. POU ou noms de type de la bibliothèque locale (c'est-à-dire, noms de listes de variables globales, blocs de fonction, etc.)

    2. POU ou noms de type d'une bibliothèque référencée

    3. Espaces de noms de bibliothèques référencées localement et de bibliothèques publiées par des bibliothèques référencées localement

Accès ambigu et accès qualifié

Malgré ces ordres de recherche, un accès ambigu peut encore se produire. C'est par exemple le cas lorsqu'une variable portant le même nom existe dans deux listes de variables globales qui ne nécessitent pas d'accès qualifié. Un tel cas est signalé par le compilateur comme une erreur (par exemple : Usage ambigu du nom XXX).

Ce type d'usage ambigu peut être rendu unique grâce à un accès qualifié, par exemple en accédant par le nom de la liste des variables globales (exemple : GVL.XXX).

L'accès qualifié peut également toujours être utilisé pour éviter les règles d'observation.

  • Le nom de la liste de variables globales peut être utilisé pour accéder de manière unique à une variable de la liste.

  • Le nom d'une bibliothèque peut être utilisé pour accéder de manière unique aux éléments de la bibliothèque.

  • le THIS pointeur soit utilisé pour accéder de manière unique aux variables d'un bloc fonction, même si une variable locale portant le même nom existe dans une méthode du bloc fonction.

Pour connaître à tout moment l'emplacement de déclaration d'un identifiant, utilisez la Édition → Parcourir → Aller à la définition commander. Cela peut être particulièrement utile si le compilateur produit un message d'erreur apparemment obscur.

Recherche dans les chemins d'instance

Les ordres de recherche décrits ci-dessus ne s'appliquent pas aux identificateurs qui existent en tant que composants dans un chemin d'instance ou aux identificateurs qui sont utilisés comme entrées dans les appels.

Pour un accès du type suivant yy.component, cela dépend de l'entité décrite par yy où la déclaration de component est recherché.

Si yy désigne une variable avec un type de données structuré (c'est-à-dire le type STRUCT ou UNION), ensuite component est recherché dans l'ordre suivant :

  • Variables locales du bloc fonction

  • Variables locales du bloc fonction de base

  • Méthodes du bloc fonction

  • Méthodes du bloc fonction de base

Si yy désigne une liste de variables globales ou un programme, alors component est recherché dans cette liste uniquement.

Si yy désigne un espace de noms d'une bibliothèque, alors component est recherché dans cette bibliothèque exactement comme décrit dans la section ci-dessus "Ordre de recherche dans la bibliothèque".

Ce n'est que dans la deuxième instance que le compilateur décide si l'accès à l'élément trouvé est accordé (c'est-à-dire si la variable est uniquement accessible localement ou si une méthode est privée). Si l'accès n'est pas autorisé, une erreur est émise.