Bibliothèque DCCpp

[Thierry]

Voilà pourquoi un schéma, une photo, une explication du contexte et les fichiers sources concernés sont nécessaires avant même de poser des questions.
Envoie ici tes fichiers ino complets, je pourrais ainsi mieux comprendre la situation.
D'après ce que tu dis, DccCommander reçoit bien des paquets accessoires pour les identifiants 2/0 et 2/1. Mais je ne sais pas si c'est ce qui est codé côté émetteur, ni ce que tu en fais dans ton ino de récepteur...

[bagou91]

voici les fichiers.

MaxiDcc pour la partie donneur d'ordre avec l'utilisation d'un LMD18200.
Les ordres envoyés à ma loco fonctionnent bien.

DccCommander pour la partie réception pour commander des accessoires
J'ai repris le schéma de l'optocoupleur de cet article (avec pin D3 pour l'interruption):
http://www.locoduino.org/spip.php?article39

[Thierry]

Pour turn1.begin().
Les trois arguments de cette fonction sont:

id : un identifiant interne à DCC++
add: adresse principale pour le Dcc
subadd: sous adresse pour le Dcc

Dans MaxiDcc on a turn1.begin(2, 1, 1);
Donc on devrait retrouver 1 / 1 real data dans l'affichage de DccCommander, ce qui n'est semble t-il pas le cas...

Honnêtement, je ne comprend pas. Le code de DCCpp (turnout.cpp) est simple :
DCCpp::mainRegs.setAccessory(this->data.address, this->data.subAddress, this->data.tStatus);
On envoie un ordre Dcc via le registre principal avec l'adresse et la sub-adresse spécifiée dans le begin().

Côté DccCommander, on reçoit bien un ordre accessoire (il n'affiche que ceux là...), mais les valeurs réelles ne sont pas les bonnes...

[bagou91]

Oui c'est ce que j'ai constaté aussi.
J'ai essayé diverses autres valeurs comme par exemple le 3eme argument de turn1.begin() qui influence les valeurs reçues côté Dcccommander...
Mais je n'arrive pas à interpréter cela.

[Thierry]

Bon. Il faudrait que je réunisse de quoi tester... Ça va prendre un peu de temps...

[bagou91]

j'ai trouvé quelquechose !

dans DccCommander:
on reçoit la trame 3 fois pour chaque ordre, hors dans la bibliothèque de DccCommander, fichier DccCommander.cpp, ligne 65, tu expliques que tu attends 3 fois la même trame, puis une 4ème trame avec 0 au dernier octet pour activer l'accessoire.
Cette dernière trame n'est jamais envoyée par MaxiDcc donc pas reçu par DccCommander.

Si je supprime le test ligne 65, ça fonctionne: mon aiguille réagit bien !
Par contre au bout de quelques actionnements de mon interrupteur sur l'arduino MaxiDcc, l'arduino DccCommander finit par perdre les pédales, freeze, plante et reboot.

[Thierry]

Ouf, voilà qui est rassurant.
Le problème est que selon la centrale, le format des ordres accessoire peut varier. Du coup, j'ai préféré me baser sur la présence d'une désactivation que j'ai considéré à l'époque comme forcément présente.
Peut être faudrait-il modifier DCCpp pour coller à la norme (s'il y en a une), ou modifier DccCommander pour réagir à un nombre donné d'activations au lieu d'une désactivation... Je vais voir ce que je peux faire côté Commanders, ça me parait plus simple. Et étudier la norme pour s'y conformer du côté DCCpp si elle existe. C'est déjà ce que j'ai fait (pour la prochaine version) pour les fonctions des locos que la norme demande d'envoyer deux fois...

[Thierry]

Pour le plantage, il faudrait activer le mode debug de Accessories pour voir si quelque chose cloche. Je vais tenter de reproduire le problème ici...

[Souris verte]

Bonjour,

je voudrais configurer les CV de ma loco et je bug...
montage : UNO, LMD18200 et MAX471.
branchement de la voie de Prog :

Code: [Sélectionner]

  DCCpp::begin();
  DCCpp::beginProg(UNDEFINED_PIN, 5, 11, A1);  // J'utilise des variables dans le code
 
  DCCpp::powerOn();

  for (int i=1; i<36; i++){
      delay(100);
      DCCpp::readCvProg (i, 200, 100);
  }

  DCCpp::writeCvProg(33, 1, 400, 100);
  delay(200);

J'obtiens:

Code: [Sélectionner]

<r200|100|1 3>
<r200|100|2 3>
<r200|100|3 32>
<r200|100|4 24>
...
<r200|100|33 0>
<r200|100|34 0>
<r200|100|35 0>
<r400|100|33 -1>
DCCpp WriteCv 33 : 1
*** DCCpp LIBRARY ***
VERSION DCC++:      2.0.0
VERSION DCCpp library: 1.3.0
COMPILED:     Jun 23 2018 16:50:48

DCC SIG PROG(DIR): 5
   DIRECTION: 255
   ENABLE(PWM): 11
   CURRENT: 15

INTERFACE:    SERIAL


J'en déduis que les connexions sont bonnes puisque la lecture se passe bien.
En revanche pour l'écriture pas possible ...
En tapant <W 33 1 400 100> même résultat.

Où est mon erreur? Merci

Yannick

[msport]

Bonsoir,
il faut se référer à la syntaxe décrite dans le document  Commands for DCCpp BaseStation du Github.
Quel est le but de la manœuvre ?

#####WRITE CV BYTE TO ENGINE DECODER ON PROGRAMMING TRACK#####
Writes, and then verifies, a Configuration Variable BYTE to the decoder of an engine on the programming track
•   Write CV BYTE Format is: < W CV VALUE CALLBACKNUM CALLBACKSUB >
•   CV: The number of the Configuration Variable memory location in the decoder to write to (1-1024 ).
•   VALUE: The value to be written to the Configuration Variable memory location (0-255).
•   CALLBACKNUM: An arbitrary integer (0-32767) that is ignored by the Base Station and is simply echoed back in the output - useful for external programs that call this function.
•   CALLBACKSUB: a second arbitrary integer (0-32767) that is ignored by the Base Station and is simply echoed back in the output - useful for external programs (e.g. DCC++ Interface) that call this function.
•   Returns: < r CALLBACKNUM|CALLBACKSUB|CV Value >
•   CV VALUE: Is a number from 0-255 as read from the requested CV, or -1 if verification read fails.

[Souris verte]

Bonjour,

J’ai utilisé la syntaxe (la commande est dans mon message).
Le but est d’ecrire Ds les cc de 33 a 47 qui sont tous à 0. Donc pas possible d’alumer Les feux.

Merci

[msport]

Bonjour,
si je comprends bien, à <W 33 1 400 100>
la réponse est <r400|100|33 -1> donc échec de l'écriture.
par contre le CV 33 a bien été lu à 0 avec : <r200|100|33 0>

je propose un reset du décodeur (pour Lenz c'est 8 ou 33 dans le CV 8 )
Vérifier alors que le CV1 est à 3, et le CV 33 à 1.

l'allumage des feux avant avec F0 est classique avec le CV 33 à 1 pour les décodeurs que je connais.

[Dominique]

J’ai constaté qu’il y a des décodeurs récalcitrants qui ne se laissent pas programmer par DCC++, notamment CTelektronic.

Mais le MS2 y arrive. Il y a donc certainement d’autres méthodes.

J’ai fait une centrale dédiée à la programmation et j’explore ces questions.
Pas trop le temps en ce moment mais je vous donnerai les résultats.

[Thierry]

Pour moi, tous les décodeurs arrivent à recevoir les messages et à faire ce qu'on leur demande. La difficulté vient de la remontée d'information qui n'est pas faite avec la même intensité et la même durée pour tout le monde. Ce n'est pas le cas ici puisque la lecture semble fonctionner. Pourtant le délai entre l'écriture et l'envoi d'une confirmation après l'écriture, ou la manière de décoder cette confirmation peuvent être différentes.
Dans le code de PacketRegister.cpp, la lecture de CV n'a pas tout à fait la même structure que la réception de confirmation. Il faudrait afficher la valeur vraiment lue par les différents analogRead qui sont faits dans writeCVByte() pour comparer. Par exemple, ajouter juste avant la fin du test "if (DCCppConfig::CurrentMonitorProg != UNDEFINED_PIN)"

Code: [Sélectionner]

#ifdef DCCPP_DEBUG_MODE
Serial.print(F("Confirmation intensity "));
Serial.println(c);
#endif

La valeur de c doit être supérieure à celle de ACK_SAMPLE_THRESHOLD (définie dans PacketRegister.h) pour valider la confirmation. Peut être faut il ajuster cette constante pour s'adapter aux capacités du décodeur ? Et puis on va faire 500 mesures de la broche analogique (constante ACK_SAMPLE_COUNT). Peut être est-ce excessif, surtout si le décodeur renvoie sa confirmation pendant bien moins longtemps que ça... Bref, il y a des choses à régler, et peut être qu'un oscillo pourrait rendre service pour étudier la forme du retour.

[msport]

montage : UNO, LMD18200 et MAX471.

En tapant <W 33 1 400 100> même résultat.

Si j'ai bien compris, le problème semble être là aussi avec le serial monitor, il vient donc soit du décodeur, soit du montage.
Et comme j'ai ce montage comme beaucoup d'autres utilisateurs (sauf si il a été personnalisé) ...
Le décodeur est un ... ?