LaBox" : Une Centrale DCC polyvalente et abordable

[lebelge2]

Tout à fait d’accord avec toi, gbo95, les diodes ne sont pas nécessaires dans ce cas-ci.

[trimarco232]

sauf si elles permettent de se débarrasser des quelques pointes parasites , dont le DCC est un vil générateur . Faites comme vous voulez , mais moi je les laisserais .

[Dominique]

Moi aussi.

[JeanMarc]

Bonsoir à tous,

Je suis resté longtemps sur la version 2.4.6 sans problème de fonctionnement particulier et je ne voulais pas évoluer.
Maintenant RailCom est arrivé avec la possibilité d'utiliser la dernière évolution XpressNet proposée par Lebelge2 pour utiliser une Multimaus.
J'ai commandé des PCB en version 1.0a5 sur lesquels j'ai déposé les diodes D1 et D2. Et j'ai évidemment chargé la dernière version 2.10.0

Je reviens sur cette première anomalie un peu ancienne

Bonjour
Il semble qu'effectivement il y ai un problème de redémarrage après une lecture/écriture de CV. Le reboot ne semble pas fonctionner. J'avais déjà corrigé un problème similaire dans les versions précédentes en décalant l'initialisation de Railcom. De mon côté je ne reproduis pas... Et sans reproduction, difficile de corriger quoi que ce soit.
Il faudrait déjà que ceux qui ont le problème essayent de désactiver Railcom pour voir si c'est bien la cause, ou en tout cas ce qui le provoque. Une fois le coupable identifié, je tenterai de reproduire le problème puis de le résoudre.

Je n'ai pas vu s'il y a eu une suite à cette anomalie.
En tout cas, je confirme que si Railcom est activé, Labox semble redémarrer en permanence après avoir quitté le mode programmation.
Seul un reset de l'ESP32 remet la box en mode pilotage. Et re connectable en wifi. Les deux leds sont allumées.
En revanche, tout semble bien fonctionner, traction et fonctions diverses. Le mode programmation aussi au prix du reset de l'ESP32 après coup !
Mais je ne sais pas si Railcom fonctionne, je n'ai pas d'oscilloscope.

Quand je désactive Railcom, Labox redémarre silencieusement en mode pilotage après avoir quitté le mode programmation.
Mais seules les fonctions sont actives (FO,F1,F2, etc...), pas la traction...et pas de programmation possible non plus.

Et puis il y a eu cette deuxième anomalie a priori sans suite également

Bonjour.
Je viens de télécharger et installer la dernière version de CommandStation pour LaBox (V.2.10) sur un PCB  V.0.2 modifié.(Sans T1-R1-R2)
Par défaut, Enable RailCom est désactivé.
Il manque une phase, seule la Pin 33 fonctionne. (Une LED allumée)
Avec un PCB non modifié, le transistor T1 génère la seconde phase et on ne constate certainement pas l’anomalie.

Avec Enable RailCom activé,  les deux LED sont allumées, les loco. fonctionnent mais sans RailCom car le CutOut est déformé (voir image)

Impossible aussi de lire les CV car il n’y a qu’une phase qui fonctionne.

A voir si d'autres personnes ont les mêmes problèmes...

Bien à vous.

Et je confirme que j'ai le même phénomène, seule la led gauche est allumée.

Si j'ai pu faire avancer le schmilblick !

Bien cordialement,
Jean Marc

[Thierry]

Je confirme bien les comportements décrits. Je n'avais pas de quoi tester, mais avec mon exemplaire de 1.0a3, j'ai bien ces problèmes. J'y travaille...
Et vu le comportement, je tablerai sur des corrections purement logicielles puisque ça peut marcher à un #define près...

[JeanMarc]

Bonsoir à tous,

Merci Thierry pour ton engagement !
Je suis bien content que tu aies pu reproduire ces anomalies non reproduites le 14 janvier dernier.
Tu vas trouver, j'ai confiance !
Encore merci pour ta disponibilité.
N'hésite pas à reprendre contact si tu veux que je fasse des tests (sans remonter systématiquement version après version par le Github...qui prend du temps)

Ce qui m'étonne est que personne, a priori, n'ai remonté ces anomalies  ...à part Lebelge2.
Sommes nous les seuls à utiliser cette nouvelle version et nouveau PCB ?

Bien cordialement,
Jean Marc

PS: Hier, j'ai omis de préciser les versions de bibliothèques installées sur mon ordi
Framework ESP32 V2.0.14
ACAN_ESP32 V1.1.2
One Button V2.6.1
ADAFruit GFX Library V1.12.0
ADAFruit SSD 1306 V2.5.15

[Thierry]

Tu veux bien essayer de modifier DCCRMT.cpp ligne 197 (environ) et mettre en remarque le test ifdef ENABLE_RAILCOM et son 'else' pour ne laisser que le addPin(pins.invPin, true);

   //#ifdef ENABLE_RAILCOM
  addPin(pins.invpin, true);
   /*#else
  addPin(UNUSED_PIN, true);
   #endif*/

Ca devrait au moins permettre de faire fonctionner Labox sans Railcom.
Je continue sur le reboot intempestif...

[JeanMarc]

Bonjour Thierry,

Merci de poursuivre tes investigations !
Pas de soucis pour faire ce test, mais il faudra attendre ce soir pour le résultat, je suis pris par d'autres obligations toute la journée.

Bien cordialement,
Jean Marc

[JeanMarc]

Bonsoir Thierry,

J'ai fait la modif, et Labox fonctionne normalement, MAIS elle continue de booter après un retour en mode pilotage suite à une programmation.
Le reset de l'ESP remet tout en ordre, rien n'a changé.

Je ne comprends pas ta démarche:
D'une part, cette modification laisserai le Railcom actif ?
Alors que tu souhaites arrêter le Railcom...
D'autre part, je pensai qu'il suffisait de dévalider le #define ENABLE_RAILCOM ligne 245 du config.h pour désactiver le Railcom ?
N'hésites pas à revenir vers moi pour d'autres tests.
Demain je serai beaucoup plus disponible qu'aujourd'hui.

Bien cordialement,
Jean Marc

[lebelge2]

Bonjour, je vous fais part de mes tests sur la version 2.10.0

1) Fait la modif ligne 197 comme demandé.
2) Réutilisé la variable  dp_rc   comme sur la version précédente (+/- ligne 151)

- RaiCom OK
- CV OK
- Nouveaux bargraph verticaux OK

Reboot en boucle après CV.

Bien à vous

[Thierry]

La correction demandée répondait seulement au second point de problème, soit le fonctionnement normal de Labox en version sans Railcom.

Pour le reboot avec Railcom, je n'ai pas trouvé, je continue de chercher.
Ce que je sais :
- Esp.restart qui est utilisé pour redémarrer l'ESP ne fait pas un reset complet, dixit le commentaire dans le fichier .h de la fonction :

Code: [Sélectionner]

/**
  * @brief  Restart PRO and APP CPUs.
  *
  * This function can be called both from PRO and APP CPUs.
  * After successful restart, CPU reset reason will be SW_CPU_RESET.
  * Peripherals (except for WiFi, BT, UART0, SPI1, and legacy timers) are not reset.
  * This function does not return.
  */
void esp_restart(void) __attribute__ ((noreturn));

ce qui explique qu'un reset au bouton corrige le problème.

- J'ai construit des fonctions end() pour à peu près tout pour clôturer WIFI, RMT, HMI, les Tracks, l'EEPROM, la liaison série,  et d'autres choses que j'oublie, plus un délai de 6 secondes nécessaires d'après plusieurs sources avant de lancer le restart mais ça ne corrige pas le problème.
- Selon les évolutions que je fais subir à mon code, j'ai des messages type WatchDog sur CPU1 qui semblerait lié à la routine d'interruption de Railcom, ou des plantages francs dès l'appel de la réinitialisation de Railcom par RailcomBegin().
- Mes tentatives de débrancher cette interruption avant le restart ne fonctionnent pas...

[Thierry]

2) Réutilisé la variable  dp_rc   comme sur la version précédente (+/- ligne 151)

Je l'ai retirée parce qu'elle me semblait inutilisée... Quel est son rôle ?

[lebelge2]

Bonjour Thierry
Au sujet de la variable dp_rc:
Cette variable n'apparaît pas dans mon code original sur GitHub (ligne 115): https://github.com/Lebelge2/CutOut-to-CommandStation-EX/blob/main/DCCRMT.cpp
Quelqu'un l'a rajoutée.
Le code suivant fonctionne correctement avec ou sans RailCom:

Code: [Sélectionner]

byte n = 0;
#ifdef LABOX
#ifdef ENABLE_RAILCOM
  setDCCBitCutOut(preamble);       // Symbole CutOut
  n = 1; 
#endif
#endif
  for ( n; n < plen; n++)
    setDCCBit1(preamble + n);      // preamble bits
#ifdef SCOPE
  setDCCBit0Long(preamble + plen); // start of packet 0 bit long version
#else
  setDCCBit0(preamble + plen);     // start of packet 0 bit normal version
#endif
  setEOT(preamble + plen + 1);     // EOT marker

Bien à vous.

[Thierry]

Bonjour à tous

Après quelques déboires, je vous ai préparé une version 2.11.0 qui devrait améliorer les choses :

- Pour une question de praticité, j'ai autorisé la définition d'une adresse IP fixe pour le Wifi. Fini de devoir se reconnecter sans arrêt sur l'app parce que l'adresse change à chaque connexion. C'est dispo aussi bien en AP qu'en STA via un routeur.
- Suite à la proposition de Lebelge2 de pouvoir fixer l'adresse d'une CV avec WiThrottle ou l'app Z21, j'ai repris l'idée en l'amendant fortement (forcément...). Il est donc possible maintenant de se servir d'une commande de vitesse et direction de loco sur une app pour fixer le numéro de CV, mais aussi sa valeur.
- Dans l'interface Sprog, l'interface Serial utilisée est définie par un define dans config.h .
- Et enfin ce que vous attendez tous, il n'y a plus de besoin de rebooter l'ESP pour lire ou écrire des CVs lorsque l'on utilise seulement la sortie DCC de Labox. J'ai tiré parti d'une possibilité de EX-CommandStation qui permet à la voie de programmation de 'rejoindre' la voie principale. Le but étant de sortir l'engin moteur de cette voie de programmation qui normalement n'autorise pas les commandes autres que la programmation. La conséquence que je n'ai pas pu mesurer concerne l'étendue des possibilités qui est peut-être réduite à cause du 'join'. Si des choses ne sont plus possibles (fonctions étendues, commandes externes sur des accessoires...), dites le moi je verrai si le vérrou peut être retiré. Pour comprendre le nouveau fonctionnement, je vous met en copie le commentaire de l'enum ProgBehavior :

Code: [Sélectionner]

/*
According to the kind of track configuration, there is 3 possible behaviors :
- The base configuration is a prog track only, which joins the main track for normal operations.
In that case, the program behavior is "joining". This is the default configuration.
- If there is a Main track and boosters, the program behavior is "rebooting" the system to change
the configuration. This does not always work with Railcom.
- If there is a Main and a Prog track, the program behavior is "normal".

A Main track only configuration is not anymore necessary, as the prog track can join the main track.

Name Config main prog

Prog only NULL PROG NULL NULL joined unjoined
Main only MAIN NULL NULL NULL reboot (not railcom) reboot
Main+boosts MAIN NULL BOOST1 BOOST2 reboot (not railcom) reboot
Both MAIN PROG NULL NULL normal normal
Both+boost MAIN PROG BOOST NULL normal normal
*/
Le seul cas litigieux concerne l'usage de boosters sans voie de programmation. Ce mode réclame encore de rebooter (c'est géré), mais ça ne marche pas toujours... Le seule solution reste de rebooter physiquement l'ESP.
La version jointe n'est pas dans Github, j'attend vos tests. Attention, le config.labox.h a changé, et le .ino aussi !

[Dominique]

Thierry, c'est un gros travail, super, qui va nécessiter des tests : je vais m'y mettre !

Un grand merci !