Bonjour Jean,
Il me semble que l’intention pour le moins louable de Märklin a été de doter la CS de fonctions programmables sans aller jusqu’à ouvrir complètement le système. D’une part sans doute pour dispenser les utilisateurs de compétences avancées en programmation. D’autre part peut-être pour ne pas dévoiler de secrets d’alcôves. En tout cas le socle est puissant, c’est du Linux, et on pourrait faire beaucoup plus de choses. Pour moi, le malheur est double : d’une part, la conception des macros est un peu paresseuse. La macro Brake, par exemple, est individualisée pour chaque loco. Est-ce pour ne pas casser le commerce du module de freinage 72442 ? Car sinon, une simple indirection permettrait de passer l’id. loco à la macro Brake en paramètre depuis l’événement appelant. Et ce n’est qu’un exemple.
Le deuxième souci contre lequel je tempête en me levant chaque matin est l’indigence de la documentation. Comment peut-on dire aux clients “attention, nous n’assurerons aucun support” sans leur donner le détail précis du fonctionnement : ce que ça fait, ce que ça ne fait pas, les paramètres et leurs limites, de vrais exemples, les éventuelles erreurs connues… ? De plus, les français sont très mal lotis, car certians traducteurs ont visiblement appris notre langue dans Mickey. Alors qu’il suffirait de faire traduire, ou au moins relire, par de vrais bilingues (ce qui paraît être le cas du “manuel” malheureusement très insuffisant). Et, par exemple, il ne manque pas sur ce forum de bilingues franco-allemands ! Donc, appel aux dieux de Göppingen : un chtit effort de bon sens (et de marketing) pour améliorer tout ça et nous rendre heureux, siouplait.
Pour revenir à ton souci du moment, je n’ai pas étudié la navette. Mais sur le principe, une macro quelle qu’elle soit ne peut être appelée que par un événement. L’événement peut lui être appelé de plusieurs manières : manuellement, par un autre événement ou par un contact de voie ou un article électromagnétique. Un même événement peut être appelé de ces 3 manières différentes. Il ne peut pas être lancé par un contact de commande ; celui-ci peut par contre servir de “condition” (traduit de manière inexacte par “déclencheur”) ; par exemple, l’événement est lancé par le changement d’état du contact de voie “Zone d’arrêt” si le contact de commande “Fonctionnement automatique” est “on”.
Notons que si la condition “déclencheur” se paramètre par liste déroulante ou par drag and drop, le contact de voie ou l’article “qui déclenche” ne peut être mis en place que… par drag and drop ! Rien n’indique dans le menu de paramétrage de l’événement qu’on peut le faire, donc si on ne sait pas…
Les articles et autres éléments inclus dans un événement comportent aussi des paramètres dont le sens peut varier selon l’élément en question. Notamment, “Action” coché signifie exécuter, par exemple passer la Zone d’arrêt à occupée (=“jaune”). Décoché, cela signifie vérifier que la zone d’arrêt est occupée. Le paramètre suivant : “continuer” ou “attendre” dépend du contexte, mais globalement : continuer signifie lire l’état du contact et poursuivre l’exécution ; dans l’exemple, si le contact est “on”, l’événement continue ; si il est “off”, l’événement s’arrête et passe en rouge (échec) mais les autres événements lancés en parallèle se poursuivent. Sur attendre, l’événement se bloque jusqu’à ce que la condition se réalise. Il y a un autre “attendre” avec un temps paramétrables à côté (grmmmlll) : il signifie “attendre n secondes après avoir traité cet élément”.
Piège fréquent : un événement contient différentes actions et dont un événement comprenant lui-même plusieurs actions, toutes étant paramétrées sur “continuer”. L’événement appelant (par exemple faire la voie 2 et démarrer le train) comporte par exemple 3 actions dont l’événement appelé, et l’événement appelé 10 actions (par exemple, faire les 10 aiguilles de l’itinéraire voie 2). Résultat : le train démarrera avant que la voie 2 soit faite, car le système lira la séquence dans l’ordre mais parallèlement l’événement appelant et l’événement appelé, lequel est plus long que le précédent.
L’appel de l’événement appelé doit donc être paramétré sur “attendre” (attendre la fin de cet événement).
Dernier point concernant ton sujet : l’allumage de l’éclairage pour lequel aucun container de la macro Navette n’est prévu. L’inclure dans l’événement appelant.
J’espère que tout ceci pourra t’aider à avancer.
N’hésite pas si d’autres questions (auxquelles j’aurais peut-être la réponse !).
Bonne journée,
Alain
j’ai bien vu que c’était d’une simplicité fantastique.
