Faire le bon choix ?

Pierrot a écrit:

Pour des aiguilles PECO j’ai peut être une idée pour faire contrôler la position d’une aiguille par RRTC, de telle sorte que si l’aiguille pour une raison mécanique n’est pas orientée correctement, RRTC stoppe le train concerné.

Pierrot

Bonjour,

C'est une trés bonne idée, qui peut être utilisée avec d'autres moteurs que les PECO, il suffit d'avoir un inverseur de libre, ou d'ajouter un relais, de plus il n'y a pas besoin de créer de canton supplémentaire.
Une aiguille étant généralement adjacente à 2 cantons de sortie, utilisés par 2 trajets différents, il faut faire une occupation fictive par le contact inverseur et 2 résistances qui peuvent être de valeur 1 à 10K suivant la sensibilité des détecteurs de présence, sur ces 2 cantons (l'un ou l'autre en fonction de la position de l'aiguille dans le trajet).
Donc pas de macro ou autre programmation supplémentaire à créer.

J'ai fait l'essai en simulant l'occupation avec un wagon aux essieux graphités, et celà fonctionne!

Oui Marc Got ta solution est bonne mais elle nécessite 2 détecteurs de présence par aiguille.

Dans ma solution il me semble si je ne dit pas de bétises qu'il ya 2 avantages

1) on n'a besoin d'un seul détecteur de présence par aiguille

2) si l'aiguille n'a pas fonctionné correctement, le train s'arrête avant d'arriver sur l'aiguille

Donnez moi votre avis

Bonne journée

Pierrot

Non, pas de détecteur supplémentaire, puisque la résistance de charge revient sur le(s) détecteur(s) existant des cantons 2 et 3 marqués indicateurs dans ton exemple.
L'inverseur du moteur sert à simuler avec des résistances l'occupation des cantons 2 ou 3, ce qui stoppe le train en amont, sauf si bien sur le trajet est paramétré pour cantons "entrer même si occupé".

Pierrot, je me suis permis de modifier ton schèma.



Evidemment dans ma version il faut un inverseur supplémentaire, mais il n'y a pas besoin de détecteur et de canton en plus, ni de programmation.

Le choix se fait selon le matériel utilisé ou la préférence de l'utilisateur

Tu restes l'initiateur de cette solution

A+

Marc_GOT grâce à ton croquis, je vois mieux ton résonnement.

A noter que sur mon croquis à l’origine j’avais fait une erreur, car pour le croquis du haut (aiguille en position déviée) il faut lire « AIGUILLE POUR Canton 1 <- - -> Canton 3 » et le croquis du bas (aiguille en position directe) il faut lire « AIGUILLE POUR Canton 1 <- - -> Canton 2 ».

Si je comprend bien lorsque l’aiguille est en position directe le Canton 3 (celui qui suit l’itinéraire dévié) est considéré occupé par RRTC.
Donc si l’itinéraire doit suivre le trajet dévié et que l’aiguille est restée en position directe, le canton 3 par lequel le train doit passer est considéré comme occupé et va stopper le train. Mais c’est super, bravo Marc.

Les vacances sont finie, je ne pourrai pas lire le forum pendant 2 jours.

Bonne soirée, à bientôt

Pierrot

Une idée en passant : si on doit contrôler une erreur d'aiguille donc de canton qui va être occupé, une solution peut être de mettre un contact de rétro dans le lien entre les cantons et de tester l'occupation du canton prévu dans le trajet à la désactivation du contact du lien.

J'ai pas tout compris, enfin je crois voir ce que tu veux dire, mais que fais-tu avec l'information de la position de l'aiguille ?

Heu, ça ne permet pas de vérifier la position de l'aiguille mais simplement de détecter une erreur d'aiguillage (donc une mauvaise position d'aiguille). A supposer que l'aiguille A permette d'accéder aux cantons A1 et A2, il suffit de tester : si A2 est activé alors que l'itinéraire vers A1 est sélectionné c'est qui y a erreur. J'espère avoir été plus clair

Oui oui, c'est clair, mais comme le train s'est arrêté, c'est qu'il y a un problème d'occupation, et donc sûrement d'aiguillage.
Alors que fais-tu ??

- tu fais le 18
- tu appelle la police
- tu te tire une balle dans la tête
- tu allume un girophare
- ou tu vas tranquillement voir pourquoi cette $&"$# aiguille a pas fonctionné?

A+
Marc

Bien les 5. Heu non pas la 3eme proposition. Il me semble que c'est ce qu'on fait en cas d'urgence. Une aiguille qui ne commute pas est un cas "normalement" exceptionnel, et à cas exceptionnel, mesure exceptionnelle me semble-t-il ? Si on doit rajouter un élément pour contrôler l'aiguille, on va finir par en ajouter un autre pour contrôler le contrôleur de l'aiguille etc..

Bonsoir Olid,

Mon post d'hier était un peu ironique, mais ce que je voulais te préciser, c'est que pour faire un test, il faut que le trajet soit démarré, et ton intervention risque d'arriver après l'arrêt du train.

A+

Bonsoir

Pour répondre à vos soucis, je vous fait part de mon idée, en utilisant la solution de Marc

Etant donné que dans un trajet toutes les aiguilles ne se positionne pas dés le démarrage du trajet, pour être averti qu’une aiguille n’est pas bien orientée, il suffit de faire arrêter le train avant l’aiguille est de déclancher une alerte sonore comme un bip bip.

Prenons l’exemple ci-dessous


Dans le trajet Canton A - - -> Canton C, on crée pour le Canton 1 un contact virtuel à environ 1 ml de la fin de ce Canton que l’on paramètre ainsi :
-Condition : Canton 3 Occupé
-Opération : Stop et Bip Bip

Le train s’arrêtera en douceur vers la fin du canton et attendra vos nouvelles instructions. Tous les autres trains peuvent continuer leur trajet sans aucun risque.
(je ne peut mettre ces idées en pratique, ma centrale est en drapeau, mais le test logiciel est OK)

Bonne soirée

Pierrot

Pierrot a écrit:

Dans le trajet Canton A - - -> Canton C, on crée pour le Canton 1 un contact virtuel à environ 1 ml de la fin de ce Canton que l’on paramètre ainsi :
-Condition : Canton 3 Occupé
-Opération : Stop et Bip Bip

C'est une solution.....mais qui ne marche pas, car RRTC arrête le train dès qu'il entre dans le canton 1, donc le contact virtuel ne sera jamais activé.


Bonne soirée

Bonjour marc_got

D’une manière ou d’une autre le train s’arrêtera vers la fin du canton et en douceur si le canton est paramétré à sa sortie avec ralentissement et arrêt (le dessin carré rouge et le carré blanc orientés à droit dans mon cas, et en indiquant la longueur du canton).
Le contact virtuel n’est pas obligatoire .Si le canton est très long, avec le contact virtuel tu diminue la distance de freinage. Un autre avantage c’est l’alarme sonore qui te signale qu’il y a un problème

Voici ci-dessous à titre d’exemple:
Le Canton 1 avec ses contacts (longueur du canton 500 cm)


Le paramétrage du contact virtuel situé à 400 cm


Bon week-end

Pierrot

Bonjour Pierrot,

J'ai fait des essais et je peux te dire que RRTC ne tient pas compte de ce qu'il y a de programmé dans l'indicateur d'arrêt et/ou de ralentissement.
S'il s'aperçoit que le canton suivant est occupé, il arrête le train le plus vite possible.

Par contre l'alarme sonore tu peux la programmer avec un contact virtuel, comme tu le suggères, ou avec une macro dans l'option de canton du canton précédent l'aiguille. Mais celà nécessite un petit peu de travail, surtout si tu as beaucoup d'aiguillages et de cantons.

Bonne soirée.

Bonjour,

olid a écrit:

Il me semble que c'est ce qu'on fait en cas d'urgence. Une aiguille qui ne commute pas est un cas "normalement" exceptionnel, et à cas exceptionnel, mesure exceptionnelle me semble-t-il ? Si on doit rajouter un élément pour contrôler l'aiguille, on va finir par en ajouter un autre pour contrôler le contrôleur de l'aiguille etc..

Je partage ce point de vue d'autant plus que rajouter un PL12 ou PL15 à un moteur Peco PL10 ne fait qu'amplifier le peu de fiabilité de ce moteur.
La qualité et conception mécanique relevent plus de la quincaillerie.
Il serait préférable de rechercher une solution sur les enchainements des bloks en mode " schedule "
Le logiciel devrait savoir identifier que les contacts indicateurs à parcourir ne sont pas ceux programmés dans le schedule.
Ensuite interdire l'éxécution du schedule avec une alarme et/ou message.
A ce moment l'operateur devra faire son travail de recherche de panne et de maintenance curative.
Bien entendu une maintenance préventive est toujours recommandée.

Comment ,pour le moment je ne sais pas.

Il doit bien y avoir des informaticiens parmi nous.
" wait ans see ".
Cordialement
René

Bonsoir à tous

je souhaite rebondir sur la proposition que nous fait René, aujourd'hui le schedule suit le train et attend que le contact du block suivant soit activé pour faire avancer le train à l'écran.
Lui expliquer la suite des contacts en plus des block me semble risqé. Que se passera t-il avec plusieur trains en circulation il peut trés y avoir des contacts activés par le train 2 et ne faisant pas parti du train 1 comment le schedule fera la différence?
L'autre solution peut être des flagmans intégrés dans le block aprés les aiguillages et arrétant le train si il a fait fausse route. Condition un contact physique doit être installé à l'entrée de chaque block aprés le ou les aiguillages ainsi si le mauvais contact du mauvais block est activé le train sera arrêté. Car un fois les aiguillages positionnés un seul block est accéssible donc si le train arrive dans ce dernier le flagman n'est pas activé et le train pas arrêté.

Peut -être es ce un début de solution.

Bon train
Pascal

Bonjour à tous,

Je suis ouvert à toutes solutions avec cependant une réserve à celles qui nécessiteraient un ajout de composants physiques ( le réseau étant déjà cablé ).
Pour faciliter le dialogue je vais mettre en ligne un TCO partiel.

A plus tard
René

Bonjour,

Avec un peu de retard ci joint le TCO partiel annoncé :



QQ explications :
- tous les trains arrivent par C66
- C64 C71 C72 sont des blocks de passage parametrés en block destination
- tous les blocks sont identifiés par au minimum un contact indicator ( board adress / input )
- le grill lui même comporte 2 indicateurs.

Supposons un schedule se terminant sur C72
Avec le logiciel dans sa version actuelle et un dysfonctionnement mécanique d'une aiguille
suivant le cas:
-le train percute le butoir
-le train dépasse le block et se trouve totalement hors controle logiciel
-dans tous les cas le train percute un autre train si le block est occupé,cette occupation n'est pas vue par le logiciel

Je suis surpris d'être un des rares utilisateurs à m'interroger à ce sujet.
Je ne sais pas résoudre le probleme,c'est pourquoi je laisse la parole aux spécialistes des conditions multiples et "flagmen".
Cordialement
René

RB 83 a écrit:

Je suis surpris d'être un des rares utilisateurs à m'interroger à ce sujet.

Bonjour,

C'est sûrement parce que les autres utilisateurs ont un fonctionnement fiable à 99,99% de leurs aiguillages

Marc

marc_got a écrit:

RB 83 a écrit:

Je suis surpris d'être un des rares utilisateurs à m'interroger à ce sujet.

Bonjour,

C'est sûrement parce que les autres utilisateurs ont un fonctionnement fiable à 99,99% de leurs aiguillages

Marc

Est-ce pour autant qu'il ne faille pas s'interesser au sujet et mettre au service de ce forum nos idées et compétences ?

René

Bien sûr que l'on doit essayer de faire progresser le système, dans la mesure des possibilités du concepteur, mais il ne faut pas perdre de vue la finalité de la chose, c'est un système ludique, fait pour piloter un réseau de trains miniatures.

Nous ne sommes pas à la SNCF!

Enfin c'est mon opinion et celà n'engage que moi.

Marc

marc_got a écrit:

Bien sûr que l'on doit essayer de faire progresser le système, dans la mesure des possibilités du concepteur, mais il ne faut pas perdre de vue la finalité de la chose, c'est un système ludique, fait pour piloter un réseau de trains miniatures.

Nous ne sommes pas à la SNCF!

Enfin c'est mon opinion et celà n'engage que moi.

Marc

Je respecte totalement votre opinion.
Faire progresser le système dans la mesure des possibilités du concepteur :
Je rappelerai que j'ai demandé à Jean_01 en sa qualité de betatester de ce logiciel ( et de surcroit parfaitement bilingue ) de prendre contact avec Jurgen.
Je n'ai pas eu de succès à ce jour mais je ne désespère pas car pour bien connaitre Jean, il est plein de bonne volonté.

Par ailleurs j'ai été gérant d'un magasin de modélisme.

Combien de clients m'ont rapporté des locomotives à qui cette protection aurait permis d'éviter un crash.
Des utilisateurs d'autres logiciels; seul DR savait par conception bloquer les convois.

Mon intervention était essentiellement technique et surtout je ne voudrais pas que cela engendre une polémique stérile.

Bon train à tous

René

Bonsoir

le systeme flagman fonctionne trés bien, seul condition ou il ne fonction pas est celle ou:

" un train est déja dans le block et il n'y a qu' un seul contact dans le block. "


Si c'est deux conditions sont réunies ça ne fonctionne pas, car pour stopper un train sur un mauvais itinéraire et éviter une collision par "flagman" il faut obligatoirement un chagement d'état d'un contact dans le block occupé.

Bon train à tous

Pascal

Bonjour Pascal,

Tu peux nous en dire plus sur le moyen de détection de l'erreur d'aiguillage.

Merci.

Marc