1216
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: janvier 23, 2016, 09:19:46 am »
Notez que je n'ai pas prévu que la carte soit alimentée par le DCC, qu'en pensent ceux qui font du numérique ?
L'Arduino pour le train miniature
Nouvelles:
Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
1217
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: janvier 23, 2016, 08:55:39 am »
C'est noté Dominique
Pour tes aiguilles fleishmann tu pourrais les commander par transistors tout de même :-)
Pour tes aiguilles fleishmann tu pourrais les commander par transistors tout de même :-)
1218
Vos projets / Re : Contrôle numérique des aiguillages
« le: janvier 22, 2016, 07:13:58 am »
Bonne analyse.
Note que l'uln intègre des diodes roue libre.
Note que l'uln intègre des diodes roue libre.
1219
Vos projets / Re : solution globale pour pilotage aiguillages avec 8 servos
« le: janvier 21, 2016, 08:33:12 pm »
Bonsoir,
Projet intéressant. Nous avons également ce type de projet, voir ici : http://forum.locoduino.org/index.php?topic=125.0
J'ai quelques questions :
J'ai moi même sur une carte servomoteurs pilotée par un PIC, mis en œuvre une fonction d'allumage de l'alimentation de chaque servomoteur. Il ne s'agissait de régler un problème de consommation ou de grognement des servomoteurs quand ils forcent en butée, mais de limiter l'appel de courant à l'allumage car les servomoteurs frétillaient à la mise sous tension. Finalement, Guillaume a découvert qu'en tirant le signal de commande à +5V les servomoteurs ne frétillaient plus à l'allumage. Je suis donc revenu est arrière et j'ai redessiné une carte sans pilotage de l'alimentation des servos.
La question est : sachant qu'un micro-servomoteurs consomme environ 20mA (de mémoire il faut que je mesure à nouveau) est-il vraiment intéressant de complexifier le matériel pour cette fonction ?
Concernant la déconnexion du servomoteur quand il est en butée, il suffit d'arrêter de le piloter pour que la position ne soit plus asservie et que le moteur cesse de forcer. Cependant, certains servomoteurs numériques continuent d'asservir la position en l'absence de signal de commande mais ils sont rares.
Pourquoi mettre une EEPROM externe alors que l'Arduino en comporte déjà une ?
Pourquoi faire un shield qui a des contraintes de connecteurs plus complexes alors qu'une carte recevant un Arduino type nano ou pro mini est, me semble-t-il plus adaptée pour réaliser ce type de système ?
Projet intéressant. Nous avons également ce type de projet, voir ici : http://forum.locoduino.org/index.php?topic=125.0
J'ai quelques questions :
J'ai moi même sur une carte servomoteurs pilotée par un PIC, mis en œuvre une fonction d'allumage de l'alimentation de chaque servomoteur. Il ne s'agissait de régler un problème de consommation ou de grognement des servomoteurs quand ils forcent en butée, mais de limiter l'appel de courant à l'allumage car les servomoteurs frétillaient à la mise sous tension. Finalement, Guillaume a découvert qu'en tirant le signal de commande à +5V les servomoteurs ne frétillaient plus à l'allumage. Je suis donc revenu est arrière et j'ai redessiné une carte sans pilotage de l'alimentation des servos.
La question est : sachant qu'un micro-servomoteurs consomme environ 20mA (de mémoire il faut que je mesure à nouveau) est-il vraiment intéressant de complexifier le matériel pour cette fonction ?
Concernant la déconnexion du servomoteur quand il est en butée, il suffit d'arrêter de le piloter pour que la position ne soit plus asservie et que le moteur cesse de forcer. Cependant, certains servomoteurs numériques continuent d'asservir la position en l'absence de signal de commande mais ils sont rares.
Pourquoi mettre une EEPROM externe alors que l'Arduino en comporte déjà une ?
Pourquoi faire un shield qui a des contraintes de connecteurs plus complexes alors qu'une carte recevant un Arduino type nano ou pro mini est, me semble-t-il plus adaptée pour réaliser ce type de système ?
1220
Shields et Modules / Re : Carte « Cerveau du réseau »
« le: janvier 21, 2016, 01:32:22 pm »Je pense qu'un accès NTP pour la date et l'heure n'enlève pas la nécessite d'un circuit RTC autoalimenté, mais ça utilise le port I2C comme l'EEPROM.
Honnêtement je sais pas. D'autant plus que autoalimenté implique une batterie qui ne se chargera qu'à quand le module sera sous tension. D'autre part, le circuit de charge de ces modules est vraiment médiocre. J'ai peur que l'heure se perdre rapidement.
1221
Shields et Modules / Re : Carte « Cerveau du réseau »
« le: janvier 21, 2016, 11:54:32 am »
A priori si tu veux utiliser les capacités étendues pour le Due, c'est 3. J'imagine que pour utiliser d'autres CS, il faut bricoler les bibliothèques.
Note que le module Adafruit CC3000 te donne la possibilité de te passer de RTC puisqu'il peut récupérer l'heure sur Internet. Elle comporte également un lecteur SD
La doc : https://learn.adafruit.com/downloads/pdf/adafruit-cc3000-wifi.pdf
Note également qu'une solution pour configurer cette carte est de le faire par le CAN à partir d'une carte IHM qui serait autonome et dialoguerait en CAN avec le cerveau.
Note que le module Adafruit CC3000 te donne la possibilité de te passer de RTC puisqu'il peut récupérer l'heure sur Internet. Elle comporte également un lecteur SD
La doc : https://learn.adafruit.com/downloads/pdf/adafruit-cc3000-wifi.pdf
Note également qu'une solution pour configurer cette carte est de le faire par le CAN à partir d'une carte IHM qui serait autonome et dialoguerait en CAN avec le cerveau.
1222
Shields et Modules / Re : Carte « Cerveau du réseau »
« le: janvier 21, 2016, 10:59:52 am »
Les 2 SPI de l'écran ne peuvent-ils pas être rassemblés ? le chip select sélectionnera le bon.
1223
Shields et Modules / Re : Carte « Cerveau du réseau »
« le: janvier 21, 2016, 10:02:17 am »
Bonjour Dominique,
Concernant la taille de l'eeprom, abondance de bien ne nuit pas. On peut imaginer y stocker la position, l'identification et la longueur des trains à l'extinction. La position des aiguilles, etc. Enfin l'état, c'est à dire l'ensemble des variable du «cerveau». On peut aussi y stocker de manière permanente le graphe du réseau. Donc autant mettre une 128k x 8 bits.
Ok pour un connecteur écran / clavier. Il faut en définir un. Note que j'avais également fait des essais d'écran SPI avec le due et j'avais monté la fréquence du SPI au max sans que l'écran décroche. Il faut que je retrouve le code. Ok pour les poussoirs. Mais dans ce cas, ne vaut il pas mieux déporter sur une carte d'IHM les éléments d'interface utilisateur ? Cette carte d'IHM n'étant pas toujour connectée. Si tu mets un écran SPI, un clavier et des boutons, l'écran LCD est il encore nécessaire ? Si oui, un 20x4 est-il nécessaire ?
Pour la mesure de courant, il faudrait un schéma.
Concernant la connectivité sans fil, nous avons avec mes camarades, expérimenté le CC3000, il s'agit d'un module wifi SPI. Il fonctioone bien. Le cerveau serait un noeud sur le réseau wifi de la maison. Comme nous somme tous sous iOS, nous nous orientons vers une appli tablette pour configurer et piloter les locomotives.
Ok pour le RTC.
Concernant la taille de l'eeprom, abondance de bien ne nuit pas. On peut imaginer y stocker la position, l'identification et la longueur des trains à l'extinction. La position des aiguilles, etc. Enfin l'état, c'est à dire l'ensemble des variable du «cerveau». On peut aussi y stocker de manière permanente le graphe du réseau. Donc autant mettre une 128k x 8 bits.
Ok pour un connecteur écran / clavier. Il faut en définir un. Note que j'avais également fait des essais d'écran SPI avec le due et j'avais monté la fréquence du SPI au max sans que l'écran décroche. Il faut que je retrouve le code. Ok pour les poussoirs. Mais dans ce cas, ne vaut il pas mieux déporter sur une carte d'IHM les éléments d'interface utilisateur ? Cette carte d'IHM n'étant pas toujour connectée. Si tu mets un écran SPI, un clavier et des boutons, l'écran LCD est il encore nécessaire ? Si oui, un 20x4 est-il nécessaire ?
Pour la mesure de courant, il faudrait un schéma.
Concernant la connectivité sans fil, nous avons avec mes camarades, expérimenté le CC3000, il s'agit d'un module wifi SPI. Il fonctioone bien. Le cerveau serait un noeud sur le réseau wifi de la maison. Comme nous somme tous sous iOS, nous nous orientons vers une appli tablette pour configurer et piloter les locomotives.
Ok pour le RTC.
1224
Vos projets / Re : Contrôle numérique des aiguillages
« le: janvier 20, 2016, 11:08:23 pm »
Ces aimants sont extrêmement puissants, ça devrait marcher.
1225
Vos projets / Re : Contrôle numérique des aiguillages
« 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 :-)
À 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 :-)
1226
Présentez vous ! / Re : Salut!
« le: janvier 20, 2016, 12:16:51 pm »
Bonjour Yves et bienvenue sur le forum Locoduino.
Nous attendons avec impatience le descriptif de vos projets
Nous attendons avec impatience le descriptif de vos projets
1227
Présentez vous ! / Re : Bonjour ! :)
« le: janvier 20, 2016, 12:14:59 pm »
Bonjour,
Bienvenue chez nous.
En gros tu dois faire un décodeur de locomotive ? Décodeur qui extrait les informations des trames DCC et commande le moteur avec ce qu'il extrait de la trame. C'est bien ça ?
Bienvenue chez nous.
En gros tu dois faire un décodeur de locomotive ? Décodeur qui extrait les informations des trames DCC et commande le moteur avec ce qu'il extrait de la trame. C'est bien ça ?
1228
Vos projets / Re : Un Arduino par module....ou pas.
« le: janvier 18, 2016, 10:07:49 am »
Une simplification consisterait à utiliser une variable booléenne à la place des variables etatVal et ancienEtatVal. Car en fait la bibliothèque RBD_button intégre déjà cette mémorisation de son état précédent. Appelons cette variable 'ok'. Au lieu d'inverser etatVal et de retenir sa valeur précédente, il suffit d'écrire dans loop :
Puis à chaque fois que vous testiez la différence entre etatVal et ancienEtatVal :
Code: [Sélectionner]
bool ok = boutonValidation.onPressed();
Puis à chaque fois que vous testiez la différence entre etatVal et ancienEtatVal :
Code: [Sélectionner]
if (ok) { ... }
1229
Vos projets / Re : Un Arduino par module....ou pas.
« le: janvier 16, 2016, 09:56:53 am »
2 autres choses :
La variable ancienEtatVal n'est jamais affectée (sauf à l'initialisation). Par conséquent, une pression de bouton sur 2 sera vue
Dans tous les case, les leds sont éteintes. Par conséquent elles sont éteintes en permanence car leur allumage est très fugace.
La variable ancienEtatVal n'est jamais affectée (sauf à l'initialisation). Par conséquent, une pression de bouton sur 2 sera vue
Dans tous les case, les leds sont éteintes. Par conséquent elles sont éteintes en permanence car leur allumage est très fugace.
1230
Vos projets / Re : Un Arduino par module....ou pas.
« le: janvier 16, 2016, 01:14:22 am »
Bonsoir,
Rapidement (trop fatigué pour étudier en détails) il manque l'appel
Dans loop()
C'est pour ça que la Schedule table ne fonctionne pas.
Je regarde le reste demain.
Rapidement (trop fatigué pour étudier en détails) il manque l'appel
Code: [Sélectionner]
ScheduleTable::update();
Dans loop()
C'est pour ça que la Schedule table ne fonctionne pas.
Je regarde le reste demain.