Scripts pour passages à niveau

[henrion 101]

Bonjour

 

Je viens de terminer le combiné carré-avertissement-RR30 de Geluc qui fonctionne maintenant correctement. Je me suis donc mis sur les scripts de ses PN.

 

Je viens d'en réaliser un pour deux voies et qui fonctionne parfaitement.

 

La configuration est la suivante:

 

[attachmentid=2315]

 

Ce qui est intéressant c'est que les liens, bien que certains ne soient pas connectés entre eux fonctionnent parfaitement bien. Cela permet d'envisager des utilisations un peu plus compliquées.

 

Les signaux qui encadrent le PN ne sont pas perturbés et fonctionnent parfaitement.

 

J'ai rajouté un compteur de passage, ainsi chaque fois qu'un train passe sur un lien, il incrémente ou décrémente ce compteur. Le PN ne se rouvrira que si le compteur est à 0 ce qui veut dire que toutes les zones contrôlant le PN sont libres.

 

Pour l'instant je n'ai pas utilisé le PN de Geluc. Pour faire les tests de ce script, je me sers d'un sémaphore lumineux en lieu et place qui présente le feu rouge pour indiquer la fermeture des barrières et le feu vert pour indiquer leur ouverture. J'utilise ce stratagème pour la bonne raison que cela permet de visualiser facilement les erreurs de syntaxe car dans ce cas tous les feux du signal sont allumés simultanément. Et j'ai bien fait de faire de la sorte car la logique LUA n'est pas forcément la mienne.

 

L'adaptation au PN en lui-même n'est pas compliquée.

 

Donc, si cela marche bien pour deux voies, il n'y a aucune raison que cela ne fonctionne pas sur trois ou quatre, voire plus.

 

Par contre, les liens extérieurs qui déclenchent la fermeture doivent être installés à au moins 500m voir beaucoup plus ce qui risque de poser des problèmes pour leur positionnement. Je vais donc réfléchir à un déclenchement à distance par le biais d'une boîte de commande.

 

Bonne soirée

 

Bernard

Edited July 6, 2010 by henrion

[Spud 144]

Salut,

 

Oulala Bernard tu es motivé....

 

Ca ne serai pas une mauvais idée le déclenchement à distance cela permettrai l'implantation d'un guidon d'arrêt. je m'explique, par exemple si le train passe ta pédale de commande et franchi le PN dans un temps déterminé le PN reste fermé et s'ouvre après le passage du train. mais par exemple si le train s'arrête en gare ou fait des manoeuvre et veut franchir le PN après la pédale de commande il faut qu'il s'arrête près du GA et attende son extinction pour pouvoir franchir le PN.

 

Ce n'est qu'une suggestion je ne sais pas si cela sera réalisable...

 

Là c'est toi le spécialiste.

 

Bye

[henrion 101]

Bonsoir Olivier

 

Je parlais de commande à distance pour faciliter la pose des liens.

 

Ce que tu proposes est beaucoup plus compliqué car qu'est-ce qu'un temps déterminé? Entre un MA80 et un V160 il va y avoir une différence importante.

 

Le problème du PN situé en sortie de gare est très très compliqué à programmer.

 

Je ne dis pas que c'est irréalisable mais je ne sais pas pour l'instant programmer une notion de temps en langage LUA. C'est donc à voir mais il faut bien définir ce que l'on veut avec précision. Par ailleurs, le fonctionnement du guidon d'arrêt me pose des problèmes puisqu'il est l'équivalent d'un signal d'arrêt à main. Je ne vois donc pas comment on peut le programmer en automatique. Il va falloir voir cela avec Jules31 pour voir si l'on ne peut pas mettre en place des astuces. J'aurai plutôt pensé commander les guidons d'arrêt par un message envoyé à partir de la cabine.

 

De toute façon, je garde ta proposition en mémoire pour l'instant à toute fin utile.

 

A bientôt

 

Bernard

[Jules31 44]

Salut Henrion.

 

Pour le PN, en roulant sur la voie de gauche en sens normal (du bas vers le haut sur ton schéma), que se passe t-il si dans l'ordre les évènements suivant se produisent :

 

- franchissement lien 0 (fermeture du PN je suppose)

- franchissement lien 2 (aucun effet sur le compteur d'essieu je présume)

-franchissement lien 4 (ouverture du PN)

- Franchissement à contre-sens du lien 4

 

Pour être réaliste, il faudrait que ce dernier franchissement provoque également la fermeture du PN. Cela permettrait de simuler une "zone courte" comme beaucoup de PN sont équipés (zone isolée couvrant le PN et quelques mètres en amont et en aval du PN et provoquant la fermeture tant qu'elle est occupée. Je ne suis pas sûr que dans ce que tu proposes tu ais intégré ce mécanisme (le PN de Geluc le permettait).

 

Pour résumer, il faudrait donc que les liens 2 à 5 inclus provoquent l'ouverture du PN en sens normal et la fermeture en sens inverse du sens normal. Les autres liens garderaient leur rôle décrit sur ton schéma.

 

-----------------------------------------------------------------------------------------------------------

 

Pour le guidon d'arrêt, si le PN qu'il protège se ferme de manière automatique par asservissement aux circulations, il ne doit pas être présenté si le PN est ouvert. Il ne peut être fermé qu'en cas d'ouverture pour un mode de fonctionnement manuel. Dans la vrai vie, un PN disposant d'un GA peut soit fonctionner exclusivement en manuel, ou en mode combiné automatique/manuel, le choix du mode étant généralement fait par un verrou commutateur à manette.

 

Dans le mode de la simulation, faire un PN pouvant aussi bien fonctionner en régime automatique et manuel est peu réaliste tant qu'on n'envisage pas de simuler l'aspect contrôle et gestion des circulations (jusqu'à nouvel ordre, il n'est pas possible de jouer le rôle d'un agent-circulation dans le simu ou de changer lors d'un scénario la loi de fonctionnement d'un objet). Par contre, on pourrait envisager de créer des PN automatiques d'un coté (sans GA) et des PN fonctionnant exclusivement en régime manuel (donc protégé par des GA ou des feux de franchissement conditionnel).

 

 

Simulation de la fermeture :

--------------------------------

Pour les PN manuels, il faudrait décider du mode de déclenchement du PN. Le plus simple à mon avis serait une fermeture lors d'une demande de franchissement d'un signal fermé (via la touche tab). Pour pouvoir faire cela, je présume qu'il faut un signal (au sens RW). On imagine bien le GA ou les feux de franchissement conditionnel jouer ce rôle, mais on aurait alors des objets PN et des objets GA dissociés, qu'il faudrait alors coupler pour retransmettre l'ordre de fermeture au PNet provoquer à sa fermeture complète l'ouverture du PN.

 

Simulation de l'ouverture :

-------------------------------

Dans la vrai vie, les PN manuels sont soit ouverts manuellement par l'agent-circulation (cas des PN classiques en mode manuel protégé par GA), soit par temporisation après la dernière attaque d'une pédale positionnée au pied du PN (cas des PN à franchissement conditionnel). Pour simuler tout cela, l'ouverture par agent-circulation est impossible pour les mêmes raisons que celles exposées plus haut pour la fermeture. Il est néanmoins possible de créer des pédales fantômes permettant de compter le nombre d'essieux engagés sur le PN tout en maintenant le principe de la fermeture via la touche TAB. Pour les PN à franchissement conditionnel, on pourrait soit envisager le même mécanisme, ou simuler le système réel de temporisation sur une pédale au pied du PN.

 

Je vous laisse juger.

 

Benoît.

Edited July 6, 2010 by Jules31

[henrion 101]

Bonjour Benoît.

 

Pour rajouter la fermeture des barrières sur les liens internes cela va me demander un boulot fou, au moins 45 secondes.

 

Si l'on veut commander le PN à distance avec un boitier ou même un crocodile on pourra supprimer les liens externes qui n'auront plus d'utilité et la pose sera plus souple sous réserve de ne pas oublier justement d'installer cette commande à distance. J'essayerai le principe avec le crocodile de Nicolas puisque je n'ai pas de boitier à disposition.

 

Dans la réalité il y a un compteur d'essieux mais dans RailWorks ce n'est pas possible. On ne peut agir que sur le début de franchissement ou la fin de franchissement d'un lien. Ce qui permet de savoir si un train occupe ou non la zone mais il y a aussi un problème incontournable dans le cas du PN, c'est que l'on ne peut pas tester cette occupation par les gOccupationTable() parce que certains liens ne sont pas connectés directement aux autres. Dans ces conditions, il ne faut pas qu'un train décroche ses wagons dans la zone contrôlée par le PN. Par contre il peut faire toutes les manoeuvres possibles train complet.

 

Pour illustrer un exemple de la logique surprenante de la programmation LUA:

 

Le compteur de trains est représenté par la variable gParametre. Donc à un moment je vais dire: si le compteur de trains est égal à zéro, on va ouvrir les barrières, ce qui s'écrit ainsi:

 

if gParametre = 0 then

SetState( SIGNAL_VOIELIBRE )

end

 

Il n'y a aucune erreur de syntaxe dans cette écriture mais LUA refuse absolumment de la prendre en compte.

 

Par contre si j'écris: si le compteur de trains est supérieur à 0, il ne se passe rien et dans le cas contraire (compteur = 0) on peut ouvrir les barrières, ce qui s'écrit:

 

if gParametre > 0 then

 

else

SetState( SIGNAL_VOIELIBRE )

end

 

Cette écriture est par contre parfaitement prise en compte alors qu'elle me semble beaucoup moins logique que la précédente. Et des exemples comme celui-ci j'en ai vu un paquet.

 

En ce qui concerne le PN, celui-ci est programmé comme un signal. Donc on peut en créer des automatiques et d'autres qui ne le sont pas. Maintenant il faudra bien que l'on se mette d'accord sur la méthode de déclenchement. Par contre je ne sais pas si la touche Tab pourra être utile. C'est donc à creuser.

 

Bonne journée

 

Bernard

 

 

[Erakis 147]

Bonjour Bernard,

 

En Lua, le signe = est un opérateur d'attribution de variable, ce n'est donc pas valable pour un test censé renvoyer true ou false. L'opérateur de test qu'il te faut est == ; je pense que ça résoudra ton problème.

 

Par ailleurs bravo pour cette commande de PN.

[Jules31 44]

Dans la réalité il y a un compteur d'essieux

 

Partiellement vrai. Tu as souvent ce système sur des voies uniques même si je mettrai ma main au feu que la prise à revers d'une pédale d'ouverture peut aussi provoquer la fermeture du PN (dernier point à vérifier).

 

Pour des VU équipées de circuits de voie et sur la plupart des DV, il n'y a quasiment pas de pédales fonctionnant comme des compteurs d'essieux). On trouve en général à distance de fermeture une pédale dite d'annonce du PN (qui sur un PN automatique provoque la fermeture). La zone du PN automatique est ensuite équipée d'une zone courte couvrant le PN et quelques mètres autour (il s'agit soit d'une zone isolée ou d'un circuit de voie court en superposition des circuits de voie de la signalisation). Cette zone a une double fonction : elle permet la fermeture du PN en cas d'occupation (pratique pour un mouvement à contre-voie car il suffit d'approcher à faible vitesse le PN de quelques mètres pour provoquer sa fermeture automatiquement ; la zone permet également lors qu'elle est dégagée et qu'il y a une annonce en cours sur le PN (donc que le PN est fermée) d'ouvrir le PN automatiquement.

 

Tout cela est valable bien sûr pour une voie et un sens de circulation donné. S'il s'agit de voies banalisées ou équipées d'IPCS, il y a bien sûr une pédale d'annonce par sens, et seule celle correspondant au sens courant (choisi par l'agent-circulation contrôlant la zone) est active. En régime de VU, les équipements d'annonce pour chacun des sens fonctionnent en même temps.

Edited July 7, 2010 by Jules31

[henrion 101]

Bonjour Erakis

 

Effectivement cela marche mieux avec ==. Il y avait là une subtilité que je ne connaissais pas. Merci donc.

 

Cordialement

 

Bernard

[Jules31 44]

Tu retrouveras cette différence entre opérateur d'affection et opérateur d'égalité également en C/C++ et Java.

 

L'opérateur d'inégalité est !=

 

Une feinte avec l'opérateur d'affectation en C/C++, c'est qu'il retourne une valeur qui est celle de l'opérande de droite. C'est surement la même chose en LUA.

 

Tant qu'on y est, voila d'autres spécificités :

- En C, le type booléen n'existe pas. On utilise des entiers (0 pour false et le reste pour true).

- En C++, il existe un type booléen qui n'est autre qu'une surcharge du type entier (on peut donc utiliser également des entiers).

 

 

Donc en C et C++ :

 

if (mavariable = 0)

{

...

}

else

{

...

}

 

compilera et il se passera ceci :

 

- maVariable se verra affecter la valeur 0

- Le test sera négatif car l'expression "maVariable = 0" retourne la valeur 0, équivalent d'un false

- On passera dans le bloc else.

 

Voilou Voilou

[Spud 144]

Salut

 

 

J'essayerai le principe avec le crocodile de Nicolas puisque je n'ai pas de boitier à disposition.

 

 

Si si il y a bien un boitier de commande, c'est une pédale de commande dans les objets de voies de Dominique.

 

Bon courage pour la suite

 

Bye

[Erakis 147]

Bonjour Jules31,

 

L'opérateur d'inégalité est !=

 

Il y a quand même pas mal de différences de syntaxe entre le C/C++ et le Lua, notamment :

 

- l'opérateur de test d'inégalité s'écrit ~= et non !=

- la valeur vide s'écrit nil et non NULL

- l'opérateur de concaténation de chaînes de caractères est .. et non +

- les opérateurs booléens donnent des résultats bien particuliers au Lua en fonction du type des paramètres entrés (par exemple false and nil renvoie false, false or nil renvoie nil, 10 and 20 donne 20 tandis que nil and 20 donne nil, etc.)

- le Lua permet d'affecter plusieurs variable à la fois avec un seul opérateur =, ce qui permet notamment la permutation facile de 2 valeurs avec une syntaxe du type x , y = y , x (en C il faut passer par une variable de stockage temporaire)

- etc.

 

Pour tous les détails : http://www.lua.org/manual/5.1/

[Jules31 44]

Je ne parlais pas du LUA.

Je me suis peut être mal exprimé.

[Erakis 147]

Alors au temps pour moi.

[henrion 101]

Bonjour à tous.

 

Dans le premier post de ce sujet j'ai montré un plan qui permet au PN de fonctionner correctement après y avoir inclus un compteur de trains. Jules31 a souhaité que je rajoute un déclenchement de fermeture supplémentaire sur les liens 2 à 5. Du coup mon compteur ne fonctionne plus du tout correctement. Et là c'est purement mathématique. Je ne vois vraiment pas comment résoudre ce problème, c'est pourquoi je me tourne vers la communauté pour voir si l'un d'entre vous saurait comment procéder.

Voici le schéma d'étude:

 

 

[attachmentid=2317]

 

un train passe le lien 0: compteur = 1. Il passe le lien 2: 1+1 =2. Donc après le passage du lien 4, il faut décrémenter de 2 pour remettre le compteur à 0. Jusque là tout va bien.

 

Mais imaginons que le train s'arrête après le lien 4 et fasse rebroussement. En repassant le lien 4: compteur = 1. Après le passage du lien 2 vers l'arrière: 1 - 2= -1 et non pas 0.

 

On serait tenté de dire que les barrières s'ouvrent si le compteur est <=0. Mais cela n'est pas possible, exemple:

le train passe le lien 0, puis 2 puis 4 et fait rebroussement sur le PN: le compteur =1.

sur l'autre voie, un train fait de même: il passe le lien 1 puis 3 puis 5 et fait rebroussement sur le PN. Sur le PN il va y avoir 1 sur chaque voie soit un total de 2. Un des trains va sortir du PN et après le passage du lien le plus proche, il va décrémenter de 2. Donc le compteur: 2-2=0. Les barrières s'ouvrent alors que le deuxième train est toujours sur le PN.

 

On pourrait aussi penser ne pas faire d'incrémentation au passage des liens 0, 1, 6 et 7 et seulement déclencher la fermeture. On incrémente ou décrémente de 1 sur les liens internes (2 à 5). Mais là aussi ce n'est pas viable:

Un train franchit le lien 0 et ferme les barrières: compteur =0. Il franchit le lien 2: compteur =1. Pendant ce temps un train franchit le lien 7: compteur toujours = à 1. Le premier train passe le lien 4: compteur=1-1=0 les barrières s'ouvrent. Le train en face fermera les barrières au passage du lien 5 c'est à dire en franchissant le PN.

 

Je n'ai donc pas encore trouvé de solution. Si quelqu'un en voit une, je suis preneur. Merci d'avance.

 

Bonne journée.

 

Bernard

Edited July 8, 2010 by henrion

[GerardS 539]

Bonjour à tous.

 

 

Je n'ai donc pas encore trouvé de solution. Si quelqu'un en voit une, je suis preneur. Merci d'avance.

 

Bonne journée.

 

Bernard

Bonjour

 

Ma proposition n'est peut être pas réalisable, mais si tu peux m'éditer un tel script je pense que mon problème d'ouverture intempestive du pn sera résolu.

 

[attachmentid=2318]

 

PS Je n'ai pas encore testé le Rappel 30, car j'ai un problème de connection internet

Je n'arrive plus à obtenir une connection correcte sur mon site . Je suis donc occupé à résoudre ce problème

 

Cordialement

Geluc

[Erakis 147]

Bonjour Bernard,

 

Je ne suis pas certain que ça puisse résoudre ton problème, mais ne serait-il pas plus simple de déclencher l'ouverture du PN par la conjonction de l'absence de train sur chacune des voies, plutôt que d'avoir un compteur global du nombre de trains toutes voies confondues ?

 

Du coup la condition d'ouverture ne serait plus compteur <= 0, mais compteurVoie1 <= 0 and compteurVoie2 <= 0.

 

Qu'en penses-tu ?

[henrion 101]

Bonjour Erakis.

 

C'est une des solutions que j'envisageais de mettre un compteur par voie. Cela marche très bien s'il n'y a pas d'aiguillage dans toute la zone du PN. En cas de présence d'un aiguillage, il faudra mettre un dispositif complémentaire pour décrémenter une voie et incrémenter l'autre.

 

Ne mettre qu'un compteur permettait de s'affranchir de ce système et permettait aussi d'avoir un PN qui pouvait être installé de façon universelle. S'il y a un compteur par voie il faudra décliner le PN en plusieurs catégories: sans aiguillage, avec un, voire deux aiguillages...... Cela va devenir compliqué. Mais s'il faut passer par cela....

 

Ce qui est le plus gênant c'est que, parce que les liens ne sont pas connectés entre eux, on ne peut pas utiliser les tables d'occupation et cela est vraiment dommage.

 

Merci de ton aide

 

Bernard

Edited July 8, 2010 by henrion

[henrion 101]

Bonjour

 

Mon problème n'ayant pas soulevé beaucoup de vocations chez les matheux , j'ai trouvé une solution.

 

J'ai créé deux zones d'occupation très courtes sur chacune des voies (60 mètres en gros). Le compteur général étant la somme de ces deux zones d'occupation.

 

 

[attachmentid=2320]

 

Chaque zone d'occupation ne peut normalement prendre que la valeur 0 ou 1. Si elle est supérieure, il n'y a plus qu'à composer le 18 et faire déclencher le Plan Rouge car cela veut dire que deux trains font route l'un vers l'autre sur la même voie .

 

Le principe de fonctionnement est le suivant:

 

Le train commence à franchir le lien 0 vers le haut, il incrémente gVoie1 de 1. Le compteur général étant >0, Les barrières se baissent.

 

En début de franchissement du lien 2, si gVoie1>0, cela veut dire que le train vient de franchir le lien 0 et il n'y a donc pas incrémentation. Par contre si gVoie1=0 cela veut dire que le train n'a pas franchi le lien 0 et fait rebroussement entre le lien 2 et le lien 0. Dans ce cas, il y a incrémentation.

 

En fin de passage du lien 4, il y a décrémentation de 1. Si le compteur général est égal à 0, donc que les deux zones d'occupation sont libres, les barrières se lèvent.

 

J'ai même pris en compte le cas ou un train passe le lien 0 vers l'avant puis fait rebroussement sans passer le lien 2, dans ce cas en fin de refranchissement du lien 0 vers le bas, gVoie1 sera décrémentée de 1.

 

Ce système est valable pour les 4 directions possibles.

 

Tout à l'air de fonctionner parfaitement avec mon signal lumineux de test. Maintenant que je suis sûr qu'il n'y a pas de faute de syntaxe, il ne me reste plus qu'à l'adapter sur le PN de Geluc.

 

Par contre cela ne résoud pas le cas de la présence d'un aiguillage dans la zone du PN. Je pense que dans ce cas, il va falloir utiliser les connexions entre certains liens mais cela est beaucoup plus complexe à réaliser.

 

Bon dimanche

 

Bernard

 

[henrion 101]

Rebonjour.

 

Le PN 2 voies de Geluc fonctionne parfaitement avec le script décrit ci-dessus. Je vais maintenant me pencher sur son fonctionnement avec des commandes à distance.

 

Bonne soirée

 

Bernard

[Jules31 44]

Salut.

 

L'algo que tu viens de mettre en place est quasiment une copie du fonctionnement des PN réels Il n'y a pas de mystère.

 

Faire un flag (un booléen ou l'équivalent comme tu viens de faire avec un int) pour l'annonce sur chacune des voies et un flag général pour la fermeture du PN, c'est tout simplement parfait.

Edited July 11, 2010 by Jules31

[henrion 101]

Donc, pour la commande à distance, voilà le principe:

 

 

[attachmentid=2321]

 

Les commandes à distance vont communiquer avec le PN par messages. Dans le cas présent, il faut 4 contacteurs spécialisés mais je me demande si en mettant un connecteur 0 à la place du 6 et en le retournant, cela n'irait pas. De même sur l'autre voie, ce qui ne ferait qu'un connecteur spécialisé par voie.

 

Il ne reste plus qu'à rédiger les scripts.

 

Pour les tests, je vais utiliser les rampes AWS car elles se voient bien. Papinic m'a autorisé à modifier et à utiliser son compteur d'essieux, ce qui sera plus discret et plus réaliste pour une utilisation par les créateurs sur leurs voies.

 

Bonne soirée

 

Bernard

Edited July 11, 2010 by henrion

[henrion 101]

Bonjour

 

Après avoir galéré toute la matinée pour mettre au point un système de commande à distance avec les rampes AWS, j'ai fini par craquer car rien ne marchait correctement. Je me suis décidé à passer aux pédales de commande de Papinic. Et là, après avoir changé le fichier bin et adjoint un script, tout fonctionne à merveille. Il reste encore du travail pour la mise au point mais ce devrait aller vite maintenant.

 

Bonne soirée

 

Bernard

[Spud 144]

 

Je me suis décidé à passer aux pédales de commande de Papinic. Et là, après avoir changé le fichier bin et adjoint un script, tout fonctionne à merveille.

 

 

Ah ben je n'ai pas que des propositions farfelues alors, tant mieux si cela marche avec la pédale de Dominique.

 

Bon courage pour la suite.

 

Bye

[henrion 101]

Mais non que tu n'as pas que des idées saugrenues!!

 

Si les pédales de commandes de papinic fonctionnent bien, il y a d'autres problèmes qui sont apparus et qu'il faut résoudre comme par exemple quand un train a franchi le PN, ce dernier s'ouvre mais dès que le signal suivant se met au rouge, le PN se ferme et là je n'ai toujours pas compris pourquoi

 

Bonne journée

 

Bernard

[Spud 144]

Salut,

 

Peut être ne mettant un aiguillage entre le PN et le signal, doncaprès tous les liens du PN et avant ceux du signal.pour voir si ce ne serait pas une information que le signal enverrai, comme pour dire au signal d'avant de se mettre a l'avertissement. et que l'état que peut prendre ton PN c'est ouvert ou fermé il se met en position fermé pour répondre au signal.

 

Car j'ai un soucis aussi sur ma ligne avec les TIV mobiles et lumineux de Geluc, a mon avis un problème de réinistialisation des signaux. du aux aiguillages. peut être la position des liens...

 

Bye