Macros avec boucle PREREQ/GOTO ne fonctionnent plus en V10

Bonjour,

Les boucles de PREREQ/GOTO un peu trop longue ne fonctionnent plus en V10. J'ai le message "Une opération goto vers une étiquette a été effectuée trop souvent dans un temps trop court dans les opérations de Macro 'PR Déplacement banalisé'. Il y a peut être une boucle infinie. L'exécution de la liste d'opération est donc annulée."

Exemple de séquence qui pose problème :


En V9, cela fonctionne bien et pour pouvoir casser une boucle infinie (si l’évènement attendu n'arrive pas), j'avais utilisée le test d'un inter que l'on voit dans l'exemple.
J'utilise ces instructions de contrôle de flux dans plusieurs macros qui me permettent de gérer mon pont roulant (voir ICI ) par exemple en attente d'activation d'un indicateurs lié à un ILS ou en attente d'activation d'un  indicateur lié à une positions de rétro d'un RS-16-O ...
Donc mon pont roulant ne fonctionne plus en V10 et je ne vois pas par quoi remplacer ces instructions de contrôle de flux en attente d'un évènement physique ? Si quelqu'un a une idée, je suis preneur ...  

A+
Georges

Bonjour à tous,

Pourquoi avoir deux prérequis ?
un prérequis avec deux conditions lié par un OU n'est il pas suffisant ?

Sur l'algorithme, en général je fais l'inverse, et si la condition n'est pas vérifiée alors je boucle tout de suite.

Label début
tempo de 0,5 sec.
Prérequis avec la/les conditions liées par un ET /OU
retour sur label début
exécution de la suite de la macro

ça évite de se perdre dans les méandres des boucles et prérequis, assurément plus facile à interpréter par TC.
d'où la question : Quelle est la priorité de ton algorithme ? le bouton M/A ou le ILS ?

Bonjour Marco et merci pour ta réponse,

J'avais ajouter le test de l'inter pour pallier à une défaillance d'activation d'un ILS (en cassant la boucle suite au basculement manuel de l'inter). Si on fait abstraction de cela, j'ai bien une séquence PREREQ/GOTO "standard" et le problème reste entier ...  



Par contre, avec l'ajout d'un délai cela marche en simulation !...   Avec 0,5", j'ai peur de rater un arrêt du pont et avec 100ms je ne fais pas un déplacement du pont d'une extrémité à l'autre sans le message d'erreur. J'ai mis 200 ms et ferai un test en réel ce soir ... Je pense que tu m'a mis sur la bonne voie !...  

A+
Georges

J'ai mis 0,5 sec. mais tu peux mettre ce que tu veux,
en fait je pars du postula que TC gère les interruptions programme, donc pendant une tempo de O,5 sec il a le temps d'aller "travailler" ailleurs. en bouclant indéfiniment sans délai, tu occupes le programme à temps plein avec pour conséquence de le saturer et de ne plus avoir le temps d'aller voir ailleurs.
je ne suis pas informaticien , je suis peut être dans l'erreur . mais en faisant ainsi je n'ai jamais eu de problème et ça me semble plus logique dans le sequencement interne de TC.
d'ailleurs il semble que Freiwald a mis une condition avec message d'erreur dans les boucles depuis la V10. ce n'est surement pas pour rien. j'avais vu il me semble que Freiwald se plaignait des boucles occasionnant une lenteur d'exécution de TC.

Y'a plus qu à essayer en gradeur nature  

Geo69 a écrit:

Par contre, avec l'ajout d'un délai cela marche en simulation !...   Avec 0,5", j'ai peur de rater un arrêt du pont et avec 100ms je ne fais pas un déplacement du pont d'une extrémité à l'autre sans le message d'erreur. J'ai mis 200 ms et ferai un test en réel ce soir ...
A+
Georges

Si tu ne trouves pas la bonne valeur de délai au-dessous de 0,5s, tu peux mettre un petit circuit condensateur/résistance derrière ton contact ILS, cela prolongera la durée de l'impulsion...

Bonjour,

DiCoS69 a écrit:

Geo69 a écrit:

Par contre, avec l'ajout d'un délai cela marche en simulation !...   Avec 0,5", j'ai peur de rater un arrêt du pont et avec 100ms je ne fais pas un déplacement du pont d'une extrémité à l'autre sans le message d'erreur. J'ai mis 200 ms et ferai un test en réel ce soir ...
A+
Georges

Si tu ne trouves pas la bonne valeur de délai au-dessous de 0,5s, tu peux mettre un petit circuit condensateur/résistance derrière ton contact ILS, cela prolongera la durée de l'impulsion...

Merci Elie pour ta contribution ... Ce changement dans la V10 ajoute encore une couche de complexité dont je me serais bien passé dans la gestion de mon pont roulant !...

Mcar a écrit:

... Y'a plus qu à essayer en gradeur nature  

Bon bin avec le réseau, ce n'est pas terrible !... Faut dire que la macro incriminée est un peu plus complexe qu'une simple attente d’évènement et était déjà, en partie, basée sur des délais. Juste pour le fun :


En clair (repris de mon fil décrivant cette unsie à gaz) :
"1 – Le pont, en face de chacune des 7 voies d'accès de la plaque du pont, alimente la file de rail du bas de ces dernières.
2 – Après le début du déplacement du pont, pour rétro-signaler les voies d'accès alimentées, utilisation d'un détecteur RS-16-O « Voies » .
3 – Pour que le RS-16-O « Voies » n'active que l'indicateur de la voie d'arrivée (et pas les voies intermédiaires), celui-ci n'est connecté qu'au dernier moment (via adresse 72 du SA-DEC-4).
4- Pour cela, utilisation d'un deuxième RS-16 « ILS » qui est raccordé aux ILS installés entre chaque voie d'accès et pour chacun des sens de circulation.
5 – A l'activation de l'indicateur « PR ILS » de la voie d'arrivée, connexion du RS-16 « Voies » après un délai de 2 s.
6 - A l 'activation de l'indicateur « PR Voie » de la voie d'arrivée, déconnexion du RS-16 « Voies » et Stop du déplacement du pont. "

Il faut donc que je me replonge dans l'historique de toutes les contraintes rencontrés ...

Un point sur le fonctionnement de la V10 : TC semble cumuler le nombre de GOTO lors d'appels successifs à la même macro car 3 déplacements successifs d'un pas se passent bien et lors du quatrième j'ai le message d'erreur ... Enfin, cela ne me semble pas être une science exacte. En tous cas, pour l'instant la balle est dans mon camp pour déjà comprendre ce que j'ai fait !... Si seulement il y avait un pont roulant numérique en N ...  

A+
Georges

Georges, il me semble que l'interprétateur de TC ne reconnait dans le nom d'une étiquette (LABEL) que 6 caractères (voir 8 à vérifier avec le manuel) or dans ta macro un LABEL  "attente PR voie" et "attente PR ILS" pour TC il ne comprend que attent
donc pour lui les deux branchements sont les mêmes.
commence déjà à renommer tes étiquettes avec 6 ( 8 ) caractères.
je ne suis pas persuadé que ta macro fonctionnait bien en V9

Au delà de ces recommandations,  honnêtement c'est bien compliqué.
pourquoi ne pas utiliser l'onglet operation sur tes switch M/A ? ça simplifierait ta macro

rectificatif apres verif sur le manual,

un label est defini avec 4 caracteres



traduction
Une étiquette est identifiée par un nom comportant jusqu'à 4 caractères. Les majuscules et les minuscules n'ont pas d'importance.

j'ai pris l'habitude de nommer mon étiquette toujours avec en debut une lettre et un chiffre puis une designation

Bonsoir Marco,

Mcar a écrit:

Georges, il me semble que l'interprétateur de TC ne reconnait dans le nom d'une étiquette (LABEL) que 6 caractères (voir 8 à vérifier avec le manuel) or dans ta macro un LABEL  "attente PR voie" et "attente PR ILS" pour TC il ne comprend que attent
donc pour lui les deux branchements sont les mêmes.
commence déjà à renommer tes étiquettes avec 6 ( 8 ) caractères.
je ne suis pas persuadé que ta macro fonctionnait bien en V9

Mcar a écrit:

rectificatif apres verif sur le manual,

un label est defini avec 4 caracteres

OK pour ce qui est indiqué dans le guide utilisateur. Par contre, j'ai toujours utilisé des étiquettes explicites avec parfois plus de 20 caractères sans problème. Je viens de refaire un test en V10 avec des étiquettes de 3 à 22 caractères, pas de problème. Peut être qu'un jour, comme déjà vu par ailleurs, cela ne marchera plus et que Freiwald dira que le bug c'était quand cela marchait !...

Pour revenir au problème de boucle infinie, j'ai simplifié ma macro de déplacement en supprimant les "cassages" de boucles puisque maintenant TC s'en charge et adapté les tempos : cela fonctionne bien pour les déplacements en manuel :

Pour le fonctionnement en automatique avec trajets, j'ai encore quelques séquences d'opérations à adapter ...

Mcar a écrit:

...  honnêtement c'est bien compliqué...

Je confirme !... mais cela s'explique par les contraintes que j'ai rencontré au fur et à mesure de la mise en oeuvre et qui sont explicitées dans ce FIL ...

Mcar a écrit:

...  pourquoi ne pas utiliser l'onglet operation sur tes switch M/A ? ça simplifierait ta macro

Je suis preneur d'une solution plus simple mais avec les contraintes rencontrées, je ne vois pas bien ...
Quand je serai au point  avec les tempos dans les boucles en automatique, je mettrai à jour le fil cité ci-dessus ...

A+
Georges

Une piste ?
peut être repenser tout le projet en utilisant le service "ascenseur" que la V10 offre.
Service mis en œuvre pour mon ascenseur et mon réseau , ça marche très très bien.
comme toujours avec TC compliqué à comprendre la méthodologie au début mais une fois assimilée c'est du bonheur.

un pont transbordeur n'est ni plus ni moins qu'un ascenseur à l'horizontal. d'ailleurs la doc donne quelques explications sur ce sujet

Bonjour,

Que Freiwald ait implémenté un contrôle sur les boucles infinies sans délai est une très bonne chose. Comme dit plus haut par Marco, il faut laisser du temps à TrainController pour les opérations "accessoires" que sont le contrôle de la vitesse des trains, le suivi de l'occupation des cantons et la préparation des itinéraires.

Par contre cette histoire de longueur des étiquettes me surprend et m'inquiète. J'utilise sans problème apparent de très longues étiquettes (20, 30 ou 40 caractères), car ces étiquettes me servent aussi à documenter les macros.

va voir la doc V10.fr en page 332 le point GOTO et LABEL
c'est écrit noir sur blanc
j'avais lu (je ne sais plus où peut être bien sur la doc V9 ) que seules les 4 premières lettres sont interprétées, le reste étant que de l'information.

Bonjour,

Mcar a écrit:

j'avais lu (je ne sais plus où peut être bien sur la doc V9 ) que seules les 4 premières lettres sont interprétées, le reste étant que de l'information.

Donc si on a un Label "XXXXYY" et un autre "XXXXZZ" on a comme un problème bien qu'ils apparaissent différents...
ça serait intéressant de tester et de voir si TrainController ou le Docteur rouspète... malheureusement je n'ai pas le temps de le faire...

Bonsoir,

Yann a écrit:

Bonjour,

Mcar a écrit:

j'avais lu (je ne sais plus où peut être bien sur la doc V9 ) que seules les 4 premières lettres sont interprétées, le reste étant que de l'information.

Donc si on a un Label "XXXXYY" et un autre "XXXXZZ" on a comme un problème bien qu'ils apparaissent différents...
ça serait intéressant de tester et de voir si TrainController ou le Docteur rouspète... malheureusement je n'ai pas le temps de le faire...

Comme je l'ai écrit hier, j'ai aussi de longues étiquettes qui ne posent pas de problème aujourd’hui (jusqu'à ce que cette absence de problème devienne un bug !... ). Voici le test dont j'ai parlé et qui infirme que seuls les 4 premiers caractères sont pris en compte :
Séquence :


Résultat :


A+
Georges

Bonsoir,

Mcar a écrit:

Une piste ?
peut être repenser tout le projet en utilisant le service "ascenseur" que la V10 offre.
Service mis en œuvre pour mon ascenseur et mon réseau , ça marche très très bien...

Je ne suis pas convaincu que le service ascenseur facilite la gestion de mon pont roulant compte tenu des contraintes rencontrées avec ce pont ...
Ceci étant, après adaptations de mes macros à la V10 (ajout de délais dans les boucles d'attentes et augmentation de la durée  des indicateurs à l'état "actif" dans leurs onglets "mémoire") , je viens de faire des essais concluants de ma séquence automatique qui met en œuvre 3 locos avec 12 déplacements du pont et 12 entrées/sorties des locos. J'ai répété la séquence 4 fois de suite et je n'ai pas rencontré d'autres problèmes que 3 arrêts de locos à l'entrée du pont. Ces problèmes sont dus à la qualité "jouet" du pont Minitrix et n'ont rien à voir avec le pilotage du pont par TC ...
Je mettrai à jour le fil qui décrit la gestion de ce pont roulant ...

A+
Georges

Geo69 a écrit:

Voici le test dont j'ai parlé et qui infirme que seuls les 4 premiers caractères sont pris en compte :
Georges

Merci pour cette confirmation.

Il ne reste plus qu'à espérer que Freiwald n'adapte pas TC à la doc, comme il prétend l'avoir fait pour les variables privées.

Bonsoir à tous,

pour revenir sur le nombre de lettres interprété par TC sur une étiquette de 4 max, mais qui fonctionne avec plus de 4 lettres, voilà ce que j'ai lu complètement par hasard sur le descriptif des différences entre V8 et V9, voir descriptif des modifications V9 à la page 12 repère 79


en revanche voici ce que l'on lit sur la doc V9


ce qui explique que ça fonctionne , la doc V9 n'a pas été mise à jour malgré un descriptif des modifs V8-V9 explicite, la V10egalement

Quand on fouille bien dans les divers manuels qui suivent la progression du logiciel, on rencontre de-ci, de-là quelques incohérences qui sont simplement le fait d'une incomplète mise à jour du texte au fil des versions...
Même si ça peut agacer, ce n'est pas grave dès lors que l'on peut soit-même vérifier quelle est la version qui dit vrai...

Bonjour,

DiCoS69 a écrit:

Même si ça peut agacer, ce n'est pas grave dès lors que l'on peut soit-même vérifier quelle est la version qui dit vrai...

La version qui dit vrai correspond à la version du logiciel que l'on utilise!