Skip to main content

Génération du code d'application

Le code d'application est le code machine qu'un automate exécute lorsque vous démarrez une application.

CODESYS génère automatiquement le code de l'application à partir du code source qui a été écrit dans le système de développement. Cela se fait automatiquement avant de télécharger l'application sur le contrôleur. Avant que le code de l'application ne soit généré, un test est effectué pour vérifier les allocations, les types de données et la disponibilité des bibliothèques. De plus, les adresses mémoire sont allouées lors de la génération du code d'application.

Vous pouvez cliquer Construire → Générer du code pour exécuter explicitement cette commande. Ceci est utile pour détecter toute erreur dans votre code source, même lorsque l'automate n'est pas encore connecté. Les erreurs sont éditées dans la vue des messages dans la catégorie "Build".

Important

Si vous avez crypté l'application, tenez compte des informations suivantes : Si une (nouvelle) application de démarrage est générée sur demande après une modification en ligne, l'application de démarrage est formée dans la RAM avec le code actuel qui n'est pas crypté.

Génération explicite du code de l'application

Condition : L'application peut être compilée sans erreur.

  • Cliquez sur Construire→ Générer du code.

    Le code de l'application est généré. Des informations détaillées sur l'allocation de mémoire sont affichées dans la vue des messages.

Pour plus d'informations, consultez : Création d'une application de démarrage

Messages lors de la génération du code de l'application

Lorsque vous générez le code de l'application, CODESYS affiche des informations sur l'allocation de mémoire dans la vue des messages. Des vides se forment dans la mémoire car la réallocation ne concerne que les POU et les variables nouvelles et modifiées en raison de la construction de mémoire incrémentielle. Les modifications en ligne ont le même effet. Cette fragmentation réduit la quantité de mémoire disponible. Cependant, vous pouvez entièrement réaffecter la mémoire en cliquant sur Nettoyer et donc augmenter la quantité de mémoire libre.

Les erreurs de syntaxe et les bogues qui CODESYS détecte pendant la génération de code et l'allocation de mémoire sont également affichés dans la vue des messages (Construire Catégorie).

Informations de sortie sur l'allocation de mémoire :

  • Taille du code généré (en octets) : Somme de tous les segments de code

  • Taille des données globales (en octets) : Mémoire totale utilisée par les variables globales. Les entrées et les sorties ne sont pas incluses sauf si les entrées ou les sorties sont mappées dans la zone des variables globales.

  • Taille totale de la mémoire allouée pour le code et les données (en octets) : la mémoire allouée totale est composée des zones de mémoire déjà utilisées plus la mémoire réservée, non encore utilisée pour les constructions incrémentielles et les modifications en ligne. Après la première construction, la mémoire déjà utilisée est approximativement égale à l'adresse utilisée la plus élevée (voir ci-dessous). La plus grande lacune de mémoire contiguë (voir ci-dessous) correspond toujours approximativement à la différence avec la mémoire allouée totale. Cependant, à mesure que le nombre de builds incrémentiels et de modifications en ligne augmente, le nombre de trous de mémoire augmente également et le plus grand trou de mémoire contigu devient plus petit.

  • Zone mémoire <n>: Contenu des différentes zones de mémoire réservées :

    Contexte : Cela dépend de l'automate, quelles données et quel code sont stockés dans quelles zones de mémoire. Par exemple, le code et les données sont situés dans la même zone sur le CODESYS Control Win. Pour les adresses %I, %M, et %Q, la mémoire est toujours réservée, même lorsqu'une variable n'est pas affectée à une adresse. Après "nettoyage" de l'application, la mémoire est entièrement réallouée. Dans ce cas, de petits écarts peuvent résulter de "l'alignement" prédéfini (normalement 8). Des écarts plus importants résultent de la modification d'une date sans "nettoyage", par exemple en augmentant une zone de tableau. Dans ce cas, seuls les POU concernés sont recompilés. De plus, dans le cas d'un changement en ligne, la mémoire n'est utilisée que pour les nouvelles variables et le nouveau code. La mémoire précédemment réservée par les variables et le code supprimés est à nouveau disponible. Par conséquent, la fragmentation de la mémoire peut se produire après de nombreuses versions incrémentielles et modifications en ligne. Cela crée de nombreux petits espaces qui pourraient ne pas être utilisables du tout dans certains cas. Pour clarifier la quantité de mémoire disponible en toute sécurité, le "plus grand trou de mémoire contigu" de la zone de mémoire est généré lors de la génération de code.

    • Adresse la plus utilisée (Byte) : Il s'agit de l'adresse réservée la plus élevée de toute la zone mémoire allouée. Lors de la première construction après une opération de "nettoyage", les adresses mémoire sont sorties vers des variables dans l'ordre croissant, en tenant compte de l'alignement (généralement 8 octets). Par conséquent, l'adresse la plus élevée utilisée à ce moment correspond approximativement à la quantité de mémoire utilisée. Le reste de la zone de mémoire allouée est toujours entièrement disponible pour les builds incrémentiels et les modifications en ligne.

    • Plus grande lacune de mémoire contiguë (en octets) : il s'agit de la taille de la mémoire disponible pour la sauvegarde.

      Les lacunes résultantes dans la mémoire allouée sont réutilisées chaque fois que possible pour d'autres modifications. Lorsque, par exemple, une variable globale de type Byte est ajouté, il est placé dans le premier octet libre de la mémoire. Même un petit écart suffit pour cela. Cependant, une instance FB, une variable de type structure ou array, ou le code d'un POU doit être stocké de manière contiguë et occupe donc plus de mémoire en conséquence. Par conséquent, ils ne peuvent être alloués qu'à la plus grande zone de mémoire contiguë. C'est pourquoi, lors de la génération de code, le "plus grand espace mémoire contigu" disponible en toute sécurité est sorti (en octets), ainsi que son pourcentage de la mémoire totale.

Pour cela, voir aussi : Options de génération d'applications

Cryptage du code de l'application

Pour plus d'informations, consultez : Chiffrer l'application

Dans cette section​: