Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - trimarco232

Pages: [1] 2 3 ... 23
1
Trucs & astuces / Re : Rétrosignalisation S88 et UNO
« le: novembre 08, 2024, 04:15:32 pm »
bien , peux-tu nous dire si cela fonctionne en panachant avec les modules S88 du commerce ?

2
Aide / Re : Choix de circuit de liaison entre écran et carte
« le: novembre 08, 2024, 12:29:09 pm »
Bonjour,
je pense que cette carte est l'oeuvre du fabricant des afficheurs miniatures
on doit pouvoir la refaire , et l'optimiser pour ton besoin , mais il faut savoir souder le lien souple du display sur cette carte
le montage avec la carte verte ne convient pas ?

3
Trucs & astuces / Re : Rétrosignalisation S88 et UNO
« le: novembre 08, 2024, 11:26:12 am »
merci (manque encore le code)
je ne connais pas ces breadboard , est-ce qu'on a les continuités au niveau des lignes de bus , telles que je les ai ajouté en rouge et en noir ?

4
Trucs & astuces / Re : Rétrosignalisation S88 et UNO
« le: novembre 07, 2024, 07:30:19 pm »
si l'interface usb  fonctionne avec les modules classiques , elle doit aussi fonctionner avec les arduino
le problème provient très vraisemblablement de ton programme ou de ton raccordement , il serait bien qu'à présent tu nous les montres

5
Trucs & astuces / Re : Rétrosignalisation S88 et UNO
« le: novembre 06, 2024, 11:46:20 pm »
amha , je ne pense pas que l'on puisse panacher des arduinos et des modules classiques sur le même port S88 , l'intérêt du projet est de tout remplacer par des arduinos ...
pour commencer , il faudrait raccorder l'arduino seul sur la centrale , tu l'avais fait ?



6
Trucs & astuces / Re : Rétrosignalisation S88 et UNO
« le: novembre 06, 2024, 07:58:38 pm »
au fait , qu'entends-tu par module précédent , c'est celui qui est + près de la centrale , ou celui qui est + près de la fin de chaîne ?

7
Trucs & astuces / Re : Rétrosignalisation S88 et UNO
« le: novembre 05, 2024, 05:22:28 pm »
cela doit fonctionner , alors on va tâtonner un peu , pour cerner le bug
peux-tu raccorder l'arduino à la place du dernier module S88 , pour voir ce que ça donne (laisser le dernier module de côté , pour l'instant) ?

8
Trucs & astuces / Re : Rétrosignalisation S88 et UNO
« le: novembre 04, 2024, 09:14:59 pm »
Bonjour,
peux-tu :
- nous communiquer ton code actuel
- nous dire comment son câblées , le cas échéant , le 15 entrées libres ?

9
Les résistances de gate de 1kR sont inutiles , car la résistance intrinsèque du mosfet de sortie de la broche de l'arduino est suffisante
En principe , il vaut mieux mettre les 1n4001 aux bornes du moteur , mais c'est en effet + pratique de les mettre sur le PCB , et cela donne une protection suffisante ; perso je mets un condensateur de 100nF / 100v en // sur cette diode , le but est d'absorber instantanément le début du pic de tension , le temps que la diode se mette à conduire pour prendre le relais (mais c'est juste intuitif , je ne sais pas en faire la démonstration)
Concernant la charge du condensateur (des + simples ici) , il faut s'assurer :
- que la résistance tient la puissance à dissiper
- qu'elle protège bien le moteur , en cas de commande intempestivement prolongée , aggravée par une non-fonctionnement du FdC ; ce non-fonctionnement peut être dû à un collage du contact , ou une translation empêchée d'aller à son terme
- que le condensateur soit suffisamment rechargé , avant d'émettre la prochaine commande

En cas de blocage de la commande , la résistance de charge débiterait directement dans la bobine , sous 18v on aurait 18ma soit 324mW : il faudrait utiliser des résistances de 1/2W ; dans ce contexte , la bobine , dont j'ai négligé la résistance dans ce calcul , ne risque rien
La recharge nécessite environ 2s (2x la constante de temps) , ce qui est normalement assez court
Le chimique serait + à l'aise avec une caractéristique à 35v

Donc pour moi , ton schéma est valable
Note que tu peux mutualiser le condensateur , en assurant le séquencement des commandes ; dans ce cas , le dispositif peut être amélioré par une charge à courant constant , voire une interruption de la charge par détection de consommation de courant

10
Bonjour Marc,

Je découvre ce fil avec un certain retard. Ce sujet est intéressant. Il a été effleuré sur un autre post assez récemment et j’avais moi-même acheté un certain nombre de ces micros moteurs il y a pas mal de temps avec, entre autres, comme idée que cela puisse piloter des aiguilles.
Bonjour Christophe , alors tu étais le 1er à en parler , donc tout ceci est de ta faute  :D


Je suis intéressé de suivre cela car tout d’abord tu adoptes des solutions qui sont aux antipodes de mes propres concepts :
merci pour l’intérêt

-   Commande au travers du bus DCC et décodeurs alors que tu connais ma position d’inconditionnel du CAN (et Ethernet). Et de réserver le bus DCC à la seule traction.
je suis bien d'accord avec cette approche , mais je voulais faire quelque chose que les autres puissent également réaliser et utiliser (même s'il semble que cela n'intéresse personne) : seuls les très grands réseaux nécessitent une préservation de la bande passante du DCC , et ils sont très minoritaires par chez nous
-   Concept de cartes spécialisées, 1 carte pilote 4, 8, x appareils similaires alors que je préfère l’idée de cartes généralistes à l’image des satellites. Une carte peut assurer plusieurs fonctions en input pour des capteurs en tous genres (dont RFID et/ou Railcom) et aussi en output, commandes d’aiguilles, de feux lumineux par exemple.
je pense que "mon" principe modulaire est entièrement compatible avec le principe de satellite : si tu as 3 sorties digitales disponibles , tu peux y ajouter mes cartes d'extension , en quantité qui colle au besoin du secteur du réseau desservi par le satellite

Mais je n’ai jamais prétendu qu’il n’y avait qu’une vérité et c’est pourquoi ça m’intéresse de suivre ton approche.

Je suis très intéressé de savoir comment tu as réglé mécaniquement le positionnement du moteur par rapport à l’aiguille : Sous le plan ? En surface ? Quel support ? Quel matériau ?  Impression 3D ? Quelles fixations ?
oui , ben moi aussi , je n'ai encore rien fait ; mon idée , c'est de faire un petit pcb sur lequel on fixera les petites vis du moteur ; les pads électriques du moteur seraient raccordé en fixe par des petits fils sur des petits pads sur le PCB , reliés à un connecteur où arrive le câble en provenance du décodeur ; le pcb serait lui même fixé sous la planche grâce à des trous oblongs ; il y aurait une fente dans le pcb pour le passage de la corde à piano . C'est la prochaine étape

Par ailleurs, tu dis que tu commandes aussi des moteurs tortoise. Cela implique quelques composants pour la puissance, (mosfets ?) et la protection des composants (diodes roues libres, condensateurs…). Peux-tu communiquer ton schéma électronique ?
les ponts en H utilisés ont tout ce qu'il faut pour commander directement des tortoises , il n'y aurait que le logiciel à compléter , pour l'instant , il ne sait faire que les PAP

Tu ne parles pas de solénoïdes, tu n’envisages pas du tout ce cas qui reste par exemple la règle chez Marklin ?
pour les solénoïdes je ne jure que par un système de décharge capacitive , y compris pour les moteurs munis de Fin de Course ; car c'est la sécurité absolue alors on enlève les FdC pour éviter qu'ils ne provoquent des pannes ; j'ai mis un tel dispositif à l'oeuvre pour le réseau du club , à la grande satisfaction des utilisateurs ; certes , je crois bien que mes cartes d'extension fonctionneraient avec des moteurs maerklin ou roco , mais il faudrait remplacer les ponts en H par des modèles de tension + élevée (ça n'a pas été conçu dans cette optique)

Bon je m’arrête là (pour le moment).

Plein de réussite pour ce que tu as entrepris.
merci et pareil

Christophe

11
En vrai , c'est (presque) mieux ; j'ai utilisé les 5 cartes d'extension que j'ai réalisé , pour faire le test , concluant , d'un décodeur pour 24 moteurs PAP , ou ... 48 moteurs MTB , tortoise , Conrad ...
On est à la limite du raisonnable , mais qui marche le plus , marche le mieux
Selon mes principes , j'ai fait une petite interface via la console arduino , ou un logiciel de console quelconque (pas ce CV chez moi : l'arduino a l'USB ! ) , on peut rapidement saisir l'adresse du 1er moteur , le nombre de moteurs , recycler l'arduino , et c'est fait
Les moteurs noirs sont moins chers , mais ils ont un chassis en plastique : il faut veiller à ne pas trop les solliciter , car le plastique ne participe pas à évacuer la chaleur du moteur , et se met même à fondre le cas échéant ... de + ces moteurs sont plus lents que les autres , à cause d'un pas de vis sans fin plus serré
Bien que les tests effectués ne stressent pas assez le système (je n'ai utilisé que 4 moteurs) , on a quand-même un très bon fonctionnement sur une chaîne qui s'approche d'un mètre de long , ce qui pour moi prouve la validité des conceptions matériel et logiciel : j'en suis satisfait (et soulagé ; c'est l'automne , les bugs viennent s'incruster dans les logements et dans les sketches)
Prochaines étapes :
- commande décalée des moteurs
- panachage moteur PAP et MTB (si demande)
- fixation et test de commande d'une aiguille

Edit :
les moteurs noirs (plastique) ont une translation de 1.2mm pour 5 secondes (par pas de 10ms) ; ils peuvent être alimentés en 3v7 , en conservant un couple suffisant
les moteurs métalliques (que j'ai) ont une translation de 3.6mm pour 5 secondes (par pas de 10ms) ; ils doivent être alimentés en 5v , pour avoir un couple suffisant ; le modèle à axes parallèles a une course de 3.2mm

12
Vos projets / Re : Rétrosignalisation avec centale Lenz
« le: octobre 13, 2024, 11:56:52 pm »
Bonsoir,
je pense que le mieux c'est de se passer de cette centrale pour la rétrosignalisation
on utiliserait un arduino pour faire une interface S88(par exemple) -> USB , et on renseigne le logiciel de gestion indépendamment de la centrale (donc ce logiciel devra accepter les 2 interfaces)

13
Trucs & astuces / Re : Rétrosignalisation S88 et UNO
« le: octobre 11, 2024, 11:26:50 pm »
Bonjour,
peut-être la librairie doit encore être installée ?

14
Des nouvelles du projet : les 1ers tests que j'ai pu faire sont concluants , alors je crois que le concept est viable (toutefois , il y a encore à résoudre la question de l'installation mécanique du moteur)
Le test a été réalisé avec 1 maître et 2 cartes d'extension
La vitesse de translation semble un peu faible : j'ai choisi un pas d'une durée de 10ms , on pourrait réduire pour aller + vite , mais ce serait au détriment de la force ; il faut peut-être réserver le principe aux petites échelles (TT , N , Z) , pour limiter la course , de manière à voir une durée de translation réaliste
Le décodage DCC avec la bibliothèque d'Aiko a fonctionné du 1er coup (y compris ma modif pour utiliser la fonction capture) , pareil pour la commande des ponts en H situés sur la carte maître
Mais j'ai perdu 1/2 journée sur la programmation de la commande des cartes d'extension , à cause d'un double bug conjugué , dont je suis (presque) entièrement responsable :
- une erreur d'offset entre un segment de RAM et son pointeur , c'est classique , mais même mis en évidence par l'analyseur logique , je n'ai pas voulu l'admettre , car bêtement persuadé que je n'avais pas pu me tromper sur ce point
- j'ai voulu absolument utiliser le périphérique SPI pour commander les 74HC595 , car c'est efficace et ... élégant ; mais quand on met le SPI en fonction , la broche MISO se met fatalement en INPUT (amha une tare dans le dessin de l'AVR (que j'avais oubliée) , pas la faute d'Arduino) , or j'utilise cette broche en OUTPUT , pour commander le fil Latch des 74HC595 ... j'ai été sauvé par ma conception des cartes d'extension , qui pour contenir les parasites , terminent le fil Latch sur une résistance reliée au +5v ; ainsi , quand le SPI fonctionne pour transférer les données vers les 74HC595 , le Latch reste gentiment en position HIGH ; à la fin des transferts SPI , (en fait au début , juste avant le démarrage des transferts suivants) , je désactive le périphérique SPI , ce qui permet d'avoir le Latch en OUTPUT , pour envoyer une courte impulsion LOW ; puis le SPI est réactivé (juste écrire un octet dans son registre) , ce qui remet le Latch en INPUT , la résistance le tire vers HIGH , et c'est à ce moment que le Latch est effectif
Un mot concernant le coût : j'en ai eu , port et montage des composants CMS compris , pour 90€ chez JLCPCB , pour 10 cartes maîtres et 5 cartes d'extension ; il faut rajouter 60€ de composants "through hole" (arduinos , supports , connectique , condensateurs , zener) , à monter soi-même , ce qui fait ~10€ la carte finie (+précisément 11€ la maître , et 9€ l'extension , car il y a en + l'arduino à 1€50 et l'optocoupleur à 0€50) ; je précise que ces prix comprennent les composants cms , fournis et soudés sur les cartes par jlcpcb
On en est revenu (peut-on s'en réjouir ?) aux prix délirément bas d'avant la pandémie , comme vous pouvez le voir ici :

15
Composants / Re : Raspberry PI Pico : Difficultés de mise en œuvre.
« le: septembre 26, 2024, 11:41:36 pm »
oui , mais avec le pwm , je sais faire ; le pio , j'avoue ne pas m'être donné la peine de creuser le sujet ; car amha , il vaut mieux réaliser le dcc avec le pwm , et réserver le pio pour d'autres interfaces , notamment s'il y des signaux à traiter en entrée (can , loconet , sniffer ...)
c'est d'ailleurs pour cela que je suis adepte du stm32 : dcc , loconet , sniffer , fastoche avec les timers , et pour le can il y a un périphérique dédié

Pages: [1] 2 3 ... 23