Messages

736

Shields et Modules / Re : Carte Servomoteurs DCC + CAN

« le: janvier 27, 2016, 09:04:13 pm »

Salut Jean-Luc,

Je n'avais pas tilté : mais c'est une nouvelle carte !!

Pour être franc, maintenant que je vois ce que peut faire le bus CAN (pour info, obligatoire sur les autos depuis 2008 !) je ne vois pas l'intérêt d'un bus DCC sous le réseau.
Je comprends ceux qui ont une commande du commerce et qui peuvent l'étendre grâce à l'Arduino et la super bibliothèque de Thierry (UAD), mais sinon ?
Sauvegarder en EEPROM, bonne idée.
OK pour tes modifs.
Vu que tu mets un MCP23017 pour avoir plus d'entrées, je vais réfléchir pour les occupations d'aiguilles (vous savez que j'ai besoin de cette info)
Je veux bien en prendre 2 si ça n'est pas trop tard. 

737

Infos et bonnes affaires / Re : L'Arduino dans les chaussettes !

« le: janvier 26, 2016, 12:18:51 pm »

Autant les chaussettes, ça me parait idiot, mais ton idée de vibreur pour "débloquer" une loco ne me semble pas si farfelue.
Ou n'importe quoi qui fasse un choc.
C'est en tout cas facile à ajouter. A minima, faire une alarme au TCO.

738

Vos projets / Re : Contrôle numérique des aiguillages

« le: janvier 23, 2016, 09:16:45 am »

Faisons de ton programme un programme universel ! 

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

Et c'est là que tu interviens. 

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

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

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

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

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

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

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

Denis

739

Vos projets / Re : Contrôle numérique des aiguillages

« 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. 

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

740

Vos projets / Re : Contrôle numérique des aiguillages

« 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

741

Vos projets / Re : Contrôle numérique des aiguillages

« 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...

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

742

Vos projets / Re : Contrôle numérique des aiguillages

« 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 
Mais je sens que tu es plein de ressources.

743

Vos projets / Re : Contrôle numérique des aiguillages

« 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é.

744

Vos projets / Re : Contrôle numérique des aiguillages

« 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  .
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 

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 !

745

Présentez vous ! / Re : Salut!

« le: janvier 20, 2016, 05:31:17 pm »

Bonjour Yves,

Bienvenue "au club". Tu sembles fourmiller d'idées, ce qui est une bonne nouvelle. On a hâte de les voir.
Juste un détail sur ton post : Tout n'est pas forcément basé sur le DCC, en particulier sous le réseau.
Quitte à faire soi-même, il y a d'autres bus, le CAN, par exemple.

746

Vos projets / Re : TCO en processing

« le: janvier 19, 2016, 04:19:20 pm »

Grosse évolution : on passe à la V3 

Mode d'emploi :

1°) télécharger processing :

https://processing.org/download/?processing

C'est du Java, mais ça ressemble énormément au langage Arduino.
C'est normal, Arduino dérive de processing.

2°) télécharger le .zip joint qui contient :
- Les fichiers .pde qui sont ceux de Processing
- Une directory qui contient un programme de démo en Arduino
- une directory "data" qui contient les sauvegardes :
   - Cubes.tsv, c'est l'image du réseau
   - RailID.tsv qui contient les identifiants du réseau (numéros de cantons, des aiguilles, identifications des compositions des cantons, …)
   - Une gare exemple qui est une copie de Cubes.tsv
   - Des étiquettes exemples qui sont les étiquettes de la gare.

3°) Il faut brancher un Arduino UNO (p. ex), c'est indispensable au fonctionnement.
Et il faut le laisser branché puisque c'est par le câble USB que transitent les échanges Arduino -> Processing.

4°) On lance d'abord le programme Arduino.
Il faut le faire avant car sinon, on ne peut pas téléverser car le port est déjà utilisé par Processing.

5°) On lance le programme Processing "Essai de cube…", ce qui ouvre tous les autres dans des onglets.

6°) Dans le setup de processing, entouré par des étoiles, les 2 variables à initialiser une fois pour toutes :
- size : ici, c'est size(1920, 1080), mais vous prenez ce que vous voulez.
- edge (arête d'un cube), ici à 40.
En changeant l'arête d'un cube, toutes les autres dimensions se recalculent toutes seules.

7°) Vous lancez le programme ("play", en haut à gauche)
Apparaissent les cubes exemple de la légende sur la gauche.
Par "glisser-déposer", on peut prendre un cube à gauche et le poser où on veut.
Puis on peut l'orienter (coin en bas à gauche pour le sens horaire, coin en bas à droite pour le sens trigo).
Petit à petit, vous construisez votre réseau. 
Je vous propose ma gare déja dessinée et étiquetée.
Faire simplement L.

8°) Si vous voulez recopier une partie ou déplacer une zone, c'est presque comme d'habitude.
- appuyez sur CTRL. Vous pouvez relâcher la touche
- vous sélectionnez la zone (qui passe en grisé). Si vous resélectionnez un cube, il se déselectionne.
- si vous appuyez sur C, les rails (et seulement les rails !) adhèrent au curseur.
- si vous appuyez sur X, pareil
- en appuyant sur V, vous collez. CTRL C+V = copier-coller, CTRL X+V = couper-coller.
Petite subtilité :
Si vous appuyez sur c minuscule, vous ne copiez qu'une fois et tout est perdu.
Mais c'est plus simple.
Si vous appuyez sur C majuscule, la copie est gardée et vous pouvez vous en resservir tout de suite.
C'est particulièrement utile pour des droites.
Pour arrêter, faire M et cliquer sur "annull" dans la boîte qui s'ouvre.

9°) Pour numéroter les cantons et les aiguilles, il faut mémoriser des étiquettes.
- appuyez sur CTRL, comme avant
- Il faut sélectionner cette fois uniquement des rails, un par un ou en groupe.
Attention : il faut les sélectionner uniquement dans le sens horaire (ça servira par la suite)
- puis appuyer sur M (mémory) une fenêtre pop-up apparait et vous donnez le numéro du canton ou de l'aiguille.
- Puis OK et c'est fini.

Mais vous allez vouloir vérifier. C'est normal.
- appuyez sur D (display) et toutes les étiquettes apparaissent.
En grand la première et en petit les filles. Vous pouvez voir ainsi si des zones sont non étiquetées, ou à l'envers.

La touche M (memory)sert aussi à déselectionner :
Vous avez appuyé par erreur sur CTRL. Vous appuyez sur M puis sur "annul".

Les étiquettes suivent le déplacement en couper-coller, mais pas en copier-coller. C'est voulu.

10°) Le mode démo :
 En appuyant sur E (Exemple), une bascule débloque le port série, et ce qui est programmé dans l'Arduino se déroule.
Vous trouvez que ça va trop vite ? : modifiez le delay(1) dans le programme Arduino. Par exemple 500.

11°) Enfin, mais c'est important, vous pouvez sauver en faisant S (Save) : les fichiers Cubes.tsv et RailID.tsv sont alors écrasés et remplacés par vos fichiers.
Mes fichiers exemple sont dont recopiés sous un autre nom pour ne pas les perdre. Vous pouvez faire de même avec les vôtres.

Il reste des choses à faire :
- ajouter des cubes aiguille triple, aiguille symétrique, des ponts et des tunnels, …
- j'aimerais bien faire rouler des trains avec une loco et des wagons sur le TCO.
- finaliser le lien entre SGDD et le TCO.
Pour l'instant, le TCO est "universel". Vous le branchez à un port série sur ce que vous voulez.

Et après, dites-moi ce que vous voudriez en plus !

Merci à Thierry pour sa simplification drastique de la class RailID. 

Si quelqu'un connait personnellement Monsieur PCDuino, j'aimerais bien lui parler.
Juste pour le fun : en faisant S, vous sauvez bien sûr les positions des aiguilles. Cela évite la fameuse EEPROM.
Mais, bon, un écran 27" plus un PCDuino pour gagner une EEPROM ... 

747

Vos projets / Re : Contrôle numérique des aiguillages

« 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 ! 

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.

748

Vos projets / Re : TCO en processing

« le: janvier 11, 2016, 09:20:07 am »

Bonjour,

Évolutions d'hier :

1°) J'ai mis un peu de couleurs. 

J'ai changé le fond des cubes qui est maintenant vert pâle.
Je garde le gris clair pour la position non choisie des aiguilles et le noir pour la position choisie.

2°) Les aiguilles ont maintenant 2 positions. 

Pour le fun (ça n'a aucun intérêt autre que de montrer que ça marche), si on appuie sur SHIFT, on change la position de toutes les aiguilles et TJD.
Il faut au préalable charger la gare (appui sur L) et elle apparaît avec toutes les aiguilles tout droit.
Un coup sur SHIFT et tout est dévié, etc...

3°) L'Arduino envoie maintenant une info au TCO. 

Il faut installer le programme sur un Arduino (il est dans le Zip) et le laisser branché sur le port USB pour utiliser le port série.
Cela fait changer toutes les secondes le contenu de la case 35,0.

A ce sujet, on se rend compte que le port série n'est pas fiable (au moins à 115 200 bits/s) et j'ai dû créer un "trop grand" dans Processing. 

4°) Évidemment, je vais faire le lien avec SGDD pour que la position des aiguilles soit répétée sur le TCO via le bus série.

Autre évolution : la couleur des rails des cantons sera fonction du signal vu par le train.

Pas de train : rails du canton en noir
Signal VL : rails en vert
Signal S ou C : rails en rouge
Autres signaux (et donc en ralentissement) : rails en orange.

A bientôt.

749

Vos projets / TCO en processing

« le: janvier 08, 2016, 02:26:32 pm »

On passe à la V2 ! 

Gros changements :

1°) Définitivement adopté les cubes dans lesquels la TJD est dans un seul cube.
Cela donne des schémas plus compacts et bien plus proches de la réalité.
Merci Pierre. 

2°) Plus de dessins anguleux, mais de belles courbes de Béziers. 
Au passage, la construction des cubes est nettement plus compacte et plus logique.

La rotation des cubes devient ainsi beaucoup plus simple.
Au passage, on tourne d'1/8 de tour à chaque fois.

3°) On peut maintenant sélectionner des cubes :

- On appuie sur la touche CTRL, ce qui a pour effet de mettre le curseur en croix (move) pour voir que l'appui sur CTRL est validé.
On peut relâcher la touche.

- On peut sélectionner des zones, des cubes particulier, disjoints ou non.
Au fur et à mesure, ils passent en grisé.
Sélectionner à nouveau, c'est désélectionner.

- On appuie sur C pour copier, X pour couper.
On peut alors les déplacer à son gré. Ne sont mobiles que les cubes qui ont des rails.

- On appuie sur V pour coller, ce qui déverrouille l'appui sur CTRL.

4°) Les tracés sont en gris clair, la position des aiguilles sera en noir pour la bonne position.

Il reste quelques cubes à définir (aiguille triple, aiguille symétrique, tunnels, ponts, angle, …).

Et, surtout, à le relier à l'Arduino pour que les trains roulent sur les tracés et que les aiguilles soient en bonne position.

750

Débuter / Re : commande servo par inter

« le: janvier 04, 2016, 09:54:50 am »

C'est une bonne nouvelle !

Enseignement : c'est toujours dur d'intervenir dans le programme d'un autre.
On n'ose pas le modifier en profondeur...