henrion

Bonjour. Partant quelques jours pour Noël et à priori sans liaison internet mais avec quelques devoirs de vacances , je voudrai souhaiter à tous de passer de joyeuses fêtes de Noël. Bernard

Bonjour. En regardant la signalisation française, il m'est venu à l'esprit quelques réflexions et j'aimerai que les spécialistes me donnent leur sentiment. Bien que la majeure partie de la signalisation française puisse être représentée sans problème majeur, il existe quelques cas d'impossibilité ou de limitation. J'ai répertorié deux impossibilités majeures: - à la sortie des gares en voie unique, un sémaphore unique s'adresse aux deux voies (directe et d'évitement). Comme un signal ne possède qu'un lien 0 qui ne peut gérer qu'une seule voie, cette représentation est impossible et il faudra donc mettre un sémaphore par voie et donc faire une concession à la réalité. J'ai essayé de contourner le problème mais pour l'instant je n'y suis pas arrivé. - le guidon d'arrêt qui correspond à un signal d'arrêt à main ne pourra pas non plus être programmé systématiquement. Après réflexion, il sera éventuellement possible de le programmer dans quelques rares cas mais de manière pas du tout orthodoxe. Si certains voient d'autres impossibilités, je suis preneur. Il existe aussi des limitations et j'en vois d'emblée deux: - dans les blocks manuels en voie unique, les signaux sont normalement fermés, même si la voie est connectée et le canton est libre. Or, on ne peut pas dire à un signal d'être fermé si le canton est libre et la voie connectée car dans ce cas il ne sera jamais ouvert. Donc, les sémaphores de sortie de gare qui se font face seront tous les deux ouverts si le canton est libre et la voie connectée, ce qui dans la réalité est impossible. C'est une simple limitation car cela n'affecte pas le fonctionnement des signaux; en effet, dès qu'un train franchira un lien 0, il fermera son sémaphore mais aussi celui lui faisant face à la gare suivante. - en BAL, devant un sémaphore fermé, le conducteur arrête son train et, s'y rien ne s'y oppose, il peut le franchir à la vitesse maxi de 15 km/h. En face d'un rouge clignotant, le train pourra le franchir à la même vitesse sans marquer l'arrêt. Si le franchissement à la vitesse maxi de 15 km/h peut être contrôlée par le signal, par contre il ne me semble pas que l'arrêt devant un sémaphore fermé puisse être vérifié et donc, en terme de programmation, il n'y aura aucune différence entre un sémaphore fermé et un rouge clignotant. Maintenant j'ai une question pour les concepteurs de cabine Un jour, en utilisant Railworks en niveau intermédiaire, sur la route Hagen-Siegen, je me suis retrouvé devant un signal au rouge et qui ne voulait pas en démordre. Il a donc dû mal se réinitialiser. Je l'ai franchi à vitesse réduite et le signal suivant étant au vert, j'ai repris ma marche normale. Il m'est donc venu une idée mais je ne sais pas si cela est réalisable, n'ayant pas étudié la programmation des cabines. Si une cabine, par l'intermédiaire d'un bouton, peut envoyer un message au signal (uniquement ceux à plaque Nf) pour lui demander de vérifier si la voie est connectée et si le canton est libre, le signal pourra lui répondre par un ConsistMessage en lui disant que la voie est libre ou pas (par le biais d'un signal vert ou rouge dans la cabine doublé éventuellement d'un message vocal si c'est possible), ce qui jouera un peu le rôle du régulateur. Mais est-ce possible?. Enfin, en regardant la signalisation américaine qui est très complexe, j'y ai trouvé deux choses intéressantes: - d'abord, une fonction dont ne parle pas la documentation de Kuju: la fonction DetermineConsistType. Lorsque l'on crée une rame, on peut lui affecter sa nature (Freight, special, express, stopping.....). Il y a une dizaine de possibilités. Cela sert à vérifier la vitesse de passage sur les aiguillages qui est différente aux USA, en fonction de la nature de la rame. Je ne sais pas si la liste qui apparaît est fixée par le logiciel ou si l'on peut en affecter d'autres. Si certains ont la réponse....Cette fonction peut être intéressante car en fait, on pourrait l'utiliser chez nous dans des cas différents. - enfin, il y a un signal spécial qui s'appelle "bloqueur de PassMessage". Si son nom est évident, je n'ai pas encore bien saisi dans quel cas spécifique il est utilisé. Par contre c'est une astuce qui permet de bloquer un message spécifique et ce pourrait nous être éventuellement utile. A voir. Bon dimanche. Bernard

Bonjour Le lien en bas de l'image est le lien 0 et doit être placé à proximité immédiate du signal. Le lien 2 ne sert absolument à rien. Dans ce cas de figure, il ne faut utiliser qu'un signal avec 2 liens en plus du lien 0. on part du principe que l'on met un lien autre que le lien 0 après la dernière jonction que ce signal protège sur chaque itinéraire pouvant être emprunté par le train. Il ne doit pas y avoir de jonction entre le lien 1 ou 2 ou 3 et le prochain signal sur la ligne. Bonne journée

Je viens de regarder les scripts des rampes AWS et TPWS. Il y a un point qui me chiffonne. Le script de la rampe AWS est long alors que celui de la rampe TPWS est très court. J'aurai plutôt pensé l'inverse. Je vais donc les étudier pour voir ce que l'on peut en sortir.

Pour ce qui est du franchissement d'un point particulier qui ouvre un passage aval, c'est possible je pense en mettant là aussi un signal invisible ou une balise quelconque. cependant pour que cela marche, il me semble qu'il faut que ce soit programmé comme un signal dont le seul rôle serait d'informer le signal aval qu'un train arrive et qu'il doit s'ouvrir. Mais pour trouver une solution il faudrait voir ce que tu veux faire exactement et dans quel contexte. Mais je vais m'y pencher pour voir si cela peut marcher notamment dans le cas de la présence d'un signal en amont afin que ce dernier ne soit pas perturbé. En ce qui concerne les voies uniques, il faut bien étudier toutes les possibilités qui se présentent. Mais c'est quand même complexe. je vais voir ce qu'il est possible de faire en fonction des éléments que tu m'as fourni ci-dessus. Je répète que je ne suis pas du tout sûr qu'en cabine on puisse envoyer un message vers un signal. Si cela était vrai, ce serait intéressant. Enfin, pour les balises et crocos, ce n'est pas compliqués à programmer dans les signaux puisque qu'en fonction des événements il y a juste envoi d'un message (encore faut-il savoir lequel envoyer). Par contre c'est en cabine que cela est compliqué dans la réponse à apporter. En fait cela ne se borne dans la programmation des signaux qu'à quelques lignes de plus. Ce n'est donc pas la mort. La priorité est évidemment la programmation des signaux, ensuite on aura tout le temps de voir la liaison signaux-cabine.

c'est sûr que ce n'est pas simple et sûrement très long à faire. Mais ce peut être un challenge intéressant si l'on s'y met à plusieurs. Je me suis mis jusqu'à présent qu'à la programmation des signaux qui me semble plus évidente pour moi mais je vais aussi essayer de comprendre la manière dont se fait la programmation des cabines. Mais en conduite de train je n'y connais rien. Pourtant la liaison signaux-balises avec la cabine est intéressante à étudier.

Bonjour. Il est évident que tout jeu à ses limitations; Avec Jules31, on menait une réflexion pour rendre la signalisation française la plus réaliste possible dans RW/RS. Il est évident aussi que le crocodile et le KVB devront être simulés. Cela ne pose pas de problème s'ils ont créés comme les balises AWS et TPWS (avec un lien sur chacun d'eux pour que le passage du train puisse être reconnu). En ce qui concerne le traitement, il ya deux parties à cela: la partie envoie du signal vers la cabine (en fait envoi du message SendConsistMessage) et cela la programmation est assez simple en prenant exemple sur les SPAD, AWS et TPWS. Ensuite, à l'arrivée en cabine, je laisse le soin à ceux qui connaissent de programmer l'action qui va bien. En l'absence de réaction, le freinage automatique sera mis en oeuvre automatiquement par le logiciel. Pour moi la programmation des balises et croco est indissociable du fonctionnement des signaux et donc tout doit être traité ensemble. Pour le bouton, ce n'était qu'une suggestion qui aurait pu résoudre certains problèmes mais je n'en fais pas un cheval de bataille loin de là, n'étant pas un spécialiste de la question ferroviaire

Cela est sûrement possible car il suffit au franchissement d'un signal, d'envoyer un message vers l'avant demandant au prochain signal de s'ouvrir. C'est sûrement plus facile à dire qu'à programmer mais cela vaudra le coup d'essayer. Pour le signal de sortie de gare en voie unique, dans RW/RS, il ne va s'ouvrir que lorsque l'aiguillage est connecté et le canton libre et c'est le problème de la position de l'aiguillage qui pose problème. En effet, si le sémaphore ne donne que l'indication de la liberté du canton, il faudra un autre dispositif pour indiquer au cinducteur que l'aiguillage est positionné pour lui. C'est pour cela que je dis qu'il faudra un sémaphore par voie. Et je ne vois pas comment faire autrement. Pour ce qui est du signal invisible, je suis parfaitement d'accord. Il me semble que ce sera assez simple à programmer. Quand je dis assez simple tout est relatif car il faut bien voir toutes les implcations possibles mais c'est faisable

Merci mais si j'ai bien compris la question, cela n'a rien à voir avec le fait que cette loco soit une loco militaire. C'est donc une question généraliste qui dépasse mes compétences. Bonne soirée

Bonjour. Quelle était la question sur les trains militaires car étant moi-même un ancien militaire, je pourrai peut être répondre. Cordialement.

Bonjour. Ne serait-ce pas dans l'autre sens qu'il faut voir les choses. Il me semble que c'est un dispositif de protection pour empêcher des wagons ou des rames de s'engager inopinément vers les voies principales ou des voies non autorisées mais aussi pour empêcher des trains sortant d'établissement privé de s'engager sans autorisation sur le domaine de la SNCF. Jules31 ou Grégoire vont sûrement nous expliquer cela correctement. Bonne soirée

Merci - J'avais vu sur un document qu'un feu rouge clignotant pouvait précéder un carré dans le cas où une distance minimale ne peut être obtenue entre le signal d'arrêt et son avertissement. Le carré est précédé d'un feu rouge clignotant, lui-même précédé d'un avertissement et si besoin est lui même précédé d'un feu jaune clignotant. mais il ne s'agit pas d'un document officiel. Je pensais bien qu'un signal ne pouvait pas établir la nature de la rame se présentant. Mais si l'on veut s'amuser avec Railworks/Rail simulator, il sera toujours possible de le programmer assez facilement.

Merci pour ces précisions. En ce qui concerne le feu rouge clignotant: - quels sont les cas d'utilisation? ( je pense à la sortie de gares pour éviter à un train ne desservant pas celle-ci de s'arrêter, dans les montées pour éviter aux trains de fret lourd de ne pas pouvoir redémarrer) mais je pense qu'il y a d'autres cas. - est-ce qu'il est présenté systématiquement à tous les types de train et chaque conducteur agit en conséquence ou alors est-ce qu'il peut différencier les types de trains? Ce dernier point peut se programmer facilement dans la signalisation Railworks. Merci d'avance.

Bonjour, Je ne suis pas de la SNCF mais il me semble que si l'on prend soin de mettre un rappel de ralentissement, cela veut dire de facto que la vitesse de la ligne en amont est forcément supérieure à celle présentée par le rappel de ralentissement, sinon cette indication ne servirait à rien. Pour moi, un rappel de ralentissement 30 ou 60 est obligatoirement précédé par un ralentissement 30 ou 60 porté par le signal précédent (de type E, F, G ou H) et donc situé à distance d'arrêt du rappel. De même, un TIV de rappel est toujours précédé à distance de ralentisement par un TIV à distance qui peut lui même être précédé sur les voies => 160 km/h d'un signal de préannonce "P". Par contre, il me semble qu'un TIV à distance n'est pas obligatoirement suivi d'un TIV de rappel si la zone de ralentissement est parfaitement identifiable par le mécanicien. Cela peut être le cas d'une ligne secondaire qui rejoint une ligne principale. Mais je laisse le soin aux spécialistes de confirmer ou d'infirmer tous ces points. Si Grégoire pouvait préciser un peu plus ce qu'il a dit dans son post précédent. Bon dimanche Bernard.

Bonjour, avec le KVB ce sera possible en grande partie mais pas dans son intégralité je pense. on peut interagir lors du franchissement des signaux et lorsqu'on est en excès de vitesse à leur passage. Par contre la gestion du ralentissement, je ne sais pas si cela sera possible.

Bonjour, Si vous avez besoin d'aide dans la rédaction des scripts, n'hésitez pas à faire appel à moi. Je pense que plutôt que d'adapter les scripts de Kuju, il faut les réécrire complètement pour les adapter aux spécificités françaises. Et dans ce domaine j'ai des idées bien arrêtées sur la façon de faire. Par ailleurs, il faudra aussi adapter ces scripts aux systèmes d'alerte en cabine français. Ce n'est pas simple mais ce n'est pas insurmontable Je m'y mettrai dès le début du mois de janvier car auparavant j'étudie les scripts des signaux américains qui offrent des possibilités supplémentaires dont kuju n'a pas parlé dans sa documentation et qui seront peut être utilisables dans la signalisation française. Par ailleurs j'écris aussi un document sur la représentation de la signalisation SNCF dans Railworks/rail simulator avec ses possibilités et ses impossibilités. Bonne journée à tous. Bernard

Bonjour. je viens juste apporter une précision puisque personne ne m'en a fait la remarque. Dans le document j'ai parlé de signal de "bloc". Cette écriture était spécifiquement utilisée dans le midi de la France. Normalement on utilise, et même en Français, le terme anglais "block". On parle donc de block automatique ou de block manuel. Mea culpa.