2. Configuration

Notes : il est beaucoup plus simple pour la compréhension d'utiliser la vue fonctionnelle quand le nombre des sections est important. Par contre il faut faire très attention à l’emplacement (l’ordre de scrutation) d’une section dans la vue « structurelle » dans le cas d’une modification, et à l’attachement à un « module fonctionnel » en cas d’insertion d’une nouvelle section.
Le programme utilise un automate Schneider M580 BMEP583040. Pour des raisons de compatibilité, il utilise un rack TSX57 et des équipements communiquant : cartes STB, passerelles ASi, maîtres IO-Link.
Le standard du client pour le site impose l’utilisation d’une API avec des cartes de communication sans cartes métiers, des cartes STB pour les pompes, des vannes ASi (avec des passerelles) et de capteurs en IO-Link.
Cette raison ajoute du poids en faveur de l’utilisation des images d’entrées / sorties sans pilotage en direct. Autres avantages / motifs :

1. Standard IMAP ;
2. Possibilité de basculement très rapide entre les technologies (cartes STB vers IO-Link, cartes API vers vannes ASi, etc.) sans toucher ou influencer la structure du programme ;
3. Synchronisation des valeurs pendant un tour de cycle. La valeur d’une image ne change pas pendant un tour de cycle, même si l’entrée associée a changé de valeur.Attention aux projets où il y a des entrées rapides ! Tâche FAST ; ce n’est pas le cas pour ce projet ;
4. Dissociation complète entre les index des forçages, animations et la position des cartes. C'est presque impossible dans des configurations non-déterministes comme les réseaux ASi ;
5. Facilité pour les simulations / tests plateforme ; avec l’activation d’un bit de simulation, toute la section est bypassée permettant un débogage rapide.

Figure 1 : Simulation active IFM AC1357

Plus d’actualité : Le nouveau format est une section de simulation appart (indépendante par type de technologie).

Figure 2 : Simulation active IFM AC2251

Ex. de section de simulation pour modules ASi.

2.1 Spécificité du projet

Chaque type de technologie a sa propre section (entrée cartes API, entrées cartes, ASi, sortie cartes STB, etc.). Cela permet une gestion plus simple (vu le nombre d’éléments), un basculement vers une autre technologie plus rapide, des simulations par type des composants.

Figure 3 : Section par type de technologie

L’insertion ou la modification des éléments communicants (passerelles, maîtres IO-Link) est faite avec le gestionnaire DTM : consulter la documentation disponible.

Figure 4 : Navigateur de DTM

Pour la facilité d’utilisation, les trames sont appelées avec un alias et pas avec leur nom complet :
Ex : E01_TrameA_I c’est la première trame d’entrées de l’équipement E01 (E01_IFM_AC1357).

Figure 5 : trame 1 d’entrées d'E01

Vu le nombre d’éléments présents, les nombres des châssis (2), armoires (2), coffrets (>20), la gestion des interventions (interventions IMAP +/- interventions clients), la fréquence de mises à jour de plans, tous les éléments sont déclarés avec un commentaire qui indique :

1. Le type de l’élément : carte, description, nomination ;
2. Adresse : position carte, adresse IP ;
3. Emplacement physique : châssis, coffret, zone.

Toutes les réserves sont déclarées.
Le format de cartes est standard :
Exemple : API_DI0101_05 – carte entrées TOR API châssis, rack 0, première carte, entrée 5, ou E04_AI1001_0 – carte entrées ANA STB, coffret 1, rack 0, deuxième carte.
Pour les éléments ASi, il faut préciser aussi l’équipement maître (passerelle, réseaux, adresse module). Il faut mapper toutes les adresses : il n’y a pas de gestion comme pour les cartes ASi → il faut préciser les réserves et chaque modification doit être faite dans la section d’entrées comme dans la section des sorties).
Pour les cartes ANA, il faut préciser la résolution (ex. 0…10000 points, ou 0…32000 points, ou 4000…20000 points) afin d’éviter les erreurs d’étalonnage.

Toutes les E/S ont un commentaire dans la description de la variable.
Les entrées analogiques ont aussi la plage maximale du capteur : ex. 0…200 °C.

Figure 6 : Entrées DI0101 cartes API

Section entrées cartes API.

Figure 7 : Entrées DI1001 cartes STB

Section entrées cartes STB.

Figure 8 : Entrées IFM AC1357 modules ASi

Section entrées modules ASi.

Figure 9 : Déclarer IMG_EA_P2CP5

Déclaration d’une variable avec son commentaire dans la section et dans le bandeau.

Figure 10 : déclarer réserve ASi

Déclaration des réserves dans les sections ASi.

Figure 11 : full map E/S ASi

Mapping « complet » section entrées ASi et sorties ASi.
Note : pour la facilité d’utilisation des passerelles ASi, il y a une section INFOS_ASi où se trouve le mapping complet des passerelles de l'ancien standard client AC1357/AC1358 dont la fabrication a été arrêtée et du nouveau standard AC1421/AC1422.

Note : Dans le module fonctionnel GENERAL, il y a une section INFO_EQUIPEMENTS où se trouve tous les éléments d’installation (tanks, lignes, équipements) avec leurs codes uniques sur 3 digits (code unique pour le site – utilisé pour les identifier dans les séquences, pour les lavages, pour la traçabilité). Chaque rajout / modification doit être inscrite dans cette section, plus il faut vérifier corriger dans le reste des programmes : NEP, Pasto, LINA.

Figure 12 : Section informations

Note : Il y a aussi une section INIT_PARAM où il y a écrit en dur les configurations des objets, des valeurs des paramètres non-modifiables par les opérateurs (ex. Temps basculement vannes pour éviter les coups de bélier). Il y a un bouton BP_INIT_ETALONNAGE pour initialiser les étalonnages des mesure (uniquement accessible par un automaticien – attention à son utilisation).
Toutes les modifications des mesures analogiques (rajout/changement) doivent être insérées dans cette section.

Tous les codes ou paramètres qui sont utilisés comme des constantes commencent par le tiret de soulignement "_" :
Exemple de constante :
_EQT_1S_VAR := 1010 ; (* Equipement analogique - 1 sortie en consigne fixe *)
ou
_CODE_ZONE_STD := 700 ; (* Zone : Standardisation *)

⚠ Attention : La modification d'une constante peut avoir des conséquences très graves.

Ici sont déclarés, aussi, tous les codes d’équipements et zones. L’utilisation des mnémoniques avec la valeur écrite en dur dans l’API permet trois avantages par rapport à l’utilisation d’une simple valeur numérique :

1. En cas de changement de code tel qu'un plan d’adressage, il faut un seul changement ;
2. La lecture du code est simplifiée en lisant :IF Seq_Lav.Code_Lav = _CODE_EQT_L_ST_CF THEN plutôt que : IF Seq_Lav.Code_Lav = 781 THEN ;
3. L’utilisation de mnémonique donne accès à l’outil de recherche ; sinon il faut balayer tout le programme pour trouver l’utilisation du code ;
4. Avec cette technique, on évite les erreurs de copier/coller : 2 codes différents pour le même équipement.

Figure 13 : Vue INIT_PARAM

Note : « BORNAGES » est une autre section nécessaire pour la configuration. Ici sont « bornés tous les paramètres critiques.

Le bornage dans la supervision est autorisé uniquement pour les variables internes PCVue.

Les autres sections du module fonctionnel « GENERAL » sont traitées ou seront traitées dans les tutoriels IMAP.
Les sections « GESTION_TIME_MAST » et « GESTION_TIME_FAST » gèrent la mise à l’heure et les fronts horaires (objets).
La section « GESTION_ZONE » gère la sécurité générale et zonale et la gestion des réarmements (objets).