Montage digikeijs

[jc59]

Bonjour Arthur,

Bonjour, quel diamètre de fils doit on employé pour relier les modules ,j'hésite entre 0,22 mm,0,25 mm ou plus. Mrci

Concernant le choix des fils, il faut distinguer le diamètre en mm et la section en mm². C'est souvent flou sur les sites de vente ; certains parlent du diamètre extérieur de l'isolant (son épaisseur et sa nature sont certes importants pour la tension maximale supportée, mais c'est surtout la section du conducteur qui intéresse notre hobby)

Pour l'alimentation (Power) du DR4018, je préfère du 0,5 mm², car ce module peut assurer un courant total de 3 A.
Pour le signal DCC, 0,2 mm² suffit ; ceci convient aussi pour les signaux ou leds en général.
Pour les solénoïdes qui consomment plus, je mettrais du 0,3 mm² voire plus, pour éviter les chutes de tension, même s'il ne s'agit que d'impulsions courtes et non répétitives.

Jean-Claude

[PaulXpress]

Bonjour Nono,

A vous lire, j'ai l'impression que le but recherché est d'utiliser le moins d'adresses possible. En quoi est-ce un problème?

Je pense que le problème n'est pas les adresses, mais les sorties qui y sont associées et qui ne sont pas utilisées. Avec le DR4018, tu utilises la totalité des sorties puisque c'est toi qui les définies.

De mon point de vue, le critère recherché est la simplicité de commande, et donc d'utilisation en fonctionnement lorsque l'on établit les itinéraires en commande manuelle.
Je n'ai pas encore étudié cela, mais à terme, j'aimerai, en fonctionnement manuel, n'avoir qu'à commander la position des aiguilles et que la signalisation suive en conséquence.
Rêve-je ?

Avec RocRail la chose est tout à fait possible puisque tu peux créer des scripts xml, mais cela te demandera pas mal de programmation en fonction de la complexité des situations.

Jean-Paul

[BR212]

Avec RocRail la chose est tout à fait possible puisque tu peux créer des scripts xml, mais cela te demandera pas mal de programmation en fonction de la complexité des situations.

Je confirme, mais c'est gratifiant.

[Nonodudu76]

Avec RocRail la chose est tout à fait possible puisque tu peux créer des scripts xml, mais cela te demandera pas mal de programmation en fonction de la complexité des situations.

Je confirme, mais c'est gratifiant.

Je confirme,
Ca fait partie du modélisme moderne. Je m'y collerai dès que tout le réseau sera construit et opérationnel techniquement parlant (probablement à l'automne prochain, ou avant si ce temps de chien se prolonge tout l'été...)
J'aime voir les yeux écarquillés de mon petit fils de 7 ans qui adore faire rouler des locos sur les quelques mètres de voies en construction (de plus en plus longues), sans être conscient de tout le travail de l'ombre qu'il faut effectuer pour en arriver là.

[BR212]

Un conseil.
Si ta place te le permet fait toi un petit réseau de test avec juste un ou deux aiguillages à des fins de test et de maitrise pour le matériel de commande et surtout le logiciel.
Crois moi cela te fera gagner pas mal de temps pour la réalisation de ton réseau final car tu auras compris tout les subtilités(ou une grande majorité) de l'exploitation numérique.
A mes yeux le plus complexe étant la rétro signalisation pour que le réseau roule sans anicroche.

[PaulXpress]

A mes yeux le plus complexe étant la rétro signalisation pour que le réseau roule sans anicroche.

Tout à fait d'accord avec toi.
Surtout quand comme hier, alors que je cherchais à résoudre un problème de retard de détection de RocRail, la console remontait bien la détection mais Rocrail ne réagissait que beaucoup plus tard.
J'ai fini par me rendre compte que le problème venait d'un décodeur. Le coupable était RailCom, celui-ci n'arrêtait pas de discuter et saturait complètement Rocrail, le fait de désactiver RailCom sur ce décodeur a résolu le problème.
Je précise que les autres locos sont également RailCom et ne posent pas de problème.

Jean-Paul

Extrait du fichier trace :

rocview.000.pdf

(63.39 Kio) Téléchargé 112 fois

[CLEMENT]

Bonjour Nono,
Je crois que mon dernier message n'a pas été sur le Forum. j'en refait donc un nouveau.

Je confirme ce que Jean Paul a écrit. Avec le DR4018, on peut utiliser tous les interrupteurs physiques alors qu'avec le CDF certaines sorties peuvent être laissées de coté.
En outre avec certains logiciels le mappage automatique de signaux compliqués pose des fois des problèmes dans l'ordre d'extinction et d'allumage des leds, alors que l'ordre est choisi dans les actions pour programmer les leds.

La détermination des cibles des signaux en fonction des aiguillages se fait bien en amont de la programmation des signaux physiques sur le réseau.
Cette détermination est faite par les logiciels utilisés pour faire fonctionner le réseau.
Le plus souvent, il faut créer des itinéraires que les trains vont utiliser. Dans un itinéraire, on règle chaque aiguillage de l'itinéraire et les cibles des signaux sont automatiquement calculées en fonction des aiguillages et des cantons en aval occupés ou non par d'autres trains.
C'est donc en démarrant un train pour un itinéraire donné que tous se met en place.
Cette façon de procéder peut ne pas convenir à ceux qui souhaiteraient que les aiguillages et les feux soient fixés indépendamment des trains.
Alors avec certains logiciel (dont iTrain que j'utilise) on peut les faire grâce à des actions qui prennent en compte les aiguillages et l'occupation des canton en conditions et la cible des signaux en résultat.
Mais pour des faisceaux d'aiguillages important en sortie ou en entrée de gare, cela peut être assez compliqué.

Comme cela a été dit, il est important de se faire la main sur un petit réseau "laboratoire" avant de se lancer.

[Nonodudu76]

...C'est donc en démarrant un train pour un itinéraire donné que tous se met en place.
Cette façon de procéder peut ne pas convenir à ceux qui souhaiteraient que les aiguillages et les feux soient fixés indépendamment des trains...

Je suis complètement d'accord. C'est un peu comme "en vrai".
Il y a la commande qui consiste à envoyer la position choisie de chaque aiguille pour un itinéraire, puis l'établissement, qui confirme que toutes les commandes ont été exécutées, et que toutes les aiguilles sont effectivement dans la position commandée.
C'est donc l'établissement qui autorise l'ouverture du signal. Nul doute que le logiciel (Rocrail dans mon cas) saura gérer tout cela une fois correctement programmé.

Mon soucis va être de le faire fonctionner à l'inverse en manuel. Il me faudra commander la position des aiguilles, puis commander l'ouverture du signal. Il faudra alors que le logiciel sache quel aspect lui donner en fonction de la position cumulée des aiguilles, comme s'il avait établi lui-même l'itinéraire.
Comme je l'ai écrit hier, ce sera pour cet automne.

Je ne manquerai pas de solliciter de l'aide, notamment dans l'analyse initiale pour ne pas partir sur la mauvaise stratégie dès le départ. Après, ce sera des heures de programmation, avec autant de tests (sans parler des noms d'oiseaux qui accompagneront le tout ...

[PhilHO95]

...C'est donc en démarrant un train pour un itinéraire donné que tous se met en place.
Cette façon de procéder peut ne pas convenir à ceux qui souhaiteraient que les aiguillages et les feux soient fixés indépendamment des trains...

Je suis complètement d'accord. C'est un peu comme "en vrai".
Il y a la commande qui consiste à envoyer la position choisie de chaque aiguille pour un itinéraire, puis l'établissement, qui confirme que toutes les commandes ont été exécutées, et que toutes les aiguilles sont effectivement dans la position commandée.
C'est donc l'établissement qui autorise l'ouverture du signal. Nul doute que le logiciel (Rocrail dans mon cas) saura gérer tout cela une fois correctement programmé.

Mon soucis va être de le faire fonctionner à l'inverse en manuel. Il me faudra commander la position des aiguilles, puis commander l'ouverture du signal. Il faudra alors que le logiciel sache quel aspect lui donner en fonction de la position cumulée des aiguilles, comme s'il avait établi lui-même l'itinéraire.
Comme je l'ai écrit hier, ce sera pour cet automne.

Je ne manquerai pas de solliciter de l'aide, notamment dans l'analyse initiale pour ne pas partir sur la mauvaise stratégie dès le départ. Après, ce sera des heures de programmation, avec autant de tests (sans parler des noms d'oiseaux qui accompagneront le tout ...

Ben justement, les logiciels ont souvent leur propre logique qui est différente de la réalité.
Par ex, avec iTrain, même si l’itinéraire, au sens que la voie est faite, est OK, iTrain ne basculera pas les signaux au vert tant que l’itinéraire (logiciel celui du programme) n'est pas activé. De ce fait, les signaux ne sont jamais mis en place en mode manuel car en manuel on n'utilise pas les "itinéraires" du logiciel.

Mais la plupart des logiciel ont une version gratuite de test et un mode "simulation": je vous conseille de tester le logiciel que vous avez choisi en mode "simulation" avant d'investir dans vos décodeurs et module de retro.
Comme conseillé plus haut, le circuit de test est une étape indispensable pour se familiariser avec un logiciel.

[PhilHO95]

Bonjour Nono,

A vous lire, j'ai l'impression que le but recherché est d'utiliser le moins d'adresses possible. En quoi est-ce un problème?

Je pense que le problème n'est pas les adresses, mais les sorties qui y sont associées et qui ne sont pas utilisées. Avec le DR4018, tu utilises la totalité des sorties puisque c'est toi qui les définies.

De mon point de vue, le critère recherché est la simplicité de commande, et donc d'utilisation en fonctionnement lorsque l'on établit les itinéraires en commande manuelle.
Je n'ai pas encore étudié cela, mais à terme, j'aimerai, en fonctionnement manuel, n'avoir qu'à commander la position des aiguilles et que la signalisation suive en conséquence.
Rêve-je ?

Avec RocRail la chose est tout à fait possible puisque tu peux créer des scripts xml, mais cela te demandera pas mal de programmation en fonction de la complexité des situations.

Jean-Paul

Pour moi, le problème n'est ni la perte de sortie du décodeur, ni la quantité d'adresses utilisées mais plutôt la quantité de commandes DCC à envoyer, ce qui va généré du délai sur la mise en place des itinéraires, et la complexité à gérer des signaux SNCF avec les logiciels et ce en se rapprochant le plus de la réalité, et cerise sur le gâteau, une solution qui fonctionne en mode manuel. RRTC le fait mais est super cher, iTrain ne le fait pas simplement, il faut passer par des "actions": j'ai fait 2 signaux pour "tester", trop compliqué à mettre en place pour le réseau du club qui évolue tout le temps. En plus, iTrain (v4) ne prend pas les aiguillages dans les actions, il faut créer des relais fictifs, commandés par les mêmes adresses que les aiguillages, bref une usine à gaz !... et ROCRAIL j'ai pas compris comment ça marche.

De plus, il y a un gros défaut sur la DR5000: elle renvoie au minimum 4 fois les commandes d'accessoires, ce qui fait que cela génère un gros défaut d'aspect (clignotement) avec les décodeurs qui gèrent un allumage progressif des "ampoules" (fader).