LOCODUINO
Parlons Arduino => Bibliothèques => Discussion démarrée par: bagou91 le janvier 06, 2018, 06:48:50 pm
-
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é:
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
-
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...
-
j'ai activé le mode debug, et me suis mis à 115200.
voici ce que j'ai:
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:
<q1>
<q2>
<Y1 0>
<Y2 0>
ou bien
<Q2>
<Y2 1>
sinon pour les BP et switch, pas besoin de résistances pullup/down ?
-
Je constate le même genre de problème sur mon émulateur. Je regarde demain...
-
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
(http://www.domorob.fr/Locoduino/DCCpp_scope1.jpg)
-
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.
-
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.
-
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:
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):
<Y2 1>
<Y2 0>
pas de réaction de la loco
appuie sur BP F0:
<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):
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:
if (event == EVENT_ENCODER)
{
int inData = Commanders::GetLastEventData();
if (inData == +1)
event = EVENT_MORE;
if (inData == -1)
event = EVENT_LESS;
}
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, ...)
-
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...
-
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...
-
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
-
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.
-
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 :D
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 ?
-
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 .
-
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 ?
-
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...
-
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
-
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...
-
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.
-
Bon. Il faudrait que je réunisse de quoi tester... Ça va prendre un peu de temps...
-
j'ai trouvé quelquechose ! :D
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.
-
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...
-
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...
-
Bonjour,
je voudrais configurer les CV de ma loco et je bug...
montage : UNO, LMD18200 et MAX471.
branchement de la voie de Prog :
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:
<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
-
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.
-
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
-
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.
-
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.
-
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)"
#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.
-
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 ... ?
-
Bonsoir,
Décodeur esu. J’ai poussé 8 dans le CV8 et ça a réglé le pb.
Le CV8 est repassé à ca valeur par défaut (151) comme le reste.
Les feux s’allument de nouveau.
Problème de décodeur plus que DCCpp. Merci pour les aides et conseils
Yannick
-
Thierry a certainement raison :
Pour moi, tous les décodeurs arrivent à recevoir les messages et à faire ce qu'on leur demande
En fouillant sur les forums les plus sérieux, j’ai eu l’impression que quand on tombe sur une difficulté, on ne cherche pas très longtemps et on la contourne :-X. En l’occurence, on ne vérifie pas la bonne programmation des CVs en les relisant.
Pour l’adresse d’une loco, c’est facile, si la loco réagit à la nouvelle adresse, c’est qu’elle est bien programmée.
Moi je cherche à lire tous les CVs pour garder une description de mon parc et surtout pour faire de la reconnaissance automatique de locos (voir le va et vient).
Je considère qu’il y a encore à explorer ce domaine et je remercie Thierry d’avoir intégré cette fonction de reconnaissance automatique dans DCCpp, même si elle ne marche pas encore avec tous les décodeurs.
Amicalement
Dominique
-
Bonjour
Avec la nouvelle version de DCCpp disponible a ce jour, je confirme que mes décodeurs D&H récents, qui posaient des problemes sous DCC++, sont désormais intégralement pris en charge sans modifier quoique ce soit. :)
Tests réalisés avec la centrale sous JMRI de Bobby&Co, en mode serial.
Bravo Thierry
Bon , maintenant, il ne me reste plus qu'a faire fonctionner cette foutue liaison Ethenet, qui, elle, se montre particulièrement enquiquinante :)
(mais j'ai du faire une bêtise quelque part)
La discussion va bon train ici : https://forum.locoduino.org/index.php?topic=1074.0
Bonne journée a tous
Jerome ...
-
Bonjour. Content de voir que ça marche mieux qu'avant...
Pour la connexion ethernet, le passage de DCC++ à DCCpp l'a rendue plus difficile et je ne sais pas pourquoi...
-
Bonjour Thierry,
je confirme aussi une nette amélioration et peut-être même "plus aucun problème" mais que je ne pourrai voir cela qu'après le déconfinement au club.
Un grand merci à toi.
Cordialement
Antoine
-
Bonsoir Locoduino,
dans ma dernière confirmation de l'amélioration de la programmation des CVs j'ai peut-être été trop rapide.
Un des membres du club vient de me signaler le dysfonctionnement suivant:
Sur voie MAIN jusqu'au cran 100 (environ) la vitesse augmente pratiquement normalement, par contre en continuant de monter les crans la loco diminue sa vitesse jusqu'à l'arrêt complet. Et selon lui ses machines ont de toute façon moins de "peps". Ce fonctionnement est testé sur ma centrale que j'ai décrit ici: https://locoduino.org/spip.php?article237
En remettant l'ancienne version de DCCpp tout rentre dans l'ordre.
J'ai même mis dans l'ancienne version les 2 fichiers "PacketRegister" de la nouvelle version et la programmation des CVS semble bonne sans voir apparaitre le problème de la vitesse.
Est-ce que d'autres membres ont testés la nouvelle version et ont-ils le même comportement ?
Merci par avance pour vos réponses.
Cordialement
Antoine
-
Bonsoir
Thierry,
pour faire fonctionner mon Shield V2 5500 j'ai du désactiver l'EPROM.
C'est grave, docteur ?
En tout cas, pour l'instant ça roule 8)
Jerome
Trop content que ca fonctionne comme il veut 8)
-
L'EEPROM n'a aucun d'intérêt si l'on utilise pas les accessoires prévus par DCC++ : les aiguillages, les capteurs et les broches à activer. Pour la partie DCC pure, pas d'EEPROM ça ne sert à rien.
Par contre, je ne vois pas le rapport avec le shield 5500... Mais peut être que sa bibliothèque de gestion utilise aussi l'EEPROM...
-
Bonjour,
je rencontre quelques difficultés pour démarrer la librairie DCCpp sur mon Arduino Uno + LMD18200 + LM471.
je teste avec le source 'Autotest' et j'ai bien une forme d'onde carrée en sortie qui ressemble à du DCC, +- 20V (sur un oscillo de poche)
quand je branche un (testé avec 2) décodeur Jouef/Hornby dessus le signal s'effondre, aie
j'ai testé le Max471 (deux en fait) a part, il semble répondre et fourni des valeurs différentes selon la charge, mais j'ai l'impression que c'est par la que je devrais commencer à debugger.
j'essaye de valider le mode debug vers la ligne 450 du fichier DCCpp.h, mais je ne vois rien dans la console...
je ne vois rien non plus en cours d'exution, pourtant les instructions "Serial.println(currentItem->comment);" et "Serial.println("Restart");" devraient bien afficher du texte dans la console ?
j'utilise 115200 baud, les autres vitesses ne changent rien
ce n'est pas mon premier essai en Arduino, donc je ne débute pas de ce coté la.
je dois oublier quelques chose de tellement gros que je ne le vois pas ???
une ame charitable pourrait elle me guider pour utiliser le mode debug me permettant de me mettre sur la piste du graal ?
merci par avance
Olivier
-
Bonjour,
est-ce qu'une simple résistance de 1 Kohm effondre aussi le signal ?
A voir directement en sortie du LMD18200.
PS : je ne commencerais pas mes tests avec 20V, certains décodeurs ne sont spécifiés que pour 15V.
-
Bonjour,
merci pour la réponse, oui pareil avec une résistance d'1k Ohm
-
du coup, j'ai changé ce que je n'avais pas encore changé: le LMD18200...coupable !
c'est beaucoup mieux j'ai de la vie sur mes sorties moteur et éclairage 8)
...mais toujours rien dans la console, étrange...
ca m'aiderait bien pourtant
Olivier
-
Bonjour,
finalement j'ai laissé tomber "Autotest" pour essayer avec 'SerialDcc'
j'ai du ajouter DCCpp::powerOn(); dans le setup et depuis que du bonheur!
ma motrice d'essai (une vénérable RTG de fin des années 70 achetée quand j'étais ado) avance, recule, s'allume ! (je l'ai numérisée moi meme donc)
pour le moment je trouve la motorisation à cardan suffisante, sur certains forums beaucoup ont changé la motorisation car bruyante, moi ca me rappelle ma jeunesse ::)
bravo pour cette librairie que je vais utiliser à présent pour la suite
Olivier
-
Bonsoir Olivier,
pourrais-tu faire un essai en envoyant par la voie série l'ordre d'avance suivant <t 1 3 127 1> en remplaçant bien sûr le 3 par l'adresse de ta loco.
Il se trouve que chez moi je suis limité à 126, le 127 stoppe ma loco.
Merci de me tenir au courant de tes essais.
Cordialement
Antoine
-
Bonsoir Antoine,
ca ne donne rien, la commande semble ne pas etre prise en compte.
par contre à 126 mon RTG fonce comme un TGV!
olivier
-
Merci beaucoup pour cette précision, je pensais à un problème chez moi.
Bonne soirée
-
Bonjour,
à force de faire des essais ma motrice RTG avec un decodeur Jouef/Hornby s'est emballée et le moteur ne tourne plus.
j'ai regardé au scope rien, et mis une led avec R de 1k: plus de vie
les commandes <t 1 3 50 1> ou <t 1 3 50 0> changent bien les LEDs de sens, mais le moteur ne bronche plus
a priori le décodeur fonctionne car j'allume/eteins les feux avec <f 3 144> & <f 3 128> et je ne pense pas avoir grillé le moteur mais peut etre le décodeur... (j'ai la flemme de dessouder le moteur pour le tester)
j'ai décider de paramétrer le code pour passer en mode programmation
ma config est Mega + LMD18200 + MAX471 et le programme SerialDcc...
j'ai donc modifier :
// DCCpp::beginMain(UNDEFINED_PIN, DCC_SIGNAL_PIN_MAIN, 3, A0);
DCCpp::beginProg(UNDEFINED_PIN, DCC_SIGNAL_PIN_PROG, 3, A0);
les commandes <t xxx> et < f ...> ne fonctionnent plus et les feux clignotent: je suppose que c'est normal?
du coup j'esaye de lire les CV et/ou de reseter le décodeur avec la commande <W 8 8 5 5>
DCCpp me répond
W command
iter : 0, max : 1
<r5|5|8 8>
en lecture avec <R 8 5 5> j'obtiens
readCVraw : start reading cv 8
iter : 0, max : 1
iter : 0, max : 1
iter : 0, max : 1
iter : 0, max : 1
iter : 0, max : 1
iter : 0, max : 1
iter : 0, max : 1
iter : 0, max : 1
iter : 0, max : 1
<r5|5|8 -1>
end reading
Les feux et ma LED de debug sur le moteur clignotent, ce qui semblerait indiquer que la sortie décodeur pour le moteur répond
j'ai commandé d'autres décodeurs pour continuer les essais bien sur, mais en attendant je m'entraine sur celui-la pour étudier le mode programmation
d'après ce que j'ai lu, dans la réponse <5|5 8 -1> -1 indique une erreur ?
la moindre piste serait la bienvenue !
Olivier
-
bonsoir,
j'ai compris depuis que la lecture des CV n'est possible que par mesure du courant consommé par le moteur.
le moteur n'étant plus alimenté, je suis bloqué.
j'ai changé d'Arduino(non convaincu), le LMD 18200(semblait une meilleure piste), de décodeur, de loco, rien n'y fait!
il reste bien le Max471 mais je vois pas pourquoi il permettrait la commandes des feux et pas du moteur, bref je je suis bloqué, les moteurs des locos fonctionnant en 12V une fois débranchés des décodeurs.
Du coté logiciel, DCCpp est piloté par l'exemple serial, on ne peut pas utiliser plus simple.
j'ai cassé mon jouet et je ne sais plus trop ou chercher, la moindre piste serait appréciée...
Olivier
-
Bonjour,
pour valider votre matériel, faites le montage de base de la BaseStation (original Gregg Berman du site) avec un UNO, un shield moteur, deux straps, une alimentation 12V et DCCpp_Uno (.ino etc.), c'est monté en 5 mn sans mofifications.
https://www.locoduino.org/spip.php?article187
-
Bonsoir,
merci pour le conseil, en fait en parcourant ce forum plus attentivement il est clair que le MAX471 est surement le coupable, je vais vérifier demain, j'en avais approvisionné plusieurs par précaution ...
la (non) fiabilité de ces composants risque de poser des problèmes de maintenance sur le long terme, je regarderai plus tard d'autres solutions n'utilisant pas LMD18200 & MAX 471, qui sont, en plus, pas évidents à approvisionner.
je pense que nous recherchons tous une solution pérenne, j'ai beau être électronicien de formation, ma vraie passion actuelle et à venir ce sont les convois à l'échelle HO! (a 60 ans je suis moins 'souple' à jouer du fer à souder)
Olivier
-
On a identifié la solution de remplacement du MAX471 (qui n'est plus produit) avec le INA169 :
https://forum.locoduino.org/index.php?topic=843.msg13879#msg13879
PS :
la BaseStation n’utilise pas de MAX471 mais la mesure de courant du L298 du shield. Aucun câblage (2 straps)
Pour LaBox, on utilise un Rsense sur le L6203.
-
merci beaucoup pour le lien, donc utilisation d'un 9110s avec INA169?
les modules 9110S semblent plus petits en 'googlant' et le schéma indique toujours MAX 471 (coquille?)
https://www.amazon.fr/L9110S-H-bridge-Stepper-Driver-Controller/dp/B07KFLZKP1/ref=sr_1_6?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=l9110S&qid=1637616359&sr=8-6 (https://www.amazon.fr/L9110S-H-bridge-Stepper-Driver-Controller/dp/B07KFLZKP1/ref=sr_1_6?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=l9110S&qid=1637616359&sr=8-6)
en tout cas, ces composants semblent disponible facilement, ceci mérite d'etre approfondi
le montage a été validé depuis ?
olivier
-
Pour l'utilisation du L9110S voir l'article :
https://www.locoduino.org/spip.php?article253
attention, il faut lire les questions/réponses, les articles ne sont pas souvent mis à jour.
le module que vous montrez est limité à 800 mA (probablement optimiste)
J'ai testé le module à L9110S 15A avec un INA169 à 1V/A (idem MAX471 3A)
-
merci pour la remarque sur la différence de puissance, j'allais commander le mauvais module !
je ferai des essais prochainement et ne manquerai pas de donner les résultats ici!
Olivier
-
Bonjour,
en attendant la réception des nouveaux composants, j'ai réussi à redémarrer ma station et compris ce qui clochait...
c'est en fait mes 2 décodeurs d'essai que j'ai flingués, j'en ai reçu depuis 2 autres, d'une autre marque et c'est reparti je sais commander le déplacement de la motrice, allumer/éteindre les feux, 8) donc la vie est belle, sauf que ...
j'ai édité la configuration pour basculer du mode 'normal' en mode 'programmation'
// DCCpp::beginMain(UNDEFINED_PIN, DCC_SIGNAL_PIN_MAIN, 3, A0);
DCCpp::beginProg(UNDEFINED_PIN, DCC_SIGNAL_PIN_PROG, 3, A0);
et la motrice s'affole (elle part en trombe), du coup je l'arrete en catastrophe car je ne pense pas que cela soit normal, (en mode programmation la loco est statique ?) et je pense que c'est comme ça que j'ai détruit mes premiers décodeurs.
j'ai donc une question: faut il forcément avoir deux boosters pour programmer les locos? (je pensais pouvoir basculer d'un mode à l'autre en recompilant)
je suis toujours en Arduino Mega + LMD18200 (x1) + Max471 (x1) (du coup je l'avais testé, il fonctionne parfaitement, la tension évolue bien suivant la consommation) + le programme serial de base exemple de la bibliothèque
je ne touche plus à rien avant de comprendre comment lire & écrire les CVs sans détruire mes décodeurs ... ::)
A bientot...
Olivier
-
Bonjour
Sur le fond, rien ne distingue la voie de programmation de la voie principale. J'y ai même ajouté la gestion des fonctions et quelques autres manques par rapport à l'original DCC++ .
-
Bonjour,
je ne suis pas entré dans les arcanes de DCCpp, aussi je me contente pour programmer mes locos du montage simplissime de la BaseStation :
UNO + shield à L298 + 2 straps + alimentation 12 V (bis repetita).
Montage que chacun devrait conserver dans un tiroir.
-
... la motrice s'affole (elle part en trombe) ...
typique d'une alimentation en courant continu à la place du DCC !
-
merci à tous pour les réponses, la sagesse me dicte donc de figer cette configuration pour "rouler" et de monter une station de programmation à part, j'ai de quoi la faire en plus, j'ai tous les composants.
étrangement, la lecture des CVs est 'tombé en marche' j'arrive à lire avec <r CV x y> adresse, ID etc... étrange, je n'ai rien touché, juste refait mon câblage loco (plus) au propre : un mauvais contact ? si c'est ça, mon CAP d'electronicien d'équipement est à revoir ;D
Serial et Autotest tournent (enfin ils s'executent, car c'est ma loco de test qui tourne, le circuit est rond pour le moment) donc comme dirait nos amis italiens "va bene" 8)
demain après-midi, direction Dreux (en voiture, pas pratique en train de chez moi et on débarque à trois)
A bientot,
Olivier
-
Bonjour Olivier,
Bonjour,
en attendant la réception des nouveaux composants, j'ai réussi à redémarrer ma station et compris ce qui clochait...
c'est en fait mes 2 décodeurs d'essai que j'ai flingués, j'en ai reçu depuis 2 autres, d'une autre marque et c'est reparti je sais commander le déplacement de la motrice, allumer/éteindre les feux, 8) donc la vie est belle, sauf que ...
Ce qui m'interpelle c'est pourquoi et comment avoir flingué les décodeurs ???
C'est costaud ces petites bêtes et il faut y aller fort : tension trop élevée, connexions au moteur et la loco...
Pourquoi ?
-
Bonjour,
j'ai une alimentation 20V (stabilisée, 19,7V mesurés), j'en recois une 18V lundi, peut etre une piste ?
elle n'est peut etre pas si bien régulée que ça après tout...je ne touche plus à rien et je la change lundi.
coté connexions, non j'ai bien fait attention au cablage, testé au multimètre etc
j'ai fait de la maintenance en labo d'electronique dans ma jeunesse, j'ai encore quelques bases !
on ne peut pas écarter la malchance du (re)débutant, la loi de Murphy and so on
par exemple, lors de mes manips en croisant les composants, une carte LMD18200 a explosé, condensateur chimique à l'envers, imparable, ils sont farceurs ces chinois.
les locos ont plus de 40 ans mais le circuit est neuf, ma concentration et ma vue a 60 ans passés n'aident pas non plus ???
Olivier
-
20V pour des essais me semble un peu risqué. Surtout si il y a des ampères derrière.
Les décodeurs LAISDCC sont spécifiés pour 15V.
De mon expérience, les composants grillés relèvent plus souvent de la fausse manip que du composant défectueux.
Et parfois les décodeurs ressuscitent après un reset.
Les grandes douleurs sont muettes pour les composants aussi.
Une petite photo du banc de test ?
-
bonsoir,
décodeur JOUEF/HORNBY R8249, pas de tension max indiquée dans la doc
décodeur TAMS (celui qui fonctionne en ce moment) LD G 42, est indiqué 12-24V
j'ai hésité à utiliser cette alimentation 20V et ai eu surement tort ...d'ou la commande d'une version 18V qui semble utilisée assez souvent, notamment dans l'article "Une station DCC complète, polyvalente et économique avec JMRI"
voici une photo de mon labo, pas rangé...
(https://ibb.co/Pj3DV5Y)
-
Pris au vol sur internet :
The Hornby system differs from the conventional type of 12V controllers in as much that it is the individual locomotives that are controlled internally rather than the controlling of a locomotive s speed and direction by varying the current to the track. The Hornby Select and Hornby Elite digital units when connected to the track pass not only a constant 15V AC voltage along the rails but also information signals to all locomotives and accessories that are on or are connected to the track. Each locomotive that is DCC controlled must have internally fitted a small micro processor based receiver called a decoder.
En fait le "AC voltage" est un signal carré, et donc chez HJ, il serait donné pour 15V.
TAMS dit aussi "16V max en courant analogique" : pourquoi un décodeur tiendrait mieux en DCC qu'en continu (alors que la tension est carrée) ?
24V lus sur un multimètre réglé sur AC ?
LENZ alimente ses centrales Z21 en 18V.
De toute manière, je pense qu'il vaut mieux éviter de faire fonctionner les moteurs HO avec plus de 14V.
Et on a tous sur la conscience quelques composants victimes de fils volants atterris là où il n'aurait pas fallu ...