Auteur Sujet: Projet Dominique  (Lu 2153 fois)

DDEFF

  • Sr. Member
  • ****
  • Messages: 413
    • Voir le profil
Re : Projet Dominique
« Réponse #15 le: mai 23, 2017, 04:18:15 pm »
Bonjour Marc-Henri,

Je rebondis sur
Citer
des cartes regroupant freinage et détection
Freinage ?
J'imagine que c'est lié au système ABC de Lenz ? (la Brems-diode, le contact et le relai)

Sur le schéma que tu indiques, je vois bien 2 diodes tête bêche, d'où le 0,7 V. OK
Mais, par ailleurs, il faut aussi 0,7 V pour déclencher le transistor.
On doit être tangents...
Tu prends quoi, comme transistor ? un "TUP" comme ils disaient sur Elektor ?

Je suis content que tu l'aies testé et qu'il fonctionne. C'est une bonne nouvelle.
D'autant que le système ABC de Lenz fonctionne aussi sur des chutes de potentiel de diodes.

PS : c'est un des avantages d'être Helvète : tu saisis certainement plus vite que moi le sens des textes en allemand !  ;)
Et pourtant, j'ai été nourri au Märklin-Magazin  ::)
« Modifié: mai 23, 2017, 10:32:18 pm par Dominique »

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 641
  • 100% Arduino et N
    • Voir le profil
Re : Projet Dominique
« Réponse #16 le: mai 23, 2017, 10:09:09 pm »
Bonjour Marc-Henri,

Je crois que je vais tester ce circuit, ainsi que celui de Pierre et comparer tout cela avec le mien.
Merci pour cette information.

Dans mon schéma, j'avais prévu des diodes Schottky SB260 qui passent facilement 2A. J'avais vu un peu grand car ces diodes ne perdent que 0,3 à 0,5V (voir les courbes ci-dessous) quand le courant est inférieur à 1A, ce qui est le cas d'une loco en N.

Même en en mettant 2 en série, il arrive que le transistor ne conduise pas assez pour l'optocoupleur.

J'ai été obligé de remplacer 2 des diodes SB260 par des 1N5819 qui sont limitées à 1A mais dont la chute de tension démarre à 0,75V (donc 1,5V avec 2 en série).
Pour le moment aucune diode ne m'a fait faux bond ;)

J'ai voulu utiliser des diodes rapides (schottky) car c'est recommandé pour ne pas dégrader le signal DCC.

Je n'ai pas essayé avec des bêtes 1N400x mais ça marche peut-être bien (en tout cas la chute de tension est bien supérieure).

Quelqu'un a-t-il un avis sur les diodes classiques (Pierre a utilisé de simples ponts redresseurs) ?

Amicalement
Dominique
« Modifié: mai 23, 2017, 10:16:57 pm par Dominique »
“Those who predict the future we call futurists. Those who know when the future will happen we call billionaires.” Horace Dediu

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 641
  • 100% Arduino et N
    • Voir le profil
Re : Projet Dominique
« Réponse #17 le: mai 23, 2017, 10:31:09 pm »
En ce qui concerne le freinage, c'est le gestionnaire qui enverra un ordre de ralentissement au train. Il doit donc connaitre le N° de train présent devant un signal de ralentissement, car c'est du DCC.

C'est un challenge pour moi, très excitant   8)

J'ai déjà fait des tests concluants et j'ai plusieurs façon d'y arriver. J'en ai parlé un peu dans ce fil -> http://forum.locoduino.org/index.php?topic=245

Ce sera décrit plus loin dans mon projet, quand j'aurai trouvé la ou les meilleures solutions.

Patience ...
“Those who predict the future we call futurists. Those who know when the future will happen we call billionaires.” Horace Dediu

DDEFF

  • Sr. Member
  • ****
  • Messages: 413
    • Voir le profil
Re : Projet Dominique
« Réponse #18 le: mai 23, 2017, 11:06:53 pm »
Bonsoir Dominique,

Dans le schéma proposé par Marc-Henri, comme le transistor n'est pas Shottky, il lui faut ses 0,7 V pour se déclencher et allumer la LED de l'optocoupleur...
Effectivement, 2 diodes Shottky en série, ça peut ne pas suffire.

J'ai une question bête :
L'ABC de Lenz déclenche le freinage s'il y a 0,6 V de différence entre une alternance et l'autre (relatif) ou à 0,6 V (absolu) ?
Parce que si c'est relatif, on peut mettre 2 diodes normales en série... dans tous le détecteurs.

Denis

Marc-Henri

  • Jr. Member
  • **
  • Messages: 62
    • Voir le profil
    • Modélisme ferroviaire & électronique
Re : Projet Dominique
« Réponse #19 le: mai 24, 2017, 07:47:51 am »
Bonjour à tous,

Je prévois effectivement un freinage ABC avec 4 diodes dans un sens et 1 dans l'autre, le tout commuté par un relais. Je confirme que c'est bien l'écart relatif entre l'alternance positive et l'alternance négative du signal DCC qui déclenche le freinage ABC. Et donc, comme Denis le mentionne, cela devrait aussi fonctionner avec une chute de tension de 1.4 V pour la détection. Mais j'aime bien l'idée de ce circuit par rapport à celui à 4 diodes. Le transistor PNP est un BC 327.

Il faut que je vérifie avec quel type de diode j'ai fait mon test ! S'il s'agit de diodes de redressement 1N400x, le temps de recouvrement de 30 us limite la fréquence du signal à 15-20 KHz, le signal DCC peut être assimilé à un signal carré de 8-9 KHz (période = 2 * 58 us, durée du 1). J'ai peut être eu de la chance en étant proche des limites.

ESU préconise l'utilisation de diodes UF5404 pour réaliser le freinage ABC. Cette diode a un temps de recouvrement de 75 ns et une tension de seuil du même ordre de grandeur que celle des 1N400x.

Bonne journée à tous.
« Modifié: mai 24, 2017, 12:55:12 pm par Marc-Henri »

CATPLUS

  • Jr. Member
  • **
  • Messages: 76
    • Voir le profil
Re : Projet Dominique
« Réponse #20 le: mai 24, 2017, 07:25:46 pm »
Bonjour

Pour rebondir, j'utilise le montage cité en amont. Les diodes de type 1N5400 ou BY.. sont parfaites pour le DCC
J'ai fait 64 décodeurs et aucun problème à ce jour.

Lorsque je pratiquai l'analogique, j'avais fait également des détecteurs à diodes 1N400x avec alim 24 volts et bon nombre de ces diodes ont claquées
je pense que ces incidents étaient dues aux tensions trop justes pour les modèle 1N400x

Amicalement
Marcel
Best Regards

Marc-Henri

  • Jr. Member
  • **
  • Messages: 62
    • Voir le profil
    • Modélisme ferroviaire & électronique
Re : Projet Dominique
« Réponse #21 le: mai 25, 2017, 11:28:13 am »
Bonjour à tous,

Je viens de procéder à de nouveaux tests avec les diodes dont je dispose.

1N4002G
Tension inverse max 100 V. Temps de récupération 2 us.

1N4007H
Tension inverse max 1000 V, Temps de récupération 2 us.

J'ai comparé l'allure du signal DCC à l'oscillo avant, après le détecteur, après le freinage ABC, sans constater aucune différence visible. La loco réagit toujours aux commandes. Je pense qu'un temps de 2 us reste compatible avec les durées des demi-périodes DCC de 58 us (1) et 100 us (0).

Bon week-end prolongé.

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 641
  • 100% Arduino et N
    • Voir le profil
Re : Projet Dominique
« Réponse #22 le: mai 25, 2017, 05:03:11 pm »
Merci Marc-Henri,

C'est convainquant ! Les diodes Schottky ne sont pas nécessaires.

Bon week-end aussi si la Suisse a le même pont.
Pour moi c'est le pont tous les jours  :D

Bien cordialement
Dominique

PS: j'adore le train en métrique qui va de Martigny à St Gervais. Chaque fois je visite la fondation Pierre Gianadda. Parfois j'ai la chance de cueillir de délicieux abricots du Valais !
“Those who predict the future we call futurists. Those who know when the future will happen we call billionaires.” Horace Dediu

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 641
  • 100% Arduino et N
    • Voir le profil
Re : Projet Dominique
« Réponse #23 le: juillet 21, 2017, 07:46:50 pm »
Je reprends doucement la description de mon réseau !

Nous en étions aux détecteurs d'occupation qui sont reliés, chez moi, au TCO physique. J'avais aussi parlé du module de commandes d'aiguilles, du module de traction et du gestionnaire.

Au départ je n'avais pas idée de la manière de gérer l'ensemble du réseau par un gestionnaire, je ne soupçonnais pas l'étendue de la complexité et le nombre de choses à relier ensemble.

C'est pour cela que le découpage en modules reliés par un bus CAN m'a semblé idéal.

Pour mettre les idées en place, les rôles du module TCO physique (avec des leds et des clés) devait :
  • représenter l'ensemble du réseau de façon simple
  • récupérer les occupations et allumer une led rouge dans la zone de la détection
  • permettre de commander les aiguilles
  • visualiser le sens droit ou dévié de chaque aiguille par une led verte allumée du bon coté
  • envoyer des messages au gestionnaire à chaque changement d'occupation ou de libération
  • envoyer des messages au gestionnaire à chaque changement de clé d'aiguille
  • recevoir des messages du gestionnaire pour allumer les leds d'aiguille

Il a donc fallu définir un certain nombre de messages CAN comme ceci :

Id CAN en Reception :
  • Id = 20H (commande de led clef)
  • Id = 21H (demande d'état de toutes les clefs)
Id CAN en  Emission :
  • Id = 11H (clef d'aiguille)
  • Id = 10H (occupations)

Je reviendrai plus loin sur les valeurs des octets de message qui suivent l'ID (maximum 8 octets, je n'utilise qu'un seul octet en général).

Le choix des messages CAN est très structurant pour le projet. Mon choix n'est pas le seul possible, il faut bien choisir un jour. Car cela définit les filtres CAN, les fonctions d'émission et réception et le traitement des messages reçus (parsing en anglais, mot qui revient souvent sur Locoduino), que l'on retrouvera partout dans les modules du réseau.

J'ai donc :

Une routine d'interruption qui se charge de récupérer tous les messages CAN acceptés dans une mémoire tampon :
/*
 *  ISR CAN
 */
 
void MCP2515_ISR()
{
     Flag_Recv = 1;
}

/*
 * Routine de récuperation des messages CAN dans la memoire circulaire _Circule
 * appelee par LOOP lorsque Flag_Recv = 1;
 */
 
void CAN_recup()
{
  unsigned char len = 0;                // nombre d'octets du message
  unsigned char buf[8];                 // message
  unsigned char Id;                     // Id

  while (CAN_MSGAVAIL == CAN.checkReceive())  {
    CAN.readMsgBuf(&len, buf);          // read data, len: data length, buf: data buf
    Id = CAN.getCanId();
    if ((_Ncan+len+2) < sizeof(_Circule))  { // il reste de la place dans _Circule
      _Circule[_indexW] = Id;           // enregistrement de Id
      _indexW++;
      _Ncan++;
      if (_indexW == sizeof(_Circule))  {_indexW = 0;}
      _Circule[_indexW] = len;          // enregistrement de len
      _indexW++;
      _Ncan++;
      if (_indexW == sizeof(_Circule))  {_indexW = 0;}
      for (byte z = 0; z<len; z++)  {
        _Circule[_indexW] = buf[z];      // enregistrement du message
        _indexW++;
        _Ncan++;
        if (_indexW == sizeof(_Circule))  {_indexW = 0;}
      }
    } else {
      _CANoverflow = 1;   // depassement de la capacite de Circule
                          // message perdu (pas enregistré dans Circule)
    }
  }
}


Et le traitement des messages CAN dans la loop :
  /*
   *  traitement des messages dans le buffer _Circule
   */
   
  while (_Ncan > 2)  {                // messages dans _Circule : au moins 3 bytes
    //digitalWrite(LedV, HIGH);       // led activité CAN reste allumée jusqu'à loop suivante
    _Ncan--;
    RId = _Circule[_indexR];          // recup Id
    _indexR++;
    if (_indexR == sizeof(_Circule))  {_indexR = 0;}
    _Ncan--;
    Rlen = _Circule[_indexR];         // recup longueur
    _indexR++;
    if (_indexR == sizeof(_Circule))  {_indexR = 0;}
    if (_dumpCan)  {     
      Serial.print("CAN id ");
      Serial.print(RId);
      Serial.print(", data ");
    }
    for (int k = 0; k < Rlen; k++)  {
      _Ncan--;
      Rbuf[k] = _Circule[_indexR];  // recup octets message
      _indexR++;
      if (_indexR == sizeof(_Circule))  {_indexR = 0;}
      if (_dumpCan)  { 
      Serial.print("0x");
      Serial.println(Rbuf[k], HEX);
      }
    } // le message est dans les globales RId, Rlen et Rbuf[..]
    curCLEF = Rbuf[0] & 0x3F;       // garder que les bits 0..5 = index aiguille
   
    if (RId == RId_TCO_Clef)  {
      // 1 octet donnees:  bit 7,6 -> 1,1 et 5..0 -> 3F = envoi etats toutes clefs               
      if (curCLEF == 0x3F) {          // commande de lecture etats
        if (bitRead(Rbuf[0], 7)) {
          if (bitRead(Rbuf[0], 6)) {  // demande etat toutes clefs (data = 0xFF)
            EnvoiCAN_toutesClefs();
          }
        }
      }
    }
    if (RId == RId_TCO_Led)  {
      // 1 octet donnees:  bit 7,6 -> 0,0 = devie ou 0,1 = droit, bits 5..0 = numero clef
      if (!bitRead(Rbuf[0], 7)) {    // bit 7=0, commande de positionnement de Led sur une Clef d'aiguille
        if (curCLEF < MaxCLES) {     // numero de clef
          ListeClef[curCLEF].LedUpdate(bitRead(Rbuf[0], 6)); // bit 6 = position
          //affiche_vertes();      // affichage vertes + rouges plus loin
          if (_dumpCan) {
            Serial.print(" CAN : curCLEF ");Serial.print(curCLEF);
            Serial.print(" Aiguille "); Serial.print(ListeClef[curCLEF].NomClef());
            if (bitRead(Rbuf[0], 6)) {
              Serial.println(" DROIT");
            } else {
              Serial.println(" DEVIE");
            }
          }
        }                             
      }   
    }                                // fin changement leds aiguilles 
  }                                  // fin traitement messages CAN (while)

Les clés et les zones sont décrites sous forme d'objets comme on peut le voir dans le traitement ci-dessus.

Ma premiere réalisation (toujours en place sur le réseau) se limitait à 19 aiguilles (dont 2 TJD) donc avec 19 clés. Mon plan de découpage en zones se limitait à 42 zones.

Il se trouve que la prise en compte des signaux, des itinéraires, les possibilités de manoeuvres offertes par le Gestionnaire que j'avais un peu de mal à appréhender par manque d'expérience, sont devenus maintenant beaucoup plus clairs grâce à l'aide de Pierre59.

Cela a entrainé un certain nombre de modifications qui ne remettent pas en cause les développements matériels et logiciels que j'avais fait, grâce au découpage en modules et aux communications CAN.

Je reviendrai donc sur ces évolutions après la description du TCO.
“Those who predict the future we call futurists. Those who know when the future will happen we call billionaires.” Horace Dediu

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 641
  • 100% Arduino et N
    • Voir le profil
Re : Projet Dominique
« Réponse #24 le: juillet 22, 2017, 06:12:51 pm »
Description du TCO "en dur"

Je précise "en dur" car réalisé sur une plaque de plexi avec de vraies Leds et de vrais inverseurs (clés). En réalité il y aura d'autres TCO tels qu'un écran graphique piloté par le Gestionnaire et un écran HDMI piloté par un pcDuino8 sous Ubuntu, avec Processing qui sera décrit plus tard.

Première opération, la plaque représentative du réseau :



Le TCO est constitué d'une plaque de plexiglass blanc sur lequel est collée une représentation simplifiée du réseau, dans laquelle les cantons des tracés haut, bas et la boucle sont réduits sur la partie droite.
J'ai réalisé le dessin avec RailModeller Express (https://itunes.apple.com/us/app/railmodeller-express/id1008811516?mt=12), imprimé sur papier avec l'imprimante jet d'encre, plastifié et collé sur une plaque de plexi blanc avec de la colle en bombe Cléopâtre.

Cette plaque est percée au milieu de chaque canton pour loger une Led rouge indiquant l'occupation du canton. Elle est aussi percée au niveau de chaque aiguille pour loger une clé de sélection de position et 2 Leds vertes représentant la position des aiguilles.

Pour réaliser les perçages proprement après le collage du dessin, j'ai utilisé un emporte-pièce et j'ai marqué le plexi en faisant sauter un confetti de papier ce qui a permis ensuite de percer les trous au bon diamètre, sans risque de dérapage de la perceuse.



Après montage des inverseurs et des Leds (collées), la vue "en coulisse" du TCO est édifiante :



Le TCO est animé par un Arduino MEGA 2560 qui gère :
- 20 inverseurs d’aiguilles = 20 pattes : AG1 à AG20 sur 21 bornes avec Gnd
- 36 Leds vertes (positions aiguilles) : 5 x 74HC595 chainés = 3 pattes
- 36 Leds rouges (occupations) : 5 x 74HC595 chainés = +1 patte
- 35 Détecteurs occupation = 35 pattes
- 36 bornes avec Gnd (y.c. va-et-vient)
- Bus CAN = 5 pattes (port SPI)
- Console = 2 pattes (port USB)
AU TOTAL = 68 pattes sur 70 !

Schéma de principe des interface avec 74HC595 (il y a en tout 2 bancs de 5 74HC595):



La réalisation de cette carte à 74HC595 est faite sur une platine 100 x 160 mm que j'avais en stock depuis très longtemps :




Pour les raccordements, surtout pour avoir la plus grande fiabilité possible et permettre le montage et les modifications, j'ai ajouté sur le MEGA une carte Prototype de ce type (il en existe plein) :



J'y ai soudé des nappes au bout desquelles j'ai soudé des borniers à vis déportées de chaque coté du MEGA.



Cela fait un peu fouillis car je n'ai pas cherché à ranger les fils mais c'est très fiable et toujours accessible en soulevant la plaque du TCO montée sur charnière. C'est promis, mon prochain TCO sera plus professionnel.

On voit sur la droite la carte CAN Locoduino et au fond au milieu la carte 74HC595.

Des trous dans le fond assurent le passage des fils avec le dessous du réseau.

Pour le bornier de raccordement des occupations de zones, j'ai fait un tableau avec les relations entre les Pins du Mega raccordées aux détecteurs d’occupation, les Leds Rouges (coordonnées de la led dans la matrice de 74HC595) et les Zones.



Bien entendu il y a quelques bornes disponibles pour ajouter des détections d'occupation supplémentaires, ce qui va arriver, on le verra plus loin.

Depuis la construction de ce TCO (ça fait bien 2 ans minimum), je n'ai jamais eu de panne !
“Those who predict the future we call futurists. Those who know when the future will happen we call billionaires.” Horace Dediu

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 641
  • 100% Arduino et N
    • Voir le profil
Re : Projet Dominique
« Réponse #25 le: juillet 22, 2017, 06:43:36 pm »
Construction du contrôleur d’aiguilles

Le contrôleur d’aiguilles est construit sur une base Arduino Mega 2560 associé à une carte bus CAN et un ensemble de 40 relais qui commandent les 18 aiguilles (2 relais par aiguille) et 2 dételeurs (1 relai par dételeur).



L’Arduino est disposé coté tableau de bord tandis que les relais, disposés de chaque coté d’une planche de CP monté sur charnière, sont placés à l’intérieur, sous le circuit. Des câbles en nappes relient l’Arduino aux relais, comme expliqué pour le TCO, avec une carte prototype permettant la soudure des nappes pour un maximum de fiabilité.



Comme les aiguillages choisis sont des modèles Fleischmann à moteur à courant alternatif, j'ai utilisé 2 relais par aiguille, avec le schéma suivant :



Le relai Impulsion est activé 150 millisecondes après que le relai Sens est positionné selon le sens direct/droit ou dévié.

Les relais en couples sont affectés aux pins de l’Arduino (tout est noté dans un tableau):
Relais d'aiguilles 4,5(A),6,7(B),8,9(C),10,11(D) - 22,23(G),24,25(H),26,27(I),28,29(J) - 30,31(K),32,33(L),34,35(M),36,37(N) - 38,39(O),40,41(P),42,43(Q),44,45(R) - 12,13(E),14,15(F),46,47(S),48(T1),49(T2).
La carte CAN est raccordée par les pins : 50 (SO), 51 (SI), 52 (SCK), 53 (CS), 2 (INT).
Les pins A0, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15 restent libres pour le moment. Elles sont réservées pour des relais supplémentaires (ça va arriver, il y en a 4 maintenant installés) et des détecteurs complémentaires (RFID, Hall, IR).

Comme pour le TCO, le logiciel utilise les routines CAN décrites ci-dessus, avec des messages dont les Ids sont :
  • Réception Id = 0x4x (commande aiguille)
  • Emission, Id = 0x12 (etat aiguille)

Les aiguilles sont déclarées sous forme d'objets :
class Aiguille
{
  private:   
    byte index;             // 0, .. MaxAIG-1
    char nom;               // 'A' ou 'B' ...
    byte pin_sens;          // sens droit (HIGH) ou devie (LOW)
    byte pin_pulse;         // impulsion de commande : actif LOW
    bool etat;              // true = droit, false =  devie
    bool change;            // rafraichir la position en fonction de etat avec envoi CAN
    bool echoCan;           // rafraichir la position en fonction de etat sans envoi CAN si false
    bool curstep;           // true = pulse en cours, false = cycle fini
    unsigned long milli;    // temps systeme au debut de l'impulsion
   
  public:
    // ----------- constructeur complet ------------
  Aiguille(byte a_index, char a_nom, byte a_pin_sens, byte a_pin_pulse);

  void Setup();
  void Armer();
  void Rafraichir();
  void Caner();
  void Preparer(bool a_sens);     // sur reception message CAN: mise en liste
  void Bouger();                  // execute suivant sens avec envoi CAN
  void Positionner(bool a_sens);  // si changement - cas recurent
  void Forcer(bool a_sens);       // cas setup lecture EEPROM
  void MiseAJour();               // din de la periode : desarmement relais
  byte NomAig();
  bool EtatAig();
};

Une des astuces que j'aime bien est le rafraichissement des positions de chaque aiguille, une toutes les 10 secondes. Cela permet d'éviter quelques déraillements en cas de changement de position provoqué par exemple par un convoi entrant par un talon positionné differemment.

/*
   * Toutes les 10 secondes : rafraichissement d'une position d'aiguille
   */
   
  if (_Minute + 10000 < millis()) {                        // toutes les 10 secondes
    _Minute = _Minute + 10000;
    ListeAig[RafraichAiguille].Rafraichir();               // rafraichissment d'une position d'aiguille sans envoi CAN
    if (_debug) {
      Serial.print(" 10SEC : rafraich: ");Serial.print(RafraichAiguille);
      Serial.print(ListeAig[RafraichAiguille].NomAig());
      Serial.print(" ram ");Serial.println(_RamFree());
    }
    RafraichAiguille++;
    if (RafraichAiguille > MaxAIG-1) RafraichAiguille = 0; // pas de rafraichisement des Deteleurs, evidemment !
  }

Voici le traitement des messages CAN:

/*
   *  Récupération d'un seul message par loop dans la memoire circulaire _Circule
   */
   
  while (_Ncan > 2)  {                 // messages dans _Circule : au moins 3 bytes
    //digitalWrite(LedV, HIGH);       // led activité CAN reste allumée jusqu'à loop suivante
    _Ncan--;
    RId = _Circule[_indexR];        // recup Id
    _indexR++;
    if (_indexR == sizeof(_Circule))  {_indexR = 0;}
    _Ncan--;
    Rlen = _Circule[_indexR];       // recup longueur
    _indexR++;
    if (_indexR == sizeof(_Circule))  {_indexR = 0;}
    if (_dumpCan)  {     
      Serial.print("CAN id ");
      Serial.print(RId);
      Serial.print(", data ");
    }
    for (int k = 0; k < Rlen; k++)  {
      _Ncan--;
      Rbuf[k] = _Circule[_indexR];  // recup octets message
      _indexR++;
      if (_indexR == sizeof(_Circule))  {_indexR = 0;}
      if (_dumpCan)  { 
      Serial.print("0x");
      Serial.println(Rbuf[k], HEX);
      }
    } // le message est dans les globales RId, Rlen et Rbuf[..]
    curAIG = Rbuf[0] & 0x3F;      // garder que les bits 0..5 = index aiguille

    /*
     * commandes aiguilles CAN sur ID 0x40
     */
     
    if (RId == RId_AIGUILLE)  {
      // commandes relatives aux aiguilles
      // 1 octet donnees:  bit 7,6 -> 1,0 = devie ou 1,1 = droit, bits 5..0 = numero aiguille

      if (bitRead(Rbuf[0], 7)) {  // commande de changement d'aiguille
        if (curAIG < MaxAIG) {    // aiguille
          if (bitRead(Rbuf[0], 6) != ListeAig[curAIG].EtatAig())  {
            ListeAig[curAIG].Positionner(bitRead(Rbuf[0], 6)); // bit 6 = position
            BougeAIG[curAIG] = true;
            if (_debug) {
              Serial.print(" CAN : curAIG ");Serial.print(curAIG);
              Serial.print(" Aiguille "); Serial.print(ListeAig[curAIG].NomAig());
              if (bitRead(Rbuf[0], 6)) {
                Serial.println(" DROIT");
              } else {
                Serial.println(" DEVIE");
              }
            }
          }
        }
      }
    }
  } 

Les commandes d'aiguilles ne sont pas directement émises par le TCO (les clés) mais par le Gestionnaire.



Imaginons qu’une aiguille soit protégée pour laisser passer un convoi prioritaire : cette aiguille ne pourra être manœuvrée qu’après le passage du convoi. C’est ce que fera le gestionnaire : si je bascule la clé de l’aiguille sur le TCO, rien ne se passe ! Dès que le convoi est passé, l’aiguille change automatiquement et la Led sur le TCO, à coté de la clé, répercute ce changement.

Je vais donc bientôt décrire le Gestionnaire !
“Those who predict the future we call futurists. Those who know when the future will happen we call billionaires.” Horace Dediu

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 641
  • 100% Arduino et N
    • Voir le profil
Re : Projet Dominique
« Réponse #26 le: septembre 14, 2017, 04:15:47 pm »
Je fume, donc je suie (sic) !



La réalisation de mon réseau prend un peu de retard à cause d'un ennui mécanique à la hanche droite qui va nécessiter un échange standard dans quelques jours. Désolé mais ça fait mal et monter l'escalier du grenier qui conduit à mon chantier ferroviaire devient pénible. Les travaux reprendront en octobre.

En attendant je travaille sur la centrale de programmation des locos, à base de DCC++ bien entendu, avec reconnaissance automatique de l'adresse DCC de la loco posée sur les rails et la lecture de la loco de même adresse en base de donnée (EEPROM).

En parallèle, j'attends 2 aiguilles à coeur métallique pour remplacer 2 aiguilles endommagées sur mon réseau, j'ai encore quelques détections de consommation à câbler, et installer de nouvelles versions des logiciels sur mes modules :

- module de traction (le prochain à décrire) : remplacer CmdrArduino par DCC++ et ajouter les commandes de pilotage (avec signal  en cabine possible) pour forcer les arrêts, ralentissements 30 et 60 à partir du gestionnaire et un mode de reconnaissance automatique de la position des trains au démarrage du système (en plus des sauvegardes en EEPROM). Je veux garder la base de donnée complète (CVs) des locos dans le gestionnaire de programmation pour décharger au maximum la traction.

- module TCO : le tracé ayant légèrement bougé, je dois refaire la platine et intégrer de nouvelles détections. A coté du TCO "boutons-leds", il y aura un TCO sur écran graphique tactile 7 pouces, histoire de programmer du graphique pour se changer les idées !

- module aiguilles et dételeur : à mettre à jour.

- module gestionnaire à base du gestionnaire de Pierre59 : intégrer plus de messages, les signaux, les itinéraires, ...

- module de signalisation : à faire

- modules décors : passer des protos à quelque chose de plus définitifs (chantier d'expérimentations extraordinaire)

Et le tout, bien-sûr, relié  en bus CAN

A suivre...
“Those who predict the future we call futurists. Those who know when the future will happen we call billionaires.” Horace Dediu

bobyAndCo

  • Full Member
  • ***
  • Messages: 104
    • Voir le profil
Re : Projet Dominique
« Réponse #27 le: septembre 14, 2017, 05:58:07 pm »
Ouuuuuuh, là, les projets permettent de rester jeune. Tu en as encore pour au moins 50 ans alors.

Et plein de bonnes choses pour ton opération.

Christophe.

CATPLUS

  • Jr. Member
  • **
  • Messages: 76
    • Voir le profil
Re : Projet Dominique
« Réponse #28 le: septembre 14, 2017, 08:20:37 pm »
Dominique
Ci-joint la photo du 3,5" au 7" cela va être sympa

Bon courage et bonne réparation
Amicalement
Marcel
Best Regards

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 641
  • 100% Arduino et N
    • Voir le profil
Re : Projet Dominique
« Réponse #29 le: septembre 15, 2017, 07:53:32 pm »
Whaaaa !
Tu as fait des frais  8)

Amicalement
Dominique
“Those who predict the future we call futurists. Those who know when the future will happen we call billionaires.” Horace Dediu