Parlons Arduino > Bibliothèques

Bibliothèque DCCpp

<< < (2/13) > >>

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):

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

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: ---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>

--- Fin du code ---

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

--- Code: ---<Y2 1>
<Y2 0>

--- Fin du code ---
pas de réaction de la loco

appuie sur BP F0:

--- Code: ---<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

--- Fin du code ---
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: ---DCCpp SetSpeed 0/128 (in Dcc 0 )
<*1: 3 3F 0 3C / 0>
<T1 3 0 0>

--- Fin du code ---
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: ---if (event == EVENT_ENCODER)
  {
      int inData = Commanders::GetLastEventData();
      if (inData == +1)
        event = EVENT_MORE;
      if (inData == -1)
        event = EVENT_LESS;
  }

--- Fin du code ---
Et ça fonctionne ! :D

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...

Navigation

[0] Index des messages

[#] Page suivante

[*] Page précédente

Utiliser la version classique