Problèmes avec une centrale DCCpp

Re: Problèmes avec une centrale DCCpp

Messagepar Lormedy » 06 Juillet 2020, 11:18

Bonjour à tous,

La limitation d'une rétro-signalisation à 128 capteurs convient pour les petits réseaux mais une limite portée à 512 capteurs sera perenne pour l'avenir.

Actuellement la routine S88.cpp que j'avais ajoutée dans le code Arduino DCCpp_S88 et une reprise de la routine de Xavier avec son accord.
Je l'ai étendu pour la rendre compatible avec plusieurs logiciels de gestion de trains.
Elle permet de lire séquentiellement jusqu'à 512 capteurs d'un seul trait avec une fréquence maxi de 10 fois par seconde environ.
Ceci lui permet une réactivité dans les 100 millisecondes qui suivent le changement d'état d'un capteur, plus les latences générées par le mode de transport de l'information jusqu'au PC.

Marklin recommandait de ne pas chainer plus de 32 modules S88 (sous 12V) à cause des pertes électriques dans les connexions, les modules gérant 8 ou 16 capteurs, ce qui conduit à un bus de 512 capteurs au maximum.
Pour des raisons pratiques évidentes, j'ai scindé électriquement le bus S88-N en 2 bras de 256 capteurs (sous 5V) qui sont concaténés en soft dans l'Arduino avant d'être transmis vers le PC.
Le contenu de la trame S88 transmise par l'Arduino dépend de la requête faite par le logiciel du PC.
Le dialoque se fait en ASCII et les commandes sont les suivantes :

<Y> envoie la dernière trame S88 lue vers le PC

<Y 0> arrête la transmission vers le PC

<Y N F> N étant un Nombre total pair, représentant les groupes de 8 capteurs connectés sur le bus. N = 2, 4, 6, 8, ..., 64.

F représente le Format d'encodage émit vers le PC :
Réponse <y data>

F = 0 envoie l'état de chaque capteur '0'/'1' encodé en ASCII dans un byte.
Exemple <y 00011010101... ...> data maxi = 512 bytes.

F = 1 envoie l'état de chaque capteur '0'/'1' groupé en nibble ASCII dans un byte.
Chaque nibble représente donc 4 capteurs de 0x00 à 0x0F encodés en ASCII de '0' à 'F'.
L'ordre des capteurs pour CDM-Rail est inversé : capteur4 capteur3 capteur2 capteur1(lsb). (option DCCpp_S88)
Sinon l'ordre naturel des capteurs est : capteur1 capteur2 capteur3 capteur4(lsb)
Exemple <y F01805B40... ...> data maxi = 128 bytes.

F = 2 envoie l'état de chaque capteur '0'/'1' groupé par 8 dans un byte Hexadécimal. 8 capteurs = un byte.
L'ordre naturel des capteurs est : capteur1 capteur2 capteur3 capteur4 capteur5 capteur6 capteur7 capteur8(lsb)
Exemple <y F01805B40... ...> data maxi = 64 bytes.

F = 3 envoie l'état de chaque capteur ID '0'/'1' encodé en ASCII "q ID"/"Q ID" dans un Byte. '0' => 'q' et '1' => 'Q'.
Ce format est utilisé par JMRI, RocRail, etc...
Exemple <Q0> ou <q1> ou <Q84> ou <q511> Maxi 512 transmissions à l'initialisation,
ensuite une seule transmission à chaque changement d'état d'un capteur.

<Y N> est équivalent à <Y N 0>

<o N*8 F> est renvoyé vers le PC indiquant la bonne réception de la commande.

<X Bad Argument value> sera renvoyé vers le PC en cas d'erreur dans la commande.

Notes : Après initialisation, à chaque changement d'état d'un capteur, une trame est transmise automatiquement vers le PC.
Les capteurs absents sur le bus S88-N sont représentés par des '0' avant encodage.
La lecture du bus progresse du capteur1 jusqu'au capteur512 et la transmission vers le PC suit la même ascendance mais encodée.

J'espère que ces éclaircissement feront avancer le modélisme auquel je contribue alors que le logiciel du forum a détruit ma mise en page...

Philippe
Réseau DCC 2 voies H0
PC + (Node.js + CDT31) ou WDD7 + Arduino Mega + L298+ Max 471
Détecteurs de train perso + S88-N_8E/16E perso
http://lormedy.free.fr
Lormedy
 
Messages: 8
Inscrit le: 09 Mai 2019, 05:31
Localisation: Grésivaudan

Re: Problèmes avec une centrale DCCpp

Messagepar jpp38 » 06 Juillet 2020, 17:07

Bonjour Philippe,

Merci pour ces infos, qui (entre autres) éclairent pourquoi j'avais prévu les préfixes Q et q dans les commandes.

En fait, il n'y a pas vraiment de limitation à 128 dans le protocole de Xavier. Il peut être étendu à 512 sans problème.
Le problème rencontré par Mathieu '(à confirmer) est a priori que la "salve" de changement d'états remontée vers CDM-Rail est limitée à 8 états différents, et c'est cette explication que nous devons approfondir.
Une fois qu'on l'aura expliqué, je pense qu'il sera facile d'adapter la DLL pour contourner ce problème.

Sinon, ma préférence personnelle aurait effectivement été vers les commandes Q / q comme JMRI RocRail.
Parce que c'est plus simple à gérer, mais surtout pour être cohérents au niveau du standard.
La seule chose qu'il me faut en plus, c'est la requête d'un état particulier du PC vers la centrale (autrement dit, pouvoir demander explicitement l'état d'un détecteur, en plus de la réception des messages de rétrosignalisation).

Mais pour le protocole, c'est Mathieu qui voit.

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

Re: Problèmes avec une centrale DCCpp

Messagepar MathieuA » 07 Juillet 2020, 17:54

Bonjour à vous deux,

Merci à Philippe pour avoir donné toutes les explications concernant l'implantation du protocole dans la centrale :D
Et Merci à Jpp aussi ! Les explications m'ont permis d'y voir bien plus claire et de cerner le problème !

jpp38 a écrit:En fait, il n'y a pas vraiment de limitation à 128 dans le protocole de Xavier. Il peut être étendu à 512 sans problème.
Le problème rencontré par Mathieu '(à confirmer) est a priori que la "salve" de changement d'états remontée vers CDM-Rail est limitée à 8 états différents, et c'est cette explication que nous devons approfondir.
Une fois qu'on l'aura expliqué, je pense qu'il sera facile d'adapter la DLL pour contourner ce problème.


Tout à fait ! Le problème réside donc dans cette limitation. Il me faut donc trouver un moyen de la contourner facilement tout en faisait en sorte que le code soit évolutif au cas où on déciderait d'augmenter encore cette limite de 512 capteurs. Plus facile à dire qu'à faire donc...
Mais grâce aux explications de Jpp et à quelques tests que j'ai mené cette après-midi le problème est bien là. J'ai d'ailleurs réussis à contourner le problème et "dupliquant" simplement les variables et la logique avec succès (malgré un potentiel décalage d'adresse, mais ça reste encore à confirmer).
Seulement ce n'est pas très évolutif et c'est surtout très sale... :?

J'ai donc revu totalement la logique et pour le moment c'est un peu bancal. Demain après-midi je vais faire un saut chez mon oncle pour tester en conditions réelles car pour le moment je test avec une centrale qui renvoie de fausses informations. Ce n'est pas très idéal donc.

jpp38 a écrit:Sinon, ma préférence personnelle aurait effectivement été vers les commandes Q / q comme JMRI RocRail.


J'ai effectivement pensé à ça aussi. Mais j'ai peur que ça soit pénalisant en termes de performances pour la centrale, surtout sur les grands réseaux.
À confirmer auprès de Philippe.

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

Re: Problèmes avec une centrale DCCpp

Messagepar jpp38 » 07 Juillet 2020, 19:10

MathieuA a écrit:J'ai donc revu totalement la logique et pour le moment c'est un peu bancal.


Attention à ne pas modifier la logique d'enchainement des diverses fonctions: c'est TRES sensible!!!!

La bonne méthode à mon avis est soit de modifier un peu le protocole, soit de faire en sorte que le message <y ...;> ne soit jamais envoyé avant que le PC ne la demande. Là, ça marchera.

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

Re: Problèmes avec une centrale DCCpp

Messagepar MathieuA » 08 Juillet 2020, 20:43

Bonjour,

Petit compte rendu de la journée: Nous avons perdu pas mal de temps à cause de quelques âneries à moi :lol:
Mais la détection et la gestion des 160 détecteurs de mon oncle fonctionnent à merveille !

Comme je l'ai dit j'ai totalement revu la logique, le code supportera donc 512 capteurs comme 1024 si on décide de doubler (pour je ne sais quelle raison) cette limite dans l'avenir.
Il y a seulement trois variables à modifier pour augmenter le nombre de capteurs maximum.
A savoir : MAX_NB_DETECTORS, MAX_NB_MODULES et MAX_GROUP_OF_128_DETECTORS. Respectivement a 512, 64 et 4.

Pour la petite explication:

J'ai contourné la limite de retours de changement d’état en découpant la chaîne renvoyé par la centrale par groupes de 32 caractères. Ces groupes de 32 caractères représente chacun les états de 128 capteurs (d'où la variable du nombre de groupes maxi). Pour stocker les changements de chaque groupe et ainsi savoir à quel moment quel groupe change et quel nibble exactement, j'ai créé trois tableaux bidimensionnel, un pour stocker le nombre de changements par groupe, un pour stocker quels nibbles ont été modifiés (ce qui avait déjà été fait auparavant) et un dernier pour stocker tous les états de chaque groupe. Le tableau qui stock tous les états de chaque groupes comporte le nombre de lignes égal au nombre de groupe de capteurs et le nombre de colonnes égal au nombre de capteurs par groupe (128 donc). Tandis que les deux autres comportent le nombre de lignes égal au nombre de groupe de capteurs et une seule colonne (ça simplifie énormément la logique derrière).

Chaque fois que la centrale renvoi un changement d'état, la fonction DCPS_ExtractS88 State parcours la chaîne de caractères tout entière et stocke les données dans les tableaux liés au S88. L'astuce c'est qu'à chaque fois que son index est un multiple de 32 (donc à chaque fois qu'elle a parcouru l'état de 128 capteurs) elle passe au groupe suivant. Elle stocke ainsi l'état des 128 premiers capteurs dans les premières lignes des tableaux, l'état des 128 capteurs suivants dans la seconde ligne et ainsi de suite. La taille des tableaux étant directement liée aux trois variables citées ci-dessus, la DLL sera capable de stocker autant d'état que ce que lui permet ses variables et par conséquent les étendre en cas de besoins.

Ensuite quand CDM-Rail demande une mise à jour des états, la DLL va déclencher une boucle qui va de 0 au nombre maxi de groupes de 128 détecteurs, et pour chaque groupe elle va regarder s'il y a eu un changement. Si c'est le cas elle va appeler une nouvelle fonction que j'ai créé (et qui reprend en grande partie ce qui avait été fait auparavant) et qui elle va se charger de remonter à CDM-Rail les états du groupe concerné.
De cette façon seule 128 détecteurs sont mis à jour à la fois. On respect donc la limite imposée par CDM-Rail tout en ayant autant de détecteurs qu'on le souhaite et surtout avec la possibilité d'en rajouter et éviter de tout refaire à chaque fois :)

J'espère avoir été assez claire dans mes explications par contre... Pour moi ça me paraît clair mais pour quelqu'un qui n'a pas vu le code je peux comprendre que ça ne le soit pas, donc n’hésitez pas à me reprendre nécessaire :D

On a faits tourner quelques trains en fin d'après-midi et tout s'est bien passé. J'ai pas mal de nettoyage à faire avant de publier cette DLL. Et aussi pas mal de commentaires à mettre un peu partout pour celui (ou celle) qui passera derrière moi dans l'avenir (on ne sait jamais). Pour le moment j'ai laissé la DLL entre les mains de mon oncle, il va faire tourner ses trains toute la semaine ce qui fera un excellent stress test.
S'il ne rencontre pas de soucis d'ici là ça sera gagné !

Je profite pour remettre ma question qui était restée en suspent l'autre fois et qui est justement revenu sur le tapis cette arpès midi entre mon oncle et moi :)

MathieuA a écrit:
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: 14
Inscrit le: 12 Janvier 2020, 16:34
Localisation: Orléans, Loiret

Re: Problèmes avec une centrale DCCpp

Messagepar jpp38 » 09 Juillet 2020, 10:59

Bonjour Mathieu,

OK.
L'essentiel est que ça marche pour toi.
Je ne vais pas récupérer ton code pour l'archiver officiellement. Je t'ai donné un coup de main pour que tu puisses adapter aux besoin de ton oncle, mais je n'irai pas plus loin.
Deux raisons à ça:
1) Tu as complètement bousillé le format d'origine en faisant ton ménage, et du coup, je suis incapable de localiser tes modifs.
Et je ne vais certainement pas entrer dans ton code.
2) Ca ne correspond pas vraiment à un standard, donc peu d'intérêt pour moi de mettre de l'énergie dessus.
S'il fallait le faire, il faudrait que tu documentes toutes les modifs que tu as faites, et je les reporterais dans mon format d'origine (le format général de CDM-Rail) , le seul qui me permettre de suivre l'historique des modifs (par comparaison de fichiers).


Pour ta question: non, ce n'est pas envisagé.

A+

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

Précédent

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