Le chantier du moment

[jpp38]

Bonjour,

Je pense que le temps reste un invariant, sinon, ça serait incompréhensible au niveau de la perception de la vitesse (distance / temps).
Par contre, je pense que le facteur à appliquer au horaires dépend de la périodicité avec laquelle les trains passent au même endroit sur le réseau quand ils sont en marche. Donc, je dirais que ça dépend de la taille du réseau, plus que de son échelle.
Mais de toute façon, c'est impossible de conserver l'heure absolue qui est la nôtre.

Robert, si tu nous entends , peux-tu nous dire comment c'est fait sur RRTC.

JP

[Guytoonet]

Bonjour,

Robert, si tu nous entends , peux-tu nous dire comment c'est fait sur RRTC.

JP

je ne dirai que et un à l'ami Robert.

Guy

[PhilB47]

Bonjour,

Je suis très dubitatif sur la compression du temps. Pour moi, le temps s'écoule de la même manière, quelque soit l'échelle, cette dernière étant basée sur les dimensions physiques du modèle, mais non sur le temps.

D'ailleurs, si je veux mesurer la vitesse de mes trains, je vais travailler sur la distance parcourue à l'échelle, pour la rétablir ensuite à l'échelle 1, mais sans rien changer au niveau de l'écoulement du temps : Une seconde reste une seconde. Le sujet sur le calcul et la calibration de la vitesse des trains travaille d'ailleurs sur le même mode : on ne change pas l'échelle d'écoulement du temps.

La vitesse d'écoulement du temps va varier avec la vitesse de déplacement du sujet, (les fameuses théories d'Einstein ) mais non avec la taille (ou l'échelle) de ce dernier.

Mais le débat reste ouvert.

Phil, pas intemporel hélas.

PS : Je n'avais pas vu qu'il y avait une deuxième page, et que JP avait déjà répondu (tempus fugit). On se rejoint d'ailleurs dans nos réflexions

[Guytoonet]

Hello les gens,

Voici donc un sujet qui passionne
Mais au fait, qu'apporterait de plus, cette fameuse notion de temps ou d'horloge, concrètement?
CDM-rail propose déjà des temporisations d'arrêts et ceux qui ont testé les simulations savent bien que ce n'est qu'avec le temps de jeu que les circulations se mettent en place, non?
Par exemple, un arrêt en gare programmé de 60 sec, peut devenir totalement différent, jusqu'à ce que les séquences de trafic soient stabilisées et puissent se reproduire.

Vous voyez ce que je veux dire?

[jpp38]

En réalité, ce qui me paraît plus important, c'est de pouvoir gérer la synchronisation d'évènements.
Par exemple:

Le train A repart après
- avoir fait un arrêt de X secondes ET
- que le train B soit arrivé ET
- avoir attendu Y secondes après arrivée du train B ET
- ....

JP

[PhilB47]

Bonjour,

Vous avez raison tous les deux, mais il y a aussi la troisième option :
16h30 : La train A démarre de la gare A vers la gare B. Trajet environ 2 mn (nous sommes en N).
16h35 : Le train A démarre de la gare B vers la gare C, même si le temps de parcours a été de plus ou moins 2 mn, à cause du trafic, etc...

On peut ainsi coordonner des horaires, les respecter, etc... Mixé avec la coordination d’événements et des arrêts temporisés, je pense qu'on peut faire un truc amusant.

Cela me fait penser (je mélange les sujets, désolé) à une autre amélioration que j'avais stockée dans un coin de ma tête : Pouvoir, lorsqu'on créé un itinéraire, faire des variantes si l'itinéraire est occupé par un autre train. Exemple, mon train doit entrer en gare sur la voie 1, mais celle ci est occupée par le train d'avant qui était en retard. Alors, mon train peut prendre un second itinéraire (une déviation) sur la voie 2, par exemple. (bien sûr, lorsque j'ai créé l'itinéraire, je lui ai dit qu'il y a une variante à cet endroit là).

Voilou

Phil

[Guytoonet]

Salut Phil,

Au contraire, je trouve que ça ne mélange pas les sujet.
Ce fil a le mérite de tout regrouper et évite de devoir faire des recherches parfois fastidieuses.

Le deuxième point que tu évoques et lié à la vie courante, en fait.
Si un train a pris du retard, la voie n'est pas libre et du coup, on dévie le train suivant, sur une voie parallèle.
Reste à voir si la vraie vie est aussi simple à transposer en modélisme

Guy

[jpp38]

Ca, Phil, c'est carrément plus compliqué à faire.
Ca rentre dans le cadre du 3eme niveau d'algorihtme de simulation (il y a deux niveaux actuellement), que je n'ai jamais abordé. Dans le même registre: gestion de la voie unique à double sens de circulation quand il y a plus d'un canton.

Pour plus tard

JP

[railenbois]

Bonsoir

mettre une notion de temps sur nos réseaux ,nous obligera à "faire l'heure" ,pour moi c'est impossible sauf en manuel et à plusieurs ,chacun avec son train et sa marche à suivre ,supervisé par un régulateur ,comme dans la réalité.

Une horloge sert au cadencement des trains ,on revient à ma demande à JP concernant la priorité selon le type de convoi ,en effet les voyageurs se doivent de respecter leur horaire dans une certaine mesure ,et c'est la qu'intervient le régulateur pour bloquer un convoi non prioritaire par rapport à un autre.

Pour faire l'heure un conducteur tourne la manette un peu plus pour regagner du temps 140 au lieu de 120 ,je ne pense pas qu'un jour un logiciel puisse intégrer tout ceci ou dans un avenir lointain.

Marcel ,qui laissera gérer la circulation des ses convois par CDM pour éviter le stress du tout manuel

[rbonneton]

Ouah! Les Neurones s'agitent de partout.. Qui a dit que le forum s'endormait? C'est vrai que c'est pas moi qui fait bouillir la marmite mais j'ai un gros défaut, celui d'écouter aux portes (au fil plutôt). Plein de sujets passionnants pour cette rentrée, JPé va avoir beaucoup de mal à gérer et chacun d'en rajouter une couche!
J'interviens suite à la fonction "horloge" qui vient de tomber et pour laquelle on me lance un petit clin d'oeuil. En effet RRTC que j'utilise propose cette possibité par édition de fiches horaires avec itérations au jour, au mois... C'est effectivement un moyen intéressant de cadencer des évènements en spécifiant une date de début.
Ca fonctionne correctement, facile à paramétrer mais je suis tout de même surpris (au travers du forum RRTC) de constater que l'utilisation de cette fonction n'est pas d'utilisation très courante. RRTC utilise une horloge visualisable en fenêtre avec une possibilité de compression du temps (de 1 à 99) pour des raisons évidentes de visualisation des enchaînements d'évenements et de séquences. Par défaut, le taux de compression est de 1/6 mais en aucun cas il n'est lié à l'échelle du réseau mais plutôt comme le dit Jpé à l'importance du réseau (dimensions) donc à la cadence de répétition de séquences identiques.
Comme il n'y a plus dans ce type de fonctionnement de liens automatiques entre les enchaînements, RRTC introduit un paramètre de taux de probabilité de réussite et de plage d'erreur sur la date d'exécution....Au delà, il y a abandon de l'action. Très fort mais difficile à tester, mes réseaux n'ont pas encore la dimension critique pour de tels scénarios. En conclusion, je ne pense pas qu'il faille en faire une priorité. La synchronisation d'évènements comme la préconise JPé me parait bien plus prioritaire car c'est elle qui permettra les jeux d'animations dés lors que plusieurs convois sont en circulation.
La possibilité d'itinéraires ou de trajets alternatifs serait une ouverture intéressante pour éviter les situations de blocage de même que la voie unique parcourue dans les deux sens lorsqu'elle comporte plusieurs cantons consécutifs.... mais là, je prêche pour ma chapelle!
Soyons sympa et laissons JPé aller à son rythme, il connait parfaitement nos besoins.