La gestion des cantons par Arduino !!

De toute façon, on ne pourra jamais faire comme "dans la vraie vie" !! A moins de mettre de l'intelligence artificielle dans chacune de nos locos !!!
Bon, je pense avoir trouvé un compromis : Etant donné que j'étais partie sur 3 zones différentes par canton, dont une pour mesurer la vitesse, mais que les résultats ne sont pas ceux que j'espérais...
Je garde mes 3 zones mais les découpe comme suit :
1ère zone : zone normale (qui permettra le passage de Pleine Vitesse à Ralenti avec un temps suffisamment long...)
2ème zone : zone de freinage (qui permettra le passage à un ralenti extrême si le feu du canton est rouge, et qui "poussera" la loco jusqu'à la zone 3)
3ème zone : la zone d'arrêt (qui passera de la limite à zéro en 1 seconde, quelque soit la loco...)

La zone 3 mesurera 10 cm maxi.
La zone 2 mesurera environ 25 cm.
La zone 1 fera le reste du canton (si le canton mesure 200 cm, alors (200-10-25)=165 cm)

Rappel, même si la rame est composée d'une UM, dès que le premier essieu conducteur de la première machine entre dans la zone 3, la vitesse passe à zéro sur le canton entier donc, les 2 locos s'arrêtent... Idem pour une rame en pousse, il suffit que le premier essieu du premier wagon soit conducteur pour activer le système.
Je viens de tester sur mon petit ovale, mais les anciennes zones n'ont pas les bonnes distances. Petite modif des coupures et le tour sera joué...
Je n'ai plus qu'à demander au Père Noël de m’offrir une trentaine de rails flexibles afin de faire un circuit de 12 cantons de 2 mètres afin de parfaire les temps et les essais !!

nicozea57 a écrit:

Petite précision sur ton idée d'entrer "en dur" dans le programme les longueurs des différents cantons : Oui dans l'absolu, mais je veux que mon programme fonctionne pour n'importe quel réseau, et donc le programme ne peut pas être modifié à souhait. Il doit se "débrouiller".

C'est plus souple de coder la description du réseau dans un fichier texte, csv, xml ou autre, plutôt que en dur dans le code. Dans le cas d'une centrale Arduino, mettre le fichier en EEPROM.

Pour la longueur du train, il suffit de noter la date d'entrée du train dans le canton N et de soustraire cette date de celle de libération du canton N-1, connaissant la longueur du canton et la vitesse, tu peux en déduire la longueur du train, après y a plus qu'a......

CleoN, tu dis ça pour alain90 ?
Car, mon système ne s'occupe que du BAL, pas le reste. Et justement, le programme ne connait pas la longueur des cantons... Et je ne veux pas lui donner. Ça doit fonctionner quelques soient les longueurs de cantons, quelque soit le réseau !

Une petite précision concernant mon paramétrage : celui-ci est codé en dur dans l'initialisation des tableaux de structures (donc dans un .h) du programme.

alain90 a écrit:

Une petite précision concernant mon paramétrage : celui-ci est codé en dur dans l'initialisation des tableaux de structures (donc dans un .h) du programme.

Oui mais ça oblige donc à recompiler le programme à chaque modification et le graver à nouveau dans la puce, ça nécessite donc quelques compétences et empêche de vendre un produit prêt à l'emploi qui est, selon moi, si j'ai bien compris, l'idée de Nicozea !

sierramike a écrit:

Oui mais ça oblige donc à recompiler le programme à chaque modification et le graver à nouveau dans la puce, ça nécessite donc quelques compétences et empêche de vendre un produit prêt à l'emploi qui est, selon moi, si j'ai bien compris, l'idée de Nicozea !

Je viens de finir ma petite modification de carte électronique, la routine fonctionne et le programme est maintenant capable de trouver seul le nombre de cantons raccordés au réseau (les entrées non utilisées sont raccordées sur le +5V).
Je reste cependant sur un nombre maxi de 12 cantons. Pour passer au delà, il faut une 2eme carte...(et qu'elles discutent entre elles...)

J'avais presque envie de dire, je serais parti sur des cartes Arduino Nano, qui gèrent un ou maxi deux cantons mais avec possibilité de les chainer, comme ça tu es illimité et tu peux placer les modules au plus près des cantons pour limiter le câblage, surtout sur de grands réseaux !

Le problème n'est pas tant de savoir s'il faudra 25 mètres ou 30 mètres de fil...
Avec le courant pulsé, il faut que toutes les sorties PWM soit synchrones, sinon, tu as le risque d'avoir des locos qui "double" leur vitesse lorsqu'elles sont à cheval sur 2 cantons. Et synchroniser plusieurs arduino n'est pas le plus simple...
Et encore une fois, je me répète, mais perso, je préfère savoir où aller pour chercher une panne, c'est à dire dans un pupitre central, plutôt que de courir sous tous les modules, ce qui n'est pas du tout pratique...

Oui, mais le Mega ne gèrera "que" 12 cantons, donc pour aller au delà, tu devras résoudre cette problématique, et je dirais que si tu résouds ce problème, après tu es illimité sur les chaînages.

Pour synchroniser, tu peux tout à fait générer un signal d'horloge sur le premier Arduino de la chaîne qui servira de "pilote" à tous les modules suivants.

+1, ça va vite 12 cantons.....

12 cantons de 2 mètres minimum, ça fait déjà un circuit de 24 m ! Je trouve que beaucoup n'ont pas ça... Et il est toujours possible de séparer un circuit en 2, avec une gare au milieu, donc on peut arriver facile à 24 cantons en 2 parties distinctes...

J'ai jeté un oeil sur la synchronisation des timers Arduino... C'est pas simple !!
Et c'est sans compter qu'il faut aussi échanger les informations concernant les cantons précédents et suivants...
Wouhhaaaouu...
Si je veux connecter plusieurs cartes entre elles, ça va être coton !!

Si tu souhaites rester avec une seule carte, tu peux augmenter le nombre de sorties avec des registres à décalage (4094 ou 74595 par exemple)

Ce n'est pas le petit délai rajouté par la sérialisation qui va changer grand chose.

Tu as aussi des circuits comme le TPIC6B595 qui peuvent piloter un peu de puissance (150mA), pour les feux ça va bien, mais c'est insuffisant pour des aiguilles.

Le problème posé est que chaque carte doit avoir une adresse différente pour communiquer, et donc, il faut soit que le programme le sache au départ, ce qui veut dire que chaque carte serait différente, soit prévoir un système d'entrées donnant l'information au programme et donc, il faut prévoir encore quelques entrées juste pour l'adresse...
Au niveau programmation, il suffit d'un maître qui demande les informations aux esclaves pour échanger, mais la question est de savoir si on laisse une seule carte gérer la totalité et n’envoyer que des ordres, ou alors laisser chaque carte gérer ses cantons et discuter entre elles, vers la carte avant et la carte après...
Pas si simple en fait...
Pour les registres, pourquoi pas, mais je voudrais limiter l'électronique au maximum, gain de place et de connexions...

nicozea57 a écrit:

Le problème posé est que chaque carte doit avoir une adresse différente pour communiquer, et donc, il faut soit que le programme le sache au départ, ce qui veut dire que chaque carte serait différente, soit prévoir un système d'entrées donnant l'information au programme et donc, il faut prévoir encore quelques entrées juste pour l'adresse...
...

Pour donner un numéro à une carte il suffit d'une entrée analogique à laquelle tu relies le point milieu d'un pont diviseur à 2 résistances entre le +5V et la masse.
La tension lue te permet de définir un numéro de carte.
Pour que toutes les cartes soient identiques, tu peux faire ça avec un mini potentiomètre soudé sur la carte.

Sur mon système, je n'y avais pas pensé......et j'ai logé le numéro de carte en EEPROM, autre solution possible.

Oui, je pensais plutôt à un système de micro interrupteurs couplés à un pont diviseur. En fonction de la combinaison, tu n'envoies pas la même valeur à l'entrée analogique. Avec 4 inters tu peux faire 16 combinaisons donc 16 cartes différentes. (en gardant le ZERO pour la carte maitre par exemple)


Mais les entrées analogiques sont au nombre de 16, et j'en utilise déjà 12 pour les cantons, 2 pour les consignes vitesse et ralenti, il ne m'en reste plus que 2 !! C'est chaud

Hello Nicozea57,

Plutôt que des microswitches pour la configuration qui consomment des entrées, je proposerais d'implanter un mode de configuration. Par exemple comme suit:

• Au démarrage de la carte, si un poussoir est maintenu pendant plus de N secondes, on passe en mode configuration, éventuellement quittancé par une led.
  
• Ensuite, le même poussoir, ou un autre, est utilisé pour entrer l'adresse, par exemple en comptant le nombre de pressions.
  
• Une pression plus longue sur le poussoir termine la configuration et la led rejoue la séquence correspondant à l'adresse pour confirmer.
  

Il y a peut-être d'autres possibilités, à creuser...

Puisqu'on en est à faire des économies....

Une broche peut être utilisée 2 fois:

- Au début du programme, configurée en entrée analogique pour lire le numéro de carte, comme je l'indique plus haut
- En fonctionnement normal, configurée en sortie numérique pour ce dont tu as besoin.

SI tu n'a plus d'entrée analogique tu peux mettre un condensateur et une résistance en parallèle entre une broche numérique et la masse.
- Au début du programme tu mets la broche en sortie et au niveau 5V.
- Puis après un "certain temps", tu bascules la broche en entrée et tu mesures le temps qu'il faut pour que l'entrée bascule à 0. En jouant sur la valeur de la résistance et donc sur le temps de décharge du condensateur tu définis un numéro de carte.....

Après pas mal de lectures, j'ai compris que le bus I2C qui me paraissait le meilleur nécessite absolument un maître et plusieurs esclaves. Ce qui ne m'arrangent pas, car qui serait le maître ? La première carte ? Mais, du coup, c'est elle qui devrait centraliser les informations et donc le programme serait différent, ce que je ne veux pas...
J'ai donc regarder du côté des liaisons séries, et ça me parait mieux : pas de maître, pas d'esclave, communication bi-directionnelle, et possibilité d'envoyer du texte afin de mieux comprendre les informations envoyées... Je vais creuser dans ce sens...
Mais, je garde toutes vos idées car elles vont certainement servir !
Je vous tiens au courant de mes recherches et de mes découvertes !
Et je vous poste une petite vidéo de mes derniers réglages dès que ma connexion voudra bien télécharger...

La gestion d'un bus multi-maitre avec gestion des collisions, ré-émissions etc... n'est pas forcément plus simple......

Vu que je ne dois échanger des données que sur la précédente carte ou la suivante, je peux simplifier les échanges.
Si Deux cartes sont présentes, il n'y a échange qu'entre ces 2 là.
Si 3 cartes sont présentes, la N°1 discute avec la N°2, la N°2 discute avec la N°1 et N°3, la N°3 ne discute qu'avec la N°2
Et ainsi de suite...
Il suffit de vider et lire les données avant d'en envoyer des nouvelles, et mettre dans les données un code pour savoir qui doit les récupérer...
Enfin, c'est mon point de vue pour le moment...
Surtout, qu'on peut créer plusieurs liaisons série différentes sur les MEGA, s'il me reste des pins disponibles...

Petite vidéo montrant les modifications :
J'ai peint les différentes zones, en rouge la zone d'arrêt (10 cm), en jaune la zone de freinage (15 cm) et en bleu la zone normale.
Lorsqu'un train arrive devant un feu jaune, dès qu'il entre dans la zone de freinage, il va réduire sa vitesse jusqu'au ralenti, le temps de décéleration est calculé en fonction de la vitesse.
Puis, il va arriver dans le canton présentant un feu rouge, et donc, en entrant dans la zone de freinage, il va réduite sa vitesse jusqu'à une valeur limite (que j'ai cherchée) qui correspond à un seuil d'enclenchement du moteur... Il va avancer dans cette zone jaune jusqu'à ce qu'il arrive dans la zone rouge où il va stopper en une seconde environ. Si le train met trop longtemps à arriver dans la zone rouge, le programme le "booste" un peu...
De cette manière, même en réduisant fortement la valeur du ralenti (ce que j'ai fait sur la vidéo), le programme "force" pour que les trains arrivent dans la zone rouge et s'arrête dans un délai qui ne doit pas être trop long. Ce système évite qu'un train (qui aurait des caractéristiques trop différentes) ne "câle" dans la zone bleue ou jaune, et fait le nécessaire pour qu'il arrive jusque dans la zone d'arrêt, c'est à dire à moins de 10 cm du feu !


Dès qu'elle sera prête, je vous poste une deuxième vidéo avec une vieille PIKO qui nécessite plus de courant et avec laquelle j'ai laissé les mêmes consignes que la 25500... Elle freinera plus brusquement mais continuera quand même jusqu'à la zone rouge...

Bonsoir,
Je suis en semi hard coding, mais j'ai rencontré les mêmes problèmes que toi. L'arduino n'a pas assez de ports E/S, de pwm ...
J'ai envisagé et maquetté deux options :
A) 1 mini arduino par canton : même programme, fait la même chose : pilote la vitesse, la couleur des feux, lit l'occupation de voie : des ordres simples. Les esclaves envoient au maître l'occupation de voie et le maître envoie les ordres aux esclaves qui les exécutent. Via le bus I2C c'est ""simple"". En init, le maître recense les esclaves et donc connait le nombre de cantons ...
B) 1 seul arduino (mega) et des mux pour les E/S (mcp23017 ou équivalnt), pwm (tlc5940 ou équivalent) ....sur un ou plusieurs bus I2C (tca9548) ... en termes d'E/S c'est open bar. Seule limite l'imagination !
Tu peux y consacrer alors quelques E/S pour programmer dynamiquement l'adresse des esclaves !

Pour te donner une idée il est prévu sur mon réseau :
 mux entrée pour 64 interrupteurs et 64 détecteurs (mcp23017) en cours de redesing pour harmoniser ... (2 pins)
 mux sortie pour les signaux (environ 100 led) mcp23017 en cours de tests (2 pins)
 mux pilotage pwm 13 cantons sur boucle, + environ 10 gare, triage, moulin ... tlc5940 en cours de tests (avantage : la gestion est déportée ce n'est pas l'arduino qui bosse) (6 pins)
 mux aiguillage 50 environs cd 4067 en debug ! (12 pins mais mal conçu !)
J'ai encore un peu de marge ...
A+

PS : concernant le bus I2C, il peut faire peur, mais avec les lib's, c'est simple : une adresse et un message et hop dans le mille !!!! (enfin presque !!!)

Pythéas, on se rappelle le bon (vieux) temps du cp/m, msdo, prologue .... !!!!!!!!!