L'environnement EcoStruxure Control Expert organise chaque projet autour de deux types de fichiers principaux. Le fichier de travail courant, avec l'extension .stu, contient l'intégralité de la configuration, du code et des données du projet. C'est le fichier que vous modifiez directement.

Pour la portabilité et l'archivage, le système utilise un fichier compressé avec l'extension .sta. Ce fichier est une archive complète qui encapsule non seulement le fichier .stu, mais aussi les bibliothèques de types de données (DDT), les bibliothèques de blocs fonctionnels (DFB), et la documentation associée. La restauration d'un projet à partir d'un fichier .sta garantit la reconstitution de l'environnement de développement complet, une nécessité absolue pour la maintenance à long terme et la migration entre postes de travail.

Ignorer la différence entre ces formats est une erreur fréquente lors des interventions. Tenter de dépanner un automate avec un fichier .stu potentiellement désynchronisé de ses bibliothèques externes peut mener à des erreurs de compilation ou à des comportements imprévisibles en production.

Le Navigateur de Projet est le centre névralgique de l'application. Il présente une vue arborescente de tous les composants, organisée de manière logique. La branche principale est la configuration matérielle. Elle représente la structure physique de votre automate, en commençant par le rack (châssis), l'alimentation, puis le CPU. Chaque carte d'E/S ou module de communication ajouté au rack apparaît ici.

Sous le CPU, on trouve la configuration des bus de communication. C'est ici que l'on déclare et paramètre les réseaux de terrain comme Ethernet/IP ou Modbus TCP. Pour chaque réseau, on définit les équipements esclaves (variateurs, E/S déportées, etc.) et on configure l'échange de données. Une configuration précise du bus est essentielle, car elle conditionne directement le mapping des variables d'E/S distribuées.

Chaque équipement déclaré sur le bus de terrain, comme un variateur ou un îlot d'E/S, est associé à un fichier de description appelé IODDT . Ce fichier, fourni par le constructeur, définit la structure de données de l'équipement. Control Expert l'utilise pour générer automatiquement des variables structurées, simplifiant grandement l'accès aux données de l'équipement (commandes, états, diagnostics) sans avoir à manipuler des registres individuels.

Le dictionnaire de données est le référentiel unique pour toutes les variables et instances de blocs fonctionnels (FB) du projet. Il est crucial de le maintenir propre et bien organisé. On y distingue trois grandes familles de variables :

1. Variables d'E/S locales (topologiques) : Adressées directement par %I (entrée) ou %Q (sortie) suivi de leur emplacement physique (rack, slot, voie). Exemple : %I1.2.3 pour l'entrée sur le rack 1, slot 2, voie 3.

2. Variables d'E/S distribuées : Liées aux équipements sur les bus de terrain. Leur mapping est géré dans la configuration du bus. Leur nom est défini par l'utilisateur et lié aux données de l'IODDT.

3. Variables internes (non localisées) : Variables de calcul, mémoires, temporisations, etc. Elles n'ont pas d'adresse physique (%M ou %MW) et sont gérées par le compilateur. L'utilisation de variables non localisées est une bonne pratique, car elle rend le programme plus portable et laisse l'optimiseur allouer la mémoire efficacement.

La distinction entre ces types est fondamentale pour un diagnostic rapide. Une panne sur une variable topologique oriente la recherche vers un problème de câblage ou de carte HS. Un défaut sur une variable distribuée suggère un problème réseau ou une défaillance de l'équipement distant. Une valeur anormale sur une variable interne pointe vers une erreur de logique dans le programme.

Une bonne maîtrise de ces concepts vous permet de naviguer avec aisance dans des projets complexes et d'identifier rapidement la source des problèmes.