Préserver les données avec des variables persistantes

Les variables persistantes ne sont donc réinitialisées que si vous réinitialisez le contrôleur à l'état de livraison, par exemple si vous utilisez la commande En ligne → Réinitialiser l'origine Sélectionner.

Si, en revanche, vous chargez à nouveau l'application, les données persistantes sont conservées si possible. Cela dépend de la profondeur des changements. La modification du nom de l'application entraîne toujours une réinitialisation complète. Les modifications des implémentations n'entraînent jamais de réinitialisation : la persistance des données est totalement préservée. Les modifications des déclarations entraînent une initialisation des nouvelles variables uniquement si les variables existantes sont persistantes, lorsque vous modifiez les déclarations afin que la liste des variables persistantes reste cohérente. C'est le cas lorsque vous ajoutez une nouvelle variable ou en supprimez une existante. Des incohérences peuvent se produire si vous éditez et modifiez les identificateurs ou les types de données de variables persistantes précédemment déclarées.

Si vous modifiez la liste des variables dans l'éditeur de persistance, la liste des variables n'est pas enregistrée comme indiqué dans l'éditeur, mais elle est automatiquement post-éditée avant d'être enregistrée.

En post-traitement, une variable que vous avez supprimée est remplacée par une variable d'espace réservé avec la même empreinte mémoire. Cela signifie que les variables suivantes conservent leurs adresses dans la mémoire image. De plus, toute variable que vous ajoutez est déplacée à la fin de la liste. Le post-traitement peut neutraliser les changements qui entraîneraient une perte de persistance. Mais vous créez des lacunes qui occupent de la mémoire supplémentaire.

Lors du chargement de l'application, la valeur CRC de la liste des variables et la longueur de la liste (nombre de variables) sont stockées sur le contrôleur. Lors du nouveau chargement de l'application, la nouvelle valeur de test est comparée à la valeur de test actuellement sur le contrôleur. Ensuite, la liste des variables est comparée successivement jusqu'à la longueur spécifiée. Si vous avez modifié une déclaration (par exemple, le nom ou le type de données), la variable est réinitialisée. Sinon, sa valeur est conservée. Lorsque l'application est à nouveau chargée, CODESYS vérifie si la liste de variables déclarée dans l'éditeur de persistance est toujours cohérente avec la liste de variables déjà présente sur le contrôleur.

Le mécanisme fonctionne bien lorsque les variables elles-mêmes ne sont pas modifiées de manière significative. Des modifications excessives des identifiants et des types de données continuent d'entraîner une réinitialisation et une perte de persistance. Par conséquent, si vous anticipez des changements fréquents en fonction des besoins de votre application, une telle liste n'est généralement pas recommandée. De plus, en cas de changement en ligne après un changement de type de données, une variable persistante est moins robuste qu'une variable à durée de vie normale.

Fondamentalement, après un certain temps, vous devez nettoyer la liste variable des lacunes et la commande Réorganiser la liste et nettoyer les lacunes Courir. Cependant, après nettoyage, la liste ne correspond plus à la liste sur le contrôleur et vous avez déclenché une initialisation de toutes les variables persistantes. La persistance de toutes les variables est perdue.

Si vous modifiez le nom ou le type de données d'une variable, cela est interprété comme une nouvelle déclaration et provoque une réinitialisation des variables au prochain changement en ligne ou chargement d'une application. Pour les types de données complexes, une modification se produit lorsqu'un nouveau composant est ajouté ou lorsque vous modifiez le type d'une variable de INT pour UINT dans la profondeur d'une structure utilisée utilisée, par exemple.

Fondamentalement, les types de données complexes définis par l'utilisateur ne conviennent pas à la gestion dans une liste de variables persistantes, car même de petites modifications entraînent l'initialisation de la variable avec tous les composants.

Vous pouvez conserver des variables globales ou des variables déclarées localement dans un bloc fonction ou un programme. Pour cela, ajoutez le mot clé à la déclaration PERSISTENT. De plus, ajoutez le chemin de l'instance à cette variable dans la liste des variables globales persistantes. Pour cela, sélectionnez la commande dans l'éditeur de persistance Ajouter tous les chemins d'instance.

L'inconvénient de ce mécanisme est que la mémoire est allouée à la fois au point de déclaration et au point du chemin d'instance. Cette variable persistante occupe double espace de stockage. De plus, les données sont copiées aux deux emplacements à chaque cycle. Cela peut prendre du temps, en particulier lorsqu'il s'agit de valeurs importantes et structurées.

Une instance de bloc fonction est toujours entièrement en mémoire. Ceci est nécessaire pour que le même code puisse fonctionner sur différentes instances. Si maintenant une seule variable dans un bloc fonctionnel avec PERSISTENT est marqué, l'instance du bloc fonction est stockée complètement avec toutes les variables dans la mémoire rémanente, bien qu'une seule variable soit traitée comme persistante. Cependant, la mémoire non volatile n'est pas disponible dans la même mesure que la mémoire principale.

Un bloc fonctionnel qui a un pointeur vers une instance dans la SRAM en tant que variable n'est pas stocké dans la mémoire sécurisée.

Lorsque vous ouvrez un CoDeSys V2.3 projet pour l'importer dans CODESYS V3, les déclarations des variables persistantes ne sont pas conservées. Vous devez réviser les déclarations et les créer à nouveau dans une liste de variables globales persistantes distincte.