LOCODUINO

Parlons Arduino => Vos projets => Discussion démarrée par: bricoleau le janvier 12, 2016, 11:03:12 pm

Titre: Contrôle numérique des aiguillages
Posté par: bricoleau le janvier 12, 2016, 11:03:12 pm
Bonjour

Voici le petit chantier qui m’occupe actuellement, sur lequel j’aimerais bien recueillir vos avis éclairés  :D

Commençons d’abord par préciser que je n’ai aucun réseau à la maison, ni aucune expérience du modélisme ferroviaire. Mais j’ai d’autres compétences et centres d’intérêt qui font que je commence à maîtriser un peu arduino et ce qui gravite autour.

Un ami m’a demandé de lui filer un coup de main pour passer son réseau (courant continu) en commande numérique. Il dispose d’une quinzaine d’aiguillages électriques de type jouef, ainsi que quelques dételeurs, qu’il souhaite commander par ordinateur, ou par une centrale qu’il se fabriquera.

On n’est clairement pas dans du modélisme haut de gamme et dispendieux.
Du coup, pour rester dans la même philosophie, mon objectif était de lui proposer une solution bon marché. Suite à la lecture de plusieurs articles très intéressants sur locoduino, je suis parti sur la création de modules de commande d’aiguillages.

Chaque module a 8 sorties, pour gérer 4 aiguillages simples.
Il est constitué d’une arduino pro mini et deux ULN2803, dont les sorties sont couplées deux à deux pour être en mesure de fournir jusqu'à 1A aux bobines de l'aiguillage, bien que j’ai quelques doutes sur la pertinence de ce montage. L’expérience dira si cela tient la route longtemps.
Le tout est assemblé à la main, soudé sur une plaque de prototypage pastillée, avec une connectique de type bornier à vis côté 12V/Aiguillages.

L’arduino pro mini fonctionne comme un périphérique escale I2C. Les modules pourront être branchés en cascade, chacun ayant sa propre adresse I2C. Le tout devra être piloté par une centrale. Une foultitude d’options est possible à ce niveau-là, à affiner plus tard.

Je suis actuellement en phase de réalisation du premier prototype. Mon objectif initial est atteint : le coût matériel d’un module est de moins de 4€ frais de port compris, soit moins de 1€ par aiguillage à commander. Evidemment, il s’agit de composants achetés en ligne auprès de vendeurs asiatiques.

Photo avec les ULN2803 pas encore montés :
(http://forum.locoduino.org/index.php?action=dlattach;topic=124.0;attach=171;image)
(http://forum.locoduino.org/index.php?action=dlattach;topic=124.0;attach=173;image)

Pour les soudures, j’en suis resté aux gros pâtés d’étain bien baveux. Pas très doué à ce niveau-là  ;D

Si l'approche reste minimaliste côté hardware, c’est l’inverse côté logiciel embarqué dans l’arduino pro mini : aucune économie de neurones n’est tolérée. Je suis plutôt du genre à ne figer une version de code que lorsque je ne vois absolument plus rien d’améliorable.

L’arduino mini gère en autonomie le premier niveau de sécurité des aiguillages : durée des impulsions, contrôle d’exclusion des sorties contradictoires etc.
J’ai retenu ce principe de module « intelligent » pour sécuriser les équipements contre toute défaillance logique de la centrale en amont et/ou perte de la communication avec celle-ci.

Du coup, c’est dans les fonctionnalités « ferroviaires » que j’ai quelques doutes, du fait de mon manque d’expérience dans ce domaine.

Voici ce qui est réalisé pour l’instant :
L’arduino mini reçoit des consignes de positionnement de chaque aiguillage. Il peut même recevoir simultanément plusieurs consignes pour des aiguillages différents.
Puis, de manière asynchrone, il gère l’activation des deux bobines de chaque aiguillage, sous forme d’impulsions et selon trois paramètres  communs à toutes les sorties :
Toute consigne reçue et non immédiatement exécutable est mise en attente pour être exécutée dès que possible.

De plus, le dispositif I2C Maître a la possibilité d’interroger l’arduino mini pour connaître son état instantané :
Cela donne la possibilité au Maître de gérer le niveau de sollicitation de la source d’alim 12V, de manière globale pour l’ensemble des modules présents sur le bus.

Les trames échangées en I2C comportent aussi des CRC, pour réduire les risques d’erreurs de communication liées à des parasites électriques. Une trame incorrecte est ignorée, charge au Maître de gérer la chose.

A ce stade, la question est : quelles fonctionnalités utiles pourrais-je avoir oubliées, au niveau de l’arduino mini, dans une optique de module le plus générique possible ?

Je m’interroge par exemple sur la position réelle des aiguilles.
Il n’y a aucun capteur pour donner un retour information. Ainsi, à la mise sous tension, la position de chaque aiguillage est indéterminée tant qu’une première impulsion n’a pas été envoyée. De plus, si l’aiguille est déplacée manuellement ou par un train qui circulerait en sens inverse (possible ?), il peut y avoir un déphasage logique avec l’arduino mini.
Actuellement, si l’arduino considère qu’un aiguillage est déjà dans la position indiquée par une nouvelle consigne, il ne déclenche rien.
Peut-être ajouter une fonctionnalité de remise en phase logique?

Autre interrogation : les aiguillages liés, typiques d’un changement de voie entre deux voies parallèles.
Ils seront commandés séparément, mais est-il utile ou nécessaire de gérer leur cohérence au niveau de l’arduino mini?

Autres points oubliés ?
Titre: Re : Contrôle numérique des aiguillages
Posté par: DDEFF le janvier 13, 2016, 09:24:52 am
Salut Bricoleau,

Avant de parler de ce qui manquerait, parlons de ce qu'il y a !
Je trouve cette réalisation sympa, très bon marché et typique du DIY. Bravo !  :D

Je te rassure sur un point : la mise en parallèle de 2 sorties ULN2803 va fonctionner. On voit ça dans beaucoup de revues d'électronique.
Par contre, j'attends avec impatience les tests en vrai sur un réseau pour l'usage de l'I2C. Là, j'aurais plus de craintes...
J'aurais naturellement tendance à lui préférer le bus CAN, nettement plus sûr.
Ceci dit, tu parles d'un CRC sur l'I2C et ça me parlerait bien.

Ce qui me parait intéressant, ce sont tes idées concernant les aiguilles.

Dans l'alimentation des aiguilles, il y a au départ 2 problèmes :
1°) Le fait que si on alimente un moteur d'aiguille trop longtemps, il crame. D'ailleurs, ne pas oublier de voir si l'ULN2803 ne chauffe pas, lui aussi.
2°) La surcharge de l'alimentation centrale.

Si l'idée de calibrer la durée d'impulsion est classique, celle d'avoir une durée mini de repos l'est nettement moins.
Et c'est une excellente idée.  ;)

Qu'appelles-tu "contrôle d’exclusion des sorties contradictoires" ?

J'aimerais avoir des précisions sur ce passage :
"Si cette durée est à zéro, les 4 aiguillages peuvent être basculés simultanément. Si elle est supérieure à la durée d’impulsion, un seul aiguillage à la fois peut être actif. Et entre les deux, cela permet de régler le nombre maximum de bobines activables simultanément."

1°) "Si cette durée est à zéro, les 4 aiguillages peuvent être basculés simultanément" : OK.
J'en déduis que ton alim supporte l'alimentation de 4 aiguilles.
2°) "Si elle est supérieure à la durée d’impulsion, un seul aiguillage à la fois peut être actif." : Donc, on est maintenant à 5 aiguilles simultanées ?
3°) "Et entre les deux, cela permet de régler le nombre maximum de bobines activables simultanément."

Mon problème : il n'y a qu'un seul nombre d'aiguilles commandables simultanément.
Deuxio : les aiguilles commandées simultanément peuvent l'être sur plusieurs modules. Par exemple 4 réparties sur 4 modules.
Donc, le maxi n'est gérable que par le Maître. Ce que tu dis d'ailleurs un peu plus loin.

Mais j'ai eu l'impression que tu gérais ça aussi au niveau du module ? Mais je me trompe peut-être ?

Tonneau des Danaïdes : trouver la position réelles des aiguilles...

En tout cas, une bonne idée : ne pas accepter deux fois la même consigne.

Enfin, "cohérence des aiguilles liées" : d'abord, il n'est pas évident qu'elles soient sur le même module. C'est au Maître de gérer ça.
Titre: Re : Contrôle numérique des aiguillages
Posté par: bricoleau le janvier 13, 2016, 07:40:53 pm
Bonjour

Pour les ULN2803 qui crament, j'ai "investi" dans des supports pour CI  :P

Le contrôle d’exclusion consiste à garantir, au plus bas niveau logiciel possible, qu’en aucun cas une bobine ne peut être alimentée si l’autre bobine du même aiguillage est déjà sous tension.
Ce contrôle est codé juste avant le digitalWrite() pour une fiabilité maximale.

La durée minimum de repos est gérée de manière globale pour les deux bobines d’un même aiguillage. Avant de mettre sous tension une bobine, le programme vérifie qu’elle et sa sœur sont au repos depuis au moins cette durée paramétrée.

Le dernier paramètre est un poil plus compliqué.
La règle s’énonce simplement, mais sa conséquence est moins triviale.
Elle s’applique de manière globale sur les 4 aiguillages (8 bobines) commandés.
Le paramètre définit un délai minimum entre les débuts de mise sous tension de plusieurs bobines. On ne s’intéresse là qu’aux fronts montants.
Ainsi, avant de mettre sous tension une bobine, le programme recherche la dernière bobine activée, et vérifie que ce délai minimum d’écart est bien respecté.

Par exemple, prenons comme hypothèses :
- une durée d’impulsion à 500 ms
- un ordre de bascule des 4 aiguillages simultanément, reçu à T0

Avec le paramètre positionné à 0 :
- les 4 aiguillages vont être activés simultanément, de T0 à T0+500

Avec le paramètre positionné à 100 :
- l’aiguillage 1 va être activé de T0 à T0+500
- l’aiguillage 2 va être activé de T0+100 à T0+600
- l’aiguillage 3 va être activé de T0+200 à T0+700
- l’aiguillage 4 va être activé de T0+300 à T0+800
Donc entre T0+300 et T0+500 on aura les 4 aiguillages actifs simultanément

Avec le paramètre positionné à 200 :
- l’aiguillage 1 va être activé de T0 à T0+500
- l’aiguillage 2 va être activé de T0+200 à T0+700
- l’aiguillage 3 va être activé de T0+400 à T0+900
- l’aiguillage 4 va être activé de T0+600 à T0+1100
Là il n’y a plus au maximum que 3 aiguillages actifs simultanément, entre T0+400 et T0+600

Et ainsi de suite en augmentant la valeur du paramètre.

Avec le paramètre est positionné à 600 :
- l’aiguillage 1 va être activé de T0 à T0+500
- l’aiguillage 2 va être activé de T0+600 à T0+1100
- l’aiguillage 3 va être activé de T0+1200 à T0+1700
- l’aiguillage 4 va être activé de T0+1800 à T0+2300
Et là seul un aiguillage est actif à la fois.

D’une part, ce paramètre permet de borner le nombre maximum de bobines actives simultanément au niveau d’un module.
D’autre part, il me semble (mais pas sur) que les instants de mise sous et hors tension des bobines génèrent le plus de parasites (inductance) sur la ligne d’alim 12V. Ce paramètre permet ne pas avoir de multiples fronts montants ou descendants simultanés. Un genre de debounce d’alim.

La nécessité de se pencher sur ce paramètre dépend des caractéristiques de l’alim 12V.
Et effectivement, si cette nécessité est avérée, il faudra aussi s’en préoccuper au niveau au-dessus, qui gère plusieurs modules parallèles.
Le maître I2C a accès à toutes les infos nécessaires pour gérer cela, dans les messages remontants. C’est vrai qu’à la fin, cela a fait une gestion à deux niveaux, mais tout ce qui peut être pris en charge au niveau le plus bas me semble plus fiable.

Dans mon cas, toujours en approche minimaliste, je pense partir sur une petite alim 12V 1,5A pour l’ensemble des aiguillages.
J’aurai donc au maximum une bobine active par module, et un seul module actif à la fois (gestion au niveau du Maître I2C : récupération régulière de l’état des modules, et envoi d’un ordre à un module seulement lorsque tous les autres sont au repos).

Pour l’I2C on verra bien. Je suis plutôt confiant car les modules ne seront pas positionnés sous le réseau, mais regroupés à la place des boitiers de boutons poussoirs actuels. Les câbles vers chaque aiguillage sont déjà tirés. Donc le réseau électrique 5V sera court et relativement distant des rails.

Pour la fiabilisation des positions d’aiguilles : admettons qu’une fonction soit prévue au niveau du maître I2C, pour resynchroniser tous les aiguillages (déclenchement manuel par appui sur un bouton poussoir, lorsque l’humain sent qu’il y a un truc qui déconne quelque part).

En l’état, le maître sera alors obligé de basculer tous les aiguillages dans un sens, puis dans l’autre, pour fiabiliser leur position. Pas terrible.
Je pourrais ajouter une fonction supplémentaire au niveau des modules, pour relancer une impulsion sur les bobines. Si l’aiguillage est censé être droit, je rebalance une impulsion sur la même bobine.

Dans la plupart des cas, l’impulsion ne servira à rien, car l’aiguillage sera déjà dans la bonne position. Du coup, je me demande s’il n’y a pas un risque à forcer trop longtemps sur la fin de course.
Il serait peut-être plus adéquat de passer par des impulsions plus brèves. Par exemple, au lieu d’une impulsion standard de 500 ms, envoyer 2 impulsions de 250 ms espacées d’une seconde.

Autre point :
Jusqu’ici j’ai raisonné aiguillage, en supposant qu’un dételeur fonctionne de la même manière. Aucune distinction n’est effectuée au niveau du module.
Est-ce adéquat ?
Par exemple, est-ce qu’il y aurait nécessité à pouvoir paramétrer séparément la durée d’impulsion, selon le type de matériel commandé ?
Titre: Re : Contrôle numérique des aiguillages
Posté par: Thierry le janvier 13, 2016, 08:50:07 pm
Voilà un projet qu'il est très intéressant !

En développant UAD, j'ai dû revoir certaines idées préconçues à propos des moteurs à bobine.
Il y a pour ma bibliothèque trois types de ces moteurs : les classiques Jouef/Marklin/etc avec deux bobines comme tu as déjà décrit.
Mais il y a aussi les moteurs Kato et Rokuhan qui sont mono bobine : c'est l'inversion de polarité qui fait le choix de la direction.
Enfin il y a les dételeurs, eux aussi mono bobine mais avec une durée d'activation nettement plus importante que les aiguillages. elle doit pour moi être réglée spécialement pour cet usage.
Si on voulait être complet, il faudrait aussi traiter les servo moteurs et les moteurs à mouvement lent comme les Seep, Cobalt, et autre Tortoise...

J'ai traité le mouvement concurrent de plusieurs moteurs différemment en permettant de construire des groupes d'accessoires à manipuler ensembles, mais de manière séquentielle ou simultanée... Ton approche de la non simultanéité d'alimentation par un délai de mise en route est très intéressante...

Enfin, comme tu le dis, un bouton pour 'reseter' tous les moteurs dans une position de départ théorique, ou pour remettre en conformité avec ce que l'Arduino croit savoir de la position de chaque aiguille est une bonne idée. Et quid de la sauvegarde de la position courante de chacune en EEPROM pour repartir avec les bonnes données après une extinction du système ? A noter que je n'ai rien fait de tout ça dans UAD !
Titre: Re : Contrôle numérique des aiguillages
Posté par: bricoleau le janvier 13, 2016, 11:27:42 pm
Sauvegarder la position courante pour la récupérer au prochain allumage du système, je verrais bien ça au niveau de la centrale.
Et au redémarrage on balance une synchro sur cette position théorique.
Par contre ça risque de faire beaucoup d'écritures sur une Eeprom.

Les 56 octets de ram non volatile d'un DS1307 feraient peut-être mieux l'affaire.
Prenons 4 octets pour une signature, et il en reste 52 d'usage libre, sans limite de réécriture.
De quoi sauvegarder la conf chaque seconde.
Titre: Re : Contrôle numérique des aiguillages
Posté par: Jean-Luc le janvier 14, 2016, 08:22:58 am
Bonjour,

Concernant la sauvegarde de la position courante, il s'agit de la position extrême : droite ou déviée (je pense là à des servomoteurs plutôt). En admettant que la position d'un aiguillage change toutes les 5 secondes (ce qui est une borne très très supérieure), 100000 écritures permettent 140 heures de fonctionnement environ. À cela on peut ajouter l'utilisation de techniques de tampon circulaire sur l'EEPROM afin de repartir les écritures sur plusieurs cases, technique présentée dans une application note de ST signalée par Marc-Henri. En l'occurrence, on serait à 1000h avec une EEPROM d'1ko qui serait entièrement libre pour cette sauvegarde.

Enfin, il existe des composants de détection de chute de tension comme le TC54VX43 (composant 3 broches que l'on trouve en boîtier TO92). Quand la tension chute en deçà de 4,3V, la sortie passe à 0. Il s'agit donc de connecter ce composant sur une entrée d'interruption et, dans la routine d'interruption, de faire la sauvegarde de l'état dans l'EEPROM. Il faut, bien entendu, s'assurer que le temps restant avant que le micro se plante à cause de la baisse de tension est suffisant pour effectuer la sauvegarde.
Titre: Re : Contrôle numérique des aiguillages
Posté par: bricoleau le janvier 14, 2016, 09:46:16 pm
J'ai pensé à un principe simple pour gérer la synchro.

J'ai déjà 3 statuts d'aiguillage :
- droit
- courbe
- indéterminé
Ce dernier étant uniquement la valeur au démarrage du système, tant qu'une première impulsion n'a pas été envoyée.

Jusqu'ici je gérais 2 types d'ordre reçus de la centrale :
- basculer droit => si le statut n'est pas déjà "droit", alimente la bobine et passe le statut à "droit"
- basculer courbe => idem mais en retournant la chaussette

Il suffit que j'ajoute un type d'ordre :
- oublier => ne fait rien sur la bobine et passe le statut à "indéterminé"

Ainsi, la resynchro peut être effectuée en envoyant d'abord un ordre d'oubli, puis un ordre de bascule.

Et derrière, si besoin, je peux même gérer deux manières d'effectuer les bascules d'aiguillage :
1) la bascule franche, pour passer de "droit" à "courbe" ou inversement : une impulsion de la durée nominale
2) la bascule douteuse, lorsque l'aiguillage est "indéterminé" : une série d'impulsions plus courtes et espacées, pour éviter de forcer longtemps sur la fin de course.
Titre: Re : Contrôle numérique des aiguillages
Posté par: bricoleau le janvier 17, 2016, 12:06:34 am
Bonsoir

Ca y est ! Premiers tests réussis haut la main !

Le programme pour l'arduino mini est achevé.
J'attends d'avoir terminé les tests pour le mettre en ligne.

Au final, j'ai opté pour ce que j'envisageais ci-dessus : implémentation d'un ordre supplémentaire pour "oublier" la position supposée de l'aiguillage, ainsi qu'une gestion des bascules douteuses.

Lorsque la position de l'aiguillage est indéterminée, le module balance deux impulsions de la moitié de la durée nominale, espacées du délai normal de repos de l'aiguillages (et donc entrelacées avec d'éventuelles autres demi impulsions vers d'autres aiguillages).

Cela fonctionne très bien.
J'ai testé avec un seul aiguillage branché (celui qui m'a été prêté pour l'expérimentation).

(http://forum.locoduino.org/index.php?action=dlattach;topic=124.0;attach=179;image)

Ce qui me surprend, c'est qu'une impulsion très brève suffit à faire basculer entièrement l'aiguillage.
Au départ, j'avais prévu 500 ms, mais une durée de 100 ms suffit largement.
Avec une durée de 50 ms, la bascule est déjà quasi complète.
Visuellement, j'ai l'impression qu'une impulsion très courte met le mécanisme en marche, et qu'ensuite le mouvement se termine par inertie mécanique. L'aiguillage est neuf et coulisse vraiment très bien manuellement.
A moins que l'inertie provienne de l'inductance de la bobine.

Ca vous paraît normal?
Titre: Re : Contrôle numérique des aiguillages
Posté par: bricoleau le janvier 19, 2016, 11:53:24 pm
Bonjour

J'ai terminé le programme de mon contrôleur pour 4 aiguillages à commande I2C

Les tests sont OK, en commande directe comme en commande I2C depuis une centrale (une autre arduino)

Vous pouvez très facilement vous faire une idée de son fonctionnement.
Il suffit de téléverser le programme ci-joint dans n'importe quelle carte arduino. Une uno fera très bien l'affaire.
Le seul câblage à réaliser consiste à relier les pin 11 et 12 avec un fil.

A partir de là, le programme démarre en mode maintenance : un menu est proposé sur le terminal série (à 9600 bauds)
Ce menu tourne en parallèle de toutes les autres fonctionnalités du contrôleur.
Il permet de modifier les paramètres de fonctionnement, et même de simuler la réception d'ordres de bascule.
Dans ce dernier cas, il affiche également un chronogramme d'activation des bobines.
Cela permet de bien comprendre le fonctionnement du contrôleur, ainsi que le rôle de chaque paramètre.


Sur la première photo au début de cette discussion, on voit le cavalier ajouté sur l'arduino mini, qui permet de démarrer en mode maintenance.
En mode normal : le contrôleur est muet sur la liaison série. Tout passe par l'I2C.
En mode maintenance : c'est le contraire. Les messages I2C sont simulés et passent par les mêmes fonctions de traitement.

Ce mode maintenance m'a permis de mettre au point le contrôleur, et d'effectuer les premiers tests en le branchant directement sur le PC.

A noter que la led 13, implantée sur l'arduino, est utilisée comme témoin de fonctionnement.
En mode normal, elle est allumée dès lors qu'au moins une bobine est sous tension.
En mode maintenance, elle clignote rapidement.

Le programme fourni ne nécessite aucune modification pour fonctionner.
Il peut être téléversé tel quel sans se poser de questions.

Pour une meilleure accessibilité, j'ai volontairement opté pour une programmation simple (sans utiliser d'objets autres que ceux natifs de l'environnement arduino) et linéaire (aucune librairie à installer).
Ca ressemble à du C "de base", avec des fonctions regroupées en sections.

Titre: Re : Contrôle numérique des aiguillages
Posté par: DDEFF le janvier 20, 2016, 08:55:52 pm
Bravo !
Bonne analyse du problème au départ, bonne réalisation du programme, clair et facile à lire.

Je n'ai pas testé sur une vraie aiguille (l'aiguillage, c'est l'action de bouger l'aiguille ...  ;) ), mais je te fais confiance.

J'ai particulièrement apprécié la gestion avec un code CRC.
Je verrais si je peux m'en servir aussi. C'est en tout cas une excellente idée.
On a peine à croire qu'il faut toutes ces lignes pour bouger une aiguille  :D.
Mais on est très loin d'une appli basique.

Quant aux délais pour le mouvement d'aiguille, c'est très variable entre une aiguille neuve, une installée, mais un peu tordue par la pose, la marque, ...
Tu dois savoir aussi que quelques vielles aiguilles Peco consomment 2A !!
Pour certaines, qui n'ont pas de ressort, on a même des rebonds ...
C'est beaucoup moins fiable que l'Arduino  ;D

Une question reste en suspens : trouver une idée pour savoir si l'aiguille est bien dans la position qu'on a voulue.
Et là, on blinde complètement le processus.

Encore bravo !
Titre: Re : Contrôle numérique des aiguillages
Posté par: Jean-Luc le janvier 20, 2016, 09:13:14 pm
Connaître la position de l'aiguille est assez simple en fait (à condition que ça marche car je n'ai pas essayé :-))

À chaque extrémité de la traversé tu colles un aimant au néodyme de petite dimension. Par exemple http://www.supermagnete.fr/aimants-cube-neodyme/cube-magnetique-1mm-neodyme-n45-nickele_W-01-N

Dans le ballast, tu noies un ILS de manière à ce qu'il colle quand la traverse est en position. Si l'un des ILS est passant, l'aiguillage est dans une position correcte et connue, si aucun des deux n'est passant, l'aiguille est quelque part au milieu. Si les deux sont passant c'est qu'il y a un problème :-)
Titre: Re : Contrôle numérique des aiguillages
Posté par: DDEFF le janvier 20, 2016, 10:40:45 pm
Excellente idée.
On peut aussi tout mettre en dessous, via la tige qui commande la traverse.
J'ai en effet un doute sur la possibilité que la partie mobile de l'aiguille se magnétise.
Moi non plus, je n'ai as essayé. ???
Titre: Re : Contrôle numérique des aiguillages
Posté par: Jean-Luc le janvier 20, 2016, 11:08:23 pm
Ces aimants sont extrêmement puissants, ça devrait marcher.
Titre: Re : Contrôle numérique des aiguillages
Posté par: DDEFF le janvier 21, 2016, 09:00:04 pm
Merci Jean-Luc. Je vais essayer.  ;)

Je vais un peu recentrer sur la problématique de bricoleau :

Prenons la problématique d'après ses bases.

Il y a 2 problèmes à gérer qui concernent ce qui peut chauffer :

1°) L'alim parce qu'on lui en demande trop en même temps
2°) l'aiguille parce qu'on l'alimente trop longtemps ou trop souvent

Je vais prendre un  exemple avec des chiffres "plausibles"
Alim 3 A, aiguille qui consomme 0,8 A pendant 10 ms et 0,4 A pendant 40 ms.
Puisque tu utilises des ULN2803, c'est que tu souhaites alimenter tes bobines par du continu (bonne idée).
Premier réflexe : mettre une diode à l'envers dite "diode de roue libre" ou "diode anti-retour" qui absorbe la pointe à la fin de l'impulsion. OK. Classique.
Deux sorties 500mA suffisent pour 1A. OK.

Grâce à ta logique, tu décales de, mettons, 20 ms pour être au large.
Donc, sur un module, 2 bobines ne démarrent pas en même temps. Excellent.

Autre paramètre : ne pas ré-alimenter une aiguille qui est déjà dans la bonne position.
Je n'ai pas décortiqué complètement, mais je pense que c'est OK aussi.
Donc, pour un module, tout va bien.

Mais il faut un maître. Et, là, ça se complique.

Un de mes itinéraires fait 16 aiguilles. L'alim ne va pas aimer, si on met tout en même temps.

Premier problème :

Coordonner les modules pour que, une fois que les 4 premier ont eu chacun leur décalage de 20 ms et sont donc non en phase (ce qui est recherché), que ça continue avec le module d'après pour lequel la première bobine soit bien 20 ms après la dernière bobine du module précédent.
Et, évidemment, on ne sait pas quel est le module précédent.  :(

Si je prends les aiguilles dans le sens 1-2-3-...15-16, ça n'est pas pareil que 16-15-...-3-2-1 !
Et si la gare est complexe, il peut y avoir plein de solutions.
Et, ça, seul le maître peut le gérer.
Admettons qu'il sache qui va après qui. Comment rendre ça cohérent avec le bus I2C ?

Deuxième problème :

On a le bon décalage dans tous les cas. OK.
Mais, même décalé, au bout d'un moment, on a dépassé les possibilités de l'alim. Et il va falloir attendre un peu pour reprendre le rythme.
C'est donc à gérer aussi.

Comme quoi, à partir d'un problème qu'on trouve simple, au départ, on est amené à de sacrés trucs  :D
Mais je sens que tu es plein de ressources.

Titre: Re : Contrôle numérique des aiguillages
Posté par: Jean-Luc le janvier 22, 2016, 07:13:58 am
Bonne analyse.

Note que l'uln intègre des diodes roue libre.
Titre: Re : Contrôle numérique des aiguillages
Posté par: bricoleau le janvier 22, 2016, 11:49:34 am
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.
Titre: Re : Contrôle numérique des aiguillages
Posté par: bricoleau le janvier 22, 2016, 12:14:46 pm
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.
Titre: Re : Contrôle numérique des aiguillages
Posté par: DDEFF le janvier 22, 2016, 12:55:52 pm
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... ;D ;D

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...
Titre: Re : Contrôle numérique des aiguillages
Posté par: bricoleau le janvier 22, 2016, 01:03:08 pm
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  :P

Titre: Re : Contrôle numérique des aiguillages
Posté par: DDEFF le janvier 22, 2016, 01:35:16 pm
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
Titre: Re : Contrôle numérique des aiguillages
Posté par: bricoleau le janvier 22, 2016, 02:33:04 pm
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.
Titre: Re : Contrôle numérique des aiguillages
Posté par: DDEFF le janvier 22, 2016, 07:20:00 pm
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.  8)

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
Titre: Re : Contrôle numérique des aiguillages
Posté par: DDEFF le janvier 23, 2016, 09:16:45 am
Faisons de ton programme un programme universel !  :D

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.  ;D

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


Titre: Re : Contrôle numérique des aiguillages
Posté par: Jean-Luc le janvier 23, 2016, 09:48:33 am
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.
Titre: Re : Contrôle numérique des aiguillages
Posté par: bricoleau le février 07, 2016, 02:55:56 pm
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é
(http://forum.locoduino.org/index.php?action=dlattach;topic=124.0;attach=212;image)

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 :
Titre: Re : Contrôle numérique des aiguillages
Posté par: bricoleau le février 07, 2016, 03:20:16 pm
(http://forum.locoduino.org/index.php?action=dlattach;topic=124.0;attach=214;image)

Liste des composants :
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
Titre: Re : Contrôle numérique des aiguillages
Posté par: DDEFF le février 07, 2016, 03:34:28 pm
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/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/ (http://www.tme.eu/fr/details/dg128-5.0-02p14/barres-de-serrages-pour-pcb/degson-electronics/dg128-50-02p-14-00ah/)
Titre: Re : Contrôle numérique des aiguillages
Posté par: Dominique le février 21, 2016, 03:02:23 pm
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++ :

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.

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.

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 :

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.

/*
   *  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.

/*
   * 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à !
Titre: Re : Contrôle numérique des aiguillages
Posté par: DDEFF le février 21, 2016, 05:18:02 pm
Salut Dominique,

Très intéressant comme démarche.   :D :D

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  ;D),
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 ?...
Titre: Re : Contrôle numérique des aiguillages
Posté par: savignyexpress le mars 07, 2019, 01:16:26 pm
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...

Merci de vos réponses et meilleures salutations.
Titre: Re : Contrôle numérique des aiguillages
Posté par: Dominique le mars 07, 2019, 02:46:08 pm
Bonjour Marc-Henri,

Quand on tombe sur des problèmes de parasites, cela devient un peu irrationnel, il peut y avoir plusieurs remèdes de grand-mère ce qui n’empêche pas d’essayer d’être rationnel quand même.

J’avoue que j’ai de la chance car cela fonctionne bien jusqu’à maintenant (depuis plus de 2 ans), sauf parfois un reset intempestif de l’Arduino qui commande les 44 relais quand une commande concerne une aiguille très proche des relais, et seulement une fois de temps en temps. Et cela ne perturbe rien d’autre : le bus Can est certainement bien étanche à cette perturbation qui doit être bien locale aux 44 relais et le Mega associé. L’inconvenient est que cela modifie les itinéraires car je n’enregistre pas (encore) tous les changements en EEPROM.

Je n’ai pas encore cherché la cause et le remède, du fait de mes problèmes de hanches qui sont réparées maintenant, et donc j’y pense à nouveau, merci de me le rappeler aussi ;)

Pour répondre à une remarque de Denis, la longueur des 3 fils bien torsadés qui vont aux aiguilles et transportent de l’alternatif ne semble pas influer. Ça ne dépasse pas 2m au plus. Il vaut mieux que ce soient les connexions entre l’Arduino et les platines à relais qui soient les plus courtes.

Voici les précautions que j’ai prises pour mettre le plus possible de chances de mon côté :
1- j’utilise des platines avec 8 relais 5v avec optocoupleurs, de ce type :
https://rover.ebay.com/rover/0/0/0?mpre=https%3A%2F%2Fwww.ebay.fr%2Fulk%2Fitm%2F190823079261 (https://rover.ebay.com/rover/0/0/0?mpre=https%3A%2F%2Fwww.ebay.fr%2Fulk%2Fitm%2F190823079261)
Le faible prix ne justifie pas de construire sa propre platine et une tension de commande de 5v est préférable à 12v pour éviter de détruire l’Arduino en cas de mauvais placement du strap d’alimentation.
2- la longueur des fils entre le Mega et les platines montées en recto verso sur une planche en bois, est inférieure à 30 cms. Ce qui comptait pour moi, c’est l’accessibilité des borniers à vis des platines de relai !
3- le 5v des relais est séparé du 5v de l’Arduino (une grosse alim de PC)
4- le 15v alternatif est produit par un transfo à part largement dimensionné et protègé par fusible qui a souvent sauté au début quand plusieurs aiguilles étaient commandées en même temps.
5- le sketch dans le Mega ne commande qu’une seule aiguille à la fois.

J’ai tout de même une piste : lorsque j’ai retourné à l’envers tous les moteurs d’aiguille pour qu’ils soient à fleur du plan des voies (en pratiquant une découpe autour des moteurs), j’ai constaté que certains moteur devaient rencontrer une résistance mécanique plus grande qu’avant parce qu’il n’étaient plus aussi bien dans le même plan qu’avant : le fait de pendre vers le bas au lieu de reposer sur le plan de voie pouvait induire cette résistance, donc augmenter le courant de commande. Cela provoquait des plantage de l’Arduino. En révisant la fixation des moteurs, les problèmes ont disparu, il en reste peut-être un à vérifier.

En ce qui concerne le blindage, je pense qu’il vaudrait mieux blinder les fils de liaison entre Arduino et platines à relais.

Après on peut imaginer de mettre des schottky pour les roues libres des relais...

Je reviendrai sur ce sujet dès que j’aurai du nouveau !

Bien cordialement
Diminique
Titre: Re : Contrôle numérique des aiguillages
Posté par: savignyexpress le mars 07, 2019, 03:55:01 pm
Bonjour Dominique,

Merci pour ta réponse rapide et ton retour d'expérience. En l'état actuel:

Je posterai le résultat de mes tests à venir.

Bonne fin de journée et meilleures salutations.
Titre: Re : Contrôle numérique des aiguillages
Posté par: nopxor le mars 07, 2019, 08:08:30 pm
Bonjour,

J'ai rencontré aussi des problèmes de parasites sur des bobines d'aiguillage PECO commandées par relais via Arduino.
Cela perturbait (plantait) la connexion USB Arduino-JMRI.
La solution radicale a été de souder une diode roue libre sur chaque bobine.
Titre: Re : Re : Contrôle numérique des aiguillages
Posté par: msport le mars 08, 2019, 05:28:02 pm

Perturbation d'un affichage LCD
Si ce n'est pas le cas, pouvez vous tester la version shield sur Arduibo UNO ...
Sinon tester la version en I2C (ça peut être pire).

Perturbation d'un monostable à 555
... les condensateurs de découplage ...
combien, valeur et où ? (mettre x10)

Mes questions... Avez-vous rencontré des problèmes similaires ? Si oui, comment les avez-vous résolu ?

On a tous rencontré ce type de problème.
A regarder :
Titre: Re : Contrôle numérique des aiguillages
Posté par: savignyexpress le mars 09, 2019, 11:37:03 am
Bonjour à tous,

Je progresse, j'ai corrigé les points suivants:

Condensateurs de découplage sur le 555
Suivant les recommandations de la datasheet, un 100 nF sur l'alimentation et un 10 nF sur l'entrée no. 5 contrôle. Pas d'amélioration, mais cela ne peut pas faire de mal de suivre les recommandations.

Alimentation des aiguilles
J'avais une boucle de masse sur les communs des aiguilles. J'ai coupé la boucle et cela a beaucoup amélioré le fonctionnement du monostable à 555.

Filtrage de l'entrée trigger du monostable
En débranchant les fils des ILS de l'entrée trigger du monostable, j'ai constaté qu'il ne se déclenchait plus de manière intempestive. Me basant sur des informations trouvées sur le web, j'ai ajouté un filtre passe-bas sur l'entrée trigger constitué d'une résistance de 1.2 KOhm et d'un condensateur de 100 nF. Le monostable n'est plus du tout perturbé.

Affichage LCD
L'affichage est relié à l'Arduino en mode 4 bits. J'ai pour le moment modifié le logiciel comme suit:
La situation est meilleure, mais pas encore parfaite. Je vais encore ajouter un condensateur de découplage proche de l'alimentation 5 V de l'affichage. En tout dernier recours, je remplacerai l'affichage, qui me sert à montrer l'état de la gare cachée, par des leds !

Bonne fin de semaine et encore merci pour les échanges.
Meilleures salutations.
Titre: Re : Contrôle numérique des aiguillages
Posté par: savignyexpress le mars 27, 2019, 06:54:43 am
Bonjour à tous,

Mon affichage LCD est toujours perturbé par les commutations d'aiguilles, malgré les tests suivants effectués hier soir:
Je prévois encore de tester:
Le point positif cependant est que l'Arduino n'est jamais perturbé !

Bonne journée et meilleures salutations.
Titre: Re : Contrôle numérique des aiguillages
Posté par: CATPLUS le mars 27, 2019, 07:18:41 am
Bonjour Marc-Henri

Pourrais-tu STP faire un schéma de ton montage.

Pour le LCD cela fait des lustres que je l'utilise en I2c, rien à ce jour dans mes montages ne le perturbe.

Amicalement
Marcel
Titre: Re : Contrôle numérique des aiguillages
Posté par: nopxor le mars 28, 2019, 03:59:44 pm
Bonjour,

Plutôt qu'essayer d'atténuer les effets des perturbations sur les récepteurs des parasites,
il est important d'annihiler la source de ces parasites:

Ce sont les bobines des aiguillages qui lorsque elles commutent provoquent une étincelle parasite.
La seule solution pour éviter cela, c'est de souder une diode dite de roue libre aux bornes de chaque bobine d'aiguillage.

Cette diode court-circuite les pointes de tension inverses qui naissent aux bornes d'une bobine lors de la coupure de son alimentation ( tension de self induction ).

Cette tension de self induction est très élevé, centaine à plusieurs milliers de volts. C'est elle qui génère les perturbations.

La diode de roue libre est branchée en parallèle aux bornes de la bobine
avec sa cathode raccordée au positif de l'alimentation de la bobine et son anode au pôle négatif.

Cette diode devient passante ( un pic de courant circule uniquement entre la bobine et la diode ) lors de la coupure de l'alimentation de la bobine, car la tension de self induction est de sens contraire à la tension normale d'alimentation de la bobine.
Titre: Re : Contrôle numérique des aiguillages
Posté par: savignyexpress le mars 28, 2019, 08:29:29 pm
Bonjour à tous,

Pour le schéma, je commande mes aiguilles à l'aide d'un module 8 relais de ce type là: http://wiki.sunfounder.cc/index.php?title=8_Channel_5V_Relay_Module (http://wiki.sunfounder.cc/index.php?title=8_Channel_5V_Relay_Module). L'alimentation des aiguilles est complètement séparée de celle de l'Arduino et de l'affichage LCD. Il s'agit d'une alimentation de PC portable.

J'ai bien pensé aux diodes de roue libre sur les électro-aimants. Mais je me demande si elles seront vraiment efficaces avec les électro-aimants qui disposent de contacts de fin de course. Il faut alors que le relais coupe le courant avant que ce contact n'intervienne. Idéalement, il faudrait brancher les diodes directement sur les bobines, mais les électro-aimants ne sont pas simples à démonter.

Je vais essayer l'option d'un affichage LCD I2C et faire passer le bus I2C dans un câble blindé.

Merci de vos recommandations et meilleures salutations.
Titre: Re : Contrôle numérique des aiguillages
Posté par: Jean-Luc le mars 29, 2019, 08:18:33 am
Bonjour Marc-Henri.

Il y a déjà des diodes roue libre sur ces cartes relais.

Tu dis que ton écran LCD  est assez loin de l’Arduino. As tu mis une capa sur l’alimentation du LCD au plus près de ce dernier ?

Cordialement
Titre: Re : Contrôle numérique des aiguillages
Posté par: savignyexpress le mars 29, 2019, 01:51:22 pm
Bonjour Jean-Luc,

Merci pour tes suggestions.

J'ai essayé une / plusieurs capacités 10 uF, 100 nF sur et à proximité de l'alimentation du LCD, mais sans succès. J'ai aussi essayé une alimentation séparée du LCD, même insuccès.

Si j'ai bien compris les échanges au sujet des diodes de roue libre, il s'agirait de les ajouter sur les électro-aimants des aiguilles. Les relais ne posent pas de problème, j'ai testé le fonctionnement en débranchant l'alimentation des aiguilles, seuls les relais étaient actifs. Par ailleurs, la carte 8 relais comporte déjà les diodes ainsi qu'une commande par optocoupleur.

Bonne fin de semaine et meilleures salutations.
Titre: Re : Contrôle numérique des aiguillages
Posté par: Dominique le mars 29, 2019, 03:14:12 pm
Bonjour Marc-Henri,

As-tu envisagé de changer l’Arduino qui pilote l’ecran LCD ?
Ainsi que de relier toutes les entrées inutilisées à la masse (analogiques et numériques) ?

En cas d’insuccès il reste encore la réinitialisation périodique du LCD et le ré-affichage pour cacher le problème.

Après, il faut peut-être se demander s’il n’y a pas d’autres dégâts causés aux variables du programme. L’art du debug ...

Bon week-end.
Cordialement
Dominique.
Titre: Re : Contrôle numérique des aiguillages
Posté par: savignyexpress le mars 29, 2019, 04:21:31 pm
Bonjour Dominique,

Pour reprendre les points que tu soulèves:
Bonne fin de semaine et meilleures salutations.
Titre: Re : Contrôle numérique des aiguillages
Posté par: savignyexpress le avril 02, 2019, 08:43:11 am
Bonjour à tous,

J'ai ajouté les diodes de roue libre, une par électro-aimant, au plus proche des moteurs d'aiguilles, mais sans amélioration significative. Je pense qu'il faudrait pouvoir relier les diodes directement sur les électro-aimants, sans inclure les contacts de fin de course.

Prochains tests prévus:
Bonne journée et meilleures salutations.
Titre: Re : Contrôle numérique des aiguillages
Posté par: Dominique le avril 02, 2019, 10:17:31 am
Bonjour Marc-Henri,

En aéromodelisme on insère des petits tores de ferrite dans les liaisons aux servos. Ici tu pourrais passer les fils de commande des moteurs d’aiguille dans un tel tore et faire 1 ou 2 tours.

C’est bien connu, pour les parasites, le tore tue  ;D ;D

Bien cordialement
Dominique

PS : ce n’est pas un poisson d’Avril !
Titre: Re : Contrôle numérique des aiguillages
Posté par: savignyexpress le avril 02, 2019, 11:16:03 am
Bonjour Dominique,

Merci beaucoup pour cette suggestion.

Si j'ai bien compris, le tore agit comme une bobine en série qui bloque les hautes fréquences. Idéalement, il faudrait trouver de très vieilles mémoires à tores de ferrite pour récupérer les tores et réaliser ce que tu proposes. Sinon, où trouve-t-on des tores ? Aurais-tu par ailleurs une photo du dispositif ?

Bonne journée et meilleures salutations.
Marc-Henri
Titre: Re : Contrôle numérique des aiguillages
Posté par: CATPLUS le avril 02, 2019, 12:08:20 pm
Bonjour Marc-Henri

Une autre suggestion, as-tu fait le test sans relais, uniquement l'Arduino et le LCD?

Si cela fonctionne remplace les sorties relais par des leds.

A te suivre
Amicalement
Marcel
Titre: Re : Contrôle numérique des aiguillages
Posté par: savignyexpress le avril 02, 2019, 04:43:28 pm
Bonjour Marcel,

Merci pour ta suggestion.

J'ai déjà essayé de faire fonctionner le système en débranchant l'alimentation des aiguilles. C'est donc un mode où les relais fonctionnent, mais n'ont rien à actionner. Dans ce cas, je n'ai aucune perturbation, raison pour laquelle je recherche plutôt du côté des charges commutées par les relais, les électro-aimants en l'occurrence.

Bonne fin de journée et meilleures salutations.
Marc-Henri
Titre: Re : Contrôle numérique des aiguillages
Posté par: savignyexpress le avril 02, 2019, 04:57:04 pm
Bonjour à tous,

J'ai trouvé un post sur le forum Arduino qui présente la solution avec les tores de ferrite.

https://forum.arduino.cc/index.php?topic=316604.0 (https://forum.arduino.cc/index.php?topic=316604.0)

Mon fournisseur habituel de composants électroniques en Suisse a ce genre d'article. À creuser...

Bonne fin de journée et meilleures salutations.

Marc-Henri
Titre: Re : Contrôle numérique des aiguillages
Posté par: savignyexpress le avril 07, 2019, 07:23:30 pm
Bonjour à tous,

Le problème a été résolu en remplaçant l'affichage LCD à interface parallèle par un modèle équipé d'une interface I2C. Le circuit d'interface I2C étant soudé directement sur l'affichage, les connexions sont réduites au minimum, ce qui réduit d'autant le risque de perturbation. La liaison I2C est longue d'environ 40 cm, réalisée avec un câble audio en profitant du blindage relié à la masse d'un côté.

Plus aucune perturbation n'est apparue en plus d'une heure de fonctionnement du réseau.

Encore un tout grand merci pour toutes les propositions de solution.
Bon début de semaine.
Titre: Re : Contrôle numérique des aiguillages
Posté par: Dominique le avril 07, 2019, 09:59:40 pm
Bonsoir Marc-Henri,

Très content de savoir que le problème est résolu.
La discussion a été très intéressante et instructive pour tout le monde.

J’espère qu’elle rendra service à d’autres modélistes.

Bien cordialement et bonne semaine.

Dominique