1231
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: janvier 29, 2016, 10:09:23 am »
En fait non. ElectroDragon a remboursé ma commande. En effet c'est le nouvel an chinois et la fab ne rouvre que le 12 ou 13 février.
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.
1232
Vos projets / Re : solution globale pour pilotage aiguillages avec 8 servos
« le: janvier 28, 2016, 11:06:49 pm »
Bonsoir Yves
Surveiller l'alimentation externe suppose qu'elle soit fixée à priori et stable. Or souvent on a une plage d'alimentation.
Le composant est le TC54 de microchip. Je ne l'ai trouvé qu'en SOT23 mais ça reste pas trop difficile à souder.
Pour la taille de ce qui est à stocker, l'expérience dira du temps dont on dispose. 8 octets pourraient se stocker en deux écritures. Je ne vois pas cette histoire de pages pour écrire dans l'EEPROM dans la Bibliothèque EEPROM, il faut que je creuse. À suivre donc.
Surveiller l'alimentation externe suppose qu'elle soit fixée à priori et stable. Or souvent on a une plage d'alimentation.
Le composant est le TC54 de microchip. Je ne l'ai trouvé qu'en SOT23 mais ça reste pas trop difficile à souder.
Pour la taille de ce qui est à stocker, l'expérience dira du temps dont on dispose. 8 octets pourraient se stocker en deux écritures. Je ne vois pas cette histoire de pages pour écrire dans l'EEPROM dans la Bibliothèque EEPROM, il faut que je creuse. À suivre donc.
1233
Présentez vous ! / Re : Bonjour de Dominique Donnat
« le: janvier 28, 2016, 11:01:48 pm »
Bonsoir Dominique et bienvenue.
Joli programme. N'hésite pas à poser des questions si tu coinces !
Joli programme. N'hésite pas à poser des questions si tu coinces !
1234
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: janvier 28, 2016, 11:00:36 pm »
J'aurai du rab 
C'est parti à la fabrication.
C'est parti à la fabrication.
1235
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: janvier 27, 2016, 09:22:17 pm »
Ce n'est jamais trop tard. C'est noté Denis. J'en aurai de 10 à 12 et je n'en ai besoin que de deux, une pour les portes de remise, une pour mon passage à niveau.
Le DCC ne prend guère de place.
Le DCC ne prend guère de place.
1236
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: janvier 26, 2016, 07:55:48 pm »
J'ai fait quelques modifications :
1 - suppression du connecteur pour observer le CAN qui ne me semble pas nécessaire sur cette carte
2 - suppression des straps pour déconnecter les LED de TX et RX, la ligne série marche très bien avec les LED en place en permanence
3 - ajout d'un diviseur de tension pour régler le seul de déclenchement du détecteur de chute d'alimentation
1 - suppression du connecteur pour observer le CAN qui ne me semble pas nécessaire sur cette carte
2 - suppression des straps pour déconnecter les LED de TX et RX, la ligne série marche très bien avec les LED en place en permanence
3 - ajout d'un diviseur de tension pour régler le seul de déclenchement du détecteur de chute d'alimentation
1237
Vos projets / Re : Re : solution globale pour pilotage aiguillages avec 8 servos
« le: janvier 26, 2016, 12:21:09 pm »
Bonjour,
Je suis un fan de TME. Choix suffisamment large, prix excellents, livraison du jour pour le lendemain si la commande est passée avant 15h pour un tarif raisonnable.
J'y ai pensé aussi au début mais ça ne fonctionnera pas. En effet, la tension de référence pour la conversion analogique numérique est la tension d'alimentation (ou bien dérivée de la tension d'alimentation). Si la tension d'alimentation chute, la référence chute également. Par conséquent une lecture analogique de la tension d'alimentation renvoie 1023 quelque soit la tension d'alimentation. La chute n'est donc pas détectable de cette manière.
La question qui subsiste est le temps dont on dispose pour sauvegarder les données. Si les servos sont à l'arrêt et en butée, un octet suffit, chaque bit représentant la position, droit ou dévié, de chaque servo. Mais si on veut également gérer le fait qu'un ou plusieurs servos sont en cours de déplacement au moment de la coupure, il faut mémoriser la position, entre 500 et 2500, donc 2000 valeurs possibles, de chaque servo. Il faut 12 bits par servo, soit 12 octets en tout. Il faut également 2 bits de plus par servo pour déterminer si il était à l'arrêt, en mouvement vers l'angle min ou en mouvement vers l'angle max. Donc 2 octets de plus. Dispose-t-on de 14 x 3,3ms = 47ms avant que le programme plante et/ou que l'EEPROM ne soit plus programmable ? Une autre solution est de ne pas sauvegarder les 12 bits par servo mais seulement les 8 bits de poids fort et d'oublier les 4 de poids faible, on peut ajuster ce poids fort si le poids faible est > 7 pour n'avoir qu'une erreur maximum de 3 bits = 8µs en plus ou en moins. Sachant que 8µs représente une erreur d'angle de 8/2000 * 180 = 0,72°, ça me semble tolérable. On économise 4 octets et on tombe à 33ms. On peut également tolérer une erreur plus importante, surtout dans la manœuvre d'un aiguillage, et intégrer les 2 bits d'état dans l'octet qui code la position et l'état d'un servo. On a alors 5 bits d'erreur, soit 32µs maximum et un angle de 2,88° ce qui me semble aussi tolérable, sachant que les angle min et max mémorisée par ailleurs ne seront pas dépassés. On tombe alors à 8 octets et donc 26,4ms de temps d'écriture.
On peut également décider qu'on ne fait bouger qu'un seul servo à la fois. Dans ce cas il y a beaucoup moins de chose à mémoriser : 1 octet pour la position des servos qui sont en butée, 4 bits pour spécifier quel servo est en mouvement (il faut un bit pour dire « aucun n'est en mouvement »), 1 bit pour indiquer dans quel sens il bouge et le reste pour sa position. On est à 3 octets, soit 10ms.
Dans le manuel, il est aussi fait mention de taille de page pour l'EEPROM. Une page fait 4 octets. Visiblement une page peut être écrite d'un seul coup. Dans ce cas, peut être que 3,3ms suffisent pour écrire nos 3 octets. Le bibliothèque EEPROM gère-t-elle l'écriture par page ? Je je sais pas, il y a une étude à faire
De combien de temps dispose-t-on ? Le micro tourne à 16MHz et page 316 du manuel, on a une courbe qui définit une zone de fonctionnement sûr en fonction de la tension d'alimentation et de la fréquence. La tension min à 16MHz se situe vers les 4V. Le circuit de surveillance que j'ai vu déclenche à 4,3V mais un diviseur de tension peut le faire déclencher avant, 4,6 ou 4,7 V par exemple.
Pour la mémoire, super site, je vais le visiter plus en détail.
Je suis un fan de TME. Choix suffisamment large, prix excellents, livraison du jour pour le lendemain si la commande est passée avant 15h pour un tarif raisonnable.
Citer
Enfin, concernant la mémorisation des positions des servos en cas de coupure de courant, j'ai prévu un monitoring des tensions par les entrées analogiques de l'Arduino. Qu'en penses-tu?
J'y ai pensé aussi au début mais ça ne fonctionnera pas. En effet, la tension de référence pour la conversion analogique numérique est la tension d'alimentation (ou bien dérivée de la tension d'alimentation). Si la tension d'alimentation chute, la référence chute également. Par conséquent une lecture analogique de la tension d'alimentation renvoie 1023 quelque soit la tension d'alimentation. La chute n'est donc pas détectable de cette manière.
La question qui subsiste est le temps dont on dispose pour sauvegarder les données. Si les servos sont à l'arrêt et en butée, un octet suffit, chaque bit représentant la position, droit ou dévié, de chaque servo. Mais si on veut également gérer le fait qu'un ou plusieurs servos sont en cours de déplacement au moment de la coupure, il faut mémoriser la position, entre 500 et 2500, donc 2000 valeurs possibles, de chaque servo. Il faut 12 bits par servo, soit 12 octets en tout. Il faut également 2 bits de plus par servo pour déterminer si il était à l'arrêt, en mouvement vers l'angle min ou en mouvement vers l'angle max. Donc 2 octets de plus. Dispose-t-on de 14 x 3,3ms = 47ms avant que le programme plante et/ou que l'EEPROM ne soit plus programmable ? Une autre solution est de ne pas sauvegarder les 12 bits par servo mais seulement les 8 bits de poids fort et d'oublier les 4 de poids faible, on peut ajuster ce poids fort si le poids faible est > 7 pour n'avoir qu'une erreur maximum de 3 bits = 8µs en plus ou en moins. Sachant que 8µs représente une erreur d'angle de 8/2000 * 180 = 0,72°, ça me semble tolérable. On économise 4 octets et on tombe à 33ms. On peut également tolérer une erreur plus importante, surtout dans la manœuvre d'un aiguillage, et intégrer les 2 bits d'état dans l'octet qui code la position et l'état d'un servo. On a alors 5 bits d'erreur, soit 32µs maximum et un angle de 2,88° ce qui me semble aussi tolérable, sachant que les angle min et max mémorisée par ailleurs ne seront pas dépassés. On tombe alors à 8 octets et donc 26,4ms de temps d'écriture.
On peut également décider qu'on ne fait bouger qu'un seul servo à la fois. Dans ce cas il y a beaucoup moins de chose à mémoriser : 1 octet pour la position des servos qui sont en butée, 4 bits pour spécifier quel servo est en mouvement (il faut un bit pour dire « aucun n'est en mouvement »), 1 bit pour indiquer dans quel sens il bouge et le reste pour sa position. On est à 3 octets, soit 10ms.
Dans le manuel, il est aussi fait mention de taille de page pour l'EEPROM. Une page fait 4 octets. Visiblement une page peut être écrite d'un seul coup. Dans ce cas, peut être que 3,3ms suffisent pour écrire nos 3 octets. Le bibliothèque EEPROM gère-t-elle l'écriture par page ? Je je sais pas, il y a une étude à faire
De combien de temps dispose-t-on ? Le micro tourne à 16MHz et page 316 du manuel, on a une courbe qui définit une zone de fonctionnement sûr en fonction de la tension d'alimentation et de la fréquence. La tension min à 16MHz se situe vers les 4V. Le circuit de surveillance que j'ai vu déclenche à 4,3V mais un diviseur de tension peut le faire déclencher avant, 4,6 ou 4,7 V par exemple.
1238
Bus CAN / Re : Re : BreakoutBoard CAN
« le: janvier 26, 2016, 11:34:10 am »J'en ai commandé une pour voir : le quartz est à 8Mhz et d'emblée elle ne communique pas avec les cartes Locoduino.
J'ai changé le quartz pour un 16 MHz et maintenant elle marche impeccablement !
Tu ferais un article dessus ?
1239
Bus CAN / Re : BreakoutBoard CAN
« le: janvier 26, 2016, 10:22:05 am »
Sans changer le quartz, il faut revoir la programmation des registres qui déterminent comment le 2515 échantillons les bits sur le bus. Ces paramètres se situent dans les lignes 269 à 340 de mcp_can_dfs.h
Il faudrait voir si quelqu'un ne s'en est pas déjà chargé dans le nombreux fork de cette bibliothèque :-)
Il faudrait voir si quelqu'un ne s'en est pas déjà chargé dans le nombreux fork de cette bibliothèque :-)
1240
Bus CAN / Re : BreakoutBoard CAN
« le: janvier 26, 2016, 08:28:40 am »
Bonjour,
De l'eau a coulé sous les ponts et des breakout boards CAN comparables et à prix très intéressant ont fait leur apparition :
http://www.ebay.fr/itm/Arduino-MCP2515-CAN-Bus-Module-TJA1050-Receiver-SPI-Module-/311520457612?hash=item488810f38c
De l'eau a coulé sous les ponts et des breakout boards CAN comparables et à prix très intéressant ont fait leur apparition :
http://www.ebay.fr/itm/Arduino-MCP2515-CAN-Bus-Module-TJA1050-Receiver-SPI-Module-/311520457612?hash=item488810f38c
1241
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: janvier 25, 2016, 02:38:07 pm »
Ça part cette semaine à la fab
1242
Vos projets / Re : solution globale pour pilotage aiguillages avec 8 servos
« le: janvier 23, 2016, 06:31:17 pm »Beaucoup de questions, mais je vais essayer d'y répondre le mieux possible:
- La coupure de l'alimentation des servos n'est pas seulement faite pour limiter la consommation globale, ni celle en butée (bien que cela soit ainsi traité) mais pour éviter tout mouvement intempestif des servos lors d'une mise sous tension. En effet, lorsque l'on met en route, j'ai observé que certains servos partaient en butée avant de revenir sur la plage autorisée. Dans le modélisme à l'échelle N, on ne peut pas accepter qu'un servo aille en butée, sinon on a de la casse. J'ai vérifié qu'un délai entre la mise sous tension de la carte micro et des servos résolvait de manière sûre ce problème.
Il semblerait bien que tirer le signal de commande à 5V (via une résistance de 10kΩ par exemple, produise le même effet. Je l'ai testé avec les HK15178 que j'ai acheté pour mes aiguillages (http://www.hobbyking.com/hobbyking/store/__16257__HobbyKing_8482_HK15178_Analog_Servo_1_4kg_0_09sec_10g.html) et le SG90 que je viens de tester a le même comportement. Si vous avez un large échantillon de servos, vous pourriez tester cette configuration. L'avantage est une complexité moindre. J'avais par le passé essayé de tirer ce signal de commande à la masse et là le servo bouge à l'allumage. Ceci couplé à l'arrêt du pilotage remplirait votre cahier des charges je pense.
Je mettrais une diode de protection sur l'alimentation externe, un mauvais branchement est si vite arrivé.
Citer
- L'EEPROM est utilisée pour pouvoir mémoriser les positions de butée et les positions de chaque servos afin de sécuriser les mises en route et arrêt. J'ai mis une mémoire externe car ce type de mémoire ne supporte que quelques dizaine de milliers d'écriture, ce qui fait que l'on ne jette pas le micro tous les deux ans, seulement un boitier à 1 Euros sur support. Mais chacun son option!
On trouve des EEPROM externe qui supportent 1 million d'écritures. Par exemple : http://www.tme.eu/fr/Document/70a2a08b621e743c2d24fbd8cde093d0/m24c01-w.pdf
http://www.tme.eu/fr/details/m24c01-wbn6p/memoires-eeprom-de-serie/st-microelectronics/
11 centimes l'exemplaire :-)
Pour ma part, j'explore une autre piste, j'attends le composant. Il s'agit d'un composant à trois broches qui surveille l'alimentation. Quand elle chute en dessous de 4,3V, le composant envoie une interruption au micro qui peut alors procéder à la sauvegarde des positions des servos avant que la tension soit trop basse. De cette manière l'écriture en EEPROM n'est fait que lors de l'extinction et il n'est pas nécessaire de la changer et on peut donc utiliser l'EEPROM interne de l'Arduino.
Citer
De ton côté, où en es-tu de ton projet?
La carte est dessinée et par à la fabrication la semaine prochaine. Concernant le montage des servos, nous avons eu la même idée. Sur les miens j'ai également des contacts de fin de course et d'alimentation du cœur. Voir ici : http://modelleisenbahn.triskell.org/spip.php?article35
A+
1243
Vos projets / Re : Contrôle numérique des aiguillages
« 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.
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.
1244
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: janvier 23, 2016, 09:45:21 am »
Ok Dominique. Donc je ne touche à rien. Je vais envoyer cette carte à la fabrication. Pourrais tu jeter un œil aux schémas pour eventuellement repérer quelque chose qui ne va pas ?
1245
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 ?