Bibliothèque DCCpp

[bagou91]

Bonjour,

Je m'essaye à la nouvelle bibliothèque DCCpp que Thierry nous a concocté
Et je rencontre des petits soucis de fonctionnement avec:

J'ai envoyé l'example MaxiDcc tel quel (juste modifié quelques broches de connexion) dans mon arduino nano, le téléversement s'est bien effectué.
Par contre aucune réaction avec ma loco dccid=3.
La led Tx de l'arduino s'affole, et la console série défile avec quasiment que des lignes vides. De temps en temps je vois passer des caractères mais pas le temps de les lire.

niveau matériel j'utilise un Nano, LMD18200, MAX471, encodeur rotatif avec switch, et des boutons poussoirs.
niveau branchement arduino:
D11 = PWM LMD18200
D10 = DIR LMD18200
A6 = out MAX471
D12, D8 = encodeur
A0 = switch encodeur
A1 = F0
A2 = F1
A3 = cancel
A4 = emergency
A5 = switch pour aiguille

au niveau des BP et switch, je branche un coté à l'arduino, l'autre à la masse. Pas besoin de résistance en pullup/pulldown ?

partie du code modifié:

Code: [Sélectionner]

buttonSelect.begin(EVENT_SELECT, A0);
buttonEncoder.begin(EVENT_ENCODER, 12, 8, 2);
buttonCancel.begin(EVENT_CANCEL, A3);
buttonEmergency.begin(EVENT_EMERGENCY, A4);
buttonF0.begin(EVENT_FUNCTION0, A1);
buttonF1.begin(EVENT_FUNCTION1, A2);
buttonTurnout1.begin(EVENT_TURNOUT1, A5);

...

DCCpp::beginMain(UNDEFINED_PIN, DCC_SIGNAL_PIN_MAIN, 11, A6);

que  puis-je vérifier d'autres ?

Merci pour l'aide

[Thierry]

Bonsoir. Il faut commencer par se mettre en mode Debug en retirant le '//' devant #define DCCPP_DEBUG_MODE ligne 296 de DCCpp.h, recompiler et téléverser. Une fois là, il devrait s'afficher des choses en clair au lancement. Sinon il y a peut être juste la vitesse de la console à régler, sans doute sur 115200...

[bagou91]

j'ai activé le mode debug, et me suis mis à 115200.
voici ce que j'ai:

Code: [Sélectionner]

begin achieved
beginMain achivied
<O>
<O>
<O>
<O>
<O>
<O>


<Y1 0>
<Y2 0>
<F2 3 144 -1>
<*2: 3 90 93 / 4>
DCCpp SetFunctions for loco3 / Activated : 0


<F2 3 145 -1>
<*2: 3 91 92 / 4>
DCCpp SetFunctions for loco3 / Activated : 0 1


<*0: A4 EB 4F / 4>
<H1 1>

puis le défilement de centaines de lignes vides...
et à certains moments:

Code: [Sélectionner]

<q1>
<q2>
<Y1 0>
<Y2 0>
ou bien

Code: [Sélectionner]

<Q2>
<Y2 1>

sinon pour les BP et switch, pas besoin de résistances pullup/down ?

[Thierry]

Je constate le même genre de problème sur mon émulateur. Je regarde demain...

[Rob1]

Bonjour, je m’immisce dans le sujet car comme Bagou91 j’essaie d’intégrer DCCpp à mon projet.
Je suis sur un Arduino Mega avec un LMD18200 sous Ethernet vers VisualStudio.
J’ai préalablement testé Autotest et SerialDCC qui ont fonctionné ainsi que EthernetDCC.
Toutefois je m’interroge sur la forme d’onde que je constate au scope les clichés ci-dessous sont pris de manière aléatoire. Avez-vous également cette forme d’onde ou suis-je devant un problème sur mon installation ?
Je pose ma question ici car quelquefois la convergence de symptômes peut aider au diagnostic.

Amicalement Roland

[Thierry]

Une nouvelle version 1.0.0 a été publiée. Elle corrige deux problèmes : l'apparition de nombreuses lignes vides sur la console, causée par Sensor::check(), et la mise à la norme de l'envoi de paquet DCC pour l'activation de fonctions qui doit toujours se faire en double.
Avec ces modifications, maxiDcc semble fonctionner. Pour la partie Sensor dont j'ai repris le codage exact (à l'exception de check(), et on a vu le résultat...), je ne comprends pas la façon d'identifier un état haut ou un état bas sur la broche. Peut être faut il impérativement une résistance de Pullup, et sans utiliser celle interne de l'Arduino. En tout cas c'est ce que dit Gregg (Sensor.cpp, ligne 62):

// don't use Arduino's internal pull-up resistors for external infrared sensors --- each sensor must have its own 1K external pull-up resistor

D'autre part, dans Commanders des événements de démarrage interviennent sur tous les switchs, pour initialiser leur état de départ, ce qui provoque l'activation des turnout...

Enfin pour la forme du signal, je n'ai pas d'oscilloscope, je ne peux pas vérifier. Ce que je sais, c'est que toutes mes locos fonctionnent.

[Rob1]

La citation parle de capteur infrarouge !!!

Chez moi aussi les locos fonctionnent, c'est surtout pour savoir si le problème vient de mon câblage car dans d'autres configurations j'avais un signal plus symétrique.

[bagou91]

merci Thierry pour cette mise à jour.

plus de lignes vides dans la sortie console, mais toujours pas de réaction de ma loco.

boot du nano:

Code: [Sélectionner]

begin achieved
beginMain achivied
<p1>
<O>
<O>
<O>
<O>
<O>
<O>
<Y1 0>
<Y2 0>
<F2 3 144 -1>
<*2: 3 90 93 / 4>
<*2: 3 90 93 / 4>
DCCpp SetFunctions for loco3 / Activated : 0
<F2 3 145 -1>
<*2: 3 91 92 / 4>
<*2: 3 91 92 / 4>
DCCpp SetFunctions for loco3 / Activated : 0 1
<*0: A4 EB 4F / 4>
<H1 1>

si j'actionne l'encodeur rotatif d' 1 cran (dans n'importe quel sens):

Code: [Sélectionner]

<Y2 1>
<Y2 0>
pas de réaction de la loco

appuie sur BP F0:

Code: [Sélectionner]

<F2 3 145 -1>
<*2: 3 91 92 / 4>
<*2: 3 91 92 / 4>
DCCpp SetFunctions for loco3 / Activated : 0 1
<F2 3 129 -1>
<*2: 3 81 82 / 4>
<*2: 3 81 82 / 4>
DCCpp SetFunctions for loco3 / Activated : 1
pas d'allumage des feux

appuie sur le switch de l'encodeur (code que j'ai ajouté pour stopper la loco et inverser son sens de marche):

Code: [Sélectionner]

DCCpp SetSpeed 0/128 (in Dcc 0 )
<*1: 3 3F 0 3C / 0>
<T1 3 0 0>
je pense que cette trame est bonne, mais évidemment la loco ne réagira pas puisque je demande son arrêt.

La réponse quand j'actionne l'encodeur rotatif me semble bizarre. Je pense qu'il y a quelque chose qui ne va pas mais je ne saurai débugguer...
J'ai ajouté un Serial.println(locoSpeed) dans le test du switch(event) pour EVENT_LESS et EVENT_MORE: pas de remontée de la valeur dans la sortie console, donc je pense que l'événement pour l'encodeur rotatif n'est pas bien traité.

Edit:
Après recherche, analyse, et comparaison avec la bibliothèque DcDccNanoController, j'ai trouvé ce qui ne vas pas:
Pour un événement de type EVENT_ENCODER, tu ne prends pas en compte la valeur intData associée.
(je me suis référé à DcDccNanoController, Handle.cpp, ligne 170).
Donc j'ai ajouté ceci après la récupération de l'événement dans l'exemple MaxiDcc:

Code: [Sélectionner]

if (event == EVENT_ENCODER)
  {
      int inData = Commanders::GetLastEventData();
      if (inData == +1)
        event = EVENT_MORE;
      if (inData == -1)
        event = EVENT_LESS;
  }
Et ça fonctionne !

Pour le BP F0, il faut appuyer très très rapidement pour que l'événement ne soit compté qu' 1 fois.
Comment peut-on améliorer ça ? (classe debounce, ...)

[Thierry]

Joli, j'ai laissé passer ça... Je modifierai les exemples pour tenir compte de l'événement EVENT_ENCODER.

Pour le BP F0, je suis surpris, parce que dans mon exemple, il s'agit d'un ButtonsCommanderSwitchOnePin, c'est à dire d'un switch dont on utilise seulement une broche, et pas un bouton poussoir. D'ailleurs l'un comme l'autre ont un mécanisme de debounce intégrés. Mais peut être le délai est-il trop court à 50ms. Dans Commanders, pour ButtonsCommanderSwitchOnePin il faut modifier le source ButtonsCommanderSwitchOnePin.cpp ligne 13 et sans doute augmenter la valeur de debounceDelay... C'est aussi la valeur à changer dans ButtonsCommanderPush.cpp pour les poussoirs, si le besoin se fait sentir...

[bagou91]

Autant pour moi, j'ai été trop vite dans mon montage, c'est sûr qu'utiliser un BP avec la classe ButtonsCommanderSwitchOnePin n'est pas idéale et donne un résultat incohérent.
Je corrigerai demain.

Ensuite plus qu'à tester la réception d'ordre Dcc avec la bibliothèque Accessories...

[bagou91]

Bonjour,

Je reprend mes petits tests DCC et m'attaque à essayer d'activer une aiguille via DCC et Commanders

je bute sur l'adressage (ou les id) et valeurs à mettre et faire correspondre entre ce qui est déclaré dans le sketch MaxiDcc et mon sketch DccCommander.
Dans MaxiDcc j'ai laissé comme l'exemple:
turn1.begin(1, 100, 1);
A quoi correspond les valeurs et que dois-je mettre pour correspondre avec mon sketch DccCommander?

Coté réception dans DccCommander j'ai déclaré comme ceci:
#define DCCID_DROIT   DCCINT(100, 0)
#define DCCID_DEVIE   DCCINT(100, 1)
et
DccCommander.begin(0x01, 0x01, digitalPinToInterrupt(3));

Merci pour l'aide

[Thierry]

Pardon pour le délai, la période est un peu compliquée pour moi...

pour les structures turnout, les valeurs sont celles utilisées par le DCC++ originel documentées dans mon code dans turnout.h :

   /** Initialize the turnout created by regular C++ instantiation.
   @param id The numeric ID (0-32767) of the sensor.
   @param add   The primary address of the decoder controlling this turnout (0-511).
   @param subAdd   The sub-address of the decoder controlling this turnout (0-3).
   @remark Should not be used in command line mode.
   */
   void begin(int id, int add, int subAdd);

le premier argument id sert à 'nommer' l'aiguillage.
le deuxième et le troisième servent à décrire le décodeur DCC qui est relié à cet aiguillage. C'est sans objet si l'aiguillage n'est pas contrôlé par DCC.

Pour la déclaration des adresses DCC, ça me parait correct.

Dans DccCommander.begin, les deux premiers arguments servent à donner un identifiant de constructeur de décodeur, et un identifiant de modèle pour ce constructeur. Laisser ces valeurs à 0 ou 1 ne pose pas de problème.

[bagou91]

bonsoir,
aucun problème pour le délai de réponse ça m'a laissé du temps pour m'occuper de mon nouveau joujou: une imprimante 3D

donc j'ai essayé ceci:
dans MaxiDcc:
turn1.begin(100, 1, 1);
et j'ai laissé DccCommander comme décrit précédemment:
-> pas de réaction.

j'ai quand même bien la led 13 sur DccCommander qui clignote ce qui indique une réception de données provenant de l'optocoupleur et donc du signal DCC.

J'ai activé le COMMANDERS_DEBUG_VERBOSE_MODE
voici ce que je reçois lorsque j'active l'interrupteur pour turn1:
Dcc packet found : real data : 1 / 3 / 1  converted : 2 / 1 / 1
Dcc packet found : real data : 1 / 3 / 1  converted : 2 / 1 / 1
Dcc packet found : real data : 1 / 3 / 1  converted : 2 / 1 / 1
et
Dcc packet found : real data : 1 / 2 / 1  converted : 2 / 0 / 1
Dcc packet found : real data : 1 / 2 / 1  converted : 2 / 0 / 1
Dcc packet found : real data : 1 / 2 / 1  converted : 2 / 0 / 1

je crois comprendre qu'il manque un dernier paquet avec une valeur à 0 pour que l'ordre soit bien pris en compte ?
j'ai l'impression également qu'il manque le type de donnée à envoyer par MaxiDcc: dans DCCCommander, on s'attend à recevoir un type MOVEPOSITIONID hors je ne le vois pas dans la trame "Dcc packet found..."

qu'en penses tu ?

[Thierry]

Bonsoir.

Je recolle au problème...

MaxiDcc a été prévu pour piloter des aiguillages avec des boutons, pas avec des ordres envoyés par Dcc... C'est d'ailleurs un peu étrange de demander à une centrale (même faite par DCCpp) de servir aussi de décodeur... Il ne peut pas y avoir deux donneurs d'ordres sur un réseau. Donc la seule centrale à envoyer des commandes Dcc est MaxiDcc. Pourquoi dans ce cas DccCommander aurait-il à analyser des trames pour les décoder ? Si j'utilise Commanders dans l'exemple MaxiDcc, c'est pour gérer les boutons de la centrale de manière bien plus simple qu'en codage classique. Mais l'utilisation d'un DccCommander là est bien plus dangereuse qu'utile !

Si l'on veut décoder les ordres envoyés par une centrale, comme la CS2 par exemple, il faut utiliser Commanders seul avec comme point de départ son exemple DccCommanders .

[bagou91]

Oui je sais tout ça grâce à tes nombreuses explications sur les autres sujets abordés sur ce forum et tes articles sur le site.

Peut être que j'ai mal expliqué :
J'ai 1 nano avec maxidcc, et un autre nano avec dcccommander.

Celui avec dcccommander décode les trames avec un optocoupleur.

Est-ce plus clair sur le montage que j'ai fait ?