La gestion des cantons par Arduino !!

nicozea57 a écrit:

Commence à préparer le câblage !! Tu connais les coupures, les soudures, et sur le sujet, tu as toutes les informations des longueurs nécessaires !!!
Ok je sors

C'est pas comme ça qu'on parle à son père !
Ok je sors aussi !

Je t'ai mis un petit mot sur le forum LR alors à bientôt Michael.

Christian

Pour la suite, je posterai sur ce forum vu que c'est ici que tu as le plus développé...

J'aime bien le charrier !
J'ai vu ton message et ton article. Bravo, c'est simple, efficace et pour les débutants en Arduino, une bonne façon de se faire la main !
Merci.

De mon côté, j'attends désespérément la livraison de mes composants (74HC259 et 74HC138) pour mettre à jour mon fonctionnement des feux et du TCO avec adressage unique, je pense que ce serait plus "sain" que les registres à décalage qui demandent + de temps !

A+

J'aime bien le charrier !

A part Jacques, j'en connais pas d'autre !!!,moi aussi je  

Pour ceux qui n'ont toujours rien compris au BAL   , j'ai trouvé cette ancienne vidéo SNCF, modélisée avec du HO !!
J'adore :

Très chouette cette vidéo !

Petite question existentielle du dimanche soir :

J'ai remplacé, dans ma BB25500 PIKO, les diodes zéner 2,7 V que j'avais mises pour la ralentir, par des diodes zéner 5,6 V pour la ralentir encore plus !
Le résultat est là, mais je viens de remarquer quelque chose de "bizarre" : lorsque je l'arrête (consigne=0), les feux restent allumés (alors qu'avec les diodes zéner 2,7 V non).
J'ai jeté un oeil sur mon schéma, et je sais qu'un courant très faible passe par mon circuit de détection.
Mais j'ai mesuré aux bornes du rail, j'ai 5,5 V (comme de par hasard...)
Je n'avais pas mesuré avec les anciennes diodes, mais j'en déduis que la tension devait être 2,7 V environ...
Ce que je ne comprends pas, c'est, pourquoi cela se produit avec des zéner de 5,6 V et pas avec les 2,7 V ? Qui connait par coeur le circuit électronique à l'intérieur de la Piko ?

J'ai fait un autre essai, du coup, qui est de mettre une zéner sur le canton où se trouve la 15000 Minitrix (pour voir si les feux s'allument). Eh bien, non, ils ne s'allument pas...

Les électroniciens du forum peuvent éclairer ma diode ???

Ce sont des feux à LEDs ?

oui

nicozea57 a écrit:

Pour ceux qui n'ont toujours rien compris au BAL   , j'ai trouvé cette ancienne vidéo SNCF, modélisée avec du HO !!

Super cette petite vidéo !

J'ai bien réfléchi à ton système et voici quelques remarques qui pourront te faire améliorer l'ensemble, d'autant que tu souhaites le commercialiser. Il ne s'agit aucunement d'une critique (je suis admiratif de ce que tu as développé) mais c'est juste mon analyse.

1- Il est évident qu'une détection de train par consommation de courant est préférable à un système de repérage par ILS (entrée-sortie) comme dans mon BAL de débutant. De plus, le schéma de ton détecteur par canton est remarquable car c'est en fait Arduino, grâce à son entrée analogique, qui fait le boulot et repère sur quelle portion de canton le train se situe. Donc, je n'ai pas grand chose à dire là-dessus : j'applaudis des deux mains ce schéma pour sa simplicité.

2- Ce système permet donc de repérer le premier essieu sur une portion de canton, et ainsi agit sur le canton pour arrêter le train si nécessaire, ce qui fait que ton système permet les UM ou les trains en pousse, et ce sans connaître la longueur des convois ou caractéristiques des engins moteurs. Avec ce principe, tu peux raccourcir la zone d'arrêt puisque la motrice n'est jamais complètement dessus et ainsi arrêter le train juste au pied du signal.

3- Tu intercales un canton "tampon" entre deux trains qui se suivent, pour des raisons de sécurité. Je trouve que c'est dommage d'introduire cette notion de canton tampon car ce n'est pas le principe de la SNCF et de plus, cela limite le nombre de trains qui circulent en même temps. Sur un ovale à 6 cantons, la théorie indique que 5 trains peuvent circuler sauf que ce n'est pas fluide. Mettons 3 trains pour que ce soit fluide. Avec le canton tampon entre deux trains se suivant, cela ne permet que deux trains au maximum. L'utilisateur doit prendre en compte qu'avec une détection par consommation de courant, tous les wagons doivent avoir des essieux graphités et cela ne doit pas être une considéré comme une contrainte. La sécurité est ainsi assurée même en cas de décrochage de wagon.

4- Tes cantons ont trois zones, dont une sert à deux choses : mesurer la vitesse du train sur le canton précédent et à arriver à vitesse réduite sur le canton actuel, avant la zone d'arrêt. Je pense que c'est sans doute faisable avec seulement deux zones (pleine voie et arrêt), la mesure de vitesse pouvant sans doute se faire sur la zone d'arrêt du canton précédent (si le train la passe sans s'arrêter évidemment) et le freinage sur la zone pleine voie du canton situé après cette zone d'arrêt. On peut aussi envisager un canton constitué d'une zone principale au milieu et d'une zone d'arrêt à chaque bout : ainsi, le canton peut être utilisé dans les deux sens, et ceci est un gros plus par rapport à ce que tu as conçu, et selon le sens, on peut utiliser une zone d'arrêt comme zone de mesure de vitesse.

5- Je trouve, tout comme jlb, que ta façon de construire ta PWM est bien compliquée et qu'il serait plus simple de mieux utiliser les Timers. jlb t'a d'ailleurs conseillé un article de locoduino qui en parle pour le UNO mais cela peut être adapté à un MEGA. Je reste également sceptique sur ton choix de fréquence PWM : comme l'a dit jlb, il y a une différence entre essais et endurance. Et c'est bien un régime d'endurance que rechercheront les utilisateurs potentiels.

C'est surtout le point 3 qui me gène le plus pour avoir un fonctionnement identique aux pratiques SNCF (ce serait un atout pour une commercialisation) et je pense que si tu peux faire un système pour voie unique, donc réversible, ce serait également un gros plus. Evidemment, quand on a commencé quelque chose, on a du mal à revenir en arrière, mais vu que tu te lances dans un circuit plus complexe, ce serait le moment idéal pour corriger des choix initiaux surtout que tu as maintenant une grande expérience dans ce domaine, et que tu as prouvé que tu es capable de développer ce que tu veux.

Voilà, encore une fois ces remarques ne sont pas des critiques de ce que tu as réalisé et qui fonctionne déjà très bien. Mais comme je te sens perfectionniste et jusqu'au-boutiste (et c'est un compliment), je voulais te faire part de cela. A toi de voir si cela vaut la peine de le mettre en oeuvre. Bien évidemment, je n'ai pas donné d'avis sur ce qui ne concerne pas le BAL à proprement parler (les écrans, la tablette, la gestion de gare, etc.) car cela me parait très bien.

Amicalement.

Christian

Merci Christian, merci d’avoir pris le temps de regarder tout le fil, et je te félicite, car tu as bien compris comment le système fonctionne ! Bravo (car des fois, les explications écrites ne sont pas évidentes à formuler)

Concernant les points 1 et 2, rien à dire, merci.

Pour le point 3, il est vrai que mon système ne correspond pas à 100% au fonctionnement de la SNCF, mais, il faut avouer que nos petits trains non plus !! Le canton tampon est pour moi la seule solution qui permette d’avoir des cantons « plus petits » que ce qu’il faudrait faire pour coller à la réalité.
Sur une vraie voie, lorsque le conducteur d’un train arrive devant un feu jaune, il sait, qu’en ce moment, il y a un train 2 cantons devant lui, il voit ce qui se passe devant lui, et la longueur des cantons de pleine voie étant conséquentes, il a le temps d’agir.
Pour nous modélistes, nos trains n’ont pas cette chance ! Et, il faut anticiper…
Si, effectivement, j’ajoute comme 2ème règle d’or, que tous les wagons doivent être conducteurs de courant, je pourrais enlever ce canton tampon, et n’utiliser que la libération d’un canton pour en permettre l’entrée. Mais, je ne suis pas certain, que tous les modélistes aient tous les wagons graphités, ou s’ils veulent le faire !
C’est pour cela que j’ai mis en place ce canton tampon, pour éviter qu’un train trop rapide puisse rattraper un train très lent qui viendrait de franchir un feu et dont la fin du convoi est encore présente sur le canton que le train rapide va parcourir !!

Pour le point 4, c’est justement mon côté perfectionniste (même si ça ne correspond pas à la réalité) qui me donne envie de voir le train s’arrêter au plus juste devant le feu rouge !

Pour le point 5, j’ai déjà fait tourner mes locos plusieurs heures de suite, sans aucun problème… Mais, j’ai regardé avec attention les articles mentionnés, et je n’ai pas encore fait mon choix définitif. La seule chose qui m’empêche de passer à une fréquence plus haute (nettement plus haute pour ne pas avoir de bruit dans le moteur) c’est le temps de gestion du programme. Car, s’il met trop de temps à modifier les sorties par rapport au temps entre 2 impulsions de l’interruption, le programme ne sera plus gérer correctement…

Voilà pour mes justifications, mais comme tu as pu le constater, pas mal de choses ont évoluées au cours du développement, et donc, il peut y en avoir encore…
A+

Message réédité pour une meilleure présentation : voir ci-dessous.

nicozea57 a écrit:

Merci Christian, merci d’avoir pris le temps de regarder tout le fil, et je te félicite, car tu as bien compris comment le système fonctionne ! Bravo (car des fois, les explications écrites ne sont pas évidentes à formuler)

J'ai été très intéressé par tout ce que tu as expliqué et cela m'a donné des idées pour réaliser un BAL plus sophistiqué que celui que j'ai décrit récemment.
.....

nicozea57 a écrit:

Si, effectivement, j’ajoute comme 2ème règle d’or, que tous les wagons doivent être conducteurs de courant, je pourrais enlever ce canton tampon, et n’utiliser que la libération d’un canton pour en permettre l’entrée. Mais, je ne suis pas certain, que tous les modélistes aient tous les wagons graphités, ou s’ils veulent le faire !

Je suis persuadé que les modélistes qui utilisent des cartes de détection d'occupation par consommation de courant ont tous leurs essieux graphités, d'abord parce que ce n'est pas difficile ni onéreux à faire, ensuite parce que ne pas le faire irait à l'encontre du choix du système de détection. Donc, tu peux poser en postulat que les essieux doivent être graphités pour utiliser ton système et ainsi l'améliorer en te rapprochant de ce que fait la SNCF et supprimer ce canton tampon. En plus, avec des essieux graphités, les trains peuvent être détectés à cheval sur deux cantons, ce qui permet de coller encore plus à la réalité (mon système en était bien incapable...)

Pour le point 5, en utilisant les timers, tu mettras le moins de temps possible pour modifier tes sorties de PWM.

Tu n'as rien dit de la réversibilité du canton pour faire de la voie unique (canton fonctionnant dans les deux sens), pourtant je pense que ce serait un sacré argument de vente !

Encore une fois, ce que je dis là, ce n'est que des idées supplémentaires pour que ton produit final soit ce que recherche le plus grand nombre. Mais rien ne t'oblige à les suivre. Comme tu dis, nous sommes toujours obligés de faire des choix et des compromis.

Je serai à Trainsmania. Et toi ? Ce pourrait être l'occasion de se rencontrer et je ne serai pas le seul de locoduino, les autres sont bien plus calés que moi. Alors si de belles conversations te tentent, n'hésites pas.

Bien amicalement.

Christian

Si ma mémoire est bonne, tu génères un signal PWM que tu multiplexes, non ? Alors pourquoi tu n'exportes pas la production du signal PWM dans un Attiny ? Ca te simplifierait bien les choses dans ton programme principal et te lèverait de cette contrainte !

sierramike a écrit:

Si ma mémoire est bonne, tu génères un signal PWM que tu multiplexes, non ? Alors pourquoi tu n'exportes pas la production du signal PWM dans un Attiny ? Ca te simplifierait bien les choses dans ton programme principal et te lèverait de cette contrainte !

Ce n'est pas une contrainte, mais une difficulté !
Pour le moment, le système fonctionne parfaitement bien. Aucune locomotive n'a l'air de souffrir du 100Hz...
Le programme gère correctement ses PWM, sans débordement de temps...

Je prends bonne note de vos remarques et suggestions, et si besoin est, j'y penserai.

Le 100Hz me convient très bien pour l'instant et permet des ralentis que les hautes fréquences ne permettent pas. (d'ailleurs les essais que j'avais fait avec une haute fréquence m'avaient donné des résultats plutôt aléatoires...)
Le fait d'ajouter un Attiny, pourquoi pas, mais ça complexifie le câblage (enfin, ça augmente le nombre d'éléments à fournir), si la Mega arrive à le gérer, ce sera aussi un gain en coût de fabrication...

Je reviens sur 2 points soulevés par Arduino :

1) Je n'ai pas envie d'imposer trop de choses aux futurs utilisateurs de mon système. Je veux qu'il soit fonctionnel (et avec le plus de sécurité possible) avec des convois graphités ou non. Remarque en passant, si je veux supprimer le canton tampon, il faudrait utiliser le fait qu'un canton soit libéré afin de permettre à un autre train d'y entrer. La perte du signal de détection serait vue par le système comme un canton libre, et donc donnerait cette possibilité... Avec le risque d'accident. Mon système, utilise une sécurité positive, c'est à dire, que c'est le fait qu'un essieu conducteur soit détecté dans la zone de freinage d'un canton (qui assure que le convoi est toujours là et qu'il roule) qui libère l'entrée du canton précédent...

2) Concernant la réversibilité du système. Dmarrion avait déjà soulevé ce point en justifiant que le système BAL de la SNCF est dans la plupart des cas utilisé sur de la double voie. Lorsqu'il s'agit d'une voie unique, c'est un système différent qui est utilisé. D'autre part, si on veut inverser le sens de rotation des moteurs, il faut inverser la polarité des rails. Mon système de détection est forcément raccordé au "moins" pour aller vers le "0" volt. Ce qui implique, que, pour inverser le sens de roulement, il faudrait inverser la polarité de toutes les zones de chaque canton. Et, il faudrait une ribambelle de relais !! (Et en plus, prévoir les coupures des deux côté du canton en choisissant le rail correspondant pour les coupures......)


Ce que je pourrais éventuellement faire concernant le fait d'être plus proche du système SNCF, c'est ajouter dans le programme un moyen de savoir si le convoi est graphités ou non (avec une mesure du temps de passage sur 2 cantons, temps court = convoi non graphités ou loco seule, temps long = convoi graphités). Ensuite, une fois cette information mémorisée, si le train est graphité, utiliser le fait qu'il libère un canton pour en permettre l'entrée, si le train n'est pas graphité, attendre d'atteindre le bout d'un canton pour libérer le canton précédent (canton tampon). Ou peut-être, de demander à l'opérateur, lorsqu'un nouveau train est détecté, de préciser s'il est graphité ou non...
Qu'en pensez-vous ?

Je commence par te répondre sur ton point N°1. Pour moi, la sécurité totale peut se faire sans canton tampon. Je te dis cela parce que justement ton système m'a fait penser à une nouvelle sécurité pour mon BAL de débutant (décrit sur locoduino pour ceux qui prendraient en cours de route).
Actuellement, ma sécurité vient du fait qu'un train ne peut pénétrer sur un canton que s'il est totalement libéré (la SNCF fait différemment dans certains cas). Imaginons que pour une raison que je n'ai pas imaginée, un train entre quand même sur un canton occupé. En mettant en mémoire l'état précédent du canton, on peut ajouter une sécurité supplémentaire et le système peut alors couper le courant et tout bloquer jusqu'à ce que l'opérateur résolve le problème. Je m'explique : le train pénètre sur un canton donc son état devient occupé. Pour que tout soit normal, l'état précédent devait être libre. Si l'état précédent était occupé, c'est qu'il y a un problème !
Comme tu vois, il y a plusieurs solutions pour que le système se surveille lui-même. Ton canton tampon ne m'a pas convaincu d'autant plus que j'ai vu sur une de tes vidéos un train en tamponner un autre par l'arrière. Alors ?

Pour le point N°2, je ne suis pas d'accord avec Dmarrion mais je ne suis pas cheminot et il l'est peut-être, auquel cas il en sais plus que moi. Mais près de chez moi, il y a des signaux BAL qui sont à l'envers par rapport au sens de circulation, pour le cas où le train emprunte cette portion de voie dans l'autre sens (cas par exemple où il faut dévier une circulation pour cause de travaux ou d'encombrement). Alors, oui je suis bien conscient que cela complique ton montage mais contrairement à ce que tu dis, il n'y a pas besoin de couper les deux rails, un seul suffit si l'électronique est capable de réagir à des tensions positives ou négatives. Ceci est décrit dans beaucoup d'ouvrages d'électronique de modélisme ferroviaire. Les réseaux miniatures sont souvent en voie unique parce que cela demande moins de place et que c'est plus sexy. C'est pourquoi je pense que c'est un sacré argument de vente pour toi au cas où... Tu devrais prendre contact avec Matabiau sur le forum de Loco-Revue, qui a une grande expérience dans le domaine des cantons en analogique. Il pourra te donner de précieux conseils.

Comme tu démarres un nouveau projet, c'est maintenant qu'il faut réfléchir à tout cela : une fois installé, il sera trop tard ou bien ce sera plus de galère. C'est un nouveau défi, mais franchement tu as prouvé à tous que tu es capable de relever ce genre de challenge. En tout cas, c'est comme ça que je te vois. Mais ce n'est pas parce que je te dis de le faire qu'il faut le faire. Prends simplement le temps d'y réfléchir, en imaginant ce que cela va apporter à ton BAL et non les problèmes qu'il faudra résoudre et que tu résoudras de toute façon parce que tu es pugnace.

Quant à imposer des contraintes à l'utilisateur, sache que quel que soit le système, y compris pour les plus sophistiqués (rétro et logiciel), il y a toujours des règles à respecter. Le système universel n'existe pas et il y a toujours des normes à respecter. L'utilisateur raisonne aussi avec ce que le système lui apporte par rapport aux contraintes à respecter et le graphitage d'essieu n'est pas ce qu'il y a de plus contraignant pour voir un système fonctionner en toute sécurité. Enfin, c'est ce que je crois...

si je peux juste me permettre une petit point sur la détection de courant...
Utilisateur de DR, qui fonctionne par détection de courant, je n'ai absolument pas envie de rendre tous mes wagons et voiture détectables. Ca représente quand même pas mal de boulot sur une grand parc et c'est assez ch...t à faire, DR préconisant la mise en place d'une résistance CMS sur l'essieu.
Donc je ne rends détectable, en plus de la loco, bien sur, que le dernier wagon du train, ce qui assure la sécurité de fonctionnement.

Mon petit grain de sel à propos des feux jaunes.

J'avais mis en place un ralentissement des trains pénétrant sur un canton présentant un feu jaune et le résultat était une très bonne fluidité de la circulation, tout comme le souhaite la SNCF.

Mais voila, en tant que modéliste, des trains qui ne s’arrêtent jamais, ce n'est pas drôle. Du coup, j'ai supprimé cette fonctionnalité pour avoir le plaisir de voir des trains s’arrêter devant un feu rouge, puis repartir en douceur.

Accessoirement, il faut que je rajoute un délai d'une ou deux secondes à l'apparition du feu vert avant le redémarrage du train. ce qui devrait ajouter au réalisme.

D'autre part, considérer que tous les convois sont graphités ne me parait pas une contrainte déraisonnable.

Ne graphiter que le dernier essieu me parait une contrainte bien plus sérieuse, il faut veiller à ce que ce wagon soit toujours installé en dernier, et ceci à chaque fois que l'on compose une rame.

Arduino a écrit:

le train pénètre sur un canton donc son état devient occupé. Pour que tout soit normal, l'état précédent devait être libre. Si l'état précédent était occupé, c'est qu'il y a un problème !

Si l'état précédent est occupé, il ne PEUT PAS pénétrer sur le canton puisqu'il a un feu rouge !
D'ailleurs, je le gère déjà dans mon système, si, malgré le feu rouge, la loco vient à dépasser la limite du canton, je coupe son alimentation immédiatement.

Arduino a écrit:

Ton canton tampon ne m'a pas convaincu d'autant plus que j'ai vu sur une de tes vidéos un train en tamponner un autre par l'arrière. Alors ?

Je n'ai pas l'intention de convaincre tout le monde !
Mes vidéos montrent l'avancement du projet. Bien-sûr qu'il y a encore des bugs... Mais de moins en moins... Actuellement, cela fait longtemps que 2 trains ne se sont pas rattrapés (sauf quand les trains sont plus longs que mes cantons, mais, là, je transgresse la règle d'or, et ce, volontairement...) D'autant plus, que sur mon petit ovale, mes cantons mesurent entre 50 et 70 cm... ce qui ne correspond pas à un réseau "normal".
Attends de voir mon BO plateau de test lorsqu'il sera prêt !!  

Pour la voie unique, ça ne m'intéresse pas pour le moment. Mon système a pour but de gérer le BAL sur de la double voie (ou voie à sens unique). Peut-être qu'un jour, je me pencherai sur la voie unique, mais cela sera complètement différent au niveau gestion et programmation, puisqu'il faut gérer les 2 sens de circulations (c'est bien plus complexe que ça n'en a l'air...). Et on n'utilise jamais une double voie comme une voie unique, ni une voie unique comme une double voie. Les 2 systèmes seront différents, utilisables séparément sur un même réseau, mais ne seront connectés ensemble que dans une gare, qui sera gérée manuellement...

Je rebondis sur Michel (je ne suis pas trop lourd, ne t'inquiète pas Michel) à propos des wagons graphités, j'allais justement en parler, seul le dernier wagon graphité peut donner de bons résultats, et du coup, c'est moins contraignant...en terme de travail, mais il est vrai que du coup, il faut que tes rames soient prévues (toujours le même wagon en fin de convoi, si tu places ton convoi en sens inverse, ça marche plus). Mais, si on veut des feux de fin de convoi, on met quand même le wagon équipé en queue...donc....

C'est pour cela, je pense, que je vais laisser mon canton tampon, pour laisser l'utilisateur mettre les convois qu'il veut. S'il veut graphiter tous ces wagons, la sécurité sera absolue, s'il graphite que le dernier, la sécurité sera toujours correcte, et s'il ne veut rien graphiter, il pourra quand même utiliser le système sans avoir trop de risque de collision par rattrapage (sauf en cas de décrochage, mais ce sera son choix)

Ce qui me ramène à ma question, pourrais-je mettre en place un système qui sache si le convoi est graphité ou non, et changer le fonctionnement des cantons en fonction ??

Pour Cleon, tu peux quand même les arrêter en gare, non ?

nicozea57 a écrit:

Arduino a écrit:

Ton canton tampon ne m'a pas convaincu d'autant plus que j'ai vu sur une de tes vidéos un train en tamponner un autre par l'arrière. Alors ?

Je n'ai pas l'intention de convaincre tout le monde !
Mes vidéos montrent l'avancement du projet. Bien-sûr qu'il y a encore des bugs... Mais de moins en moins... Actuellement, cela fait longtemps que 2 trains ne se sont pas rattrapés (sauf quand les trains sont plus longs que mes cantons, mais, là, je transgresse la règle d'or, et ce, volontairement...) D'autant plus, que sur mon petit ovale, mes cantons mesurent entre 50 et 70 cm... ce qui ne correspond pas à un réseau "normal".
Attends de voir mon BO plateau de test lorsqu'il sera prêt !!  

Tu as l'air d'être sur la défensive, mais ce que j'ai dit n'est absolument pas une attaque ; c'est une simple remarque. Moi non plus, je ne cherche pas à te convaincre, mes remarques, tu en feras ce que tu voudras bien évidemment. J'analyse ton système et te donne mon impression sur les points forts (et il y en a) et sur les points faibles (il en reste et pour une commercialisation, le mieux serait de les corriger) ; dans cette démarche, tu ne peux que reconnaître que j'ai essayé d'être objectif, ni à charge, ni à décharge, je pèse le pour et le contre. Je m'interroge sans aucune prétention de connaître les réponses.
Ce qui est arrivé une fois peut se reproduire, sauf si tu as changé quelque chose dans la conception de ton système depuis, et c'est peut-être le cas. Faire de la sécurité totale est très difficile, sauf à prévoir une redondance de système qui s'autosurveillent comme dans les avions de ligne. Le prix aussi est en conséquence.

Voilà, je t'avais promis de te donner mon analyse : c'est fait et je n'ai rien à ajouter. Une fois de plus, cela ne doit pas être considéré comme une critique mais plutôt comme un axe de réflexion, comme tous les forums permettent de le faire, rien de plus. Tu es assez grand pour savoir si tu tiens compte ou non de tout ce qui est exprimé ici par les uns et les autres. Je reste à ta disposition bien entendu si tu le souhaites et encore bravo pour cette somme de travail que tu as réalisée. Mais je ne m'en vais pas, je continuerai à suivre le développement de ton BO plateau et à intervenir de temps en temps.

nicozea57 a écrit:

........

Pour Cleon, tu peux quand même les arrêter en gare, non ?

Oui, bien sur ! A la main, ou en forçant un feu au rouge ou encore via un itinéraire.

nicozea57 a écrit:

Le 100Hz me convient très bien pour l'instant et permet des ralentis que les hautes fréquences ne permettent pas. (d'ailleurs les essais que j'avais fait avec une haute fréquence m'avaient donné des résultats plutôt aléatoires...)

Au risque de me répéter, les transistors que tu utilises ne suivent pas à « haute » fréquence

Voici une vidéo avec une PWM à 32kHz et un asservissement de vitesse par mesure de la FCEM

http://locoduino.org/pic/ralenti.m4v

J'adore vos discussions animées, quoi qu'il arrive ça fera avancer le schmilblick !

Par contre plutôt qu'une mesure de temps de déplacement pour détecter le graphitage, moi je mettrais juste une option générale dans le système, ou alors un paramètre en plus de la consigne puisque tu suis les trains à la trace, car un autorail naviguant là dedans sera pris pour un train non graphité

JLB : N'hésite pas à m'aider, je suis preneur !! J'ai modifié ma PWM grâce aux timers, comme conseillé plus tôt. C'est plus simple, je l'accorde, et le fonctionnement est tout à fait similaire. Par contre, j'ai tenté d'augmenter ma fréquence de 100Hz à 400Hz (mon interruption intervient toutes les 128µs, j'ai voulu descendre à 32µs), eh bien, mon programme ne fonctionne plus du tout, ce qui veut dire que ce que je demande au programme dans mon interruption prend + de 32µs... Conclusion, si je fait ma propre PWM, mon programme ne peut pas s'exécuter correctement si je demande de la haute fréquence...(ou alors sous traiter à un autre arduino...). Et là, ce n'est pas les transistors  
Est-ce que le 100hz pose vraiment problème ? (je me répète aussi, j'ai bien lu l'article concernant l'échauffement avec tous les calculs théoriques de puissance dissipée, etc...) Je n'ai pas de loco équipée d'un moteur "sans fer" pour vérifier par moi-même...
Comment je peux faire pour générer une PWM à 32kHz capable de gérer 64 cantons ( et donc 64 valeurs potentiellement différentes) dans une même interruption ??

sierramike : mon idée serait de demander à l'opérateur lors de l'ajout d'un train, s'il est "graphités" ou non, ce qui deviendrait un paramètre du train mémorisé comme les différentes consignes. Pour un autorail, il faudrait le considérer comme une loco seule, ou comme un convoi graphités (tous les wagons ou bien seulement le dernier) puisque lorsqu'il quitte le canton, on sait que c'est bon (sauf s'il a une remorque non graphitée, considérée alors comme un wagon non graphité)...
Si le paramètre dit "le train est graphité" alors on utilise la libération d'un canton pour permettre son entrée (comme la SNCF)
Si le paramètre dit "le train n'est pas graphité" alors on utilise le canton tampon pour minimiser les risques.
C'est pas mal ça non ?

nicozea57 a écrit:

JLB : N'hésite pas à m'aider, je suis preneur !! J'ai modifié ma PWM grâce aux timers, comme conseillé plus tôt. C'est plus simple, je l'accorde, et le fonctionnement est tout à fait similaire. Par contre, j'ai tenté d'augmenter ma fréquence de 100Hz à 400Hz (mon interruption intervient toutes les 128µs, j'ai voulu descendre à 32µs), eh bien, mon programme ne fonctionne plus du tout, ce qui veut dire que ce que je demande au programme dans mon interruption prend + de 32µs... Conclusion, si je fait ma propre PWM, mon programme ne peut pas s'exécuter correctement si je demande de la haute fréquence...(ou alors sous traiter à un autre arduino...). Et là, ce n'est pas les transistors  
Est-ce que le 100hz pose vraiment problème ? (je me répète aussi, j'ai bien lu l'article concernant l'échauffement avec tous les calculs théoriques de puissance dissipée, etc...) Je n'ai pas de loco équipée d'un moteur "sans fer" pour vérifier par moi-même...
Comment je peux faire pour générer une PWM à 32kHz capable de gérer 64 cantons ( et donc 64 valeurs potentiellement différentes) dans une même interruption ??

C'est pour ça que si j'étais toi, je sous-traiterais la PWM à une unité extérieure, ça me semble tout à fait recevable, un Arduino, même Mega, a quand même ses limites ! Pour ainsi dire, là tu as besoin d'un "dual core" pour paralléliser tes exécutions, et comme un Atmega est "mono-core", autant en mettre deux (pas forcément deux Mega, à toi de voir ce dont tu as besoin, un Uno ça vaut 2,50€, encore moins si à la fin tu utilises uniquement le composant sans toute la plaque qui tourne autour, vu tout ce que ton système va gérer, c'est pas choquant !)

nicozea57 a écrit:

sierramike : mon idée serait de demander à l'opérateur lors de l'ajout d'un train, s'il est "graphités" ou non, ce qui deviendrait un paramètre du train mémorisé comme les différentes consignes. Pour un autorail, il faudrait le considérer comme une loco seule, ou comme un convoi graphités (tous les wagons ou bien seulement le dernier) puisque lorsqu'il quitte le canton, on sait que c'est bon (sauf s'il a une remorque non graphitée, considérée alors comme un wagon non graphité)...
Si le paramètre dit "le train est graphité" alors on utilise la libération d'un canton pour permettre son entrée (comme la SNCF)
Si le paramètre dit "le train n'est pas graphité" alors on utilise le canton tampon pour minimiser les risques.
C'est pas mal ça non ?

Eh ben ça me semble pas mal du tout comme ça !

nicozea57 a écrit:

.....
Si le paramètre dit "le train est graphité" alors on utilise la libération d'un canton pour permettre son entrée (comme la SNCF)
Si le paramètre dit "le train n'est pas graphité" alors on utilise le canton tampon pour minimiser les risques.
C'est pas mal ça non ?

Cela me parait mieux car ainsi, tu gardes une certaine sécurité et si l'utilisateur veut un comportement comme la SNCF, il peut l'avoir en graphitant son matériel (ou en le faisant consommer du courant : éclairage par exemple). Ca peut être une bonne option.