Contrôle numérique des aiguillages

[bricoleau]

Bonjour

La bonne nouvelle, c'est que je comprends toutes ces questions et que je me les étais déjà posées en codant le biniou.
Donc si je ne me suis pas gourré quelque part, cela devrait le faire.

Bien sur si l'aiguille est déjà en position droite, un ordre de bascule droit ne fait rien.

A tout moment, le maître I2C peut interroger le contrôleur pour savoir où il en est.
L'information retournée est :
- la position cible des 4 aiguilles, issue du dernier ordre reçu du maître
- la position actuelle des 4 aiguilles : si différente de la position cible, c'est que le contrôleur est en train de travailler
- le nombre de bobines actuellement sous tension.
- et si aucune bobine n'est sous tension, la durée écoulée (en ms) depuis la dernière mise hors tension de bobine.

Je reprends ton exemple :
"Alim 3 A, aiguille qui consomme 0,8 A pendant 10 ms et 0,4 A pendant 40 ms."

Là tu introduis une nouveauté à laquelle je n'avais pas réfléchi : une consommation décroissante des aiguilles.
Mon contrôleur est un poil plus basique.
Il est prévu pour raisonner en nombre de bobines actives à un instant t.

Ainsi sur ton exemple, je limiterais à 3 le nombre d'aiguilles actives simultanément sur tout le réseau, de la manière suivante :
Au niveau d'un contrôleur : durée d'impulsions à 100 ms (par exemple) et intervalle entre impulsions à 40 ms.

Au niveau du maître I2C, deux possibilités :
Simple : attendre que le dernier contrôleur sollicité soit revenu au repos avant d'en solliciter un autre
Sophistiqué : à partir des informations retournées par le contrôleur, on peut évaluer le nombre maximum de bobines qu'il lui reste à activer, et utiliser la puissance disponible pour commencer à solliciter un autre controleur.

[bricoleau]

Pour compléter :

La position actuelle est mise à jour dès le début d'impulsion sur la bobine.

Donc par exemple, si le maître reçoit :
- position cible = (COURBE, COURBE, DROIT, COURBE)
- position actuelle = (COURBE, COURBE, DROIT, DROIT)
- nb bobines actives = 1

Cela veut dire qu'une bobine des trois premières aiguilles est actuellement sous tension (je n'ai pas estimé utile de préciser laquelle), et que derrière il restera encore une bobine à activer pour la quatrième aiguille.

Donc ce contrôleur pourra encore avoir au maximum deux bobines actives simultanément, ce qui autorise à basculer une aiguille d'un autre contrôleur.

C'est sur que le maître va avoir du taf pour suivre et piloter tous les contrôleurs.
Il va y avoir des portions de code sophistiquées, à camoufler dans des librairies.

J'ai aussi évalué qu'il ne devrait pas y avoir de problème de saturation de bande passante du bus I2C :
Une trame I2C retour fait 20 octets, soit dans les 200 bits transmis sur le bus I2C (incluant les bits de protocole) à 100 kHz, donc un temps de transmission de l'ordre de 2 ms.
C'est encore loin du biorythme d'une impulsion d'aiguille.
Et de toute manière, même s'il y a beaucoup de contrôleurs sur le réseau, le maître n'a besoin de dialoguer qu'avec les quelques uns qui sont actifs à un instant t.

[DDEFF]

Bonjour,
Tu ne l'avais peut-être pas programmé, mais tu l'avais pensé très fort (et même écrit) :
C'est à la mise sous tension et à la retombée que la bobine consomme le plus. Une bobine, ça s'oppose au changement.
Et, à voir la bobine des gens, ça doit être vrai aussi pour d'autre chose que les selfs...

Donc, dans mon exemple, tu as comme consommation :
00 - 10 ms = 0.8 A
10 - 20 ms = 1.2 A
20 - 30 ms = 1.6 A
30 - 40 ms = 2.0 A
40 - 50 ms = 1.6 A
50 - 60 ms = 1.2 A
etc

Donc malgré les 4 aiguilles, tu culmines "seulement" à 2A

Autre remarque : si on ne s'intéresse qu'à la consommation, l'ordre peut être indifférent.
Ce serait plus joli (et plus conforme) que les aiguilles d'un itinéraire donné bougent dans l'ordre.
Mais si on arrive à ne pas faire exploser l'alim, c'est déjà un bon point 

A mon avis, ta gestion du module est bonne.
Reste le maître...

[bricoleau]

Fichtre !
L'ordre d'itinéraire, je n'y avais pas pensé !

Je croyais que les modélistes ferroviaires n'étaient que des vieux papis qui ne perçoivent plus l'ordre des événements, dès lors que ceux-ci durent moins d'une demi seconde 

[DDEFF]

En fait, tu raisonnes parfaitement avec 4 aiguilles.

Considère que tu as un gros module de 100 (!) aiguilles.
Et ce que tu fais pour que 4 bobines ne soient pas  alimentées en même temps, tu l'appliques à "n" bobines.
Parce qu'un itinéraire, ça va "picorer" des bobines dans plusieurs modules.

Je pense que c'est au "gestionnaire du réseau" de savoir dans quel ordre sont alimentées les bobines.
Et à ton "maître" de gérer l'alimentation.
D'un côté, le gestionnaire de réseau envoie des numéros de bobines à alimenter et, en sortie, ton maître alimente les bobines dans l'ordre qu'on lui a donné, mais en s'arrêtant de temps en temps quand trop de bobines sont alimentées simultanément. Et en n'envoyant pas l'ordre à la bobine si elle est déjà dans la bonne position.

Qu'en penses-tu ?

Denis

[bricoleau]

Oui c'est exactement ça.

C'est au maître d'assumer les règles de gestion multi-contrôleur, quand le réseau est complexe et que le besoin existe.

Cependant, je vois deux aspects dans le fonctionnement actuel du contrôleur, qui peuvent poser question :

1) lorsqu'un même contrôleur doit basculer simultanément plusieurs aiguilles, on n'est jamais sûr de la séquence de bascule.
Ce n'est pas géré dans les messages maître -> contrôleur
A partir du moment où une première bobine est alimentée, et que d'autres attendent de l'être, la séquence devient aléatoire.
Dans cette phase, le contrôleur passe sont temps à évaluer en boucle, aiguille après aiguille, si les conditions d'activation sont réunies.
L'événement déclencheur est le changement de valeur de la fonction millis(), qui peut intervenir à n'importe quel moment.
Pour avoir la maîtrise totale, il faudrait revoir le message maître -> contrôleur pour ajouter la notion de séquence de bascule.

2) le contrôleur est pensé pour raisonner sur le nombre de bobines actives simultanément, sans tenir compte des variations de consommation de courant entre le début / milieu / fin d'impulsion.
Pour aller dans ce sens, il faudrait revoir la gestion des bascules douteuses implémentée dans le contrôleur.

J'ai baptisé "bascule douteuse" une bascule DROIT ou COURBE appliquée à une aiguille dont la position est inconnue.
En principe, cela intervient lors de la première bascule après mise sous tension du système.

Lors d'une bascule douteuse, le contrôleur envoie deux impulsions successives, dont la durée est la moitié de celle d'une impulsion normale.
Mon idée était d'éviter de forcer sur la fin de course, dans le cas où l'aiguille serait déjà dans la position souhaitée.
Mais ce n'est peut-être pas une idée judicieuse, je n'ai pas l'expérience suffisante pour évaluer sa pertinence.

De plus, le maître I2C a également la possibilité d'ordonner au contrôleur d'oublier la position des aiguilles (fonction utile pour ensuite resynchroniser la position réelle des aiguilles avec leur position supposée, en passant par des bascules douteuses).

Du coup, cela fausse tes calculs de consommation.
Si le maître devait gérer la consommation au plus fin, il faudrait certainement prévoir de lui remonter plus d'infos.

[DDEFF]

OK, j'ai fait des calculs de consommation pour montrer qu'on ne va pas forcément avoir 3.2 A avec 4 aiguilles à 0.8 A chacune.
C'est un peu moins et c'est tant mieux. Cela donne une marge bienvenue.

Mais dans ton raisonnement, ne tient compte que d'aiguilles à 0.8A, sans parler de début/milieu/fin.
On n'en est pas là.
En plus mes données sont plausibles, mais sans plus. Il ne faut pas les prendre au pied de la lettre. C'est indicatif.

Par ailleurs, j'ai bien indiqué dans un  post précédent que l'ordre, c'était la cerise sur le gâteau. 

Un gestionnaire envoie les aiguilles à alimenter et leur positions.
Et ton maître se débrouille pour que toutes finissent à la bonne position, sans dépasser l'intensité maxi que l'alim peut fournir.

Autre écueil que je sens venir : qu'on balaie toutes les aiguilles avec une durée fixe (p. ex 50 ms).
Si on a 2 aiguilles à bouger , la 1 et la 100, il ne faut pas attendre 98 x 50ms entre les deux.
100, c'est aussi un exemple.
L'intérêt d'un trop grand nombre, c'est qu'on met en évidence les failles d'un raisonnement, grâce à la caricature amenée par un trop grand nombre.

Bon courage !
Denis

[DDEFF]

Faisons de ton programme un programme universel ! 

Il y a un gestionnaire de réseau. Cela peut être une vraie personne ou un programme.
Il assure la sécurité et donne les ordres.
Il est relié par un procédé quelconque à un maître conso.

Et c'est là que tu interviens. 

Le maître conso (un Arduino spécifique) gère 25 modules de 4 aiguilles via un bus I2C avec CRC.
Il reçoit l'info 1 courbe, 5 droit, 6 courbe, 15 droit, 25 courbe, 60 droit, 61 droit, 98 courbe pour un itinéraire.

Tout d'abord, il se rend compte que c'est trop pour l'alim 3A.

Il va donc ne lancer que les 4 premiers (4 x 0.8 ~ 3 A).

Le module 1 lance l'alimentation de l'aiguille 1 courbe pour 50 ms.
Le module 2 lance l'alimentation de l'aiguille 5 droit pour 50ms.
Mais le module 2 voit que l'aiguille 6 courbe est déjà en position et il envoie le OK tout de suite pour l'aiguille 6 courbe.
Le module 3 lance l'alimentation de l'aiguille 15 droit pour 50ms.

En recevant le OK du module 2, le maître conso lance l'alimentation du 25 courbe.
Et, à chaque fois qu'il reçoit un OK, il lance la suite.

En parallèle, il remonte l'info OK au gestionnaire du réseau à chaque OK reçu.

C'est, finalement, assez "simple" et pas de temps perdu.
On ferait pour 100 ce que tu faisais pour 4.

Denis

[Jean-Luc]

Denis a raison.

Gérer des synchronisation de manière décentralisée est un problème difficile. Il est préférable du point de vue du câblage et de la modularité d'avoir des systèmes distribués mais les décisions qui touchent le comportement global du système sont beaucoup plus simples à prendre si on les centralise.

[bricoleau]

Bonjour

J'arrive au bout de la première phase de prototypage.
Les tests sont OK sur le fonctionnement tel que je l'avais envisagé


Je vais à présent livrer le tout à mon "commanditaire", pour des tests en réel sur 4 aiguilles de son réseau.

Je joins également une librairie pour piloter un contrôleur, avec deux exemples de programmes :

• une console générique qui utilise le terminal Serie, et qui peut piloter jusqu'à 127 contrôleurs
• le code du contrôleur lui-même, à téléverser dans l'arduino pro mini

[bricoleau]

Liste des composants :

• 1 arduino pro mini 328P : 2€06 (10€30 les 5)
• 1 plaque de prototypage pastillée 5x7 cm : 0€135 (1€35 les 10)
• 2 ULN2803A : 0€34 (1€70 les 10)
• 2 supports pour CI DIP18 : 0€185 (1€85 les 20)
• 5 borniers à vis doubles : 0€35 (2€10 les 30)
• 1 barrette mâle 40 connecteurs : 0€12 (1€23 les 10)
• 1 cavalier : 0€01 (1€ les 100)

Ce prototype m'a donc coûté 3€20.
Evidemment, il s'agit de prix ebay chez des revendeurs chinois.
+quelques bouts de fil, un peu d'étain

[DDEFF]

Sympa.
Avant d'acheter des trucs, penses au site TME.
C'est livré par UPS le lendemain (ce qui n'est pas les cas des chinois, loin de là !!), à des prix vraiment sympa.
Exemples :
http://www.tme.eu/fr/details/uln2803a/drivers-circuits-integres/st-microelectronics/
http://www.tme.eu/fr/details/dg128-5.0-02p14/barres-de-serrages-pour-pcb/degson-electronics/dg128-50-02p-14-00ah/

[Dominique]

Bonjour,

Si cela peut t'intéresser, ou quelqu'un d'autre, j'ai réalisé mon contrôleur d'aiguilles (pour 20 aiguilles) à partir d'un Mega et 40 relais car j'ai des aiguilles Fleishmann Piccolo qui s'alimentent plutôt en alternatif (entre 12 et 15v)

J'ai réalisé le montage ci-dessous qui exclut que les 2 bobines soient alimentées en même temps. Cette tension alternative n'est présente que du coté des contacts mobiles des relais.

Cela me fait une belle platine à relais (5 barrettes de 8 relais, répartis des 2 cotés d'une planche en bois montée sur charnière sous le circuit pour permettre un accès facile aux borniers à vis.

Comme le dit Denis, j'ai mis un bus CAN pour piloter ce contrôleur par le gestionnaire du réseau.

Coté code, chaque aiguille est un objet C++ :

Code: [Sélectionner]

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();               // fin de la periode : desarmement relais
  char NomAig();
  byte EtatAig();
};

Bouger une aiguille se fait par l'appel de la méthode Armer() qui positionne le relai de direction (droit ou dévié) puis démarre l'impulsion envoyée au relai qui va alimenter la bobine désirée.

Code: [Sélectionner]

void Aiguille::Armer()
  {
   if (this->etat) {
    digitalWrite(this->pin_sens, HIGH); // Droit = HIGH
   } else {
    digitalWrite(this->pin_sens, LOW);  // Devie = LOW
   }
   digitalWrite(this->pin_pulse, LOW);  // demarrage relai pulse
   this->curstep = true;
   this->milli = millis();              // armement du timer
  }
Tu remarques d'une variable milli de l'objet mémorise le temps système.

Le fin d'impulsion est faite par la méthode MiseAJour(). J'ai choisi une durée d'impulsion PulseAiguille = 150ms.

Code: [Sélectionner]

void Aiguille::MiseAJour()
  {
    // gestion de la fin du cycle pour relacher les relais
    if (this->curstep && (milli + PulseAiguille < millis())) { 
    digitalWrite(this->pin_pulse, HIGH);    // retour relai pulse
    digitalWrite(this->pin_sens, HIGH);     // retour relai sens
    if (this->echoCan) {
      Caner();
    }
    this->change = false;
    this->echoCan = false;
    this->curstep = false;
    }
  }
Cette méthode est appelée en tâche fond dans la loop par :

Code: [Sélectionner]

for (int i = 0; i < MaxAIG; i++)  {
    ListeAig[i].MiseAJour();
  }
Où ListeAig[] est mon tableau de pointeurs sur les objets aiguilles.

Pour éviter de commander plusieurs aiguilles en même temps, j'ai une liste de booleans (1 par aiguille) qui permet de "marquer" chaque aiguille à bouger. Les aiguilles ne sont, en fait, pas commandées directement par les ordres reçus, mais par ce code appellé à chaque loop. Il y a 200 ms entre 2 commandes d'aiguilles.

Code: [Sélectionner]

/*
   *  Toutes les 0,2 secondes
   */
 
  if (_AigTour + 200 < millis()) { 
    _AigTour = _AigTour + 200; 
   
    if (BougeAIG[BougeAiguille])  {
      BougeAIG[BougeAiguille] = false;
      ListeAig[BougeAiguille].Armer();
      BougeAiguille++;     
      if (BougeAiguille == MaxAIG) {BougeAiguille = 0;}
    }
  }

L'inconvénient c'est qu'une aiguille n'est pas forcément commandée immédiatement mais en général ça parait instantané  à l'échelle humaine.

Au démarrage du système, soit je lis les positions initiales dans une EEPROM, soit je mets les aiguilles en conformité avec les clés du TCO (via le CAN)

J'ajouterai pour finir que j'ai ajouté une tâche périodique qui repositionne chaque aiguille dans l'état où elle devrait être, une aiguille toutes les 10 secondes. Cela évite quelques déraillement au cas où une aiguille aurait été déplacée inopinément.

Code: [Sélectionner]

/*
   * 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 !
  }

voilà !

[DDEFF]

Salut Dominique,

Très intéressant comme démarche.   

J'aime plusieurs choses :
1°) au niveau programmation par des objets distincts, programmation propre et claire,
2°) que 2 aiguilles ne puissent pas être commandées en même temps => pas de surchauffe de l'alimentation,
3°) que l'impulsion soit calibrée => pas de surchauffe d'une bobine,
4°) le rattrapage toutes les 10s de la cohérence bouton <-> position aiguille (super idée  ),
5°) la gestion de la mise sous tension, avec double choix, en plus !

Ce qui me chagrine un peu (mais je dors la nuit, rassures-toi  ), c'est la centralisation qui amène des fils longs et, donc, les chances de perturbations puisque ce sont des intensités assez élevées.

Au niveau structure, j'aurais mis les relais à proximité des moteurs d'aiguille avec un bus 15V qui va de relai en relai (en regardant bien qu'il soit loin de tout).
Donc, des fils courts avec une forte intensité.
Et on ne balade plus que des courants très faibles pour alimenter les relais, alimentés souvent par des optos sur les cartes de relais. Donc des courants de commande faibles, diminuant les perturbations potentielles.

Par exemple, découper par barrette de 8 relais pour 4 aiguilles seulement. Et un bus CAN qui y va.

Mais, par contrairement à toi, je n'ai pas testé et je raisonne dans l'absolu. Quand j'aurais mon réseau, je centraliserai peut-être aussi, ça a aussi des avantages.

Et on exagère peut-être aussi lesdites perturbations ?...

[savignyexpress]

Bonjour à tous,

Merci pour ces échanges intéressants sur la gestion des aiguilles, un sujet d'actualité pour mon nouveau réseau en N utilisant des moteurs d'aiguille Minitrix.

J'ai une approche similaire à celle de Dominique, soit l'impossibilité mécanique d'alimenter les 2 bobines d'une aiguille simultanément en reliant 2 relais en série: 1 pour le choix de la bobine, l'autre pour l'impulsion de commande. La commande par l'Arduino Mega est fonctionnelle, mais je rencontre 2 problèmes hors Arduino.

Perturbation d'un affichage LCD
J'ai un affichage LCD 2 * 16 relié à l'Arduino en 4 bits data et les signaux RS, R/W, E habituels. L'affichage est piloté par la librairie LiquidCrystal d'Adafruit, compatible avec LiquidCrystal de base.

L'affichage fonctionne bien, mais au bout de quelques mouvements d'aiguillage, il affiche des caractères bizarres ou s'éteint. J'ai testé avec une version du programme où les commandes d'aiguilles sont désactivées, le problème n'apparaît pas.

Perturbation d'un monostable à 555
J'ai un petit circuit annexe pour une autre fonction qui se déclenche intempestivement lorsqu'une aiguille est actionnée. J'ai ajouté les condensateurs de découplage préconisé dans la notice du 555, mais le problème subsiste.


J'ai une alimentation séparée pour les aiguillages, mais ces perturbations subsistent.

Mes questions...

• Avez-vous rencontré des problèmes similaires ? Si oui, comment les avez-vous résolu ?
• Les diodes de roue libre intégrées aux ULN2004 ont été évoquées. Je pense tester l'ajout de diodes, mais elles n'auront un effet que si le relais coupe l'alimentation avant le contact de fin de course du moteur d'aiguille. J'ai aussi vu sur le web la combinaison d'une diode de roue libre et d'un condensateur de 100 nF, mais je pense que la même remarque est applicable.
• La décharge capacitive améliorerait-elle la situation en raison de la diminution du courant résultant de la décharge ?
• Des câbles blindés pour entre les relais et les moteurs d'aiguille pourraient-ils être une solution ?
• Rapprocher les relais des aiguilles ainsi que le suggère DDEFF, quelqu'un a-t-il testé ?

Merci de vos réponses et meilleures salutations.