LOCODUINO
Parlons Arduino => Shields et Modules => Discussion démarrée par: Jean-Luc le janvier 14, 2016, 06:12:22 pm
-
Bonsoir,
J'ai été hors course ces derniers temps mais je ne suis pas resté complètement inactif.
Voici donc une carte destinée à piloter 8 servomoteurs et raccordable au bus DCC et au bus CAN.
La carte comporte
- une alimentation pour les servos (un 7805, certains modèles délivrent 1,5A)
- un Arduino Nano
- un contrôleur CAN et un transceiver
- une interface DCC
- 2 connecteur RJ11 pour le CAN
- un bornier pour le DCC
- un bornier pour l'alim 9 à 12V
- 8 connecteurs pour les servos
- optionnellement un expandeur d'I/O pour lire des fins de course
- J'ai casé un détecteur de coupure d'alim pour la sauvegarde en EEPROM
J'ai réussi à tout faire tenir sur une carte 10x5 cm
Voici les schémas : http://www.locoduino.org/pic/carteServoCANDCC/schematique.pdf
Les typons :
Recto
(http://www.locoduino.org/pic/carteServoCANDCC/ServoBoardCANDCC.cmp.png)
(http://www.locoduino.org/pic/carteServoCANDCC/ServoBoardCANDCC.plc.png)
Verso
(http://www.locoduino.org/pic/carteServoCANDCC/ServoBoardCANDCC.sol.png)
(http://www.locoduino.org/pic/carteServoCANDCC/ServoBoardCANDCC.pls.png)
Le logiciel reste à faire. Il se basera sur SlowMotionServo
-
Très jolie carte qui m'intéresse, non pas pour commander des aiguilles (j'ai choisi des aiguilles Fleischmann piccolo N, avec moteur à electro-aimant commandées par relais, je sais c'est plus brutal et plus bruyant), mais pour l'animation du décor (passages à niveau, parc de loisir).
La mémorisation à la coupure d'alimentation est un plus appréciable.
Je suis donc candidat pour une ou deux cartes :))
Merci d'avance
Dominique
-
C'est noté Dominique
Pour tes aiguilles fleishmann tu pourrais les commander par transistors tout de même :-)
-
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 ?
-
De toute façon, il est préférable d'alimenter seulement les décodeurs des machines par le DCC.
Dans le réseau, au sol, les sources d'alimentation continues et non bruitées ne manquent pas.
Donc pas besoin d'alimentation par le DCC, d'autant que les commandes peuvent provenir du bius CAN.
-
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 ?
-
Tout me paraît Ok dans les schémas de cette carte.
Dominique
-
Ça part cette semaine à la fab :)
-
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
(http://www.locoduino.org/pic/carteServoCANDCC1.4/ServoBoardCANDCC.cmp.png)
(http://www.locoduino.org/pic/carteServoCANDCC1.4/ServoBoardCANDCC.plc.png)
(http://www.locoduino.org/pic/carteServoCANDCC1.4/ServoBoardCANDCC.sol.png)
(http://www.locoduino.org/pic/carteServoCANDCC1.4/ServoBoardCANDCC.pls.png)
-
Je n'y vois pas d'inconvénient :)
On peut toujours ne pas monter les Leds Tx et Rx si on n'en a pas besoin.
Je confirme : 2 carte pour moi s'il y en a assez.
Un grand merci !
-
Salut Jean-Luc,
Je n'avais pas tilté : mais c'est une nouvelle carte !! ;D ;D
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. :'(
-
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.
-
L'entrée DCC peut toujours servir à faire un moniteur DCC dans un coin du programme ou dans un mode de mise au point.
-
Du coup, si tu as du rab, je suis partant pour deux aussi ! Je vais tâcher d'adapter UAD pour qu'il sache piloter tout ça.
-
J'aurai du rab ;)
C'est parti à la fabrication.
-
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.
-
En attendant je vais donc m'occuper du soft :P Thierry, j'accueille ta participation avec plaisir :)
La carte est donc à géométrie variable. On peut la piloter en DCC ou en CAN. Doit-on embarquer le même logiciel qui s'adapte à l'un ou à l'autre ? Pourquoi pas il y a assez de place je pense.
Quoiqu'il en soit, la carte sera configurable par la ligne série grâce à CommandInterpreter pour :
- lui donner une adresse.
- déterminer si l'expandeur de fin de courses est en place ou non. La présence du composant indique qu'au lieu de se caler sur des butées définies logiciellement, le mouvement se poursuit jusqu'à arriver à la butée physique avec tout de même des butées logicielles pour éviter de dépasser les valeurs min ou max des servos si la butée physique dysfonctionne. Vous pouvez vous référer à http://modelleisenbahn.triskell.org/spip.php?article35 pour des servomoteurs avec butées physique. La platine a été redessinée pour avoir le même ordre de signaux.
- activer/désactiver des servos car toutes les sorties ne sont pas forcément utilisées.
- fixer la période d'émission de la position effective des servos.
La configuration de la carte s'effectue si le bouton CFG est enfoncé au démarrage. En pratique, on appuie sur CFG puis sur RESET et la carte redémarre en mode configuration. La configuration est stockée en EEPROM afin d'être conservée d'un allumage à l'autre.
Les commandes de configuration et de lecture de la carte seront les suivantes :
- exp : affiche oui si l'expandeur de fins de course est utilisé, non sinon.
- exp oui : active l'utilisation de l'expandeur de fin de course. Idéalement le logiciel devrait tenter de communiquer avec le circuit et afficher 'ok' ou 'erreur' si l'expandeur répond ou non.
- exp non : désactive l'utilisation de l'expandeur de fin de course
- can : demande de l'état d'activation du CAN, réponse : oui ou non selon que le CAN est utilisé ou non.
- can oui : active l'utilisation du CAN.
- can non : désactive l'utilisation du CAN.
- canad : affiche l'adresse CAN, c'est à dire l'identifiant de message que la carte reçoit, cet identifiant est utilisé pour programmer les filtres et les masques.
- canad <adresse> : configure l'adresse CAN.
- dcc : demande l'état d'activation du DCC, réponse oui si le DCC est activé, non sinon.
- dcc oui : active le DCC.
- dcc non : désactive le DCC.
- dccad : affiche l'adresse DCC.
- dccad <adresse> : configure l'adresse DCC.
- retro : affiche oui, suivi de l'identifiant des trames et de la période d'émission des trames de rétrosignalisation en millisecondes si la rétrosignalisation est activée, non sinon.
- retro oui <id> <periode> : active l'envoi des trames de rétrosignalisation avec des messages CAN d'identifiant <id> et avec une période d'émission <periode> en millisecondes.
- retro non : désactive l'envoi des trames de rétrosignalisation.
- servo : affiche l'état des 8 servos. Le résultat est : '<num> : ' suivi de 'non' si le servo est désactivé ou bien '<type> : <min>, <pos>, <max> : <vitesse min vers max>, <vitesse max vers min>' si le servo est activé. <type> est le type de mouvement (pour l'instant dans SlowMotionServo il y a 3 types de mouvement : linéaire, doux, c'est à dire une courbe sinus de 0 à π/2, et doux avec rebond, c'est à dire un sinus suivi d'un amortissement en sens inverse), <min> est la position minimum, largeur de l'impulsion en µs, <pos> est la position actuelle, largeur de l'impulsion en µs et <max> est la position maximum, largeur de l'impulsion en µs. <vitesse min vers max> et <vitesse max vers min> sont respectivement les vitesses de déplacement de l'angle min vers l'angle max et de l'angle max vers l'angle min.
- servo <num> : affiche l'état du servo <num>. Voir ci-dessus
- servo <num> <commande> : change les réglages du servo <num>. Les <commande> peuvent être :
- min <valeur> : fixe l'angle min en µs
- max <valeur> : fixe l'angle max en µs
- vitesse <valeur> : fixe la vitesse de déplacement à la fois de min vers max et de max vers min
- vitesse max <valeur> : fixe la vitesse de déplacement de min vers max.
- vitesse min <valeur> : fixe la vitesse de déplacement de max vers min.
- go <valeur> : demande au servo d'aller à une position relative de 0 à 1 en mouvement lent.
- fdc : lit l'état des fins de course si l'expandeur est utilisé.
- fdc <num> : lit l'état du fin de course <num> si l'expandeur est utilisé.
- fdc <num> oui : prend en compte le fin de course <num>.
- fdc <num> non : ne prend en compte le fin de course <num>. En effet, bien qu'utilisant les fin de course, on peut, sur certains servos, utiliser les butées logicielles
L'utilisation d'une détection de fins de course change le fonctionnement de SlowMotionServo. Actuellement la bibliothèque utilise les butées logicielles. Il faut que je lui ajoute une méthode permettant de stopper le mouvement avant d'arriver sur la butée logicielle. Cette méthode sera appelée lorsque le fin de course est détecté. Il faut aussi que le mouvement continue un peu plus après le stop. En effet, si on arrête le mouvement dès la détection du fin de course, l'interrupteur est à la limite du contact. Pour bien l'enfoncer, il faut continuer un peu le mouvement. Je n'ai pas lister les commandes pour régler ce dépassement par rapport à stop pour l'instant.
La conséquence est que la totalité de la courbe de mouvement ne sera pas parcourue sauf si on ajuste les butées logicielles de manière à les faire coïncider avec les butées matérielles. Ce n'est pas grave car l'utilisation de fins de course sera essentiellement sur les aiguillages et les signaux mécaniques. Sur des animations type passage à niveau ou portes, on utilisera les butées logicielles. On peut également faire en sorte que les butées logicielles coïncident toutes seules avec les butées matérielles en ajustant chaque butée logicielle à la butée matérielle correspondant : le logiciel apprend. De cette manière on récupère la courbe complète.
J'ai certainement oublié des trucs mais ce fil de discussion va me servir à établir l'architecture fonctionnelle qui va évoluer selon vos remarques.
-
Beau sujet, effectivement bien en continuité de tes articles sur ton blog. :-*
A partir du moment où tu gères un bus I2C pour le MCP23017, il est tentant pour moi de demander qu'on puisse ajouter une carte fille sur laquelle j'aurais 8 entrées d'occupation de l'aiguille.
Sur ta carte, juste pouvoir "sortir" le bus I2C et une alim quelconque (2,5 V - 7 V) . Sur ma carte fille, un PCF8574 et 8 broches d'entrées.
Il n'est pas question d'ajouter ça à ta carte qui a déjà les dimensions idéales (1/2 format Electrodragon) et certainement peu de gens intéressés.
J'ai, par ailleurs, adapté ta partie mécanique côté servo en mettant 6 micro rupteurs au lieu de tes 4.
J'utilise une cornière alu 2,35 x 4,35 cm à 7,20 € dans laquelle je découpe des tranches de 2,4 cm (pour être < 2,56 cm PECO N)
http://www.leroymerlin.fr/v3/p/produits/corniere-inegale-rainure-en-aluminium-brut-l1m-x-l4-35cm-x-h2-35cm-x-ep0-15cm-e17191#&xtmc=corniere_alu&xtcr=45 (http://www.leroymerlin.fr/v3/p/produits/corniere-inegale-rainure-en-aluminium-brut-l1m-x-l4-35cm-x-h2-35cm-x-ep0-15cm-e17191#&xtmc=corniere_alu&xtcr=45)
Pour fixer les SG90, je fais un trou rond de 12, ce qui m'évite un trou carré dans l'alu.
J'ai tout le matériel (TME), mais je suis parti sur TCO en Processing et ça m'a détourné :D :D
Donc, je vais monter le matériel et voir si ça marche, mécaniquement.
Mais ça n'a aucun impact sur ta carte.
Concernant le logiciel, ton choix de la fonction sinus est une idée simple (pour simuler une accélération/décélération on devrait prendre une sigmoïde 1/(1+exp(-x) :D), mais ça me parait plus simple de s'en tenir à sinus. Et la différence sera complètement invisible dans les faits.
-
Heureusement que nous entrons dans l'année du singe :)
J'ai pas tout compris. Qu'entends-tu occupation de l'aiguillage ? En quoi ajouter 2 micro rupteurs ajoute de l'information par rapport aux deux qui renseignent sur la position effective du servo ?
Quoiqu'il en soit, je vais voir où ajouter un connecteur 4 broches. Il te faut aussi l'alimentation.
-
Si on ne peut plus singer ... ;D
Comment veux-tu qu'on résiste à de si belles propositions ?
Pour mes contacts supplémentaires, je te joins un début d'article potentiel.
-
Ok, tu veux alimenter seulement la lame qui sert et isoler l'autre.
Je pense que tu t'embêtes pour pas grand chose. Tu isoles les lames du coeur et tu raccordes chaque lame au rail correspondant sous la table. Elles sont donc tout le temps alimentées mais tu ne risque pas de court circuit.
Concernant les arcs électriques, d'après ce que j'ai lu, il faut au moins 340V. Il n'y a aucun risque Aves le 20V du DCC :)
-
Que nenni ! :P
La solution que tu proposes est la solution classique (voir PJ).
Certes, il n'y a plus de problème côté lames mobiles puisqu'elles sont à la même polarité que le rail voisin.
Mais on n'a pas résolu le problème : on l'a déplacé.
C'est maintenant sur les croix du schéma qu'on trouve deux rails proches à des potentiels opposés ! :(
Le schéma le montre bien.
Le maître mot, et tu l'a cité, c'est "isoler".
En isolant le rail qui ne sert pas, il n'y a plus aucun endroit où il pourrait y a voir un court-circuit. On élimine totalement la cause.
Cela ne côte qu'un inverseur de plus à côté du servo (20 centimes par 250, ceux que tu connais bien, chez TME )
http://www.tme.eu/fr/details/msm-22/microcommutateurs-a-connecteurs/ninigi/msw-22/ (http://www.tme.eu/fr/details/msm-22/microcommutateurs-a-connecteurs/ninigi/msw-22/) pour ceux qui découvrent.
-
Certes mais tu pourrais poursuivre le raisonnement pour les jonctions entre cantons et continuer à ajouter des interrupteurs pour résoudre de manière compliquée un problème que tu résous par l'informatique plus simplement. Ça coûte un interrupteur par aiguille mais également un expandeur, une carte, de la filasse et de la complexité qui ne me semble pas nécessaire.
Par ailleurs si tu veux effectivement isoler une des deux lames il te faut un interrupteur mais tu veux également remonter cette information ? Il te faut un 2e interrupteur. Pourquoi ? C'est la même que celle donnée par la paire d'interrupteurs de fin de course. Le PCF8574 va te donner la même info que le MCP23017.
-
Nous avons un décalage...
Mon contact supplémentaire ne cherche à résoudre qu'un problème de train qui aurait déraillé. Et ce problème ne se pose qu'aux aiguilles. Il n'y a pas ce problème au niveau des cantons.
Par ailleurs, je ne cherche surtout pas à remonter cette info. C'est purement local et ça ne sort pas de l'espace servo-aiguille.
L'info que je veux remonter, c'est l'occupation de l'aiguille par un train qui n'aurait pas déraillé. C'est pour le PRS qui doit effacer les aiguilles au fur et à mesure de la progression du train sur le grill.
-
Ah ok. On mélangeait donc deux choses et du coup je ne comprenais plus rien.
Je croyais que tu avais par ailleurs des détecteurs d'occupation.
-
Oui, j'ai par ailleurs des détecteurs d'occupation.
Mais pour remonter cette info dans le bus CAN, je pensais qu'il était plus simple d'ajouter un PCF8574 sur le "bus" I2C que tu avait créé pour ta carte.
"bus", un bien grand mot puisqu'il n'y a que 2 composants : l'Arduino et le MCP23017 ;)
-
Bon,
Ça ne rentre pas. J'arrive à caser l'électronique de l'ACK DCC, l'électronique de détection de perte d'alimentation mais je n'arrive pas à faire rentrer le connecteur.
Je peux faire rentrer le connecteur en sacrifiant l'ACK DCC.
Il va falloir faire un choix. Denis, tes détecteurs d'occupation sont de toutes façon à réaliser séparément. Tu peux sans doute y mettre l'occupation de tes aiguillages ?
-
Il ne faut rien sacrifier et surtout pas le DCC.
Je détecte l'occupation des aiguilles à part.
Soit tu arrives à mettre 2 picots (je ne "veux" rien de plus) sur le bus I2C, soit je mets un module CAN supplémentaire avec la détection et c'est totalement indépendant.
Bon courage !
Et merci d'avance. :D
-
Finalement j'y suis arrivé :)
L'I2C avec alimentation est disponible sur un connecteur SPOX droit (K13) : http://www.tme.eu/fr/details/mx-5267-04a/connecteurs-de-signal-pas-250mm/molex/022035045-22-03-5045-5267-04a/
Voici la schématique :
http://www.locoduino.org/pic/carteServoCANDCC1.5/schematique1.5.pdf
Une partie du typon
(http://www.locoduino.org/pic/carteServoCANDCC1.5/ServoBoardCANDCC.plc.png)
(http://www.locoduino.org/pic/carteServoCANDCC1.5/ServoBoardCANDCC.cmp.png)
(http://www.locoduino.org/pic/carteServoCANDCC1.5/ServoBoardCANDCC.sol.png)
J'envoie ça aujourd'hui avec d'autre trucs, il y a 10% de réduction pour le nouvel an chinois 8)
-
Belle carte !
Bravo !
-
Formidable !! ;D ;D ;D ;D ;D ;D
Merci, j'ai mon connecteur, avec même l'alim, en plus !!
Si j'ai tout compris, comme tu as intégré avec T1, la zener, et 2 résistance, le seul fait de couper l'alim va envoyer une interruption qui va faire la sauvegarde des positions (et autres) dans l'EEPROM.
J'essaie de comprendre la page 6 :
1°) En haut, le DCC arrive à gauche, et via l'opto bizarre, tu envoie ce signal DCC sur IT_DCC. Tu récupères ainsi les créneaux du signal DCC.
Tu peux donc l'analyser. OK
2°) En bas, c'est l'inverse : le CFG, via l'opto et le pont (RC1, c'est un pont ?) pour envoyer des ordres (configuration ?) à la voie DCC.
-
Pour le 2), c'est pour faire un ACK à la centrale DCC pour acquitter l'envoi d'une CV
-
J'aurai du rab ;)
Beaucoup de rab ? Je suis candidat pour une s'il en reste.
Merci
-
Je vais en recevoir entre 10 et 12. J'en ai besoin de 2.
-
J'aurai du rab ;)
Beaucoup de rab ? Je suis candidat pour une s'il en reste.
Merci
bonsoir Jean-Luc,
Est-ce que j'arrive trop tard? Je serais aussi candidat pour une , voire même deux.
Merci de ta réponse.
Bernard
-
Bonjour Bernard,
Si je compte bien :
| Dominique | 2 |
| DDEFF | 2 |
| Thierry | 2 |
| jpjcb66 | 1 |
| ma pomme | 2 |
Je suis à 9. Si j'en reçois plus de 10, ça ira pour 2 :)
-
Merci pour 1 si 2 ne sont pas possibles . J'ai 14 aiguilles à commander individuellement.
Les animations seront à voir ultérieurement.
adresse Mail en MP
Bernard
-
Les cartes sont arrivées, il y en a 12.
J'en monte une et je dispatche. Il va falloir faire du collaboratif pour le logiciel, c'est pas moi qui vais faire le DCC, je ne suis pas équipé :)
-
Superbe, comme d'hab'
Et on ne la confondra pas avec celle pour le CAN, parce qu'elle est rouge ;D ;D ;D
-
Superbe ! Pas de problème pour le collaboratif, on est là pour ça !
-
Tres jolie carte !
On va pouvoir s'échanger des expériences intéressantes :P
Merci mille fois
-
Super carte ,comme les autres.
Merci Jean-Luc
Si je sais encore compter 12, c'est plus que 10....... ;D ;D ;D
-
Oui c'est plus que 10 ;D
-
Bonjour,
Je suis en attente de composants pour monter une carte. Je devrais les avoir lundi ou mardi.
Quelques infos sur le montage. Comme ils y a deux interfaces, CAN et DCC, tous les composants ne sont pas à monter selon les besoins.
Sur la figure suivante, j'ai colorié les composant par rôle :
Jaune : CAN
Bleu : DCC
Rose : ACK DCC
Vert : Contacts de fin de course
Bleu ciel : Connecteur I2C
Concernant le connecteur I2C, les deux résistances vertes doivent être montées si il est utilisé (Pullup I2C)
Concernant les connecteurs pour les servos. J'ai prévu des connecteurs 5 broches au pas de 2,54mm : 1 pour le signal de commande, 2 pour l'alimentation, 2 pour les contacts de fin de course. Si les contacts de fin de course ne sont pas employés, on peut souder un connecteur 3 broches type barre de broches mais il n'y aura pas de détrompeur. L'alimentation est sur les broches du haut. Donc à adapter également selon les besoins.
PS: Merci les gars :)
-
Pour l'envoi des cartes, je vais utiliser une lettre suivie en prêt à poster. Une carte pèse 16g selon ma balance de ménage. Il y aura également quelques composants car, par exemple, pour la résistance R12 c'est 100 exemplaires minimum (3 centimes pièce). Les frais d'envoi se montent donc à 2,40€ si le tout tient en 50g (c'est probablement le cas), 3,06€ si c'est plus lourd.
Chaque carte revient à 1,5€ et pour les composants que j'ai en rab, ça sera moins de 1€
Envoyez moi en MP la quantité désirée et votre adresse postale ainsi que les composants que vous voulez monter. Je répondrai avec la somme exacte et mon adresse mail pour Paypal
-
Super , Jean-Luc.
je vais tout monter!! je suis parti en analogique mais sais-t-on jamais si un jour le DCC me prenait...C'est pas terrible de compléter une carte déjà câblée sur le réseau ;D ;D
-
J'en ai monté une. Il manque juste les deux résistances litigieuses du DCC sur le 6N137.
Le nano fonctionne :-)
Je fais un inventaire des composants ce week end mais à vue de nez je peux fournir les résistances, les diodes, certains connecteurs, certains supports de CI et certaines capas. Il faudra se procurer par ailleurs le nano, les deux connecteurs pour le monter, les connecteurs et supports manquant et les CI.
-
Je fais un inventaire des composants ce week end mais à vue de nez je peux fournir les résistances, les diodes, certains connecteurs, certains supports de CI et certaines capas. Il faudra se procurer par ailleurs le nano, les deux connecteurs pour le monter, les connecteurs et supports manquant et les CI.
Je suis preneur des résistances, diodes, connecteurs, et capas.
J'ai le reste. Envoies moi la note :P
Merci d'avance
Dominique
-
Envoie ce que tu peux (et la facture qui va avec).
De toutes façons, je vais faire une commande chez TME.
Disez-moi (?) si vous voulez quelque chose, d'ailleurs...
-
Bonjour,
Inventaire fait, voici ce que j'ai en stock, il s'agit des composants marqués en vert et des supports marqués en jaune.
(http://forum.locoduino.org/index.php?action=dlattach;topic=125.0;attach=252)
-
Comme dit Denis, proposes ce que tu peux. L'essentiel est qu'une liste existe quelque part avec les références à commander par nous même pour compléter.
-
Je commande chez TME.
Si j'ai la liste des composants nécessaires (Jean-Luc) et si certains d'entre nous ont besoin de compléter, dites moi de quoi vous avez besoin et on fera un "groupiert"...
-
Je suis en train de faire la liste avec les liens chez TME, une minute :)
-
Pas l'feu... ;D
D'autant que je ne ferai la commande que quand on m'aura dit ce qui manque ...
C'est déjà bien d'avoir tout inventé et développé !
-
La liste des composants, le (F) en début de ligne indique que je le fournis, comme c'était pas très clair j'ai mis en rouge si je ne le fournis pas :
ARD1 Arduino Nano v3.0 arduino-nano-v-3-0 arduino-nano-v-3-0
Là j'ai monté un Nano chinois avec un CH340 (USB-série) : http://www.electrodragon.com/product/edarduino-nano-c-new-usb-ch340/
Il faut deux socles à broches, on ne peut pas le monter autrement à cause du 6N137 qui est dessous : http://www.tme.eu/fr/details/zl262-16sg/barres-et-socles-a-broches/ninigi/
B1 CFG push-button-pcb-4-pins tact : http://www.tme.eu/fr/details/tact-67n-f/microcommutateurs-tact-pcb/ninigi/
(F) C1 100nF unpolarized-capacitor metallized-polyester-capacitor-50 http://www.tme.eu/fr/details/mc5-100n-5%25/condensateurs-de-polyester-tht/arcotronics/r82dc3100dq50j/
(F) C2 100nF unpolarized-capacitor metallized-polyester-capacitor-50 http://www.tme.eu/fr/details/mc5-100n-5%25/condensateurs-de-polyester-tht/arcotronics/r82dc3100dq50j/
C3 470µF aluminium-capacitor radial-capacitor-25-70 http://www.tme.eu/fr/details/uvz1a471med/condensateurs-electrolytiques-tht-105c/nichicon/
(F) C4 100nF unpolarized-capacitor metallized-polyester-capacitor-50 http://www.tme.eu/fr/details/mc5-100n-5%25/condensateurs-de-polyester-tht/arcotronics/r82dc3100dq50j/
(F) C5 22pF ceramic-multi-layer-capacitor ceramic-multi-layer-capacitor-100mil http://www.tme.eu/fr/details/cc-22/condensateurs-ceramiques-tht-50v/sr-passives/
(F) C6 22pF ceramic-multi-layer-capacitor ceramic-multi-layer-capacitor-100mil http://www.tme.eu/fr/details/cc-22/condensateurs-ceramiques-tht-50v/sr-passives/
C7 1nF unpolarized-capacitor metallized-polyester-capacitor-50 http://www.tme.eu/fr/details/r82ec1100dq50k/condensateurs-de-polyester-tht/kemet/
(F) C8 100nF unpolarized-capacitor metallized-polyester-capacitor-50 http://www.tme.eu/fr/details/mc5-100n-5%25/condensateurs-de-polyester-tht/arcotronics/r82dc3100dq50j/
(F) C9 100nF unpolarized-capacitor metallized-polyester-capacitor-50 http://www.tme.eu/fr/details/mc5-100n-5%25/condensateurs-de-polyester-tht/arcotronics/r82dc3100dq50j/
C10 470µF radial-electrolytic-capacitor radial-capacitor-50-100 http://www.tme.eu/fr/details/rd1v477m10016bb/condensateurs-electrolytiques-tht-105c/samwha/
(F) C11 100nF unpolarized-capacitor metallized-polyester-capacitor-50 http://www.tme.eu/fr/details/mc5-100n-5%25/condensateurs-de-polyester-tht/arcotronics/r82dc3100dq50j/
(F) D1 1N4007 1n400x do41 http://www.tme.eu/fr/details/1n4007-dc/diodes-universelles-tht/dc-components/1n4007/
(F) D2 1N4148 1n4148-thin do35-thin http://www.tme.eu/fr/details/1n4148-dio/diodes-universelles-tht/diotec-semiconductor/1n4148/
(F) D3 1N4148 1n4148-thin do35-thin http://www.tme.eu/fr/details/1n4148-dio/diodes-universelles-tht/diotec-semiconductor/1n4148/
(support F) IC1 expandeur fins de course mcp23017 dil28 http://www.tme.eu/fr/details/mcp23017-e_sp/multiplexeurs-et-commutateurs-analogues/microchip-technology/ et (F) http://www.tme.eu/fr/details/gold-28p-w/supports-de-precision/ninigi/gold-28p-w/
IC2 7805 lm78xx to220up http://www.tme.eu/fr/details/l7805acv/stabilisateurs-de-tension-non-regles/st-microelectronics/
IC3 MCP2515 mcp2515 dil18 http://www.tme.eu/fr/details/mcp2515-i_p/circuits-integres-interface-can/microchip-technology/ et http://www.tme.eu/fr/details/gold-18p/supports-de-precision/ninigi/gold-18p/
(support F) IC4 MCP2551 pca82c250 dil08 http://www.tme.eu/fr/details/mcp2551-i_p/circuits-integres-interface-can/microchip-technology/ et http://www.tme.eu/fr/details/gold-8p/supports-de-precision/ninigi/gold-8p/
(support F) IC5 6N137 6n137 dil08 http://www.tme.eu/fr/details/6n137-l/optocoupleurs-sortie-logique-tht/liteon/ et http://www.tme.eu/fr/details/gold-8p/supports-de-precision/ninigi/gold-8p/
(F) K1 ALIM terminal-block-2ways-angled terminal-block-2-3-5mm-angled http://www.tme.eu/fr/details/15edgrc-3.5_2p/barres-de-serrages-pour-pcb/degson-electronics/ et http://www.tme.eu/fr/details/15edgk-3.5_2p/barres-de-serrages-pour-pcb/degson-electronics/
(F) K2 à K9 S0 modular-5-male-connector modular-5-points-connector http://www.tme.eu/fr/details/ns25-w5p/connecteurs-de-signal-pas-254mm/ninigi/ et http://www.tme.eu/fr/details/ns25-g5/connecteurs-de-signal-pas-254mm/ninigi/ et http://www.tme.eu/fr/details/ns25-t/connecteurs-de-signal-pas-254mm/ninigi/
(F) K10 et K11 CAN 6p4c-modular-jack-low-profile 6p4c-right-angle-modular-jack-low-profile http://www.tme.eu/fr/details/rj11gk/connecteurs-rj/
K12 DCC terminal-block-2ways-angled terminal-block-2-3-81mm-angled http://www.tme.eu/fr/details/15edgrc3.81-02p/barres-de-serrages-pour-pcb/degson-electronics/15edgrc-381-02p-14-00ah/ et http://www.tme.eu/fr/details/15edgk3.81-02p/barres-de-serrages-pour-pcb/degson-electronics/15edgk-381-02p-14-00ah/
(F) K13 spox-4 spox-4 http://www.tme.eu/fr/details/mx-5267-04a/connecteurs-de-signal-pas-250mm/molex/022035045-22-03-5045-5267-04a/ et http://www.tme.eu/fr/details/mx-5264-04/connecteurs-de-signal-pas-250mm/molex/050375043-50-37-5043-5264-04/ et http://www.tme.eu/fr/details/mx-5263-pbtl/connecteurs-de-signal-pas-250mm/molex/008701040-08-70-1040-5263pbtl/
OC1 4N33 4n3x-darlington-optocoupler dil06 http://www.tme.eu/fr/details/4n33/optocoupleurs-sortie-de-transistor-tht/vishay/ et http://www.tme.eu/fr/details/gold-6p/supports-de-precision/ninigi/gold-6p/
(F) Q1 16MHz quartz-ext hc49u-488 http://www.tme.eu/fr/details/16.00m-hc49-s/resonateurs-a-quartz-tht/yic/
(F) R1 4,7kΩ resistor mf12-rect http://www.tme.eu/fr/details/1_4ws4k7/resistances-carbon-tht-14w-subminiat/royal-ohm/cfr0s4j0472a50/
(F) R2 4,7kΩ resistor mf12-rect http://www.tme.eu/fr/details/1_4ws4k7/resistances-carbon-tht-14w-subminiat/royal-ohm/cfr0s4j0472a50/
(F) R3 120Ω resistor mf12-rect http://www.tme.eu/fr/details/1_4ws120r/resistances-carbon-tht-14w-subminiat/royal-ohm/cfr0s4j0121a50/
(F) R4 1kΩ resistor mf12-rect http://www.tme.eu/fr/details/1_4ws1k/resistances-carbon-tht-14w-subminiat/royal-ohm/cfr0s4j0102a50/
(F) R5 4,7kΩ resistor mf12-rect http://www.tme.eu/fr/details/1_4ws4k7/resistances-carbon-tht-14w-subminiat/royal-ohm/cfr0s4j0472a50/
(F) R6 4,7kΩ resistor mf12-rect http://www.tme.eu/fr/details/1_4ws4k7/resistances-carbon-tht-14w-subminiat/royal-ohm/cfr0s4j0472a50/
(F) R7 10kΩ resistor mf12-rect http://www.tme.eu/fr/details/1_4ws10k/resistances-carbon-tht-14w-subminiat/royal-ohm/cfr0s4j0103a50/
(F) R8 10kΩ resistor mf12-rect http://www.tme.eu/fr/details/1_4ws10k/resistances-carbon-tht-14w-subminiat/royal-ohm/cfr0s4j0103a50/
(F) R9 10kΩ resistor mf12-rect http://www.tme.eu/fr/details/1_4ws10k/resistances-carbon-tht-14w-subminiat/royal-ohm/cfr0s4j0103a50/
(F) R10 10kΩ resistor mf12-rect http://www.tme.eu/fr/details/1_4ws10k/resistances-carbon-tht-14w-subminiat/royal-ohm/cfr0s4j0103a50/
(F) R11 330Ω resistor mf12-rect http://www.tme.eu/fr/details/1_4ws330r/resistances-carbon-tht-14w-subminiat/royal-ohm/cfr0s4j0331a50/
(F) R12 180Ω resistor rc2512 http://www.tme.eu/fr/details/smd2512-180r-1%25/resistances-cms-2512/royal-ohm/25121wf0181t4e/
(F) R13 330Ω resistor mf12-rect http://www.tme.eu/fr/details/1_4ws330r/resistances-carbon-tht-14w-subminiat/royal-ohm/cfr0s4j0331a50/
RC1 rectifier-dil rectifier-dil-to-269-aa http://www.tme.eu/fr/details/b1s/redresseurs-monophases-a-diodes-cmstht/dc-components/
(F) RN1 10kΩ 4-bussed-resistor-array sil5 http://www.tme.eu/fr/details/dr10k-4_5/reseaux-de-resistances-tht/royal-ohm/rnla05g0103b0e/
(F) RN2 10kΩ 4-bussed-resistor-array sil5 http://www.tme.eu/fr/details/dr10k-4_5/reseaux-de-resistances-tht/royal-ohm/rnla05g0103b0e/
(F) S3 TERM 1-strap strap-sil2 http://www.tme.eu/fr/details/zl201-20g/barres-et-socles-a-broches/connfly/ds1021-1_20sf11/ et http://www.tme.eu/fr/details/jumper-h_r/barres-et-socles-a-broches/ninigi/jumper-/
(F) T1 BC547 bc547 to92-bent http://www.tme.eu/fr/details/bc547c-dio/transistors-npn-tht/diotec-semiconductor/bc547c/
Z1 6,8V zener do35 http://www.tme.eu/fr/details/bzx55c6v8-tap/diodes-zener-tht/vishay/ en attente de test
-
Et dans la foulée, si vous n'êtes pas bien équipés pour monter des cartes, je vous recommande deux outils pas chers et utiles pour travailler propre :
Un plieur de pattes (résistances, ILS, etc) : http://www.tme.eu/fr/details/d-ab5/appareil-de-formatage-de-broches/donau/
Complètement indispensable pour les ILS ou le pliage sauvage aboutit à la casse de l'ampoule.
Un bracelet antistatique quand on manipule des composants sensibles : http://www.tme.eu/fr/details/scs-ecws61m-1/bandes-esd-pour-poignee/scs/ecws61m-1/
et éventuellement :
Un redresseur de pattes pour les CI en boîtier DIP (moins utile) : http://www.conrad.fr/ce/fr/product/168203/Redresseur-de-pattes que je n'ai pas trouvé chez TME.
-
3615 qui n'en veut ?
-
J'ai commencé le logiciel ce week-end.
Pour l'instant j'en suis à l'implémentation du moniteur permettant de paramétrer la carte selon les commandes que j'ai indiquées précédemment.
Ensuite je passerai à la détection de perte d'alimentation. Il faut que je fasse des essais pour voir combien d'octets on arrive à écrire dans l'EEPROM avant que le micro ne plante.
Ça se passe ici : https://git.framasoft.org/locoduino.org/ServoBoardCANDCC
-
Petit problème de mise en œuvre de la détection de perte d'alimentation.
Il s'avère que le Nano que j'ai monté arrête de fonctionner lorsque la tension d'entrée de la carte passe sous les 9V. Derrière j'ai une diode de protection donc le Nano reçoit 8,3V sur VIN, ce qui est supérieur à la tension mini de 7V.
Mais voilà ce n'est pas un nano officiel et les caractéristiques annoncées sur arduino.cc ne sont visiblement pas respectées. Comme personne ne va monter un Nano officiel à 35$ pour mettre sur cette carte, il faut faire avec.
Or, la détection de perte d'alimentation déclenche à 7,5V (c'est la zener que j'ai montée à la place de 6,8V) après la diode de protection. Donc un VIN de 8,2V et donc plus bas que le plantage du micro. C'est ballot.
Donc :
1 - Il faut alimenter la carte en 12V car à 9V on est au seuil du plantage du Nano. Le Nano recevra 11,3V
2 - Il faut détecter au dessus de 9V, le plus au dessus possible en fait et juste en dessous du 12V.
Il existe des zener 11V et 10V. À cela il faut ajouter les 0,7V de la diode de protection. En 11V, la détection déclenche si l'alimentation passe en dessous de 11,7V. J'ai peur que 0,3V soit un peu juste comme marge de bruit. En 10V, la détection déclenche à 10,7V ce qui me semble mieux.
Donc, ne commandez pas les composants manquants tout de suite. Je vais aller acheter quelques zener supplémentaires chez mon revendeur local et continuer mes essais.
-
Je vais faire le candide de service (il en faut un... ::) )
Et si on met un condo externe (sous le réseau, il y a de la place), on pourrait s'apercevoir que la tension (avant condo) a chuté et déclencher les hostilités pour enregistrer en EEPROM.
-
C'est plus ou moins déjà le cas.
-
Oui, bien sûr. Mais je pensais à un gros qu'on ne pourra jamais mettre sur le CI, mais à côté.
Un seul composant externe, c'est peut-être supportable ?
-
Je vois pas trop ce que ça apporte en fait
-
Le principe du détecteur de coupure de courant :
Une alim externe, + 12 V p. ex, est reliée à 2 diodes (+12V sur anodes communes).
La première diode (d1) alimente le NANO et le condensateur (sur la cathode de d1).
La deuxième diode (d2) est sur une pin du NANO en entrée.
Le courant se coupe :
d1 continue d'alimenter le NANO grâce au condo.
Mais la tension sur d2 chute brutalement car elle ne "voit pas" le condo.
Donc, le NANO continue de fonctionner, mais il a détecté qu'il n'y avait plus d'alim et sauvegarde sur l'EEPROM.
Et si tu mets un gros condo, tu prend le temps que tu veux.
-
Je mets mon grain de sel : Personnellement j'utilise une alimentation de PC récupérée, qui a une sortie avec un 5V toujours présent (quand elle est branchée) et une patte PS-ON pour commander la mise en et hors service.
Je vais carrément piloter l'alimentation (patte PS-ON) à partir du gestionnaire, par l'intermédiaire d'un mini qui se chargera de gérer plusieurs alimentations.
L'extinction de l'alimentation sera donc effectuée seulement après que toutes les sauvegardes soient faites
-
Ok je vois ce que tu veux dire.
Le circuit de détection avec la zener et le transistor remplit le même rôle que D2 à la différence que ça garantit que tu n'auras pas plus de 5V sur l'entrée du Nano et donc ça ne crame pas.
D1 existe mais alimente un condensateur en entrée du régulateur ainsi que le Nano. Le défaut est que le régulateur tire également dessus pour alimenter les servos et donc il va se vider plus vite.
Calcul de dos d'enveloppe :
J'avais mesuré la consommation du microservo que j'utilise, le HK15178 de Hobbyking. Au repos un servo consomme 7mA. En mouvement 60mA. Si on suppose qu'on a 2 servos en mouvement maximum (cas des portes de remise) ça donne 200mA, l'équivalent d'une résistance de 25Ω. De son côté, le Nano consomme 15mA (led PWR) + 20mA environ. Soit l'équivalent d'une résistance de 140Ω. Grosso modo on a une résistance équivalente de 20Ω. Avec les 470µF on a donc un peu plus de 9 ms, soit le temps d'écrire 3 octets ::) flute
Donc oui il faudrait mettre une capa mais elle n'a pas besoin d'être grosse si on la met entre le 5V et la masse du Nano. En effet, on n'a que le Nano et la led PWR qui tirent dessus et donc avec 470µF la constante RC est de 65ms. On peut utiliser une capa comme C3 au dos de la carte.
-
Je pense que tu n'es pas loin de la solution.
Dans les ré-enclencheurs du commerce (que j'utilisais dans mon ancien boulot), c'était une batterie rechargeable qui était chargée par le secteur, avant le compteur.
Quand le jus disparaissait (foudre, surtension, ...), la batterie faisait marcher un moteur qui appuyait sur le bouton du compteur EDF (avec un doigt métallique) et ça ré-enclenchait.
On ne faisait pas 250 km pour aller appuyer sur un bouton...(les sites de mobiles, c'est parfois paumé).
Note que dans ce cas, ça ne réglait que les surtensions, surintensités, pas la coupure franche du secteur.
Parce que, là, tu peux toujours appuyer sur le bouton :D
-
Ah, j'ai oublié la capa de 470µF sur la sortie du régulateur qui étalera la consommation des servos. C'est donc moins pire qu'exposé. Je vais testé avec un seuil plus haut (zener de 10V). Tout ça c'est à la louche, c'est beaucoup plus complexe dans la réalité. L'expérience dira combien j'arrive à sauvegarder en l'état actuel.
-
Bonsoir à tous.
De retour de mon Cotentin sublime, après tempête, grandes marées++, je reprends le cours du fil.
Merci à Jean-Juc pour ce boulot, et cette liste super précise et documentée des composants.
J'utilise moi aussi une alim d'ordi récupérée avec 3V, 5V et 12V inébranlables et PS-ON commandable par ce qu'on veut. Super pratique.
-
Disons que sur ton schéma 3/6, au lieu d'aller tester le "Vin" aux bornes du condo, j'aurais mis une diode (1N4148) :
-> anode au point 1 (anode de la 1N4007)
-> cathode au point 2 (cathode de la zener)
Et je pense que c'est tout.
Comme ça, la zener coupe tout de suite et le NANO attend la fin de décharge du condo.
-
Disons que sur ton schéma 3/6, au lieu d'aller tester le "Vin" aux bornes du condo, j'aurais mis une diode (1N4148) :
-> anode au point 1 (anode de la 1N4007)
-> cathode au point 2 (cathode de la zener)
Et je pense que c'est tout.
Comme ça, la zener coupe tout de suite et le NANO attend la fin de décharge du condo.
Oui, prendre la tension avant D1 est mieux mais il n'est pas nécessaire de mettre une diode. Si on se trompe de sens pour l'alimentation, la zener sera prise dans le sens direct mais la résistance de 10kΩ empêchera sa destruction. Faire cette modif est facile, il faut couper une piste au recto et mettre un strap au verso.
-
Je suis en train de faire les sachets de composants. C'est presque complet (les items en vert de la liste sont dans le sachet). Il me reste à découper les cartes, à faire le total et à vous envoyer tout ça.
-
Un grand merci d'avance, quel boulot !
J'ai hate de recevoir ces cartes
Amitiés. Dominique
-
C'est super !
J'ai hâte de faire ma commande chez TME pour le peu qui manque.
Qui veut quelque chose chez TME ?(Dernier rappel !)
Et quand Dominique dit "quel boulot", il sait de quoi il parle
Il l'a déjà fait... ;)
-
TME livre en 24h, pas de précipitation :)
Les valeurs de résistance dans la détection d'alimentation ne sont pas bonnes. je vous tiens au courant.
-
J'aurai probablement quelques produits à acheter mais je te dirai cela dimanche : je profite du soleil pour avancer mon mur de cloture (25m de fondations, mur parpaings et panneaux rigides !)
-
Moi pareil, j'aurais des choses, y compris parmi les outils proposés plus tôt par Jean-Luc... Mais j'attend que tout ça se décante et que l'on arrive à une liste stable... Au besoin, si je m'y prend trop tard, je commanderai de mon côté.
-
Jean-Luc a raison.
C'est quand même pas urgent ...
Prenez votre temps. D'autant qu'il faudra tester après (et donc avoir du temps aussi)
-
Les sachets de composants sont au complet à l'exception des résistances qui seront sur la détection de perte d'alimentation. Il faut que je fasse des essais pour déterminer les valeurs.
-
comme tous hâte de me mettre au fer à souder et au testing
:D :D
-
Bonjour,
J'ai les prêts à poster et j'ai fait la douleureuse :
| PU | QT | Total |
| Carte | 1,25 | 1 | 1,25 |
| Capa 100nF | 0,0288 | 6 | 0,1728 |
| Capa 22pF | 0,00777 | 2 | 0,01554 |
| Diode 1N4007 | 0,02355 | 1 | 0,02355 |
| Diode 1N4148 | 0,01550 | 2 | 0,031 |
| Support SIP 8 | 0,1619 | 2 | 0,3238 |
| Support SIP 28 | 0,5408 | 1 | 0,5408 |
| Barre serrage 3,5 | 0,1362 | 1 | 0,1362 |
| Connecteur 3,5 | 0,2838 | 1 | 0,2838 |
| Connecteur servo male | 0,05209 | 8 | 0,41672 |
| Connecteur servo femelle | 0,01855 | 8 | 0,1484 |
| Broches connecteur | 0,00829 | 40 | 0,3316 |
| Connecteur RJ11 | 0,3184 | 2 | 0,6368 |
| Connecteur I2C male | 0,0733 | 1 | 0,0733 |
| Connecteur I2C femelle | 0,0344 | 1 | 0,0344 |
| Broches connecteur | 0,0385 | 4 | 0,154 |
| Quartz 16MHz | 0,2476 | 1 | 0,2476 |
| Résistances | 0,00419 | 13 | 0,05447 |
| Réseau de résistances | 0,08005 | 2 | 0,1601 |
| Strap male | 0,014509 | 1 | 0,014509 |
| Cavalier | 0,02417 | 1 | 0,02417 |
| Transistor | 0,00994 | 1 | 0,00994 |
| | Total par carte | 5,083499 |
À cela s'ajoute le port :
1 carte : 3€20
2 cartes : 4€56
Donc en résumé :
1 carte -> 8€28 + 3% de commission Paypal = 8€53
2 cartes -> 14€72 + 3% de commission Paypal = 15€16
-
Et ton temps ?????
-
Je ne fais pas de commerce :D
-
Bon, j'ai arrondi... :D
5,08 € pour 8 aiguilles, c'est quand même pas cher ! Un grand bravo !
Jean-Luc, tu maintiens ta liste en rouge (ce que tu ne fournis pas) ?
C'est pour la suite...
-
Jean-Luc, tu maintiens ta liste en rouge (ce que tu ne fournis pas) ?
C'est pour la suite...
Oui, elle reste comme référence
-
Les petits paquets sont faits 8) Ça part en fin de journée.
-
J'ai commandé 15 NANO chez Electrodragon (20 jours), dont quelques-uns pour moi. Pour info, 3,23 € pièce, port compris.
Je démarre la commande TME.
-
C'est des centimes d'Euro € 323 ou Suisses ? CH340 ?
-
C'est la proposition de Jean-Luc (voir p4 de ce fil)
http://www.electrodragon.com/product/edarduino-nano-c-new-usb-ch340/ (http://www.electrodragon.com/product/edarduino-nano-c-new-usb-ch340/)
-
Ca y est, j'ai reçu les 2 cartes et monté les composants.
Il me manque seulement l'interface DCC dont je n'ai pas besoin et l'expandeur I2C
J'ai aussi quelques Nano Iduino rouges du plus bel effet (et avec FT232).
Chargement du logiciel de Jean-Luc (le moniteur seul) : ça marche !
Mais je n'ai pas testé plus loin car...
Seule question : je ne vois pas bien comment le GND du Nano est relié au GND de l'alimentation 5V de la carte. D'après le schéma 1.5, GND1 (pin 4) est NC et GND 2 (pin 30) est relié à la 330 ohm puis au poussoir CFG. Il n'est même pas relié au strap S1.
Verif à l'ohmmêtre : pas de connexion de GND sur le Nano!
Ai-je oublié quelque-chose ?
-
Seule question : je ne vois pas bien comment le GND du Nano est relié au GND de l'alimentation 5V de la carte. D'après le schéma 1.5, GND1 (pin 4) est NC et GND 2 (pin 30) est relié à la 330 ohm puis au poussoir CFG. Il n'est même pas relié au strap S1.
Verif à l'ohmmêtre : pas de connexion de GND sur le Nano!
Ai-je oublié quelque-chose ?
Non, j'ai fait une bêtise :-\ Quel idiot je fais.
Tout d'abord il faut souder les straps S1 et S2.
L'absence de masse entre l'Arduino et le reste n'est pas compliqué à régler : soude une queue de résistance entre la broche 4 de l'Arduino et la broche 5 (GND-LOGIC) du 6N137
(http://forum.locoduino.org/index.php?action=dlattach;topic=125.0;attach=295;image)
-
Donc, plus de peur que de mal ;)
-
Merci Jean-Luc,
Ajouter une masse n'est jamais compliqué, heureusement!
Mais il faut le faire avant d'installer tous les circuits.
Peut-être que la sauvegarde en EEPROM fonctionne mieux maintenant.
-
Le logiciel de configuration avec enregistrement en EEPROM est de toute beauté !
C'est un bon exemple de CommandInterpreter.
De plus, la mise en onglets séparés ne surcharge pas le programme principal.
C'est ainsi plus facile à réutiliser dans d'autres projets.
-
bonsoir à tous
la poste est "flemmarde"' à Villeurbanne , et j’attends mes 2 cartes avec impatience. Je pourrai commencer par les straps de ground. Et voir si mes Nano chinois sont compatibles 16MHZ.... ::) ::)
-
je viens de recevoir ce matin mes deux cartes
Chapeau Jean-Luc et merci pour tout le boulot que tu as fait . :D :D
-
Chez moi aussi le Père Noël est passé ;D ;D ;D
Si vous avez besoin de quelque chose chez TME, dites-le moi.
-
Oui Denis:
- Une dizaine de chaque des capas C3 et C10
C3 470µF aluminium-capacitor radial-capacitor-25-70 http://www.tme.eu/fr/details/uvz1a471med/condensateurs-electrolytiques-tht-105c/nichicon/
C10 470µF radial-electrolytic-capacitor radial-capacitor-50-100 http://www.tme.eu/fr/details/rd1v477m10016bb/condensateurs-electrolytiques-tht-105c/samwha/
- 2 expandeurs mcp23017
IC1 expandeur fins de course mcp23017 dil28 http://www.tme.eu/fr/details/mcp23017-e_sp/multiplexeurs-et-commutateurs-analogues/microchip-technology/
- 2 paires de circuits CAN 2515 et 2551
IC3 MCP2515 mcp2515 dil18 http://www.tme.eu/fr/details/mcp2515-i_p/circuits-integres-interface-can/microchip-technology/
IC4 MCP2551 pca82c250 dil08 http://www.tme.eu/fr/details/mcp2551-i_p/circuits-integres-interface-can/microchip-technology/
Merci d'avance
Dominique
-
Denis ,
pour moi, comme Dominique,
_une dizaine de chaque capacité C3 et C10
_2 expandeurs de fin de course mcp23017
Le reste, j'ai. même le support Gold-6p pour l'OC1 4N33, qui est en rupture de stock chez TME; il est chez Farnell mais une commande n'est pas interressante vue les prix de livraison...J'ai trouvé sur la Baie, mais la qualité n'est pas la même, c'est sûr.
Merci
-
La commande chez TME vient de partir.
J'espère que "j'ma pas gourré"... ;D
J'aurais ça très rapidement.
Par contre, chez Electrodragon, j'avais commandé les NANO le 24/03 et je pense qu'on peut tabler sur une vingtaine de jours (mi-Avril).
J'enverrai tout d'un coup pour diminuer le coût du port.
-
y'a pas le feu, merci d'avance
-
Commande TME partie le 30/03 à 10h10, arrivée chez moi le 31/03 à 13h50 !
Ils sont quand même très forts !!
-
reçu les composants de TME. Merci Denis.
Les tests sont nickel avec la zener 10V.
:D ;D ;D
-
De rien, mais c'est surtout Jean-Luc qu'il faut remercier :
Conception du circuit, réalisation de la platine (pro) et la moitié des composants !
-
Je m’apprête à assembler la carte, et qu'est ce que je m'aperçois-je ? Des composants CMS ! Jamais soudé ça, mais on va tenter le coup... Avant de m'y mettre je tente un placement manuel des tout petits composants, et je m'aperçois aussi que je ne sais pas dans quel sens mettre RC1 ! Pas moyen de trouver de la doc sur la symbolique inscrite sur la carte pour savoir de quel côté mettre le flanc biseauté du boitier...
Un peu d'aide ?
-
Oui,
C'est pas dur.
Tu commence par déposer un peu de soudure (très peu) sur un des pads. Tu places ton composant et tu le maintiens appuyé avec un tige quelconque. Ça va âtre un peu bancale mais c'est pas grave. Puis tu refais fondre la soudure qui vient napper le composant. Un fois fait le reste est facile.
Commence par la résistance R12 puis fais le redresseur.
Il vaut mieux souder ces composants en premier évidemment.
Je peux te faire une vidéo si tu patiente 1/2h
-
Non, la question c'est pas sur la soudure, mais bien dans quel sens je dois placer le boitier !
-
Pour la résistance ça n'a pas d'importance
Pour le redresseur RC1, tu as un marquage sur le boîtier. Deux des broches sont marquées + et - avec DC entre les deux.
Si tu regardes la carte dans ce sens :
(http://forum.locoduino.org/index.php?action=dlattach;topic=125.0;attach=252)
Ces deux broches sont à mettre à droite vers le Nano.
-
Ok, je tente la soudure... Merci.
-
Ok, c'est soudé sans -trop- de difficultés... Autre question, est-ce que je dois mettre ou pas la Zener livrée (C10PH), en fin de compte ?
-
J'ai pas eu le temps de valider cette partie. Donc tu peux ne pas souder la zener pour l'instant.
-
Voilà, c'est tout soudé. Après ce marathon de soudure (trois cartes Can, deux cartes Servos, trois Nanos...), je me pose plusieurs questions:
D'abord sur la carte servo :
1) Dans quel sens mettre le Nano ? Je n'ai pas vu de renseignement sur la sérigraphie... J'ai dû me référer à la photo prise en page 4.
2) Quel est le brochage des servos ? Les miens sont, comme beaucoup je crois, livré avec un connecteur trois broches, pas cinq !
(http://tiptopboards.com/169-thickbox/mini-servo-moteur-sg90-9g-mod%C3%A9lisme-arduino.jpg)
Enfin, et de manière plus générale, ne serait-il pas souhaitable d'avoir une section dédiée sur le site Locoduino pour les cartes maison, avec les docs, les listes de composants, les fichiers pour lancer une fabrication, des tutoriaux de montage et/ou une doc d'utilisation ?
-
1) le Nano se met avec la prise USB vers la droite selon l'orientation de l'image ci-dessus
2) le brochage des prises servo est le suivant selon la même orientation :
Masse
5V
PWM
FC1
FC2
C'est à dire le fil marron sur la broche du haut, le fil rouge sur la 2e et le orange sur celle du milieu :
(http://forum.locoduino.org/index.php?action=dlattach;topic=125.0;attach=329;image)
3) si il faudrait. Dès que j'ai fini le boulot en cours, je m'y colle.
-
Oui, il y a pas urgence, c'est juste que je me pose les questions du béotien qui va découvrir la carte... Je viens de tester avec deux servos et une alim externe, ça roule. Yapluka...
-
Et mer...credi! J'ai monté le RC1 à l'envers, merci Thierry pour les questions que tu as posé et qui éclairent le schmilblick. comme d'hab, on ne devrait jamais hésité à demander des précisions aux hommes de l'art. Il ne faut jamais avoir peur de passer pour un ignare, surtout quand on l'est vraiment, comme moi...
Conclusions du voyage: la carte ne risque rien puisque je suis en analogique exclusif , au mois actuellement;mais qui a dit"fontaine je ne boirais pas de ton eau".....
mais pour le fun, dessoudage du RC1, au besoin en s'aidant du dessoudage du connecteur DCC, puis remise en place dans le bon sens. :P :P :P ;D >:(
Bonne journée à tous
-
Ah zut
Pour dessouder un CMS, voici une technique.
Fixe la carte sur la table.
Avec une tresse à dessouder tu assèches les soudures du composant.
Tu prends un fil d'acier fin sur lequel la soudure ne prend pas. Tu glisses le fil derrière une des pattes et d'une main tu tiens les deux bouts du fil : ça fait une boucle qui passe derrière la patte. Tu chauffes en tirant le fil qui se glisse sous la patte. tu retires le fer en continuant de tirer doucement. Normalement la patte est dessoudée.
Tu recommences avec les 2 autres
Pour la dernière tu saisis le composant avec des brucelles
-
Une technique similaire : http://www.egloff.eu/index.php/fr/la-technique/astuces-techniques/dessouder-des-cms
-
Merci, Jean-Luc.
J'essaye des demain matin
-
Au passage, petite question, à quoi sert la partie côté DCC comprenant le pont et la résistance CMS et l'opto 4N34 ?
Je suppose que c'est pour envoyer un signal de type consommation de courant au moment de la configuration ?
-
Oui c'est ça.
-
bonjour a tous.
échange standard effectué sans problème, avec réutilisation de la pièce primitive, avec qd même quelques moments de transpiration...
Je ne peux même pas tester le DCC!!
Je reviens sur la proposition de Thierry concernant la création sur locoduino d'une section dédiée aux cartes maisons... Les fichiers , modes d'emploi, etc... éviteraient un certain nombre de loupés. Qu'en pensez vous?
-
Tester le DCC est possible, même sans les composants RC1, 4N33, R11 et R12.
Le DCC est récupéré à la sortie du 6N137 (IT-DCC) sur l'entrée D2 du Nano.
Un test facile est possible en chargeant le code du moniteur DCC ici : http://www.locoduino.org/spip.php?article39 (http://www.locoduino.org/spip.php?article39)
Normalement le code de cet article est compatible avec l'entrée DCC sur D2.
Je n'ai pas eu le temps de le tester mais j'y crois :))
-
Nouvelle question. Si je veux relier deux cartes servos pour faire des essais sur le bus CAN, il faut un cable RJ11 droit ou croisé ?
-
droit (cable téléphonique standard)
même couleurs des fils sur les prises à chaque extrémité
j'ai ma propre pince RJ11/12 et une autre RJ45, c'est bien pratique pour se faire des cables à la longueur désirée
-
Comme dit Dominique. C'est bien sûr le même brochage que sur les cartes CAN.
-
Oui, il faut bien relier tous les CanH ensemble et tous les CanL ensemble.
Si tu croises, c'est certain que ça ne marche plus (Denis a testé).
Le bus Can fonctionne uniquement en différentiel entre CanH et CanL : la masse, le 5v ou le 3,3V n'interviennent pas du tout. Il ne faut que 2 fils (contrairement à l'I2C).
C'est pratique pour relier un Due en 3,3v à un Nano en 5v, sans problème : ca je le vois fonctionner tous les jours dans mon réseau.
-
En passant j'ai testé un servo branché sur la prise S7 (comme sur la photo de Jean-Luc là http://forum.locoduino.org/index.php?topic=125.msg1539#msg1539 (http://forum.locoduino.org/index.php?topic=125.msg1539#msg1539)), en utilisant l'exemple "sweep" de la bibliothèque standard SERVO de l'IDE.
Et ça marche aussi :))
Je n'avais encore jamais joué avec des servos !
-
Juste une petite précision :
Si tu croises, c'est certain que ça ne marche plus (Denis a testé)
Ce ne sont pas les fils du bus CAN que j'avais croisés ::), mais le lien entre la carte CAN et l'Arduino DUE.
En voyant Rx et Tx de chaque côté, j'avais croisé et il ne faut pas : Rx du DUE vers Rx de la carte et Tx du DUE vers Tx de la carte.
-
Exact !
Tu as bien fait de préciser. Merci Denis
-
Bon, je continue mes tests... Lorsque je tente d'initialiser le bus Can, rien ne bouge :
void setup()
{
Serial.begin(115200);
while (CAN_OK != CAN.begin(CAN_500KBPS)) // init can bus : baudrate = 500k
{
Serial.println("CAN BUS Shield init fail");
Serial.println(" Init CAN BUS Shield again");
delay(100);
}
Serial.println("CAN BUS Shield init ok!");
}
Le while n'est jamais validé, ni en alim USB, ni en alim externe ! Y aurait-il quelque chose à faire que j'ai oublié du côté matériel, ou un test simple à mettre en oeuvre ? Et dans la même veine, il a deux prises RJ11, a quoi elles correspondent, et est ce que le terminateur est nécessaire ?
-
C'est la phase la plus stressante : on branche et ça ne marche pas.
Je suis sûr d'au moins un truc : il faut 2 termineurs (un à chaque bout).
Schéma générique :
https://fr.wikipedia.org/wiki/Controller_Area_Network#/media/File:CAN_Support.svg (https://fr.wikipedia.org/wiki/Controller_Area_Network#/media/File:CAN_Support.svg)
C'est une boucle. Si tu ne la fermes pas (la boucle :D ), ça ne peut pas marcher
-
La discussion entre l'Arduino et le contrôleur CAN (le 2515) n'est pas influencée par le terminateur.
Par contre, comment alimentes tu la carte. Si c'est uniquement via l'USB, seul le Nano est alimenté. Il faut que tu alimentes via la prise d'alimentation pour que le 2515 et le reste de la carte soit alimenté
-
Je viens de tester l'init du CAN en utilisant le sketch de la carte Locoduino, modifié pour avoir le CS sur la pin D10 (selon schéma 1.5) :
// demo: CAN-BUS Shield, receive data with check mode
// send data coming to fast, such as less than 10ms, you can use this way
// loovee, 2014-6-13
#include <SPI.h>
#include "mcp_can.h"
// the cs pin of the version after v1.1 is default to D9
// v0.9b and v1.0 is default D10
const int SPI_CS_PIN = 10;
MCP_CAN CAN(SPI_CS_PIN); // Set CS pin
void setup()
{
Serial.begin(115200);
START_INIT:
if(CAN_OK == CAN.begin(CAN_500KBPS)) // init can bus : baudrate = 500k
{
Serial.println("CAN BUS Shield init ok!");
}
else
{
Serial.println("CAN BUS Shield init fail");
Serial.println("Init CAN BUS Shield again");
delay(100);
goto START_INIT;
}
}
void loop()
{
unsigned char len = 0;
unsigned char buf[8];
if(CAN_MSGAVAIL == CAN.checkReceive()) // check if data coming
{
CAN.readMsgBuf(&len, buf); // read data, len: data length, buf: data buf
unsigned long canId = CAN.getCanId();
Serial.println("-----------------------------");
Serial.print("get data from ID: ");
Serial.println(canId, HEX);
for(int i = 0; i<len; i++) // print the data
{
Serial.print(buf[i]);
Serial.print("\t");
}
Serial.println();
}
}
/
Résultat : j'ai bien "CAN BUS Shield init ok!" sur le moniteur :))
-
Par contre, comment alimentes tu la carte. Si c'est uniquement via l'USB, seul le Nano est alimenté. Il faut que tu alimentes via la prise d'alimentation pour que le 2515 et le reste de la carte soit alimenté
D'après le schéma, les MCPxxxx sont alimentés par le 5V-Logic.
Si les straps S1 et S2 sont soudés ET si le Gnd1 du Nano est relié au Gnd-Logic, comme tu l'as recommandé plus tôt dans cette discussion, les MCPxxxx sont alimentés aussi à partir de l'USB du Nano : en tout cas ça marche chez moi (pour l'init CAN).
Citation de Jean-Luc : Tout d'abord il faut souder les straps S1 et S2.
L'absence de masse entre l'Arduino et le reste n'est pas compliqué à régler : soude une queue de résistance entre la broche 4 de l'Arduino et la broche 5 (GND-LOGIC) du 6N137
Néanmoins, vu le schéma, je ne vois pas comment ça peut marcher car le 5v du Nano n'est pas connecté, et pourtant ça marche chez moi ! : Mystère :o :o
-
Curieux oui.
J'ai pas le temps dans la semaine mais je vous accompagne ce week end
-
je pense qu'il vaut mieux alimenter la carte par le port K1 de toute façon.
Pour les servos, c'est sûr que les servos ne sont pas alimentés si K1 n'a rien.
-
Je viens de refaire des essais avec et sans alim sur K1 :
- avec alim sur K1 on a du 5V correct partout
- sans alim sur K1, l'alim du 2515 et du 2551 est plutôt vers 2V
C'est comme si le circuit était alimenté par les signaux SPI, ce qui n'est pas sain du tout (ça peut même l'endommager, peut-être, mais le mien marche toujours) = donc il faut éviter de ne pas alimenter K1 : alimenter K1 avant de connecter la prise USB !
-
Si tu charges un sketch vide qui ne programme pas les broches SPI en sortie, il y a toujours 2v ?
-
Merci à tous. Avec le programme de Dominique ça marche. C'est sans doute le numéro de broche SPI que j'avais laissé à 9, sa valeur par défaut dans l'exemple de la biblio... J'y ai repensé dans la nuit, et je pensais bien que c'était ça.
Et effectivement, ça marche aussi pour moi avec seulement l'USB branché... Cela pose t-il un problème d'avoir à la fois l'alimentation extérieure via K1 et un câble USB branché ? Parce que pour vérifier ce qui passe avec la liaison série, c'est quand même plus pratique...
-
Non ça ne pose pas de problème car le Nano est alimenté via VIN et pas par le 5V. C'est fait pour.
Le Nano intègre un dispositif un peu rudimentaire mais fonctionnel pour sélectionner la source d'alimentation (une diode schottky qui empêche que le régulateur envoie du jus dans l'USB) :
- Si VIN n'est pas alimenté le régulateur embarqué dans le Nano ne délivre pas de 5V et c'est VUSB qui est appliqué via la diode schottky.
- SI VIN est alimenté, le +5V du Nano est fourni par le régulateur, celui venant de l'USB ne sert pas.
-
Après divers essais, je n'arrive à rien. Si maintenant l'initialisation est correctement faite, la carte de réception ne reçoit rien !
J'ai connecté par un câble RJ11 droit (vérifié, au cas où...) les prises côté Nano de chacune des cartes, alimentées toutes deux par l'extérieur, plus des câbles USB en place.
Code émetteur :
// demo: CAN-BUS Shield, send data
#include <mcp_can.h>
#include <SPI.h>
// the cs pin of the version after v1.1 is default to D9
// v0.9b and v1.0 is default D10
const int SPI_CS_PIN = 10;
MCP_CAN CAN(SPI_CS_PIN); // Set CS pin
void setup()
{
Serial.begin(115200);
while (CAN_OK != CAN.begin(CAN_125KBPS)) // init can bus : baudrate = 500k
{
Serial.println("CAN BUS Shield init fail");
Serial.println(" Init CAN BUS Shield again");
delay(100);
}
Serial.println("CAN BUS Shield init 125K ok!");
}
unsigned char stmp[8] = {0, 1, 2, 3, 4, 5, 6, 7};
void loop()
{
// send data: id = 0x00, standrad frame, data len = 8, stmp: data buf
Serial.println("send data!");
CAN.sendMsgBuf(0x00, 0, 8, stmp);
delay(1000); // send data per 100ms
}
Code récepteur :
// demo: CAN-BUS Shield, receive data with interrupt mode
// when in interrupt mode, the data coming can't be too fast, must >20ms, or else you can use check mode
// loovee, 2014-6-13
#include <SPI.h>
#include "mcp_can.h"
// the cs pin of the version after v1.1 is default to D9
// v0.9b and v1.0 is default D10
const int SPI_CS_PIN = 10;
MCP_CAN CAN(SPI_CS_PIN); // Set CS pin
unsigned char flagRecv = 0;
unsigned char len = 0;
unsigned char buf[8];
char str[20];
void setup()
{
Serial.begin(115200);
while (CAN_OK != CAN.begin(CAN_125KBPS)) // init can bus : baudrate = 500k
{
Serial.println("CAN BUS Shield init fail");
Serial.println(" Init CAN BUS Shield again");
delay(100);
}
Serial.println("CAN BUS Shield init ok!");
attachInterrupt(digitalPinToInterrupt(3), MCP2515_ISR, FALLING); // start interrupt
}
void MCP2515_ISR()
{
Serial.println("Exception raised");
flagRecv = 1;
}
void loop()
{
if(flagRecv)
{ // check if get data
flagRecv = 0; // clear flag
// iterate over all pending messages
// If either the bus is saturated or the MCU is busy,
// both RX buffers may be in use and reading a single
// message does not clear the IRQ conditon.
while (CAN_MSGAVAIL == CAN.checkReceive())
{
// read data, len: data length, buf: data buf
CAN.readMsgBuf(&len, buf);
// print the data
for(int i = 0; i<len; i++)
{
Serial.print(buf[i]);Serial.print("\t");
}
Serial.println();
}
}
}
Les codes ont été adaptés pour coller au matériel : pin 10 pour le SPI, interruption CAN sur la pin 3 pour la lecture et vitesse réduite à 125K... Mais rien n'y fait. Une idée ?
-
Il ne faut pas faire de print dans une routine d'interruption.
Si le buffer d'émission est plein, print fait une attente active sur la disponibilité d'un emplacement dans le buffer d'émission. Comme il est vidé par l'interruption d'envoi de l'UART et que l'ISR correspondante ne peut pas s'exécuter tant que l'ISR du MPC n'est pas terminée...
... Ça fait un deadlock
-
Ben, le print je l'ai juste ajouté parce que je ne comprenais pas, et que je voulais savoir si une interruption avait été lancée, mais ça ne marche pas sans non plus !
-
Les terminateurs sont en place ? les 2551 dans le bon sens ?
-
Je crois que tout est bon :
-
Vu d'ici oui.
Tu as un oscillo ?
-
J'en ai un petit, mais je ne sais pas m'en servir. Je referais des essais dimanche, lorsque je reviendrais de week-end. Je descend en Bourgogne voir mon beau-frère (youpi...), ça me fera un break en tout cas.
Il faudra aussi que j'essaie avec les cartes CAN d'essai pour voir si ça marche avec elles...
-
Je vais m'y mettre également ce week-end. On va déverminer tout ça ;)
-
Après avoir cherché un cable RJ11 pendant 1 heure, j'ai réussi à connecter une carte 8 servos à un moniteur CAN que j'avais réalisé pour voir ce qui s'y passe.
Sketch sur le nano (carte servo) = send_Blink de l'exemple CAN Locoduino, à 500 kb/s, avec SPI_CS_PIN = 10 comme il se doit. Pas d'autre motif.
Ce sketch envoie un message par seconde et 'In loop" sur la console.
Mon moniteur affiche un compteur des messages reçus : il y en a bien un toutes les secondes. Voici ce qu'il affiche sur la console :
CAN Monitor V0.6 du 22/01/2016 copyright Dominique Bultez
CAN bus initialized.
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
70 1 1 2 3 0 5 6 7
Ca correspond bien à ce qu'envoie send_Blink.
Maintenant, Thierry, il faut décortiquer un peu ce qui se passe de ton coté.
Je vais essayer de faire un programme de test entre 2 cartes servos
-
Petit test entre les sketchs receive_check et send_blink pris dans les exemples du Can Locoduino à 500 kb/s = OK :) ;) :D
J'ai inversé les tests pour être sûr que la carte 8 servos joue bien l'un ET l'autre :
CAN BUS Shield init ok!
-----------------------------
get data from ID: 70
1 1 2 3 0 5 6 7
-----------------------------
get data from ID: 70
1 1 2 3 0 5 6 7
-----------------------------
get data from ID: 70
1 1 2 3 0 5 6 7
-----------------------------
get data from ID: 70
1 1 2 3 0 5 6 7
Donc pas besoin de tests plus compliqués pour valider le CAN.
Après, si tu veux, je peux t'envoyer mes programmes, mais il faut ajouter d'autres composants comme des afficheurs lcd.
-
Il y a quand même un truc qui ne va pas : les cartes émettent bien des messages CAN puisque que je les reçois bien sur mon moniteur CAN.
Par contre, elles ne voient pas les messages reçus, sous interruption ou pas.
J'ai bricolé un test qui émet et reçoit avec des Id aléatoires pour permettre de charger le même code sur 2 cartes connectées par le bus CAN.
J'ai adapté l'initialisation de l'interruption à la méthode recommandée du moment. L'interruption est bien sur la pin 3.
Il manque l'initialisation des filtres, mais ça ne devrait rien filtrer.
// Demo: CAN-BUS Shield, send data & receive data with interrupt mode
// Dominique 21/04/2016
// TEST des cartes 8 servos conçues et réalisées par Jean-Luc Bechennec
#include <SPI.h>
#include "mcp_can.h"
// La pin CS du 2515 sur la carte 8 servos est 10
const int SPI_CS_PIN = 10;
// L'IT_CAN est sur D3
const byte interruptPin = 3;
MCP_CAN CAN(SPI_CS_PIN); // Set CS pin
unsigned char flagRecv = 0;
unsigned char len = 0;
unsigned char buf[8];
char str[20];
unsigned char stmp[8] = {0, 0, 0, 0, 0, 0, 0, 0};
unsigned long _Seconde;
int Id;
void setup()
{
Serial.begin(115200);
START_INIT:
if(CAN_OK == CAN.begin(CAN_500KBPS)) // init can bus : baudrate = 500k
{
Serial.println("CAN BUS Shield init ok!");
}
else
{
Serial.println("CAN BUS Shield init fail");
Serial.println("Init CAN BUS Shield again");
delay(500);
goto START_INIT;
}
pinMode(interruptPin, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(interruptPin), MCP2515_ISR, FALLING); // start interrupt
_Seconde = millis(); // start tache emission periodique
randomSeed(analogRead(A6));
Id = random(10,200); // pour éviter d'avoir la même adresse des 2 cotés
}
void MCP2515_ISR()
{
flagRecv = 1;
}
void loop()
{
if(flagRecv) { // check if get data
flagRecv = 0; // clear flag
// iterate over all pending messages
// If either the bus is saturated or the MCU is busy,
// both RX buffers may be in use and reading a single
// message does not clear the IRQ conditon.
while (CAN_MSGAVAIL == CAN.checkReceive()) {
// read data, len: data length, buf: data buf
CAN.readMsgBuf(&len, buf);
unsigned char canId = CAN.getCanId();
// print the data
Serial.print(canId);Serial.print("\t");
for(int i = 0; i<len; i++) {
Serial.print(buf[i]);Serial.print("\t");
}
Serial.println();
} // while
} // if(flagRecv)
if (_Seconde + 1000 < millis()) {
_Seconde = millis();
CAN.sendMsgBuf(Id,0, 8, stmp);
Serial.println("envoi message");
stmp[0]++;
if (stmp[0]==0) {
stmp[1]++;
if (stmp[1]==0) {
stmp[2]++;
if (stmp[2]==0) {
stmp[3]++;
if (stmp[3]==0) {
stmp[4]++;
if (stmp[4]==0) {
stmp[5]++;
if (stmp[5]==0) {
stmp[6]++;
if (stmp[6]==0) {
stmp[7]++;
}
}
}
}
}
}
}
}
}
Je n'ai pas réussi à recevoir les messages qui sont pourtant bien émis.
Il est tard, je verrai ça demain soir.
-
en tant que néophyte ignare , je suis attentivement les questions posées par le fonctionnement de la carte, sans pouvoir y ajouter qq avis que ce soit.
Par contre je reviens 30sec sur les prises RJ 10et 11 du bus CAN. J'ai trouvé ça sur le Net et ça ne semble pas correspondre au câblage utilisé pour les cartes CAN et Servo de Jean Luc
Merci de votre avis.
-
J'ai regardé ta référence sur les standards télécom : ils me semblent américains, en France on a peut-être un standard différent.
Jean-Luc a assigné CANH aux fils du centre 2 et 3 et CANL au fils extérieurs 1 et 4. Il n'y a pas de possibilité d'alimentation type PoCan (Power over Can).
Si tu utilises un bête fil de téléphone, ça doit marcher. Pourquoi faire compliqué ?
-
Tu as raison.
De toute façon 4brins 4contacts. Selon le câblage des prises femelles... Mais mon attention avait été attirée par le PoCan. Pourquoi faire simple... ;D ;D
-
Je n'ai pas assez d'expérience sur le CAN pour affirmer quelque chose avec certitude. Mais je pense que, comme le CAN permet des transmissions fiables en milieu bruité, ce qui est le cas sous un réseau de machines électriques, ce serait dommage de bruiter les alimentations des organes connectés.
Ça irait à l'encontre du but à atteindre.
-
Moi aussi, j'ai suivi avec attention sans pouvoir aider, malheureusement (la faute à mes préparatifs de déménagement ??? et mon TCO objet).
On voit qu'on est sur un site actif et que tout le monde se démène pour aider quelqu'un dans le besoin.
Ce n'est pas une découverte, loin de là, mais ça fait plaisir !
Pour la question de Bernard, je dirais que, comme, moi aussi, je fais mes câbles RJ, je ne me suis pas posé de questions existentielles : câblage droit.
J'ai juste respecté le code des couleurs (pas dur : c'était marqué sur la boîte ;D )
-
Ben je sais pas trop quoi vous dire les gars parce que de mon côté je n'ai pas de soucis ???.
Je viens de mettre en route :
1) la carte 8 servos
2) un module CAN locoduino branché sur un Nano
(http://www.locoduino.org/pic/setup.jpg)
Les deux reliés par un cable RJ11 cablé droit comme ceci :
(http://forum.locoduino.org/index.php?action=dlattach;topic=125.0;attach=334;image)
Notez que quand on regarde les socket RJ11 de dessus, les deux contacts centraux sont CANH et les deux contacts des bords sont CANL. Par conséquent, si le câble était croisé avec sur la prise de droite sur la photo les couleurs noir rouge vert jaune de haut en bas, ça n'aurait aucune importance puisque sur la carte le noir est relié au jaune et le rouge au vert.
J'ai chargé le sketch que Dominique a donné juste ci-dessus
Et j'ai bien envoi et réception de message à chaque bout comme l'atteste cette vidéo : http://www.locoduino.org/pic/sortie.mp4
Donc : vérification des soudures, n'y en a-t-il pas une d'oubliée ? Tous les composants sont bien en place ?
-
Concernant la connectique, j'ai choisi le RJ11 car c'est également la connectique CAN de mon réseau et de celui de deux copains Pierre et Philippe avec lesquels je développe l'électronique du réseau. C'est Pierre qui a fait ce choix il y a lontemps, avant que je me raccroche au projet.
Classiquement le CAN est en DB9 mais les socket DB9 sont très encombrants (30mm de large !), les câbles sont également plus chers et sont plus fastidieux à réaliser soi même. donc pour des raisons de coût (le prix des cartes est proportionnel à la surface/dimensions) et de facilité d'emploi le DB9 a été écarté.
-
Je confirme partiellement la manip de Denis : entre une carte 8 servos et une carte CAN Locoduino, ça marche en émission et réception, vu du coté de la carte Locoduino :
On voit les messages émis ("envoi message"), et les messages reçus ("166 75 0 0 0 0 0 0 0").
Par contre, du coté de la carte 8 servos, on ne voit que les messages émis ("envoi message"), pas les messages reçus !!!
Est-ce que ça fonctionne chez toi Denis des 2 cotés ?
Autre phénomène bizarre, j'ai un Nano dont le port est visible de l'IDE quand il n'est pas installé sur la carte 8 servos, mais devient invisible dès qu'il est installé sur la carte. Pourtant il fonctionne (tout du moins en émission de messages CAN). Un autre Nano ne fait pas ce problème.
Et c'est pareil sur les 2 cartes 8 servo que j'ai !
Ca doit être une grosse bourde, je m'en excuse d'avance :-\
Je vais inspecter soigneusement les soudures et les composants
-
Ou bien ça vient du Nano. La Nano que j'ai sur la carte est celui disponible chez ElectroDragon : http://www.electrodragon.com/product/edarduino-nano-c-new-usb-ch340/ et j'ai la liaison série quand il est sur la carte (interface CH340)
Avec un autre Nano de Funduino, je n'ai pas la liaison série quand il est sur la carte :-\
La gravure de la marque du FTDI (laser) qui l'équipe est pas top, il doit être bidon. C'est celui qui est sur la breadboard ci-dessus
Avec un autre d'origine inconnue mais qui a également copié la marque de l'original (gravitech), c'est ok
La gravure du FTDI est nickel, c'est peut être un vrai. (ou alors c'est un vrai Gravitech tombé dans un carton en bout de chaine et vendu sur le marché gris, va savoir)
-
On a des rebondissements dans cette affaire :o 8)
Je viens de remplacer le Nano, dont le port ne se voit pas, par un autre Nano et maintenant on voit les émissions ET receptions sur la carte servo, avec ce nouveau Nano.
Celui dont le port n'est plus visible (mais avec le bon sketch) n'est plus visible non plus sur mon breadboard avec carte Locoduino
C'est donc le Nano qui semble être en cause.
Donc ça se passe sur le port SPI.
Comme ces Nano ne me posaient pas de problème avant, il y a matière à investigation.
Est-ce que le fait de les avoir alimentés par le port USB uniquement au début a pu les endommager ?
Cherchons, ça peut servir !
-
Bizarre,
Il n'est pas impossible qu'il ait été endommagé mais de mon côté le Nano Funduino n'est pas visible quand il est sur la carte et il n'y a jamais été avec une alimentation côté USB et pas côté carte.
Par ailleurs j'ai branché le Nano d'ElectroDragon seulement par l'USB au tout début mais ni le 2515 ni le 23017 n'étaient en place et de toute manière je ne me suis occupé que de la broche du bouton CFG.
Quoiqu'il en soit : Il ne faut pas brancher l'USB alors que la carte n'est pas alimentée
-
Je crois que Jean-Luc a raison.
Tous mes Nano ont une belle gravure FTDI.
Mais le bleu marqué "Arduino Compatible", d'origine inconnue ne permet pas de voir son port aussi sur le breadboard.
On ne voit son port que quand il est pas branché ! Pas normal. Il ne me faisait pas cala avant.
Bon c'est vrai que je les torture un peu quand même !
Le rouge "Iduino" pose moins de problème
Si ceux d'Elecrodragon (à base de CH40 ?) fonctionne bien, pourquoi pas, mais je rechigne à installer un driver non certifié sur mon Mac.
J'ai du mal à comprendre la relation qu'il peut y avoir entre le port USB et le port SPI !!!
-
Ce que je comprend mal, c'est que quand on utilise la carte Locoduino branchée sur le 5v du Nano et le SPI, donc quand le Nano est alimenté QUE par le port USB et alimente la carte Locoduino par son 5V, là ça ne semble pas endommager le Nano.
Ne serait-il pas possible d'utiliser la pin 5v pour alimenter les chips CAN ? (évidemment pas les servos)
-
A coté du Nano bleu "compatible" dont je ne vois plus le port, j'ai un Nano rouge Iduino de Geeetech.com dont je vois le port quand il est installé sur la carte 8 servos, qui se laisse programmer sans problème, mais, quand le sketch tourne, n'affiche pas les messages reçus.
C'est quand même troublant : il va falloir tester les Nanos ! Cette carte 8 servos est donc un bon banc de test de Nano :-[ :-[
-
On peut utiliser le 5V fourni par le Nano pour fournir +5V-LOGIC, c'est à dire tout sauf les servos.
Il faut :
1) retirer la soudure du strap S2, ça déconnecte +5V-LOGIC du régulateur 7805
2) souder une queue de résistance sous la carte entre le +5V de l'Arduino et +5V-LOGIC. Le 5V de l'arduino est, vu de dessus, la 4e broche en haut à gauche. Le +5V-LOGIC est en face sur le 23017, 2e broche. C'est dans l'alignement du "1" de "v1.5".
Je viens de le faire sur ma carte. Alimenté par l'USB seul, l'init du 2515 est Ok. C'est vrai que c'est plus confortable pour développer tout sauf le mouvement des servos. Mais ça ne change rien au comportement de mon Funduino. Visiblement il n'aime pas du tout être alimenté en même temps par l'USB et par le régulateur embarqué du Nano. Je pense qui si tu branches ton alim de breadboard sur VIN, le comportement devrait être le même que quand le Nano est sur la carte servos.
Voici une photo des modifs, coup de pot, les broches à raccorder sont en face :)
(http://forum.locoduino.org/index.php?action=dlattach;topic=125.0;attach=336;image)
-
Je vois la liaison série de mon Funduino si je connecte d'abord l'USB et ensuite l'alimentation de la carte.
Visiblement le convertisseur USB série n'aime pas avoir d'abord VIN on puis l'USB. Même comportement sur breadboard
-
J'ai mis mon funduino sur la carte et celui d'ElectroDragon sur la breadboard (donc je les ai échangé par rapport à tout à l'heure) et les deux émettent et reçoivent les messages sans problème.
-
j'ai un Nano rouge Iduino de Geeetech.com dont je vois le port quand il est installé sur la carte 8 servos, qui se laisse programmer sans problème, mais, quand le sketch tourne, n'affiche pas les messages reçus.
Merci Jean-Luc, avec ta motif, maintenant ce Nano rouge affiche les messages reçus ;D
C'est bizarre en effet que le Nano n'aime pas la double alim USB + Vin.
J'avais déjà constaté cela mais sans faire attention particulièrement, l'usage normale étant USB seul ou Vin seul. Maintenant je constate bien cette difficulté.
A la limite, c'est plus sûr d'utiliser un mini (sans USB) qu'un Nano !
-
Houlà, pas sûr. Le convertisseur USB série que tu branches alimente le Pro Mini il me semble (obligatoire sinon il ne peut pas le programmer). Je ne suis même pas sûr qu'il y ait une quelconque protection entre le VIN et la tension fourni par le convertisseur. Je suis même sûr que non. J'ai un Pro Mini sur une de mes cartes et quand le convertisseur est branché mon régulateur 7805 chauffe, il doit injecter du courant dedans. Au moins le Nano est prévu pour être alimenté des deux côtés en même temps.
Note que le problème, à priori, est dû à des puces FTDI de contrefaçon qui ne démarre pas dans la circonstance identifiée et ne se connectent pas sur l'USB.
-
Je joins à nouveau mon sketch de tests à toutes fins utiles, avec un numéro de version (1.0) qui s'affiche sur le moniteur.
Dès que j'aurai un peu de temps, j'en ferai un plus sophistiqué (avec filtres).
Vous avez remarqué que les messages sont tous différents : on peut voir ainsi s'ils sont reçus dans l'ordre !
-
Houlà, pas sûr. Le convertisseur USB série que tu branches alimente le Pro Mini il me semble (obligatoire sinon il ne peut pas le programmer). Je ne suis même pas sûr qu'il y ait une quelconque protection entre le VIN et la tension fourni par le convertisseur. Je suis même sûr que non. J'ai un Pro Mini sur une de mes cartes et quand le convertisseur est branché mon régulateur 7805 chauffe, il doit injecter du courant dedans. Au moins le Nano est prévu pour être alimenté des deux côtés en même temps.
Note que le problème, à priori, est dû à des puces FTDI de contrefaçon qui ne démarre pas dans la circonstance identifiée et de se connectent pas sur l'USB.
Oui c'est vrai !
J'ai écrit trop vite :-[
-
J'ai publié l'état actuel de la documentation dans la rubrique cachée. L'article n'apparaît donc pas dans les menus. Pour y accéder : http://www.locoduino.org/spip.php?article168
-
Bon, enfin de bonnes nouvelles !
Ça marche, mais sous certaines conditions...
La première est de prendre un bon câble ! Comme beaucoup je suppose, j'ai fouillé chez moi jusqu'à trouver un ancien câble téléphonique en RJ11 pour relier les prises CAN. Quelle erreur ! En cherchant à comprendre pour la Nième fois, je me suis aperçu que ce câble n'avais que les deux fils au centre de reliés ! Les deux autres sont vides ! Difficile évidemment dans ces conditions de faire passer un message... Après d'autres recherches, j'ai mis la main sur un câble disposant des quatre fils bien reliés, certes beaucoup plus long et encombrant mais ça c'est pas grave... Et ça ne marchait toujours pas.
Comme préconisé par Jean-Luc, j'ai relié deux cartes d'essai CAN plutôt que les cartes servos. Et là ça a marché, mais pas longtemps... Essai avec une autre carte d'essai (j'en ai monté trois) qui a beaucoup de mal à s'initialiser...
Bref, après de multiples essais et variantes, les deux cartes servo semblent marcher à la perfection, une carte CAN marche bien. La deuxième fonctionne si l'on y touche pas, mais s'arrête dès qu'on l'effleure. Sans doute une soudure mal faite qui ne fait pas bien contact. La troisième, avec laquelle une petite capa à côté du quartz m'a posé de gros problèmes, refuse de s'initialiser la plupart du temps.
J'ai en tout cas de quoi progresser. Merci de votre aide à tous !
Je précise que je n'ai pas fait la modif d'alimentation... Et que j'ai bien entendu confondu les connecteurs Dcc et alimentation ! Je n'avais pas noté qu'ils étaient différents...
-
Bien content pour toi !
Je retiens plusieurs choses :
1°) Je crois que je vais faire un programme tout bête qui teste les câbles ethernet, fil à fil.
Parce que toi, il en manquait, des fils, mais moi, je vais fabriquer mes câbles et je vais forcément en rater.
Et deux prises RJ (bien soudées sur un circuit) et un Arduino, on doit pouvoir tester : ça doit même être très très simple.
2°) Vérifier les soudures à la loupe. Entre autres, elles doivent être bien brillantes et pas en boules. Et pas de cours-jus.
3°) Une vérif simplissime aussi : avant de mettre les CI dans les supports, vérifier qu'on a bien les tensions d'alim aux bornes des CI (on en grille moins...)
A part ça, si jamais tu as, par mégarde, grillé quelque chose, j'ai un peu de rab.
Bon courage !
-
Ah. Bonnes nouvelles :)
Concernant la carte CAN qui ne démarre pas. Si une des capas de 22pF autour du quartz a souffert, ce dernier n'oscille pas correctement et l'horloge du 2515 est donc défaillante.
-
Comme quoi, connecter soi même ses prises RJ11 ou ethernet avec les câbles AdHoc est un plus (si on s'applique un peu). Et honnêtement le prix de la pince spéciale polyvalente est vite amorti au coût du mètre de câble...
De la même façon, une alim bidouillée à partir d'une alim ATX de vieil ordi, stabilisée à 3,3V, 5V et 12V est sacrément rentable et sûre. à part les alim de labo, mais les prix ne sont pas les mêmes et on ne joue pas dans la même cour...
A part ces qq réflexions de vieux barbon inculte et radin , j'ai eu de la chance. rien est grillé, et ayant tjs alimenté la carte d'abord par l'USB, tout marche ! Les messages passent d'un Arduino à l’autre et réciproquement. Par contre ,je dois encore tester la commande des servos. Résultats au prochain épisode.
-
Comme quoi, connecter soi même ses prises RJ11 ou ethernet avec les câbles AdHoc est un plus (si on s'applique un peu). Et honnêtement le prix de la pince spéciale polyvalente est vite amorti au coût du mètre de câble...
Oui et non. Faire soi même n'est pas forcément moins cher. La paire de prise RJ11 mâle est à 8 centimes, les 100m de cable à 13-14€. Donc faire un cable d'1 mètre coûte 30 centimes. Le câble d'1 mètre tout fait est à 30 centimes si on en prend 25 :) Donc bon (et je n'ai pas compté l'outil). Et puis tu vas en rater, tu n'as pas besoin de 100m de câble, ça prend du temps de faire et le temps est compté et je préfère faire autre chose de mon temps que de sertir des câbles.
Il me faut une bonne raison pour faire soi même (en écartant le problème du câble qui n'est pas le bon :)). La bonne raison est que mes cartes de sont pas à 1 mètre l'une de l'autre, que je ne veux pas avoir des câbles à touiller ou qui pendouillent et que je n'ai trouvé que des câbles en multiple de 1 mètre. Donc la bonne raison est d'avoir le câble exactement fait pour. (je ne suis pas très sensible à l'aspect économique de la récup)
De la même façon, une alim bidouillée à partir d'une alim ATX de vieil ordi, stabilisée à 3,3V, 5V et 12V est sacrément rentable et sûre. à part les alim de labo, mais les prix ne sont pas les mêmes et on ne joue pas dans la même cour...
Faut voir (bon j'ai pas de vieilles alims de PC) mais les alims industrielles fermées sont vraiment pas chères. Exemple une 12V 3V coûte 10€ http://www.tme.eu/fr/details/lrs-35-12/alimentations-a-decoupage-industrielles/mean-well/
Donc faut évaluer les avantages et les inconvénients de chaque solution :)
-
J'avais acheté ma pince à RJ11 aux USA il y a plus de 20 ans quand on n'en trouvait pas encore en France. J'en ai une pour les RJ45 aussi.
Rien que faire ses propres câbles à la longueur voulue, ça vaut de l'or :))
-
Je n'osais plus le dire ::)
-
Concernant http://www.locoduino.org/spip.php?article168, je vais continuer avec un 2e article décrivant l'électronique en détail. Si vous voyez des choses pas claires, dites moi :)
-
Rien de pas clair, au contraire.
J'aurais peut-être ajouté ça :
(http://forum.locoduino.org/index.php?action=dlattach;topic=125.0;attach=344;image)
Et les modifs sous le circuit, expliquées sur le forum (ton message du 27 mars à 11h32 (p7 du topic)).
Par contre, le "pb" du funduino peut rester sur le forum (ton message du 23 avril à 17h57 (p12 du topic))
-
Ok Denis
Je vais ajouter une figure avec les brochages des servos utilisables (donc pas sanwa, multiplex et robbe) quoique j'ai des multiplex et ils ont un brochage différent de la figure :-/
Concernant les modifs sur la carte, les fichiers de production que je vais mettre en ligne les incluent mais je vais mettre un encadré sur la carte proto
Merci !
-
Enfin un petit moment de loisir avec Locoduino ::) :-[ :-\
Voilà ce que je propose pour l'article 1, hardware (mais tu n'es pas obligé de tout intégrer):
- Ajouter les spécifications, les schémas comme dans ta première contribution (http://forum.locoduino.org/index.php?topic=125.msg893#msg893 (http://forum.locoduino.org/index.php?topic=125.msg893#msg893))
- Ajouter une figure du plan d'implantation avec les couleurs selon les fonctions (http://forum.locoduino.org/index.php?topic=125.msg1232#msg1232 (http://forum.locoduino.org/index.php?topic=125.msg1232#msg1232))
(http://forum.locoduino.org/index.php?action=dlattach;topic=125.0;attach=233;image)
- ajouter la liste des composants, avec un renvoi vers le Forum pour la liste des liens vers TME.
Avec tout cela, je pense qu'on ne peut pas faire plus exhaustif ;D
Ah si !
Une demande que j'ai trouvée intéressante dans mon club : un renvoi vers un site très bien fait qui décrit merveilleusement une commande par servomoteur avec, en particulier, des détails de réalisation mécaniques très intéressants : http://modelleisenbahn.triskell.org/spip.php?article35 (http://modelleisenbahn.triskell.org/spip.php?article35)
;) :D ;D
-
Une demande que j'ai trouvée intéressante dans mon club : un renvoi vers un site très bien fait qui décrit merveilleusement une commande par servomoteur avec, en particulier, des détails de réalisation mécaniques très intéressants : http://modelleisenbahn.triskell.org/spip.php?article35
Ah, que oui !!!
-
Ok, c'est noté. J'ai attaqué un 2e article pour ne pas surcharger le premier qui décrit la carte du point de vue de quelqu'un qui souhaite la connecter et que je complèterai avec l'utilisation du moniteur. Le 2e décrira l'électronique en détails et le 3e le logiciel.
Sinon, un nouveau problème que j'ai constaté hier (et je m'en excuse :-[)
Je me suis loupé sur le partage de l'entrée D4 entre le bouton CFG et l'optocoupleur commandant la surconsommation pour l'acquittement. Ce que je n'ai pas vu est que le fait de mettre la broche en INPUT_PULLUP pour lire le bouton fait circuler un courant dans la LED IR de l'optocoupleur.
La conséquence est que l'entrée D4 est en dessous de 1V (donc un état bas) que le bouton soit enfoncé ou non et donc le bouton est toujours vu comme étant enfoncé. Le bouton sert à faire démarrer la carte en mode configuration.
J'aurait dû partager une entrée plutôt qu'une sortie pour le bouton CFG.
Deux solutions :
1 - vous vous moquez de la fonction d'acquittement, il suffit de ne pas monter l'optocoupleur (le DIP 6 broches)
2 - vous voulez que ça soit pleinement fonctionnel, il faut modifier un peu la carte et re-câbler le bouton sur D2 (qui sert également à l'IT DCC) : 1) couper la broche 4 du bouton poussoir, celle qui est près du bord à côté de la résistance R4 pour séparer le bouton de la broche D4 de l'Arduino. 2) souder un fil fin (fil à wrapper si vous avez) entre la broche 1 du bouton poussoir et D2 de l'Arduino. Photos ci-dessous
-
Pour relever un peu le moral, un essai hier a permis de faire fonctionner un servo simultanément par I2C et CAN grace à ma librairie Commanders. 18 lignes de code utile sans rien de bien compliqué ! Je dois y ajouter le Dcc pour parfaire le test, mais j'ai un doute maintenant... Est ce que la carte est prévue (broches partagées...) pour supporter tous les modes simultanément ? J'envisageais même de brancher un poussoir sur la broche de mouvement d'un des servos pour y ajouter un élément Button de ma bib !
-
Il n'y a que le bouton CFG qui est partagé avec l'IT DCC (ou l'ACK si pas de modif)
Donc, pas de soucis pour brancher un bouton sur une broche servo si la broche en question est programmée pour gérer un bouton. À noter que les broches servo sont tirées à 5V via une résistance de 10k. Donc INPUT_PULLUP n'est pas nécessaire.
De manière générale, toute broche non raccordée à un autre circuit de la carte peut être utilisée pour un autre usage que celui prévu. C'est le cas des 8 broches pour les servomoteurs : 6, 7, 8, 9, A0, A1, A2, A3. Il vaut mieux laisser le SPI et l'IT_CAN tranquilles si le 2515 est en place. Si rien n'est branché sur le connecteur DCC, la broche IT_DCC peut être également utilisée.
La carte est prévue pour supporter tous les modes simultanément : CAN + DCC en même temps.
Ceci dit, les AVR 8 bits ne supportant pas les interruption nichées, c'est à dire qu'une interruption ne peut pas en interrompre une autre de plus faible priorité, plus il y a d'interruptions en route et plus l'IT DCC risque d'être imprécise. Par défaut il y a l'interruption du TIMER 0 qui sert à compter le temps (c'est là dessus que se basent millis(), micros(), delay(), ...). Il y a également la bibliothèque Servo qui utilise l'interruption du TIMER 1. Certe l'IT DCC est la plus prioritaire mais ça ne joue qu'en cas de concurrence avec plusieurs IRQ présentes simultanément. Si une IT de faible priorité est en court d'exécution l'IT DCC sera prise en compte avec du retard.
Je vois les choses comme ça :
1) on ne peut pas se passer du comptage du temps car le DCC l'utilise
2) on ne peut pas se passer de la bibliothèque Servo
3) on peut se passer de l'IT CAN si la carte est utilisée en DCC
Donc selon le mode DCC ou CAN on a
Mode DCC : pas d'IT CAN, IT DCC. Si rétrosignalisation, on a seulement de l'émission de messages CAN à un rythme assez faible (10 fois par seconde ?)
Mode CAN : pas d'IT DCC, IT CAN
Donc quoiqu'il en soit 3 IT actives
Les IT du TIMER 0 et du TIMER 1 sont assez courtes. Celle du CAN est très courte.
Celle du DCC me semble courte également.
Concernant le fonctionnement des servos qui, alors que la consigne est censée ne pas changer, bougent faiblement. Comme les interruptions ne sont pas nichée et qu'on a une IT externe de plus forte priorité (IT DCC > IT CAN > IT TIMER 1 > IT TIMER 0) la synthèse du signal de commande des servos subit un peu de gigue. Donc au lieu d'avoir un beau signal carré de x µs de large, on a un signal qui varie de x µs à x µs + durée de l'ISR externe +durée de l'ISR TIMER 0.
Le pire scénario est :
à t0, l'IT du TIMER 0 survient
à t0+dt, l'IT du TIMER 1 et l'IT externe surviennent (dt € [6,25ns, durée d'exécution de l'ISR du TIMER0])
Lorsque l'IT du TIMER 0 termine, on continue du l'IT externe et lorsque cette dernière termine, l'IT du TIMER 1 s'exécute.
La solution est d'arrêter de générer ce signal quand le servo a atteint sa position en appelant detach sur l'objet servo. C'est pris en charge automatiquement dans SlowMotionServo.
-
Bonjour à l'équipe Locoduino,
lors de mes différentes interventions sur le forum je n'avais pas pris le temps de lire toutes les pages (1814 + 1917 + 1560 + 697 + 155 encore heureux que ce ne soit pas dans l'autre sens :D) ce qui maintenant fait, parfois un peu en diagonale j'avoue.
J'ai du coup découvert que vous aviez déjà développé une carte 8 servos en 2016 et aimerais savoir où en est ce projet pour ne pas partir encore sur quelque chose qui a été abandonné entre temps. Je sais qu'il y a des "satellites" en cours de développement mais ce ne sont pas eux qui vont remplacer cette carte je pense.
Il serait idiot de développer quelque chose de mon côté alors que vos 'ingénieurs" l'ont déjà fait et bien mieux que moi, car je me laisse entièrement guider au niveau soft par vos réalisations.
Autre petite question à la communauté, je n'ai pas l'habitude des forums (c'est le seul auquel j'ai envie de participer), comment épingler un sujet particulier puisqu'il semble y avoir cette possibilité ?
Merci pour vos réponses et bon dimanche soir à tous (ici gros orages, je vais surveiller ma cave; oui je sais, ce n'est pas votre soucis mais je n'ai rien d'autre à vous proposer aujourd'hui :) :D ;D) )
Antoine
-
Bonjour et merci à tous pour vos réponses.
Désolé d'avoir accaparé votre temps pour ce genre de question, je vais continuer à mettre les pages les plus consultées en favoris.
Par contre la question ci-dessous reste sans réponse pour l'instant, pourtant elle me serait bien utile.
J'ai du coup découvert que vous aviez déjà développé une carte 8 servos en 2016 et aimerais savoir où en est ce projet pour ne pas partir encore sur quelque chose qui a été abandonné entre temps. Je sais qu'il y a des "satellites" en cours de développement mais ce ne sont pas eux qui vont remplacer cette carte je pense.
Il serait idiot de développer quelque chose de mon côté alors que vos 'ingénieurs" l'ont déjà fait et bien mieux que moi, car je me laisse entièrement guider au niveau soft par vos réalisations.
Bonne journée à tous
Antoine
-
Non Antoine,
La carte 8 servos est toujours d'actualité et la carte Satelite dont tu as eu vent d'une indiscrétion sera très bientôt décrite et ne rend pas obsolète la carte 8 servos.
-
Bonsoir à tous,
est-ce que l'un des utilisateurs de la carte 8 servos l'a déjà utilisé avec l'expandeur MCP2317 ?
Cordialement
Antoine
-
Bonjour,
J'ai fait le ménage et créé une section Vie du forum où sera discuté ce genre de choses. Essayer de ne pas digresser trop s'il vous plait
-
Bonjour
J ai quelques questions un peu "basiques" vous voudrez bien m'en excusez!
Est il possible de "modifier" pour avoir 4 AIG ET 4 relais dédies chacun à la polarisation de la pointe de cœur ( peut être la carte satellite aura cette possibilité?)
En effet, les servo c est bien, avec la polarisation des cœurs C EST BEAUCOUP MIEUX! (tout projet confondu!!)
Lorsque vous parlez de commande via le protocole CAN je n'ai pas identifié par quelle "magie" vous l'interfacez ( quelle interface, quelle déclaration dans le logiciel? aller au hazard avec un logiciel comme RRTC, par exemple...)
D avance merci pour vos reponses.
-
Oui, bien sûr, c’est possible de répartir différemment les huit sorties de cette carte 8 Servos , et les affecter à quatre servos et quatre relais.
Il est possible aussi d’alimenter les cœurs d’aiguilles à partir du même Servo qui commande l’aiguille, en ajoutant des contacts de fin de course.
Après, il faut évidemment adapter le logiciel.
Pour le bus Can, il faut vous reporter à l’article : http://www.locoduino.org/spip.php?article148 (http://www.locoduino.org/spip.php?article148)
L’interface Can décrite dans cet article est la même que celle qui est implémentée dans la carte huit servos.
Nous vous donnerons prochainement plus de détails pour ce logiciel Can à l’occasion de la réalisation d’une carte qui est encore en chantier.
-
Lorsque vous parlez de commande via le protocole CAN je n'ai pas identifié par quelle "magie" vous l'interfacez ( quelle interface, quelle déclaration dans le logiciel? aller au hazard avec un logiciel comme RRTC, par exemple...
Une question : RRTC propose-t-il une interface CAN ? Ou est-ce décrit ? (Je ne connais pas RRTC, réalisant le gestionnaire moi-même avec l’aide de mes amis de Locoduino, voir le site éditorial).
-
Bonjour
Non RRTC ne propose pas (encore) de prise en charge ( native ou via interface dédiée/particulière) d une interface CAN. Cela fait parti de developpements à venir ( un jour, peut être?!, mais déjà en cours pour intégrer ces éléments via les centrales les plus rependues qui en disposent ZIMO/ESU)
Mais quel CAN sera retenu?
- ROCO/ZIMO
ESU
CAN autre? ( type MERG?, autre?)
Tous?
Mystere!...
Yes we CAN.... certes mais... tout n est pas encore gagné!
Cela dit c est peut etre l'avenir?...
Pour le moment hors ZIMO et ESU (niveau indistrielle) en développement propriétaire sur leur BUS de communication CAN c'est plutôt desert. ( et fermé?!)
A chaque fois une centrale type DCC avec CAN bus sert de passerelle.( MX1, Z21, ECOS...) et les logicelles passe par cette paserelle.
Si des alternatives apparaissent et enrichissent l'offre cela sera intéressant. (et prometteur)
Laurent
-
Laurent,
c'est une réflexion en cours ici à Locoduino :D
Nous avons en tête l'échec commercial du standard LCC (https://openlcb.org/openlcb-and-lcc-documents/layout-command-control-lcc/ (https://openlcb.org/openlcb-and-lcc-documents/layout-command-control-lcc/)) qui a été adopté en 2015 mais qui n'a donné lieu à pratiquement aucune implémentation interessante, vue sa complexité et le surcoût induit. Mais je ne veux pas critiquer ce type d'effort qui reste louable.
Nous pensons qu'on peut probablement se contenter d'un jeu de messages Can bien choisis pour permettre de mettre en relation la plupart des périphériques dont nous avons besoin dans notre passion préférée.
En tout cas c'est ce que nous sommes en train de réaliser pour l'expo d'Orleans :
http://forum.locoduino.org/index.php?topic=515.0 (http://forum.locoduino.org/index.php?topic=515.0)
Venez nous voir !
-
Et bien, pour terminer positivement cette discussion, maintenant que l’expo d’Orleans est passée, le mieux est de se rendre sur les articles concernant les Satellites :
http://www.locoduino.org/spip.php?article242 (http://www.locoduino.org/spip.php?article242)
Et pour aller plus loin, avec le version V2, voir ou revoir la conférence de Jean-Luc à Trainsmania!
https://vimeo.com/ondemand/conferencestrainsmania/335340679 (https://vimeo.com/ondemand/conferencestrainsmania/335340679)
-
Bonjour à toute l'équipe de passionnés,
Je me suis lancé dans la réalisation de la carte mais je bute sur la partie logicielle, en effet la librairie CommandInterpreter ne fonctionne pas lorsque compilée avec l'IDE v1.8.13.
Existe-t-il une autre version que celle qui se trouve dans le fil de la discussion car mes connaissances en langage C++ sont basiques et ne m'ont pas permis de trouver ce qui ne va pas.
la version du sketch servoBoardCANDCC est V101.
Encore bravo pour la clarté et la richesse des articles qui m'ont incité à me lancer dans le DCC.
Patrick