Problèmes avec une centrale DCCpp

Re: Problèmes avec une centrale DCCpp

Messagepar jpp38 » 21 Mai 2020, 17:39

Bonjour Philippe,

Merci pour ce retour.

Je vais revenir sur la DLL nettoyée par Mathieu, et voir comment faire pour faire remonter l'évènement "POWER OFF" sur réception de <p2>, parce que ça, c'est clairement indispensable.
En pratique, sur un POWER OFF, CDM-Rail fait un arrêt complet de tous les trains, et il faut les redémarrer explicitement (il y a un bouton pour ça) après avoir fait le "resume operations".

Par contre, je ne comprends pas bien ce que tu veux dire quand tu parles de bouton "emergency stop". Il est à quel niveau ce bouton? Sur la centrale?
En pratique, si je fais cette modif, ça veut dire que côté CDM-Rail, ça se comportera comme un POWER OFF, avec l'inconvénient ci-dessus, à savoir qu'il faudra demander le redémarrage de tous les trains. Il me semble comprendre, d'après ce que tu dis, que c'est acceptable?

JP
jpp38
 
Messages: 11187
Inscrit le: 31 Mars 2009, 10:15
Localisation: Grenoble (Isère / Rhône Alpes)

Re: Problèmes avec une centrale DCCpp

Messagepar Lormedy » 23 Mai 2020, 13:15

Bonjour,

Dans DCCpp il est prévu de pouvoir connecter un bouton Emergency Stop entre une entrée de la centrale Arduino et la masse.
Si on appuie sur ce bouton ou si un court-circuit est détecté par la centrale, l'effet est le même : l'Arduino bloque les Boosters DCC pour éviter la surchauffe.
En même temps l'Arduino envoie vers le PC un feedback <p2> pour lui signifier que le réseau DCC (Main) est hors tension.
Ceci a le même effet que si le Soft du PC lui envoie la commande d’arrêt général <0> sauf que le PC ne le sait pas s'il ne surveille pas les feedbacks de la centrale.

Le soft sur le PC doit lire les feedbacks de la centrale Arduino DCCpp pour identifier les <p?> avec ? = 0..n.
<p1> est le seul feedback actuel de la centrale qui indique que le réseau DCC est sous tension, voies principales et voie de programmation.
Tous les autres feedbacks qui commencent par "<p" indiquent que le réseau DCC a été placé hors tension par la centrale DCC.
Particulièrement, <p3> indique que la voie de programmation a été mise hors tension. Il faut en tenir compte pour ne pas bloquer inutilement le réseau principal.

Par sécurité, il semble logique que les trains qui ont été arrêtés brutalement ne repartent pas dès la remise sous tension DCC.
Il est nécessaire de les relancer un par un en tenant compte de l'occupation des cantons qui les précèdent pour éviter des collisions.

C'est un peu tordu comme fonctionnement mais il a été conçu ainsi et on essaye de s'en accommoder.
Cependant je vais suggérer à Thierry Paris de modifier son feedback <p3> en <p4>.
Ceci aurait l'avantage de considérer tous les feedbacks qui commencent par <p suivi_d'un_nombre_pair> comme des indications d’arrêt du DCC.
Tous les feedbacks qui commencent par <p suivi_d'un_nombre_impair> seraient des indications de mise sous tension du DCC sur leur secteur de voies concernées.
Cela ouvrira la porte à la gestion future des différents secteurs qui composent un réseau, comme à la SNCF.
Cette gestion sectorisée est déjà utilisée par les modélistes américains et je compte l'utiliser aussi.

En résumé :
Seule la commande <0> avec son feedback <p0> concernerait un arrêt général du DCC sur tout le réseau à la demande du PC.
Le feedback <p2> indiquerait que la centrale a décidé de mettre le réseau principal hors tension.
Le feedback <p4> indiquerait que la centrale a décidé de mettre la voie de programmation hors tension.
Et ainsi de suite avec les secteurs suivants.

De même la commande <1> avec son feedback <p1> concernerait une mise sous tension générale du DCC sur tout le réseau à la demande du PC.
Les feedbacks <p suivi_d'un_nombre_impair> indiqueraient que le PC a demandé de mettre sous tension individuellement les secteurs de voies concernées du réseau.

Dans un premier temps, CDM-rail devrait surveiller les feedbacks <p0>, <p2> et peut-être <p4>.
Cela gardera une porte ouverte vers des développements ultérieurs.

Regardons vers l'avenir.

Ferroviairement,
Philippe
Réseau DCC 2 voies H0
PC + TCO WiFi + WDD + DMC + Arduino Mega + L298+ Max 471 + D1-Mini WiFi
Détecteurs de train perso + S88-N perso + MAM perso + Décodeurs d'accesoires DCC perso
http://lormedy.free.fr
Lormedy
 
Messages: 11
Inscrit le: 09 Mai 2019, 05:31
Localisation: Grésivaudan

Re: Problèmes avec une centrale DCCpp

Messagepar jpp38 » 24 Mai 2020, 06:26

Bonjour Philippe.

OK. Merci pour ces précisions.

Bonne journée.

JP
jpp38
 
Messages: 11187
Inscrit le: 31 Mars 2009, 10:15
Localisation: Grenoble (Isère / Rhône Alpes)

Re: Problèmes avec une centrale DCCpp

Messagepar MathieuA » 25 Mai 2020, 18:00

Bonjour tout le monde !

Philippe a apporté toutes les explications nécessaire au problème de court circuit. Il n'y a plus qu'a !

En revanche pour ma seconde question:

jpp38 a écrit:
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 ?


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



Est-ce voulu ? Ou est-ce un développement mis en attente ?

Mathieu :respect1:
MathieuA
 
Messages: 57
Inscrit le: 12 Janvier 2020, 16:34
Localisation: Orléans, Loiret

Re: Problèmes avec une centrale DCCpp

Messagepar MathieuA » 11 Juin 2020, 09:31

Bonjour,

Je vois que les développements vont bon train par ici ce qui est motivant ! :D

Je travaille actuellement sur un autre projet pour CDM-Rail mais je réfléchis en parallèle au problème d'arrêt d'urgence.
L'arrêt d'urgence cache en vérité plusieurs cas qui peuvent poser problème;

  • Le premier est dans le cas ou l'arrêt d'urgence est déclenché par CDM-Rail, la centrale arrête tout et tout semble aller pour le mieux dans ce cas de figure.
  • Le second dans le cas ou l'arrêt d'urgence est déclenché par la centrale, là le message est remonté à CDM-Rail mais il ne le prend pas en compte (du moins pour le moment). Je n'ai pas encore consacré de temps à ce point.

  • Le troisième qui me pose un peu plus problème se produit dans le cas où CDM-Rail plante sans prévenir. Il faut que la centrale puisse s'en rendre compte et arrêter tout en une fraction de seconde.
    Deux possibilités s'offre alors pour détecter ces éventuelles pannes du logiciel:
    • Mettre en place un Ping récurrent auquel CDM-Rail devra répondre (et s'il ne répond plus la centrale déclenche l'arrêt d'urgence).
    • Ou alors simplement détecter la perte de messages soudains venant du logiciel.
Je ne sais pas encore quelle méthode adoptée et quelle méthode seraient la plus fiable, toute suggestion est la bienvenue :)

J'en profite pour réitérée ma question au cas où elle serait passée inaperçu :lol:

jpp38 a écrit: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 ?


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


Est-ce voulu ? Ou est-ce un développement mis en attente ?

Mathieu :respect1:
MathieuA
 
Messages: 57
Inscrit le: 12 Janvier 2020, 16:34
Localisation: Orléans, Loiret

Re: Problèmes avec une centrale DCCpp

Messagepar MathieuA » 01 Juillet 2020, 10:03

Bonjour à tous,

Je viens aux nouvelles !

J'ai réussi à remonter l'info d'arrêt d'urgence jusqu’à CDM-Rail, un problème de plus résolu donc :)
Je joins les sources pour Jpp.

J'en profite pour demande un peu aidée. Il y a de ça une semaine mon oncle a modifié un peu son réseau et a ajouté un certain nombre de capteurs.
Le nombre de ses capteurs est passé à 160 et nous nous sommes rendu compte que la DLL Arduino ne prend en compte que les 128 premiers capteurs (alors que la centrale peut en gérer jusqu'à 512) et les données suivantes semble passer à la trappe....

J'ai donc tout simplement augmenté les variables globales en pensant que ça suffirait et que le concepteur du code avait pensé a cette éventualité, mais apparemment ça ne suffit pas.
Je bute donc sur ce sujet depuis plusieurs jours sans savoir où est la cause du problème...

De l'aide de la part de quelqu'un qui a mis le nez dans les DLL sera grandement apprécié

Mathieu :respect1:
Pièces jointes
DDGI_DCCpp.zip
(50.76 Kio) Téléchargé 106 fois
MathieuA
 
Messages: 57
Inscrit le: 12 Janvier 2020, 16:34
Localisation: Orléans, Loiret

Re: Problèmes avec une centrale DCCpp

Messagepar jpp38 » 03 Juillet 2020, 19:25

Mathieu a écrit:A"
J'ai donc tout simplement augmenté les variables globales en pensant que ça suffirait et que le concepteur du code avait pensé a cette éventualité, mais apparemment ça ne suffit pas.


Quand tu poses une question de ce type, essaye d'être plus précis.
Quelles variables globales as-tu essayé de modifier?
Je suppose, si tu poses la question, que tu as déjà essayé de modifier MAX_NB_DETECTORS? Je le vois toujours à 128 dans le code que tu viens de mettre sur ce fil.

Ensuite, il faut vérifier dans DCPS_ExtractS88State() que nNbDetectors a bien la valeur spécifiée dans le fenêtre de paramétrage d'entrée (debugger ou MessageBox).

Après, je ne sais pas comment tu as fait évoluer le protocole de Xavier (toi ou d'autres). Il n'avait été question que de 128 états, et donc d'une chaine de 32 caractères hexa.
Si on va au-delà, est-ce que l'extension du protocole de départ prévoit d'allonger la chaîne de caractères hexa au-delà de 32, ou est-ce qu'une autre méthode a été prévue? Rappelle-toi que je ne suis pas dans la boucle là-dessus.

JP
jpp38
 
Messages: 11187
Inscrit le: 31 Mars 2009, 10:15
Localisation: Grenoble (Isère / Rhône Alpes)

Re: Problèmes avec une centrale DCCpp

Messagepar MathieuA » 04 Juillet 2020, 18:45

Bonjour Jpp,

Merci d'avoir pris le temps de me répondre.

jpp38 a écrit:Quelles variables globales as-tu essayé de modifier?
Je suppose, si tu poses la question, que tu as déjà essayé de modifier MAX_NB_DETECTORS? Je le vois toujours à 128 dans le code que tu viens de mettre sur ce fil.


J'ai gardé ces modifications de mon coté car pour le moment ça ne fonctionne pas, mais oui j'ai modifié la variable MAX_NB_DETECTORS pensant que ça suffirait et que le code derrière serait capable de gérer.
Malheureusement ce n'est pas le cas :(

jpp38 a écrit:Ensuite, il faut vérifier dans DCPS_ExtractS88State() que nNbDetectors a bien la valeur spécifiée dans le fenêtre de paramétrage d'entrée (debugger ou MessageBox).


C'est là que se concentrent mes recherches effectivement, pour le moment tout semble bon et la boucle lit bien tous les caractères renvoyés par la centrale. Mais il semble qu'au-delà de 32 caractères les états ne sont plus sauvegardés.
Je penche donc pour un problème de taille de variable mais je tatonne encore à savoir réellement qui fait quoi....

jpp38 a écrit:Si on va au-delà, est-ce que l'extension du protocole de départ prévoit d'allonger la chaîne de caractères hexa au-delà de 32, ou est-ce qu'une autre méthode a été prévue?


L’implémentation effectué dans la centrale allonge effectivement la chaîne de caractère, elle va donc jusqu'à 128 caractères pour 512 capteurs.
Et cette chaîne allongée arrive bien jusqu'à la fonction DCPS_ExtractS88State et là encore elle est parcourue de bout en bout mais seuls les 32 premiers caractères sont enregistrés.

Cela dit il y a un point que je peine encore a éclairci, c'est la forme des données à laquelle CDM-Rail s'attend concernant les capteurs.
S'attend-il simplement à des 0/1 avec l'adresse correspondante ou à un caractère hexadécimal ou autres ?
Vous pourriez m'éclairer sur ce point ? :)

Merci

Mathieu :respect1:
MathieuA
 
Messages: 57
Inscrit le: 12 Janvier 2020, 16:34
Localisation: Orléans, Loiret

Re: Problèmes avec une centrale DCCpp

Messagepar jpp38 » 05 Juillet 2020, 18:01

Bonjour Mathieu,

Je vais essayer de t'expliquer tout ça, en faisant un document dessus, car ce n'est pas simple du tout, du fait de la généricité des DLLs.
La contrainte commune de toutes les DLL est d'avoir une interface générique commune vue de CDM-Rail, qui rende le traitement par CDM-Rail indépendant de la centrale utilisée. Et c'est pour cette raison qu'au niveau de la DLL, c'est toujours plus tordu que ça ne le serait si on ne traitait qu'une centrale unique.

Mais auparavant, je voudrais que tu me rafraîchisses la mémoire sur l'ensemble des commandes de rétrosignalisation S88 effectivement utilisées dans l'implémentation DCC++ que tu utilises.
J'étais resté sur la solution de Xavier qui ne prévoyait que deux commandes:
- La commande (centrale vers PC)
y <état nibble1> <état nibble2> <état nibble3> ...<état nibbleN>
émise par la centrale à chaque fois qu'un détecteur change d'état

- La commande (PC vers centrale)
Y
qui demande la réémission de la commande y par la centrale.


Mais je vois aussi, dans mon code, deux commandes 'Q' et 'q', manifestement liées aux détecteurs, mais dont je n'ai plus aucun souvenir.

JP
jpp38
 
Messages: 11187
Inscrit le: 31 Mars 2009, 10:15
Localisation: Grenoble (Isère / Rhône Alpes)

Re: Problèmes avec une centrale DCCpp

Messagepar jpp38 » 05 Juillet 2020, 19:29

Je joins un fichier qui décrit la séquence des fonctions appelées dans le cas d'une commande de rétrosignalisation "y ...".

J'y décris en particulier, la façon dont l'info remonte à CDM-Rail.

Cette info limite le nombre de changements de détecteurs à 32 (paramètre DGI_MAX_DATA_ITEMS = 8 nb max de nibles, x 4) .

Ce paramètre DGI_MAX_DATA_ITEMS, ne doit pas être modifié. Il fait partie du standard CDM-Rail .
Cette limite vient du standard Xpresnet, le plus répandu (centrales Lenz, DR5000,.Z21).
Lorsqu'il y a plus de changements, le protocole Xpressnet prévoit l'envoi de plusieurs séquences de rétrosignalisation, chacune limitée à 8 nibbles.


L'initialisation, par CDM-Rail, se fait différemment: c'est CDM-Rail qui demande séquentiellement l'état des détecteurs à l'initialisation du RUN.
Et donc, il faut absolument éviter que la centrale envoie sa commande "y..." AVANT le démarrage du RUN, car alors, tous les détecteurs changent d'état simultanément.

Voilà pour le moment. je pense que le problème tourne autour de ça.

Soit il faut modifier le protocole de retrosignalisation lui-même, en tronçonnant la chaîne de rétro.
Soit il faut s'arranger pour que CDM-Rail renvoie plusieurs messages de rétro.... Plus simple à dire qu'à faire.

Mais avant d'aller un cran plus loin, il faut qu'on discute de la façon dont se manifeste le problème.
Et tout d'abord, la limite des DETECTEURS modifiés est-elle de 32 , ou de 128?

JP
Pièces jointes
DCCpp_S88.txt
(2.7 Kio) Téléchargé 98 fois
jpp38
 
Messages: 11187
Inscrit le: 31 Mars 2009, 10:15
Localisation: Grenoble (Isère / Rhône Alpes)

PrécédentSuivant

Retourner vers CDM-Rail et DCCpp pour Arduino (ou DCC++)

Qui est en ligne ?

Utilisateurs parcourant actuellement ce forum : Aucun utilisateur inscrit et 1 invité

cron