Certaines évolutions logicielles, modifications, corrections peuvent parfois conduire au fait qu'un paramétrage réagisse différemment, et nécessite d'être corrigé ou modifié...
Liste peut-être à enrichir, merci de signaler vos retours d'expériences ! un petit courriel à m.ledouarain@fareco.fayat.com ...
Valeurs variables %VTCx.DAy 9999 ou 99999
La valeur "infinie" (pas de VTC en cours) sur les premières versions de logiciels était fixée à 9999. Hors cette valeur a évoluée (en v1.2.006 du 20/5/2009) et vaut désormais 99999 (ça permet d'avoir "****" en transmission Diaser par ressource numérique 16 bits). Hors certains paramétrages effectuaient des tests sur la valeur particulière "9999" pour connaître la présence ou non d'un VTC. S'ils avaient utilisées la variable correspondante %VTCx.PRESENTy (existante depuis l'origine), le problème ne serait pas arrivé... (ou un test sur le DA < zz secondes)
Défaut PROG15 au démarrage car aucun point de récorrélation paramétré.
Modifier le paramétrage, et préciser le point qui doit servir en recorrélation. Le logiciel nécessite dorénavant qu'un point lui soit précisé (afin de simplifier l'analyse et la gestion des points de corrélation déjà bien assez compliquée comme ça).
V1.2.070, correction temps inhibition après fin dans BlocVTC (temps divisé par 2 par-rapport au temps paramétré)... maintenant valeur correcte. à modifier si paramétré avec une valeur "x 2" !!!
Micro-régulations de lignes ne s'appliquant pas au début d'une deuxième phase en cas de deux phases consécutives. Depuis V1.2.018, modification condition ràz "flag micro ligne fermée" (auparavant, raz simplement effectuée uniquement sur fin demande d'ouverture rencontrée). Maintenant tient compte de l'ouverture à temps fixe demandée (si nouvelle ouverture rencontrée on effectue une ràz). Du coup, attention aux couples d'ouverture à temps fixes DV/FV "collés" que génère l' assistant de l'outil en cas de deux phases consécutives, si l'adaptativité commence juste en début de deuxième phase...(il faut transformer les 2 couples DV/FV en un seul!!!) - OBSOLETE: CORRECTION AUTOMATIQUE DIAGRAMME REALISEE PAR OUTIL DE PROG !
DEFPROG20 (ou DEFLOG301 sur la première version). Depuis les versions 1.2.71, une analyse préliminaire plus approfondie du plan de feux est réalisée (pour renseigner variables %PLAN et d'éventuels calculs de transitoires BTS). Des erreurs sur le plan de feux qui ne gênaient plus sont maintenant bloquantes. Bien vérifier le contenu du plan de feux concerné. Une erreur par-exemple que j'ai déjà rencontré: une même phase définie deux fois (superposée)!
DEFLOG13 : accès invalidité sur variable non booléenne, défaut pouvant avoir de nombreuses causes, mais déjà rencontré à cette occasion: lié à des variables <inconnues> (visible ainsi sur l'outil de programmation) pour les entrées de blocs détecteurs. à-corriger en supprimant les blocs détecteurs mal paramétrés.
DEFLOG1 à-partir v1.3.068 avec modèles lignes "PIETON+RPP" (modification permettant sur une nouvelle demande d'ouverture, de terminer immédiatement la séquence de fermeture DurDegMax, et ce sans passer par la séquence indéterminée). MAIS POUR UN FONCTIONNEMENT CORRECT ET ÉVITER UN DEFLOG1 DANS CE CAS, IL FAUT METTRE A-JOUR CES MODÈLES DE LIGNES DE FEUX !!!!! Les modèles de lignes de feux font partis du fichier xpkz: appuyez sur le bouton "RàZ modèles" dans la fenêtre des lignes de feux (l'outil de programmation doit être à jour avec les nouveaux modèles....)
v1.3.100, modification comportement micro verticale d'escamotage SANS variable paramétrée. dorénavant on l'escamote (ce qui n'était pas le cas avant). normalement ça ne devrait concerner (quasiment) aucune programmation...
Certaines fonctionnalités n'étaient pas forcément activées par-défaut, et il serait généralement souhaitable qu'elles le soient à-présent :
Transitoires BTS pour les plans de feux: à cocher dans les propriétés de chaque plan.
Au-niveau matériel, à une époque la "synchronisation des tâches de régulation sur le secteur électrique" était activé. Il est fortement conseillé dorénavant que ça soit désactivé.
En cas de remise à l'heure faite à la fois par un PC en DIASER et également localement en "secours" par un boitier externe (GPS, France Inter) en secours, veiller à ce que le défaut RHOR soit bien activé (le boitier local ne servira qu'en cas d'apparition de défaut RHOR, et sinon en plus on se retrouve en alternance avec des événements MAHD/MAHR qui pollue le journal de bord !!!).
Lors de la création d'un nouveau paramétrage, il est largement préférable de faire un "nouveau" (sélectionner "annuler" lors du choix d'un modèle) au niveau de l'outil de prog, plutôt que de partir sur un ancien modèle/base de paramétrage (dont le paramétrage par-défaut était plus adapté au logiciel à cette époque...)
Marc, 4 janvier 2022.