Commande : Générer

Symbole:

Cette commande (catégorie "Composer") démarre un processus de build qui génère automatiquement le CODESYS application à partir de l'arborescence des modules et les paramètres du Configuration du générateur.

Les messages et les erreurs seront affichés dans la vue des messages.

Tous les objets créés par le générateur standard (sauf les objets tâches et les applications) seront stockés dans le sous-dossier de l'application resp. Pool de POU nommé AC_Std et AC_FBs. Si un dossier du même nom existe déjà, un nom unique sera créé en ajoutant un suffixe _0.

Figure 39. Blocs fonction générés

Tous les objets créés par le Générer Les commandes sont marquées d’une icône de superposition bleue. Si l'utilisateur tente de supprimer, déplacer ou modifier l'un de ces objets, une boîte de dialogue s'ouvrira indiquant que cette action peut provoquer des problèmes de compilation. Si l'utilisateur continue, la couleur de l'icône de superposition passe au rouge (voir bloc fonction AC_PRG_RMP (PRG) dans la capture d'écran ci-dessus).

Astuce

Si vous utilisez Application Composer avec CODESYS SVN:

Tous les objets générés par Composer sont marqués d'un Ignore on Commit pour SVN. De plus, SVN passe en mode hors ligne pour éviter les verrous SVN pendant l'exécution de la commande Built.

Création d'instances de blocs fonction par le générateur standard

Pour chaque instance de module, un bloc fonction sera créé (dans le dossier AC_FBs). Ce bloc fonction dérive du bloc fonction module.

Le bloc fonction contient des variables d'entrée

Instances de sous-module
Tableaux de taille configurable
Variables tampon des connexions E/S directes
Tableaux de multislots et références d'instance

Le nom de la variable de tableau respective est créé par le préfixe AC_ARRAY_ suivi du nom de la variable de pointeur respective. Pour les tableaux avec une taille d'index variable (VarArrays), le nom peut être écrasé par le paramètre VarArray.InstName.

La partie implémentation du bloc fonction contient la commande SUPER^(); qui appelle la partie implémentation du bloc fonction module.

Exemple 11. Exemple

L'instance du module ModuleInstanceA est du type ModuleA et bloc fonctionnel associé ModuleA_FB. Cette instance a une instance de sous-module de type ModuleB.

FUNCTION_BLOCK AC_ModuleInstanceA EXTENDS ModuleA_FB

VAR_INPUT
        Inst_Sub1 : AC_ModuleInstanceB ;
END_VAR

Le nom du bloc fonction est créé à partir du chemin de l'instance du module et du préfixe AC_.

Le nom de la variable de l'instance de sous-module est créé à partir d'un préfixe suivi du nom de l'instance de sous-module respective.

Chaque bloc fonctionnel est instancié une fois, l'instance FB du module de niveau supérieur directement dans le GVL - le reste dans les blocs fonctionnels correspondants des instances pères.

Pour chaque instance de module référencée qui se trouve dans une autre application, exactement une instance de bloc fonctionnel du FB proxy sera créée dans un GVL d'une instance de module référente. Le nom de l'instance proxy est AC_PROXY_<InstanceName> où <InstanceName> est le nom de l'instance cible dans l'autre application.

Des adresses uniques sont attribuées à toutes les instances de module. Les instances FB proxy sont attribuées par les adresses des instances de module dans l'application distante.

La méthode IBaseInstance.Main des instances proxy est appelée cycliquement dans la tâche de communication.

Création de l'application et des appels de tâches

Si un module est affecté à une application qui n'existe pas, cette application sera créée.
Création d'une tâche standard inexistante
- TASK_MODULE_HIGH
- TASK_MODULE_MEDIUM
- TASK_MODULE_LOW
La priorité et le temps de cycle des tâches sont définis en fonction des paramètres du générateur. De plus, des tâches spécifiques au module avec les paramètres donnés seront créées.
Création d'une liste de variables globales par niveau supérieur. Dans ce GVL, les instances de module situées sous les instances de module de niveau supérieur de la même application seront créées. La liste des variables globales a le nom défini dans le module, ou si elle n'a pas de nom défini, elle obtiendra le nom GVL_MODULE. Le GVL est situé sous l'application sélectionnée ou dans l'arborescence globale des POU.
Création d'un GVL avec le nom GVL_ MODULE_TREE pour chaque candidature. Cette liste contient des variables pour gérer l'arborescence des modules. Le GVL sera créé dans le dossier AC_Std.
Création du code d'initialisation qui est appelé automatiquement lors du téléchargement et de la modification en ligne :
- L'arborescence sera créée.
- Les valeurs des paramètres seront définies.
- Les références et les instances de sous-modules seront attribuées.
- Les tableaux de taille variable seront remplis.
- Les références d’instance seront définies.
Lors du téléchargement, seuls les paramètres qui ne sont pas définis sur leur valeur par défaut seront définis. Lors du changement en ligne, tous les paramètres seront définis. Les POU seront créés dans le dossier AC_Std.
Pour chaque point d'entrée défini, un PROGRAM Un POU (langage ST) sera créé qui contient les appels des modules de niveau supérieur. L'appel de ce nouveau POU sera ajouté en dessous de la tâche. Dans le cas de la tâche standard, les noms des POU sont :
- MODULE_CALL_<TASKNAME>_START
- MODULE_CALL_<TASKNAME>_END
Les POU seront créés dans le dossier AC_Std.
Pour les modules de niveau supérieur dans le POU pool, les appels de tâches seront créés dans toutes les applications.

Création de l'affectation des E/S

En fonction du type d'affectation des E/S, les actions suivantes seront exécutées :

[Canal E/S] : dans le canal d'appareil correspondant, le nom d'instance des E/S de l'instance de module sera ajouté.
[expression ST] : les affectations des expressions aux entrées ou des sorties aux expressions seront pour toutes les instances de module situées en dessous de la même instance de niveau supérieur. S'il existe des affectations correspondantes, pour chaque instance de niveau supérieur, une fonction nommée
- AC_Io_SetInputs_<instance name> ou
- AC_Io_SetOutputs_<instance name>
sera créé.
La tâche qui définit les entrées et les sorties sera identifiée par le drapeau UPDATE-IOS dans la description du module. Cette tâche sera appelée « tâche d'E/S » dans la description suivante.
La fonction pour les entrées sera appelée dans la tâche d'E/S avant que la méthode de tâche de l'instance de module ne soit appelée. (Si la tâche d'E/S est une tâche standard, avant la méthode de démarrage.) La fonction pour les sorties sera appelée dans la tâche d'E/S après la méthode de tâche de l'instance de module. (Si la tâche d'E/S est une tâche standard, après la méthode end.)
[Connexion directe au module E/S, local] : Une variable tampon de type compatible sera créée dans le bloc fonction de l'instance de l'entrée. Le nom de la variable tampon commence par le préfixe AC_Io_Buffer_.
Les variables tampon seront initialisées aux valeurs actuelles des sorties connectées lors de l'initialisation de l'application. Le générateur gère les affectations d'entrée et de sortie comme une affectation ST à cette variable tampon (voir [Expression ST].
[Connexions directes aux E/S du module, à distance] : Pour chaque sortie connectée à une entrée d'une instance de module d'une autre application, une variable tampon de type compatible sera créée dans le réseau d'émission GVL correspondant. Le nom de la variable tampon commence par un préfixe AC_RemoteIo_Buffer_ et sera construit à partir du chemin de l'instance et du chemin de la variable de la sortie. Les variables tampon seront initialisées avec l'expression d'initialisation de la variable de sortie, si elle existe. Si la valeur de cette expression d'initialisation n'est pas contenue dans les informations de précompilation (car l'expression utilise des exemples : variables, fonctions et constantes), une erreur est créée.
Le générateur gère l'affectation de sortie comme une affectation à cette variable tampon. L'affectation d'entrée dans l'autre application est gérée comme une affectation de la variable correspondante dans le récepteur NVL (voir [expression ST]).
Remarque : La synchronisation entre la tâche dans laquelle la variable réseau doit être mise à jour et la tâche d'E/S du module n'est pas encore réalisée. Par conséquent, il est possible que les valeurs aient été écrites de manière incomplète pendant que la tâche d'E/S les lit.

Création de l'infrastructure de communication

Définition : Dans la description suivante, l'application A1 envoie à l'application A2 (ou A2 reçoit de A1) si les conditions suivantes sont remplies :

Une instance de module affectée à l'application A1 fait référence à une instance de module affectée à l'application A2 ou vice versa.
Une sortie d'une instance de module qui est affectée à A1 est connectée à une instance de module qui est affectée à A2 au moyen d'une connexion E/S de module directe.

Tous les objets mentionnés ci-dessous seront créés dans le dossier AC_RMP pour chaque application créée par le générateur.

Une tâche de communication sera créée. (Temps de cycle et priorité selon les réglages de la configuration du générateur). Dans cette tâche, les instances proxy seront appelées et les variables FB proxy du module miroir seront lues resp. écrit.
Pour chaque application qui envoie vers l'application actuelle, un GVL (d'envoi) sera créé et les paramètres réseau seront définis. (Protocole "UDP", transmission cyclique, somme de contrôle, temps de cycle selon paramétrage, tâche de communication). L'"identifiant de liste" qui doit être une valeur entière comprise entre 1 et 2^15-1 sera déterminé aléatoirement au début de la génération et augmenté de 1 après chaque envoi de GVL. Cette valeur est d'au moins 128 et se situe dans la plage valide. S'il existe des références de module entre les applications une variable de type RMPExchangeData sera créé dans le GVL. Le nom de la variable contient le nom de l'application source et de l'application cible. Si une instance de module définit des variables dans sa définition de proxy à mettre en miroir (MirrorVar) et est référencé à partir d'une autre instance de module, pour chacun de ces MirrorVars, une variable sera créée dans le GVL (d'envoi) de l'instance de module référencée. Son nom contient le chemin d'instance de l'instance du module et le TargetID de la définition "MirrorVar" correspondante.
Pour chaque application A2, à laquelle l'application actuelle envoie, un NVL (réception) sera créé et connecté au GVL d'envoi correspondant de A2 et à la tâche de communication.
Un bloc fonction de type RMPService sera instancié dans le GVL AC_RMP et initialisé dans la déclaration (avec l'attribut init_on_onlchange). Deux tableaux de type RMPConnection seront créés qui font référence aux variables créées de type RMPExchangeData dans les GVL et NVL.
Un programme AC_PRG_RMP sera créé qui appelle le bloc fonction de type RMPService. Ce programme sera ajouté à la tâche de communication. De plus, la valeur des variables en miroir ("MirrorVars") sera définie et lue dans le AC_PRG_RMP programme. Cela signifie que le proxy "MirrorVars" sera affecté aux variables correspondantes du (recevoir) GVL. Puis le Main La méthode de l'instance proxy est appelée et enfin les variables correspondantes du GVL (expéditeur) du module "MirrorVars". Cela se produit en fonction du sens d'envoi des instances de module aux proxys.

Dans cette section: