Version 22.02 du 14 Février 2022

[CC72000]

Bonjour à toutes et à tous,

Pour les amoureux du train miniature, Je viens de mettre en ligne la version V22.02 de CDM...

Cette version est la suite de la version V21.12 de décembre, avec les corrections de BUG suivantes :
1- Dans la fonctionnalité JK, certains court-circuits n'étaient pas cerclés pour certaines configurations de raccords circulaires.
2- Dans la fonctionnalité de Signalisation Automatique, les feux tête bêche et les détecteurs n'étaient pas implantés à la bonne position dans les courbes.

Modification des Stratégies de Vitesse, re-pointage de tout le dispositif des options, en effet ces options ne sont pas indépendantes les unes des autres.
Dans le Menu Option Simulation, les Options BAL / BAPR / Maintient du RALENT et RALENT 30/60 sont gérées de façon cohérente au niveau du Menu.
- La clause disant que le RALENT ne peut être inférieur à 30 km/heure n'existe plus, donc si une limite de vitesse de canton est inférieure à 30, elle sera bien prise en compte.
- Le départ d'un train qui franchit immédiatement un feu jaune, continuera de monter en vitesse jusqu'à atteindre la vitesse de ralentissement déduite de la situation.

Merci à Midav91 de me confirmer que tout est bon au niveau des vitesses...

En corrigeant le problème de départ en petite vitesse avec franchissement d'un feu jaune, j'ai trouvé sur ton réseau un cas de plantage de CDM sur le placement de train.
Je vais regarder maintenant ce cas, mais j'ai préféré faire cette version pour ne pas tout mélanger...

[Maxime LESAGE]

Bonjour Michel,
J'ai bien chargé cette version de CDM et j'ai testé mon petit scénario d'accouplement de deux voitures au train en arrêt et tout fonctionne à merveille dans ce scénario.
Merci Michel
Amicalement.
Maxime

[midav91]

Bonsoir tout le monde

Michel, encore un grand coup pour cette nouvelle version ... ça avance, ça avance !!

...
1- Dans la fonctionnalité JK, certains court-circuits n'étaient pas cerclés pour certaines configurations de raccords circulaires.

J'ai testé et la fonctionnalité J/K entoure bien les courts circuits pour tous les cas que j'avais constaté  !

2- Dans la fonctionnalité de Signalisation Automatique, les feux tête bêche et les détecteurs n'étaient pas implantés à la bonne position dans les courbes.

Pour le signalisation automatique, c'est OK sur le petit réseau où j'avais constaté ces décalages de positionnement automatique … pas dû être évident non plus d'aller chercher ce bug là dans les courbes !!

Modification des Stratégies de Vitesse, re-pointage de tout le dispositif des options, en effet ces options ne sont pas indépendantes les unes des autres.
Dans le Menu Option Simulation, les Options BAL / BAPR / Maintient du RALENT et RALENT 30/60 sont gérées de façon cohérente au niveau du Menu.
- La clause disant que le RALENT ne peut être inférieur à 30 km/heure n'existe plus, donc si une limite de vitesse de canton est inférieure à 30, elle sera bien prise en compte.
- Le départ d'un train qui franchit immédiatement un feu jaune, continuera de monter en vitesse jusqu'à atteindre la vitesse de ralentissement déduite de la situation.

Merci à Midav91 de me confirmer que tout est bon au niveau des vitesses ...

J'ai commencé à tester en RUN et les 2 points sont respectés ... mais je veux secouer cela un peu plus car j'avais quelques interrogations sur le respect des courbes de décélération comme je te l'avais évoqué sur la vidéo transmise en mail.

En corrigeant le problème de départ en petite vitesse avec franchissement d'un feu jaune, j'ai trouvé sur ton réseau un cas de plantage de CDM sur le placement de train.
Je vais regarder maintenant ce cas, mais j'ai préféré faire cette version pour ne pas tout mélanger...

ok

Amicalement
et bonne soirée

[CC72000]

Bonjour,

J'ai commencé à tester en RUN et les 2 points sont respectés ... mais je veux secouer cela un peu plus car j'avais quelques interrogations sur le respect des courbes de décélération comme je te l'avais évoqué sur la vidéo transmise en mail.

Surtout vas y Michel, secoues le machin, ne te gènes pas...

Et encore merci pour tes vidéos qui m'ont bien permis de cerner les problèmes que tu avais signalés.

Pour le BUG sur le placement initial, plus je creuse et plus je m'enfonce...
C'est un placement sur une section parallèles...

[midav91]

Bonsoir Michel,

Je continue à secouer ... pourvu que les noix de coco ne me tombent pas sur le nez

Le bug de placement initial, attention de ne pas creuser jusqu'à atterrir de l'autre côté ... en Chine

Alors effectivement, j'ai constaté quelque chose depuis longtemps, tu me diras si c'est bien cela que tu as débusqué.
Quand CDM plante en RUN (bon ,c'est quand même pas tous les matins) et que je dois repositionner tout mon petit monde (c'est en RUN mais effectivement je n'avais même pas chercher à voir si on retrouvait cela simplement en simu)
Pour moi, il s'agit effectivement du positionnement sur des sections parallèles mais apparemment surtout avec des autorails.
J'avais une petite idée que ça pouvait être lié à la difficulté de les remettre dans le bon sens (avant / arrière) par rapport à l'itinéraire, quand on passe plusieurs fois sur cette section parallèle et surtout dans les 2 sens !!!
Me doutant de la difficulté de résoudre un tel problème, sans doute assez peu courant, je n'avais pas voulu trop "charger la mule" avec ça ... il reste pour l'instant encore suffisamment de boulot plus prioritaire je pense ... humm ... et qui s'y colle ??
D'autant que j'ai résolu cela "facilement" ... je refais tout simplement le placement initial des autorails ailleurs que sur ces sections parallèles, quitte des fois à les promener à la main vers une section libre

A bientôt et bonne nuit les petits !

[midav91]

Bonjour à tous, bonjour Michel

Après quelques secousses tests réalisés en simu sur mon petit réseau d'essai (voir vidéo en mail) et confirmés en RUN sur mon réseau physique (à noter dans mon avant dernier post, j'évoquais un questionnement sur les courbes de ralentissement mais après moult essais, ça me paraît bien correspondre à tes descriptions) :


En BAL (juste la case autoriser nouveaux modes cochée) :

Un canton dont la vitesse spécifiée est de moins de 30 km/h (20 par ex) est bien parcouru à cette vitesse (20)
SAUF si ce canton comporte soit un arrêt programmé, soit un rebroussement (en ligne ou sur butoir), dans ces cas là, la vitesse remonte alors à 30 jusqu'à l'arrêt !


En BAPR, les 2 premières cases cochées (j'ai noté que les 2 autres cases sont inactivées dans ce cas) :

La vitesse inférieure à moins de 30 km/h est là bien respectée dans tous les cas, càd même sur un canton avec arrêt programmé ou rebroussement

Je t'envoie en mail un petite vidéo qui récapitule tout cela

Nota :
en BAPR, le déclenchement du ralentissement se fait à une distance du signal de 2 fois dA.
Sur mon réseau, j'ai des motrices avec une inertie un peu importante et cette distance est alors insuffisante (même si je baisse un peu le coef de ralentissement de 50 %), en fait la motrice a encore une vitesse supérieure au palier V R2, n'a pas le temps de le marquer, et finit un peu au delà du signal (sans toutefois provoquer le déclenchement KVB !) … ça dépend aussi de l'exactitude du schéma par rapport à la voie réellement posée !
voir ma courbe rouge ci après :

Je suppose que cette valeur est issue de ta formule qui donne la distance d'arrêt (et qui dans tous les cas me paraît sans vraiment de marge de sécurité). Qu'est-ce qui empêcherait de l'augmenter, par exemple à 3 x dA pour obtenir une marge  ?

Bon, après on peut aussi reprendre la table de vitesse de la (des) machine(s) … mais c'est un peu plus lourd !



Autre chose pour la fenêtre état du train (bien pratique quand on veut analyser les différentes vitesses d'un train) - voir image ci-après :
- le train affiché est le dernier survolé avec la souris, alors lorsque les circulations sont denses c'est très délicat de rester « accroché » sur le même train. Ne pourrait-on pas rajouter un 3ème bouton en bas qui nous bloquerait sur le train désiré, quel que soit le survol de la souris après ?
- les 2 dernières cases d'affichage en bas ne sont pas assez larges pour afficher les valeurs entre parenthèses

fenetre etat du train.jpg (33.51 Kio) Consulté 1066 fois

Voili voilou ... je crois que la perfection n'est pas loin !!

Amicalement et à +

[CC72000]

Bonjour Michel,

En BAL
si ce canton comporte soit un arrêt programmé, soit un rebroussement (en ligne ou sur butoir), dans ces cas là, la vitesse remonte alors à 30 jusqu'à l'arrêt !

Oui, vu, il restait encore une correction à 30...

En BAPR, les 2 premières cases cochées

(j'ai noté que les 2 autres cases sont inactivées dans ce cas)

les deux autres cases n'ont de sens qu'en BAL... cela évite de faire des combinaisons d'options farfelues...

en BAPR, le déclenchement du ralentissement se fait à une distance du signal de 2 fois dA.
Sur mon réseau, j'ai des motrices avec une inertie un peu importante et cette distance est alors insuffisante (même si je baisse un peu le coef de ralentissement de 50 %), en fait la motrice a encore une vitesse supérieure au palier V R2, n'a pas le temps de le marquer, et finit un peu au delà du signal (sans toutefois provoquer le déclenchement KVB !) … ça dépend aussi de l'exactitude du schéma par rapport à la voie réellement posée !
...
Qu'est-ce qui empêcherait de l'augmenter, par exemple à 3 x dA pour obtenir une marge ?

x 2 DA non respectée, cela veut dire que l'inertie de CDM est fausse à 100%, donc il faut ajuster le Coef.

Bon, après on peut aussi reprendre la table de vitesse de la (des) machine(s) … mais c'est un peu plus lourd !

Non, enfin je modère mon propos, il faut bien sûre que les tables de vitesses soient le plus juste possibles. Mais c'est la vitesse, pas l'inertie.

Je pense que je vais faire un "Outil" ou un "tuto" ou ... pour aider à régler le Coef d'inertie de décélération, en mesurant la DA réelle.

Ne pourrait-on pas rajouter un 3ème bouton en bas qui nous bloquerait sur le train désiré, quel que soit le survol de la souris après ?
- les 2 dernières cases d'affichage en bas ne sont pas assez larges pour afficher les valeurs entre parenthèses

Moi j'utilise la fenêtre Information États des Trains, mais je vais regarder cela...

[Conchito]

Bonjour Michel,

J'interviens dans cette discussion pour proposer une correction dans CDMRail, après quelques échanges avec gily sur les communications entre un client Comm/IP et le serveur CDM, .http://cdmrail.free.fr/ForumCDR/viewtopic.php?f=63&t=4463#p56171

Je souhaite pouvoir jouer au "petit train" avec mon petit-fils. Le pilotage du réseau à travers le dessin du réseau dans la fenêtre CDM et les throttles créés pour chaque train permet de commuter les aiguillages en cliquant dessus, faire circuler les trains en manuel et en automatique, en ayant la sécurité des convois assurée par CDM. Pas de franchissement de carrés, pas de changement d'aiguillage si ce dernier est réservé pour un train ...
Cela convient tout à fait, mais se pose alors le problème de n'avoir que le PC pour piloter. A deux sur un PC c'est difficile. De plus, ce n'est pas trop pratique pour circuler autour du réseau avec le PC !
En passant par Comm/IP, avec les conseils de gyli, j'ai commencé à écrire, en Processing, un programme client basique (pour vérifier la faisabilité pour le moment) qui permet de lire des états et d'envoyer des ordres au serveur CDM. Le but est de transposer ce client sur une tablette ou un smartphone ultérieurement pour réaliser le contrôle d'un ou deux trains..

Avec ce client, pas de problèmes pour lire la liste des trains, les états des aiguillages, signaux détecteurs et actionneurs. Je pilote les locos via le serveur qui impose le respect des signaux, des limitations de vitesse en limitant automatiquement les ordres envoyés aux locomotives. Le client semble piloter le throttle de CDM. CDM prend alors en compte les limites imposées par la sécurité avant d'envoyer les ordres à la centrale et de renvoyer la vitesse réellement commandée au client.

Par contre, pour le pilotage des aiguillages, c'est autre chose :
Quand le serveur CDM reçoit l'ordre de commutation d'un aiguillage, il le transmet directement à la centrale qui exécute bien le changement de l'aiguillage. Mais le dessin n'est pas mis à jour et la nouvelle position de l'aiguillage n'est pas prise en compte dans la gestion de la sécurité des convois. Il faut alors cliquer sur le dessin de l'aiguillage pour mettre le modèle du réseau et le dessin en conformité avec la réalité et rétablir la sécurité si aucun autre évènement n'est intervenu entre temps.

Voici donc ma demande :
S'il vous plait, serait-il possible de modifier le comportement du serveur Comm/IP de CDMRail, ou CDMRail, pour que quand le serveur reçoit un message de demande de commutation d'aiguillage, ce dernier agisse comme si l'utilisateur avait cliqué sur l'aiguillage concerné ?

Je ne sais pas si ma demande est très complexe à mettre en oeuvre, mais cela apporterait un grand plus sur l'aspect ludique de CDMRail.
On pourrait alors laisser tourner les trains en automatique sur la partie principale du réseau (contrôlés par le PC), pendant que d'autres utilisateurs piloteraient sur leur smartphone ou leur tablette quelques manœuvres dans un dépôt ou une gare de triage, sans risquer de perturber les itinéraires et la sécurité des convois.

En espérant que ma demande puisse être prise en compte, je vous souhaite un bonne journée.
Amitiés

Serge

[CC72000]

Bonjour Serge,

Voici donc ma demande :
S'il vous plait, serait-il possible de modifier le comportement du serveur Comm/IP de CDMRail, ou CDMRail, pour que quand le serveur reçoit un message de demande de commutation d'aiguillage, ce dernier agisse comme si l'utilisateur avait cliqué sur l'aiguillage concerné ?

Je ne sais pas si ma demande est très complexe à mettre en oeuvre, mais cela apporterait un grand plus sur l'aspect ludique de CDMRail.

Pour répondre à cette demande, il faut que je regarde ce que Jean-Pierre avait écrit sur ce sujet qui n'est pas nouveau...

Je sais que ce serait une grande amélioration de CDMRail, mais pour le moment je n'ai pas les idées claires sur la difficulté de réalisation de cette modification.

[gily]

bonjour

pour ce sujet, commander un aiguillage depuis un client, c'est comme si on bougeait un aiguillage avec la raquette de la centrale plutot qu'avec CDM, donc on "force" un état d'aiguillage. Pas forcément simple de faire une prise en compte de cela dans CDM en run...