Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - Dralliam

Pages: [1] 2 3
1
Oui !
Merci Msport,
Merci Dominique,

Le comportement sous Manette n'est pas celui attendu mais j'ai des pistes pour avancer dans les recherches (DCC inspector) et/ou trouver des palliatifs.

Le projet LaBox me faisait rêver mais je vais attendre un peu avant de le construire, me former et essayer de fiabiliser le matériel que j'ai déjà. Ça risquerait d'être encore plus complexe avec LaBox...

Je ne manquerai pas de vous tenir informés sur ce fil

2
Je voyais une contradiction entre ces 2 affirmations [tronquées pour faciliter la compréhension,  mais je ne pense pas creer de contresens] :
[...] ce que vous décrivez est différent, et "normal" :
Oui, pour le DCC seule la dernière consigne concernant la dernière adresse sélectionnée est répétée

Comme expliqué dans l’article Réalisation de centrales DCC avec le logiciel libre DCC++ (1)
Citer
Il peut y avoir 12 registres dans un Uno [...].
[...] ces 12 registres (sauf le 0) sont répétés

Je n'y comprends plus rien et vais donc reprendre une nouvelle lecture attentive des articles  :o

Pour ce qui est des "micro coupures liées" à la voie qui est en place je crois que je n'arrive toujours pas à me faire comprendre :

- avec JMRI tout marche très bien (en tous cas je ne rencontre pas le problème décrit), j'ai juste les "hésitations" classiques du matériel moteur sur les cœurs isolés ou sur les zones "sales". Les locomotives ne calent pas si elles sont lancées à vitesse suffisante et d'ailleurs très raisonnable (un classique de l'analogique amateur que j'ai trop pratiqué dans ma jeunesse  ;) )

- avec la Manette ou l'Arduino IDE la locomotive destinataire de l'avant-derniere consigne cale et repart lorsque la consigne est rafraîchie (pressions successives sur "#" de la manette ou nouvelle consigne via l'Arduino IDE).
En pleine voie en général elles repart alors sans même une intervention physique de ma part. Et si elle était lancée suffisamment vite sur l'aiguille idem !
La locomotive à qui s'adressait la dernière consigne, elle, ne subit que les "hésitations" sans caler (sauf vitesse trop faible donc)

Et pourtant ce sont les mêmes locomotives, le même réseau, et la même station : exactement les mêmes conditions d'exploitation !
Sauf pour la partie consigne...

Le comportement étant différent entre une utilisation sous JMRI et sous Manette ou Arduino IDE, difficile de conclure que la voie est la seule cause de ce problème, non ?

Je vais essayer de tester sur de la voie Peco, mais je m'attends à des problèmes similaires sur les aiguilles insulfrog

3
Comme expliqué dans l’article Réalisation de centrales DCC avec le logiciel libre DCC++ (1)

Citer
Il peut y avoir 12 registres dans un Uno et probablement jusqu’à 50 dans un Mega. En tout cas c’est réglable dans la configuration (onglet Config.h).
Le registre N°0 est réservé pour les commandes à envoyer une seule fois (paquets Idle et Reset, commandes de programmation, commandes de fonctions, commandes d’accessoires). Les registres suivants N° 1 .. MAX_MAIN_REGISTERS sont réservés chacun à une machine sur le réseau.
[...]
Ces 12 registres (sauf le 0) sont répétés. Ce qui est contradictoire avec vos observations !

Merci pour ces précisions, en effet ça me semblait absurde
Mais me voila à nouveau perdu, moi qui pensais avoir identifié le problème !

Y a-t-il contradiction entre ce que vous rappelez et ce que je comprends de Msport ? (ce n'est pas pour vous monter l'un contre l'autre, c'est juste que je deviens fou  :P)

4
votre problème était l'arrêt de la première loco quand une deuxième loco reçoit un ordre ? Ce qui vous est spécifique.

Oui c'était bien ma compréhension du problème au départ (notamment car je ne soupçonnait pas ce que j'apprends sur la seule répétition de la dernière consigne), mais en cherchant beaucoup on a réussi à isoler et comprendre plus finement le problème
Pas facile entre l'inertie des machines, leur âge, et le soin apporté à la voie et les aiguillages (type insulfrog) !

Mais ce que vous décrivez est différent, et "normal" :
[...]
Oui, pour chaque régulateur de JMRI, la consigne de l’adresse correspondante est répétée

Ca signifie que mon installation a été consciencieusement réalisée, tant mieux

En revanche ceci m'inquiète :
Oui, pour le DCC seule la dernière consigne concernant la dernière adresse sélectionnée est répétée
Je pensais naïvement que les consignes de vitesse et de sens de circulation étaient répétées pour chaque décodeur (comme le fait JMRI)
Il est donc tout à fait logique que les coupures provoquées par la conductivité de la voie arrêtent les locomotives dont la consigne n'est pas répétée (avant-dernière et antérieures)
--> Est-ce propre à DCC++/DCCpp ? ou lié à la norme DCC ?
--> Comment les autres utilisateurs arrivent-ils à composer avec les aiguillages type Insulfrog ou avec les locomotives anciennes / mal entretenues dont la prise de courant est parfois aléatoire ?

Je devrais logiquement faire le même constat avec tous les montages de stations Locoduino qui n'utilisent pas JMRI
Même si mon réseau d'essai n'est vraiment pas très soigné, je n'arrive pas à croire que je sois le seul a souffrir de ce problème. En l'état je ne vois pas comment je peux exploiter un réseau avec le risque qu'une loco s'arrête n'importe où parce qu'une conductivité parfaite n'a pas été assurée (du moins dans mes standards d'utilisation de vieux rails Jouef...)

Je ne veux pas encore me résigner, il doit bien y avoir des solutions

ex. faire répéter les ordres à la manette
ou trouver un moyen qu'elle agisse "à la manière de JMRI"

5
votre problème était l'arrêt de la première loco quand une deuxième loco reçoit un ordre ? Ce qui vous est spécifique.

Oui c'était bien ma vision du problème au départ, mais en cherchant beaucoup on a réussi à isoler et comprendre plus finement le problème (pas facile entre l'inertie des machines, le soin apporté à la voie et les aiguillages !)

Mais ce que vous décrivez est différent, et "normal" :
[...]
Oui, pour chaque régulateur de JMRI, la consigne de l’adresse correspondante est répétée

Ca signifie que mon installation a été consciencieusement réalisée, tant mieux

En revanche ceci m'inquiète :
Oui, pour le DCC seule la dernière consigne concernant la dernière adresse sélectionnée est répétée
Je pensais naïvement que les consignes de vitesse et de sens de circulation éta

6
Oui je m'aperçois que je n'ai pas réussi à me faire comprendre ^^
Pas facile d'arriver à être clair, précis et concis

Je me permets de repartir d'un message précédent qui présente le protocole de test qui fait tourner 2 loco avec décodeurs en adresse 5 et en adresse 6 avec la Station et les consignes envoyées via la Manette ou via l'Arduino IDE (mêmes résultats)

Nouvelle description du problème (non pas que ça empire, mais que nous comprenons mieux ce qui se passe) :
En cas de coupure de courant d'alimentation sur la locomotive* qui est l'avant dernière à avoir reçu une consigne, elle s'arrête.
Illustration :
1- la locomotive adresse 5 reçoit une consigne --> OK [la consigne adresse 5 est appliquée]
2- la locomotive adresse 6 reçoit une consigne --> OK [la consigne adresse 6 est appliquée]
    la locomotive 5 poursuit sa route (OK)
3- micro coupure dans l'alimentation de la locomotive adresse 5 --> la locomotive adresse 5 s'arrête, ne reprend pas sa marche après le rétablissement de l'alimentation [la consigne adresse 5 n'est plus appliquée]

Je peux ajouter :
En parallèle la locomotive adresse 6 poursuit sa route normalement (normal, il ne lui est rien arrivé) [la consigne adresse 6 est toujours appliquée]
Et :
Si je lève les essieux de prise de courant (simulation rupture de conductivité de la voie) de la locomotive adresse 6 (la dernière à avoir reçu une consigne), la locomotive 6 poursuit sa route normalement après avoir retrouvé le courant [la consigne adresse 6 est toujours appliquée]

* Je parle d'une rupture dans l'alimentation du décodeur de la locomotive, tout à fait accidentelle, liée à la conductivité de la voie : rails "sales", ou aiguillage sans coeur alimenté.
Pour les besoins de l'expérience j'ai reproduit cette situation en levant un court instant les essieux de prise de courant, mais je n'ai pas touché à l'alimentation côté station

Dit encore autrement :
Lorsque l'avant-dernière locomotive à avoir reçu une consigne perd un court instant l'alimentation DCC, elle s'arrête et ne reprend pas sa route après avoir récupéré l'alimentation DCC.
Lorsque la dernière locomotive à avoir reçu une consigne perd un court instant l'alimentation DCC, elle reprend normalement sa route après avoir récupéré l'alimentation DCC.
--> Tout se passe comme si seule la dernière consigne concernant la dernière adresse sélectionnée était répétée
Et dans la pratique, avec la télécommande, le simple fait de faire défiler les locomotives en pressant sur "#" (rangs 1 à 4) envoie la consigne gardée en mémoire concernant le rang, et ma locomotive "avant dernière" s'arrête à la première rupture de conductivité

Mais ça ne se passe pas comme ça sous JMRI
La circulation n'est alors pas perturbée par les séquences successives de consignes sur le même anneau avec les mêmes défauts de conductivité de la voie
C'est à dire : la dernière comme l'avant-dernière locomotive conservent leur consigne, même après avoir (accidentellement) perdu un court instant l'alimentation DCC.
--> Tout se passe comme si les dernières consignes pour chaque adresse était répétées

Est-ce que cela vous semble plus clair ?

Je ne vous dit pas le nombre d'essais qu'on a dû réaliser pour arriver à cette analyse et l'attention nécessaire pour assurer les conditions reproductibles  :'(

7
Sniffer le plus abouti :
https://dcc-ex.com/ex-dccinspector/index.html
https://github.com/DCC-EX/DCCInspector-EX

Voir aussi :
https://forum.locoduino.org/index.php?topic=460.msg4650#msg4650

https://forum.locoduino.org/index.php?topic=244.15

Merci beaucoup, je vais regarder ça en parallèle des autres tests


Autrement, je me permets d'insister sur cette question assez fondamentale suite aux tests que vous avez eu la gentillesse de réaliser :
Je viens de tester avec ma BaseStation de référence (UNO + shield moteur = ma première centrale)et deux manettes style https://www.locoduino.org/spip.php?article286

Pas de coupure au changement de manette ou de locomotive sur une manette.
--> Avez-vous pu observer la réaction de "l'avant-dernière locomotive ayant reçu une consigne en cas de coupure de l'alimentation de celle-ci" ?

8
Citer
A priori, c'est DCC++ qui répète sans fin la dernière commande de locomotive (pas les fonctions - imaginons le sifflet)


Oui c'est obligatoire dans Communications Standards For Digital Command Control, All Scales
Adopted July 2004 S 9.2
:

C: Frequency Of Packet Transmission
Packets sent to Digital Decoders should be repeated as frequently as possible, as a packet may have been lost due to noise or poor electrical conductivity between wheels and rails.

Et c'est que fait bien DCCpp.

Tout cela est très intéressant, il semble qu'en dehors de l'utilisation "vanille" avec JMRI et sans manette ce ne soit pas ce qui se produit sur mon montage (seule la dernière consigne communiquée serait répétée vu que l'avant derniere locomotive, elle, ne semble plus avoir de consigne)

--> Est-ce qu'il existe un montage "mouchard DCC" capable de retranscrire en rétro engineering les communications qui transitent dans les rails telles que les décodeurs les reçoivent ?

Je pourrais ainsi comparer ce que JMRI fait envoyer comme informations par la station vs. ce qu'elle ne fait pas à partir des commandes envoyees par l'Arduino IDE ou par la manette

9
Je vous remercie sincèrement pour votre support et votre soutien, ce n'est pas sur tous les forums que la core team mouille la chemise comme vous le faites.
Il ne me reste plus beaucoup de cheveux mais je me sens moins seul !

Je viens de tester avec ma BaseStation de référence (UNO + shield moteur = ma première centrale)et deux manettes style https://www.locoduino.org/spip.php?article286

Pas de coupure au changement de manette ou de locomotive sur une manette.

--> Avez-vous pu observer la réaction de "l'avant-dernière locomotive ayant reçu une consigne en cas de coupure de l'alimentation de celle-ci" ?

Compte tenu de ce qui marche (JMRI seul parfaitement ou manette seule mais sans parcourir la liste des 4 adresses de loco embarquées) et de ce qui marche pas ou mal en l'état sur mon montage, je doute fort que ce soit un problème de connectique vu que ca ressemble plutôt a un probleme de répétition des commandes.
J'ai déjà réinitialisé plusieurs fois les décodeurs, malheureusement sans effet
Mais oui je vais essayer avec un autre montage de station même si les différences sont bien faibles entre les cartes de puissance.

J'ai aussi commandé une paire de décodeurs Lenz Standard+ V2. Il m'en fallait d'autres et ça changera des LaisDCC qui ne sont peut-être pas totalement innocents après tout.

10
Ce problème de l'arrêt "post micro coupure de l'avant dernière loco à avoir reçu une consigne" serait peut-être évité si mes locomotives étaient équipées de condensateurs "Stay alive", mais je n'ai pas les moyens de le vérifier.
Je m'étonne (et c'est tant mieux !) que ça ne se produise pas en utilisation avec JMRI et je m'interroge pourquoi.
Ca me permettrait peut-être de comprendre ce qui pourrait être modifié dans le programme de la manette par exemple.

JMRI répète-t-il les consignes ? Suivant quelles règles ?

11
Pour résumer :
Je cherche à utiliser le montage "Une station DCC complète, polyvalente et économique avec JMRI" avec au moins une télécommande "physique".
J'ai donc réalisé le montage "Ma première Manette DCC", à ce stade connectée en filaire.
L'utilisation / les fonctionnalités de JMRI sont, pour mon usage, pour l'instant, un bonus non nécessaire (c'est peut-être la faute originelle  :D ). J'ai au moins besoin de commandes physiques / non digitales

Note : j'ai bien noté qu'il sera préférable de passer au raccordement "sans fil" pour utiliser plusieurs télécommandes

A ce stade, en configuration "standard", c'est à dire Station connectée à JMRI en USB et sans manette : tout marche parfaitement !
(c'est déjà super et je suis vraiment reconnaissant envers toute l'équipe Locoduino de m'avoir permis cet "exploit")

Pour tous les autres cas d'utilisation que j'ai expérimentés, le fonctionnement n'est pas satisfaisant celui attendu :

A- Station commandée via Arduino IDE en USB à base de commande <t 1 X XX 1>
--> Problème de la loco ayant reçu l'avant dernière consigne qui rencontre une micro coupure d'alimentation (cf. posts précédents)

B- Station commandée par "Ma première Manette DCC" en filaire
--> Problème idem

C- Station commandée par "Ma première Manette DCC" en filaire ET connectée à JMRI en USB
--> Problème idem
--> également "Inhibation" de JMRI constatée


12
Ce qui est prévu c'est une connexion RX/TX du Nano de la manette vers le TX/RX du UNO de la centrale. Revoyez le schéma.

Oui c'est bien ce qui est réalisé en mode "raccordé au réseau de train".

Dans le cadre des essais conduits en prolongement vos conseils, le cas 1. Nano de la manette directement branchée à l'Arduino IDE en USB, sans la station a simplement servi à auditer la communication du Nano de la manette vers le Uno de la station, sans chercher à faire tourner les trains. Elle n'était aucunement raccordée à la Station.
Pour une utilisation en situation de commande, la manette est bien raccordée en TX/RX avec le UNO de la station

Cas 2. Manette branchée à la station, sans JMRI - Station connectée par USB à l'Arduino IDE
--> je précise manette raccordée à la station en TX/RX
L'intention est bien d'essayer de faire marcher le montage de "Une station DCC..." avec une manette, mais sans JMRI / sans ordinateur. Le branchement par USB de l'Arduino UNO de la station au moniteur série de l'Arduino IDE servait à voir ce que le Uno de la Station avait à dire

13
3. Manette branchée à la station, avec Moniteur DCC JMRI
Dans ce cas de figure, la manette empêche la commande des locomotives par les fenêtres "Régulateur" de JMRI. Cf. photo 3bis. : le statut passe à "Inconnu" lorsque la manette est branchée, mais revient à "On" à la première variation de consigne de la manette, sans pour autant que JMRI puisse contrôler les locomotives. Il n'y a pas de "rétro affichage" des consignes Manette dans les fenêtres "Régulateur" de JMRI (ex. JMRI ne reprend pas les valeurs de vitesse)

Il n'y a que la télécommande qui agit, je suppose que le contexte d'utilisation est donc le même qu'au 2.

Et d'ailleurs le problème constaté est le même : lorsque l'avant-dernière loco ayant reçu une consigne perd momentanément son alimentation, elle ne redémarre pas

On voit sur l'image du moniteur DCC de JMRI (resté fonctionnel néanmoins) que, comme avec l'Arduino IDE, on ne lit pas de mention d'adresse (je ne sais pas si c'est normal)

4. Station branchée à JMRI sans manette, commande par JMRI
Ca a l'air de marcher tout à fait normalement
En cas de "coupure d'alimentation" l'avant-dernière locomotive reprend sa marche normale

Sur le moniteur je note une activité TX et RX, l'adresse du décodeur de la locomotive étant rappelée en TX, c'est le seul cas de figure où cette adresse apparaît

Note : si sur la configuration 3. je débranche "à la barbarre" la manette, JMRI peut alors prendre le contrôle des locomotives à la volée

14
Audit des informations qui transitent
Les photos sont numérotées

1. Nano de la manette directement branchée à l'Arduino IDE en USB, sans la station
On peut voir les informations qui défilent à chaque pression sur "#" sur le clavier, pour les adresses 3, 4, 5 et 6 de décodeurs.
Exemple dernière ligne : Décodeur adresse 6, vitesse 21, sens 1

2. Manette branchée à la station, sans JMRI - Station connectée par USB à l'Arduino IDE
C'est le cas de figure réalisé à l'origine qui m'a fait constater le problème.
Je note (cf. photo) qu'en cas de changement de consigne, l'adresse du décodeur n'est pas rappelé (dans ce que l'Arduino UNO communique à l'Arduino IDDE)
En lecture directe de ces informations du moniteur série, on ne peut pas savoir à quel décodeur la consigne s'adresse
On voit une séquence de <T1 0 1> qui s'enchaînent, ceci correspond à la pression de la touche "#" sur le clavier de la manette.

Nouvelle description du problème (non pas que ça empire, mais que nous comprenons mieux ce qui se passe) :
En cas de coupure de courant d'alimentation sur la locomotive qui est l'avant dernière à avoir reçu une consigne, elle s'arrête.
Illustration :
1- la locomotive adresse 5 reçoit une consigne --> OK
2- la locomotive adresse 6 reçoit une consigne --> OK
    la locomotive 5 poursuit sa route (OK)
3- micro coupure dans l'alimentation de la locomotive adresse 5 --> la locomotive adresse 5 s'arrête, ne reprend pas sa marche après le rétablissement de l'alimentation

Note : cette micro coupure survenait accidentellement sur des rails "sales" ou en passant sur un aiguillage sans coeur alimenté. Pour les besoins de l'expérience cette situation était reproduite en levant les essieux de prise de courant

A suivre
3. Manette branchée à la station, avec Moniteur DCC JMRI
4. Station branchée à JMRI, commande par JMRI


15
Bonjour,

Voici des photos de l'installation, encore un peu à l'état brouillon, mais c'est parce qu'on passe pas mal de temps à débrancher / rebrancher pour bien tout tester consciencieusement.

Note : L'Arduino UNO de la station est sous un shield qui nous a permis de proprement centraliser les "prises" de raccordement avec la télécommande, le MAX471 (raccordé en Jaune et Blanc) et la carte de puissance

A suivre : les détails de la suite des tests

Pages: [1] 2 3