Page 1 sur 3

Problèmes avec une centrale DCCpp

MessagePublié: 12 Janvier 2020, 23:00
par MathieuA
Bonjour,

Je poste ici les bugs rencontrés avec une centrale Arduino :)
Pour commencer il semble que certains clones chinois utilisant des drivers différents ne soient pas pris en charge par CDM-Rail. Ce qui oblige à ne pas acheter n’importe quelle carte… Il semblerait cependant que les clones de la marque « Elegoo » soit fonctionnels. On obtient toujours les messages "CAANNOT WRITE s COMMAND" au démarrage mais cela ne semble pas poser de problème ensuite pour la connexion.
Les autres bugs concernent surtout le mode run, en mode configuration des aiguillages ou de la rétrosignalisation il ne semble pas avoir mais si on tente de lancer la calibration d’un train CDM-Rail se coupe sans prévenir. Pendant le mode run classique en faisant tourner un train le retour d’informations semble être instable, certains messages ne remontent comme si la connexion est saturée ou tout simplement coupée. Il arrive aussi que CDM-Rail se coupe sans prévenir.

Parfois CDM-Rail envoi une quantité astronomique de commandes à la centrale sans qu’on ne lui demande rien ce qui finit par saturer la centrale et pose problème. La centrale DCCpp possède un mode debug que CDM-Rail n’apprécie pas du tout, la floper de message que la centrale envoie pour debuger un éventuel problème fait se fermer CDM-Rail dès la connexion sans rien pourvoir essayer.

Voilà j’espère pouvoir aider à résoudre ces problèmes. Si d’autres modélistes passant par-là ont constatés les mêmes problèmes qu’ils n’hésitent pas à laisser un petit message. Cela permettra de savoir si je suis un cas isolé et sinon trouver des personnes prêtes à faire le cobaye. :D

:thanku:

Re: Problèmes avec une centrale DCCpp

MessagePublié: 14 Janvier 2020, 12:14
par jpp38
Bonjour Mathieu,

Tout d'abord, je précise que la gestion de chaque type de centrale est assurée non pas pas le programme principal, mais par des DLL spécifiques. Il y a une DLL par type d'interface, et toutes ces DLLs sont situées dans le sous-répertoire CDM_DGI du répertoire d'installation de CDM-Rail.

La DLL qui gère dcc++ s'appelle DDGI_7DCCpp.DLL.

Les problèmes que tu mentionnes indiquent clairement un dysfonctionnement au niveau de cette DLL, car on ne les rencontre pas sur les autres interfaces.

Mais il faut préciser que le gars avec qui j'avais avancé sur cette DLL a laissé tomber avant qu'elle soit complètement mises au point. Cette DLL n'a dons jamais été complètement validée.

Je confirme ce que tu dis à propose des clones. A chaque nouveau clone, il faut refaire l'adaptation de l'interface. L'interface actuelle a été adaptée sur l'Arduino de base, et un clone particulier, mais il est clair que c'est à revalider et éventuellement modifier pour chaque nouveau clone.

C'est pour cette raison que j'étais sur le point de retirer cette interface de la liste supportée par CDM-Rail, car je considère qu'elle est impossible à maintenir.
Personnellement, je n'ai pas le temps de la valider sur la base d'un vrai réseau. Ce qui complique aussi beaucoup les choses, c'est que chaque développeur sur Arduino a tendance à réinventer la roue sur ses propres idées, et on a donc à traiter non pas une centrale Arduino, mais N centrales Arduino.

Donc, si tu te sens le courage d'entrer dans le code de cette DLL, c'est plus que bienvenu. Ca évite d'entrer dans le programme principal, et c'est donc beaucoup plus limité. Par contre, le code des DLLs est quand même bien tordu.

JP

Re: Problèmes avec une centrale DCCpp

MessagePublié: 15 Janvier 2020, 08:29
par MathieuA
Bonjour JP,

J'ai commencé avant-hier à fouiller un peu et m'imprégner de ce qui a été fait dans CDM-Rail. J'avais déjà repéré la DLL qui gère le DCC et j'ai pu la compiler assez simplement.
J'ai commencé par enlever le message "CANNOT WRITE s COMMAND" qui est plus que gênant et qui n'est pas très utile... Concernant les clones non supportés j'ai vu passer le contrôle RTS qui explique pourquoi certains clones ne fonctionnent pas. La raison est relativement simple seul le driver U2 (le driver des Arduino officiels) prend en charge cette fonctionnalité. Je me pose encore la question de l'utilité ici mais je finirais par trouver et savoir si c'est réellement utile ou non.
J'ai aussi fait quelques modifications que je n'ai pas encore testé correctement mais je continuerais à poster ici au fur et à mesure de mes avancés. :)

Effectivement chacun fait sa tambouille de son côté pour les centrales Arduino, mais il faut faire un choix... CDM-Rail supporte les centrales Arduino oui mais il ne va pas s'adapter à chacun c'est impossible. Le mieux est simplement de préciser dans la doc que seul les centrales Arduino basées sur le code DCCpp sont supportés.

J'ai en revanche une petite question concernant la DLL, j'ai remarqué que les sources ne sont pas à jour. Actuellement les sources disponibles sont basées sur la version V6.01 st-ce possible d'avoir la dernière version en date pour ne pas partir sur de mauvaises basses ?

Mathieu :respect1:

Re: Problèmes avec une centrale DCCpp

MessagePublié: 15 Janvier 2020, 09:37
par jpp38
Bonjour Mathieu,

Voici la dernière version de cette DLL (qui est encore une version provisoire).

DDGI_DCCpp.zip
(103.98 Kio) Téléchargé 156 fois


Pour ce qui est de la mise au point, il faut éviter de lancer trop tôt le mode RUN complet.
Il faut savoir que cette DLL est le résultat de la combinaison
- d'une part de la recommandation DCC++ à peu près généralement utilisée par tous les arduinistes,
- d'autre part de l'implémentation complètement spécifique de la gestion S88 fait par Xavier, de ce forum.

Autant la 1ere partie est quasiment standardisée de façon satisfaisante, autant la seconde ne l'est pas. Il y a 36 implémentations de la rétrosignalisation S88, et il n'y a aucun standard sur les commandes de rétro.

Les étapes à suivre pour la mise en route d'un réseau sont résumées dans la liste suivante.
http://cdmrail.free.fr/SiteCDR/First_St ... _Steps.htm

Il faut décorreler ce qui utilise la rétro, de ce qui ne l'utilise pas.


Il faudrait donc faire les étapes 1,2,3 et 5 , sans aucuns détecteurs sur le .lay (au fait, j'aimerais bien que tu mettes le .lay pour que j'y jette un œil).

Le fonctionnement en RUN TCO, sans détecteurs, en envoyant des commandes de vitesse à la loco ou aux locos sur le réseau, pilotées à vue, ainsi que des commandes d'aiguillages), devrait fonctionner. Ca ne met en œuvre que la première partie (DCC++ standard). Il faut déjà s'assurer du bon fonctionnement de cette partie, avant de passer au reste.


Si ça fonctionne, il faut ensuite (avant l'étalonnage de vitesse des trains):

- Configurer les détecteurs dans le .lay,

- Exécuter le test des détecteurs (test configuration),

- exécuter le RUN TCO avec rétrosignalisation: on doit voir les zones de détection s'allumer au passage des locos.


On se synchronise déjà là-dessus avant de passer au reste.

Mais si vous avez déjà mis en place la rétrosignalisation S88, où avez-vous trouvé les infos pour le faire, vu que c'est complètement spécifique à la solution de Xavier?


JP

Re: Problèmes avec une centrale DCCpp

MessagePublié: 01 Mars 2020, 17:33
par MathieuA
Bonjour tout le monde !

Pour commencer je m’excuse du manque de nouvelles depuis le mois dernier, les semaines ont été assez mouvementées et je n’ai pas eu beaucoup de temps…

Merci JP pour la dernière version de la DLL ! Comme j’ai eu plus de temps ces deux dernières semaines je me suis plongé pleinement dedans !

Pour commencer j’ai parcouru les 7000 et quelques lignes de la DLL… et je me suis rendu compte que le code manquait cruellement de mise en forme et qu’il y avait beaucoup de « petites » choses qui pouvaient poser de gros problèmes. J’ai donc commencé par reformater tout le code (ça a pris du temps) et corriger toutes les petites choses que j’ai vues (des switch case sans default, des bloc if else sans accolades ou encore des chaînages de if elseif sans else…).
Après ça la DLL est devenue bien plus stable, j’ai dû avoir un seul plantage du soft en deux semaines… autant dire quasiment aucun. J’ai aussi résolu le problème des messages infini, enfin de compte la DLL faisait un peu n’importe quoi ! Et fais pas mal de petites choses en plus. ;)

Donc en résumé actuellement
- La DLL est relativement stable, les plantages ont quasiment disparu.
- La DLL supporte le mode debug de la centrale (ce qui est très utile !).
- La commande des trains fonctionne très bien.
- La commande des aiguillages fonctionne bien elle aussi.
- La rétro-signalisation fonctionne plutôt bien malgré un ou deux faux positif que j’ai constaté sur deux jours de tests (ce qui est assez négligeable, mais je pense savoir comment résoudre ce problème)
- Et comme nous avions le temps non avons tenté l’étalonnage d’un train et après une heure d’étalonnage, ce fut une réussite !

La seule chose que nous n’avons pas pris le temps de tester est la lecture/écriture des CVs, c’est donc le sujet de test du weekend prochain.
A ce stade je pense que les étapes 1 à 5 sont validées (malgré le manque de test sur les CVs).

Pour en revenir à la rétro-signalisation, mon oncle et moi utilisons l’implémentation de Xavier dans la centrale DCCpp (disponible sur le site de Philippe a cette adresse), à vrais dire je crois que c’est la seule implémentation que nous avons trouvé assez stable et poussé. Et elle fonctionne très bien alors pourquoi vouloir réinventer la roue. :D
N’ayant pas de réseau, j’effectue les tests sur le réseau de mon oncle (qui se reconnaîtra en passant par-là) dont voici le dessin avec toute la configuration des aiguillages, des detecteurs etc
Re_Mario_8.2.2020.lay
(343.23 Kio) Téléchargé 147 fois


Hier en mode run une bonne partie de l’après-midi nous n’avons constaté aucun problème, la loco virtuelle était très synchro avec la réelle, les commandes de vitesse ainsi que le retour d’info de la rétro-signalisation ont fonctionné sans problème. Nous attendons maintenant les décodeurs d’aiguillage que nous faisons fabriquer par JLC PCB car ceux actuellement installé ne fonctionnent plus correctement et après ça nous entamerons des tests de pilotage automatique avec plusieurs loco sur le réseau !

En attendant j’ai repéré deux points d’améliorations de la DLL à savoir le scan des ports com qui mérite d’être optimisé (le travail avait déjà été commencé en plus) ainsi que le mode RTS pour les clones chinois. C’est donc les points sur lesquels je vais me pencher cette semaine en attendant de pouvoir faire les prochains tests (CV et pilotage automatique) sur le réseau de mon oncle. Ce qui rendrais CDM-Rail compatible avec les clones chinois et aussi bien plus rapide pour la connexion à la centrale.

Pour ceux qui passent par ici et qui souhaitent faire quelques tests voici la DLL testée ce weekend avec toutes les améliorations citées dans ce messages, vos retour (bon ou mauvais) seront les bienvenue !
DDGI_7DCCpp.dll
(78.14 Kio) Téléchargé 151 fois


Mathieu :respect1:

Re: Problèmes avec une centrale DCCpp

MessagePublié: 02 Mars 2020, 13:38
par SUPERN
Salut,
Quel bon travail ! Merci pour ce partage.
Je suis sur un autre projet analogique pour le moment, mais je planifie de prendre la solution DCCpp avec S88 pour les réseaux club.
Donc si tu peux voir avec Xavier pour mettre à jour la DLL ça me faciliterai bien la tâche...
À bientôt
Bien amicalement
Yves

Re: Problèmes avec une centrale DCCpp

MessagePublié: 06 Mars 2020, 16:42
par jpp38
Bonjour Mathieu,

Merci pour ce retour. Et bravo pour ce travail. :bravo2: :bravo2: :bravo2:
Ca me fait carrément plaisir que tu aies réussi à valider cette DLL, que j'étais sur le point de de ne plus joindre à la distribution du logiciel.
Et qu'en plus tu sois arrivé à entrer dans la DLL, et à l'améliorer, ça c'est la cerise sur le gâteau.


Quand tu auras l'impression d'avoir à peu près convergé, tu me renverras tes sources de la DLL, pour que je les intègre à mes sources.

Encore merci.

Re: Problèmes avec une centrale DCCpp

MessagePublié: 19 Mai 2020, 14:32
par MathieuA
Bonjour JP,

Toutes mes excuses pour le temps de réaction !

J'ai travaillé un peu sur la DLL et à priori la connections avec les clones chinois semble établie, elle parait un peu longue mais fonctionne et est relativement stable d'après les tests que j'ai pu faire sur le réseau de mon oncle.
Le scan des ports com est lui aussi fonctionnel, je pense donc avoir une bonne version a proposé à la communauté dès à présent :D

Je vous joins les sources afin de les intégrer à CDM-Rail.

J'ai cependant deux questions sur lesquelles j'ai passé un peu de temps sans trouver de réponse:

- La centrale DCCpp possède un mode d'arrêt d'urgence cependant je n'ai trouvé aucun moyen de remonter l'info à CDM-Rail. Du coup quand la centrale détecte un court-circuit elle stop les messages arrivant sur la connexion série et envoi un power of. Mais malheureusement je n'ai pas trouvé comment remonter cette info au-delà de la DLL ce qui implique pas mal de problèmes. En effet quand la centrale ne détecte plus de court-circuit et se relance elle continu de recevoir les ordres de vitesse de CDM-Rail et relance immédiatement toutes les locos. Ce qui nous a fait quelques frayeurs :oops: Y a-t-il un moyen de remédier à ça au travers de la DLL ?

- La seconde est un peu plus générale: Lors de la mise en route du réseau ils nous arrivent de ne placer qu'un seul train, virtuellement parlant, alors qu'en réalité il y en a plusieurs sur le réseau. Tous les trains sont bel et bien détectés par la centrale et l'info remonte bien jusqu'à CDM-Rail. Cependant si on ne place pas de train virtuel aux endroits détecté physiquement par la centrale CDM-Rail ne prend pas en compte ces détections pour le pilotage. Il affiche bel et bien la détection (le voie change de couleur) mais il ne se prive pas de lancer un train en direction du dit canton. Est-ce normal ?

Mathieu :respect1:

Re: Problèmes avec une centrale DCCpp

MessagePublié: 19 Mai 2020, 17:35
par jpp38
MathieuA a écrit:Bonjour JP,

Toutes mes excuses pour le temps de réaction !

J'ai travaillé un peu sur la DLL et à priori la connections avec les clones chinois semble établie, elle parait un peu longue mais fonctionne et est relativement stable d'après les tests que j'ai pu faire sur le réseau de mon oncle.
Le scan des ports com est lui aussi fonctionnel, je pense donc avoir une bonne version a proposé à la communauté dès à présent :D

Je vous joins les sources afin de les intégrer à CDM-Rail.


OK. Merci Mathieu. Je vais l'intégrer dans une prochaine version, après avoir documenté les modifs.

MathieuA a écrit:J'ai cependant deux questions sur lesquelles j'ai passé un peu de temps sans trouver de réponse:

- La centrale DCCpp possède un mode d'arrêt d'urgence cependant je n'ai trouvé aucun moyen de remonter l'info à CDM-Rail. Du coup quand la centrale détecte un court-circuit elle stop les messages arrivant sur la connexion série et envoi un power of. Mais malheureusement je n'ai pas trouvé comment remonter cette info au-delà de la DLL ce qui implique pas mal de problèmes. En effet quand la centrale ne détecte plus de court-circuit et se relance elle continu de recevoir les ordres de vitesse de CDM-Rail et relance immédiatement toutes les locos. Ce qui nous a fait quelques frayeurs :oops: Y a-t-il un moyen de remédier à ça au travers de la DLL ?


C'est une grosse faille au niveau du protocole DCCpp. Il est très dommageable qu'ils n'aient pas prévu un "broadcast" pour remonter ces évènements à la centrale. C'est une des premières choses que j'avais remarqué quand j'avais fait les premiers jets de cette interface.
Donc,
- soit il existe (maintenant , ou même avant si je l'avais pas vu) un tel message de broadcast dans le protocole, et il sera facile de l'intégrer.
- soit ce n'est pas simple. Il faut faire périodiquement (1 fois par seconde?) un "polling" de l'état de la centrale depuis la DLL, et créer un pseudo- broadcast qui remonte le STOP ou POWER OFF à la centrale. C'est faisable, mais ça va être plus compliqué que ce que tu as fait jusqu'ici.

Mais en effet, en l'absence de ce genre d'infos, les trains redémarreront à leur vitesse antérieure après un cour-circuit. C'est normal vu le fonctionnement de CDM-Rail. Il lui FAUT ce broadcast de Power Off.

Mathieu a écrit:- La seconde est un peu plus générale: Lors de la mise en route du réseau ils nous arrivent de ne placer qu'un seul train, virtuellement parlant, alors qu'en réalité il y en a plusieurs sur le réseau. Tous les trains sont bel et bien détectés par la centrale et l'info remonte bien jusqu'à CDM-Rail. Cependant si on ne place pas de train virtuel aux endroits détecté physiquement par la centrale CDM-Rail ne prend pas en compte ces détections pour le pilotage. Il affiche bel et bien la détection (le voie change de couleur) mais il ne se prive pas de lancer un train en direction du dit canton. Est-ce normal ?

Mathieu :respect1:


Oui, c'est normal. CDM-Rail ne gère pas les occupations de cantons des trains non placés sur le réseau.

JP

Re: Problèmes avec une centrale DCCpp

MessagePublié: 21 Mai 2020, 15:50
par Lormedy
Bonjour,

Lorsque DCCpp ou DCCpp_S88 active le DCC sur les Boosters et donc met l'alimentation DCC sur les rails, cela passe par l'envoi la commande <1> via l'USB ou Ethernet depuis le PC.
La centrale DCC renvoie <p1> vers le PC.
Pour arrêter l'alimentation DCC sur les rails, le PCenvoi la commande <0>.
La centrale DCC renvoie <p0> vers le PC.
Tout ceci peut se lire sur le moniteur de l'IDE Arduino.

Lors d'un court-circuit sur les voies principales (Main), la centrale DCC renvoie <p2> vers le PC.
Lors d'un court-circuit sur la voie de programmation (Prog), la centrale DCC renvoie <p3> vers le PC.
Quand on utilise le bouton "Emmergency Stop", DCCpp renvoi <p2> vers le PC. Ca semble logique car le risque de court-circuit est maximum sur les voies principales.
Ces informations en retour devraient être reprises par CDM-Rail pour savoir quand le réseau est effectivement sous tension.

Après un échange avec Thierry Paris en mai/juin 2019, il a modifié la routine qui lit le courant pour séparer la mise hors tension de la voie principale et de la voie de programmation en cas de court-circuit sur l'une ou l'autre.
C'est un bon début vers l'utilisation de plusieurs secteurs (district) alimentés par des plusieurs boosters commandés individuellement pour ne couper que la zone en court-circuit.
J'imagine facilement de prévoir l’utilisation de <p4>, <p5>, <p6>, etc, pour que la centrale DCC indique au PC une coupure d’alimentation DCC sur un secteur précis. Sa réalimentation passera par la commande <1> issue du PC.
Je n'ai pas eu encore le temps de m'en occuper car je suis occupé avec d'autres développements. Je mettrai à jour DCCpp_S88 dans quelques temps, par manque de temps disponible...

Mathieu a fait un bon travail que j'ai encouragé mais il ne peut pas tout savoir de ces montagnes de soft, tout comme nous autres.
En associant nos compétences et nos savoirs, nous arriverons à résoudre ces petits problèmes de compatibilité qui ne sont dus qu'au manque d'information.

Ferroviairement,

Philippe