Levée de boucliers!

[trimarco232]

Bonjour Laurent,

merci pour le partage !
je trouve ces modules remarquables (j'essaie aussi de faire de beaux pcb), mais - comme d'autres - je m'interroge quant-à la pertinence de la démarche

le but est sans doute de réaliser quelque chose dont tu as besoin ou (et) envie, de le partager, de demander - et obtenir - l'aide nécessaire pour la réalisation des logiciels. Rien à redire pour ce qui me concerne

une autre approche aurait été de solliciter en amont les avis des forumistes, afin de faire correspondre si possible ton projet aux attentes de certains, et aussi - on ne sait jamais- recueillir de bonnes idées à y ajouter
il y a beaucoup de choses à discuter : synoptique global, interfaces avec des choses existantes, connectique. S'il nest jamais possible de satisfaire tout le monde, car chacun a naturellement sa propre conception en fonction de ses goûts et ses possibilités, on peut quand-même progresser sur des compromis

ainsi, si certaines choses me paraissent formidables, comme la platine de commande avec cdu incorporé (je n'ai pas vu la diode de décharge des condensateurs ?), d'autres me laissent interrogatifs, comme les cartes de commande de relais, de leds ou de signaux pwm, qui existent déjà sous forme de modules tout faits, et a des prix défiant toute concurrence

je pense par conséquent qu'il serait bien qu'au moins tu expliques les raisons de tes choix et que tu donnes les schémas de tes montages (déjà demandé)
-> pas de souci, mon humble avis importe peu, tu peux très bien continuer à faire comme tu l'entends, je (et nous tous, je pense) serai toujours heureux de pouvoir te lire

[laurentr]

Bonsoir

Comme je l ai expliqué je me suis basé sur une base connue qui est ARCOMORA.

La CDU est une extrapolation de la CDU du MERG et de son décodeur d accessoires.

J ai par contre repris toute la base hard pour la moduler selon des concepts approfondis sur mes réflexions en la matière ( rationalisation, standardisation de composants, extensions...) tant de mes besoins que ceux d autres dont je veille aux intérêts à disposer de quelque chose qui fonctionne et qui soit simple à mettre en œuvre.

Depuis une base commune avec 2x8 entrées/sorties du NANO ( ou du 328P) on peut utiliser des extensions de plusieurs types
commande de leds  (pour signaux par exemple)
commande de relais
commande de bobines d aiguillages (forte puissance)
commande de servo moteurs

utiliser des modules existants n offre pas cette modularité avec un coté "intégré" et laisse alors un câblage volant entre les blocs fonctionnels qui consomme de la place,... ce n est volontairement pas mon approche pour éviter un "bazar"

LE choix de l'interface de commande  "DCC contre le CAN" est évident à ce stade: toucher le plus grand nombre de prospects pouvant utiliser ces modules... avec des centrales (indus ou home made en DCC)
C est une autre approche de la version satellite V2 avec une partie des finalités (usages) communs. Le jour où existeront
un passerelle CAN/DCC DCC/CAN et DCC protocoles de retro signalisation+ une IHM de mise en œuvre d approche "simple d utilisation" alors la supériorité des satellite V2
 sera démontrée.
Coté simplicité de mise en ouvre cela sera toujours plus élaboré mais la trame sera beaucoup plus simple pour le plus grand nombre.
Je doute raisonnablement que le SAM (n co) du satellite V2 "passionne les foules" en dehors d un noyau dure de "sachant"... Bien que le travail derrière soit colossal également.

Mon approche c est voulu beaucoup plus humble, simple, large et ouverte pour s adresser au maximum de personnes.

Pour les personnes qui passeront à l exposition SALON DU TRAIN de MAUBEUGE les 14 et 15 SEPTEMBRE 2019 à l Espace SCULFORT, elles pourront découvrir nombreuses de mes réalisations et éventuellement les acquérir.

Laurent

[trimarco232]

j'ai regardé un peu + près ARCOMORA, cela me semble en effet une très bonne idée, je dirais presque l'invention d'un chaînon manquant dans un monde ou ça part - peut-être un peu trop - dans tous les sens ...
les 3 points forts sont amha :
1) paramétrage à la portée de tous (comme pour un produit du commerce), sans IDE ni connaissance arduino ou autre
2) ciblage restreint à des appareils populaires : décodeur multifonction ou de signaux, encodeur loconet. Le choix de loconet me parait judicieux, car il est populaire et assez complet
3) (en l’occurrence) offrir des solutions matérielles à des prix quasi dérisoires, basées sur des clones arduino + shield ad-hoc, ou bien le kit DCCnext, qui, (même si ça fait drôle d'y voir un mcu en boitier dip*) me paraît particulièrement bien né


je voudrais revenir sur le point 1). Le concept permet d'ouvrir le monde du diy aux non-programmateurs : dans l'idéal, il serait bien qu'il soit applicable à tout projet se basant sur arduino ou autre !
je note que pour autant les schémas et les .ino sont communiqués, ce qui rassure certains
je laisse en dire + à ceux qui ont déjà testé la chose ...


*ça fait vintage, il me semble que l'atmega8 à 20 ans

[trimarco232]

pour en revenir au projet de Laurent :
- d'abord merci de m'avoir répondu !

il serait bien que tes modules puissent être paramétrés selon le concept "à la portée de tous comme ARCOMORA"
c'est peut-être automatiquement le cas, je n'ai pas encore regardé + en avant

j'ai notamment une question concernant le décodeur à cdu :
- peut-on le paramétrer pour que si les commandes arrivent en même temps, on obtient en fait une commande séquentielle des aiguilles ?
- le temps de recharge du cdu dépend de la consommation de chaque moteur et de la puissance de l'alimentation. Il est donc variable. Peut-on paramétrer le temps séparant 2 commandes pour pouvoir laisser le temps de recharge, qui est particulier pour chaque installation ? 

[laurentr]

Bonjour

1/ Comme pour le moment ils fonctionnent 100/100 avec le code ARCOMORA, leur initialisation est donc très simple d approche ( l'interface est la mème!)

Nous travaillons dans ce fil a produire une fonction similaire qui gérera spécifiquement  la partie signal SNCF avec toutes les combinaison possibles ( ce que ne fait pas et ne fera pas l ARCOMORA) en traitant 2 signaux affichant des cible G avec œilleton.

2/Pour le CDU c est le pilotage d'envoi des ordres (PC+logiciel ou toi!) qui doit tenir compte de ce paramétrè. Le module lui ne porte pas cette "intelligence" il applique en FIFO les ordres reçus dès réception.
Ainsi par exemple sous RRTC tu as une fonction qui te permet de choisir le délai entre 2 ordres consécutifs d envoi d ordres de commandes pour les aiguillages.
avec 1.5 1.8 Sec on doit assurer le coup! ( on peut monter un peu plus ce qui aura pour seules conséquence d avoir des itinéraire complexe plus log à déployer au complet, mais c est aussi le cas dans la réalité donc.. jouable!)
Pour rappel il est d usage aussi de positionner un léger délai d envoi des instructions DCC de l'ordre de 350ms
Le montage de la CDU que j ai implementé ne "pilote" que 4 paires de "coils"
Actuellement avec 4400uF je vais voir pour monter cette capa et identifier si cela permet des cycles d envois plus courts des ordres de commutation successifs. ( et inversement pour trouver un optimum)
Avec un temps plus bref j ai parfois assisté à des non basculements des bobines.

Laurent

[laurentr]

Le code de la fin de SignalArduinoPattern::beginSignal() entre balises VISUALSTUDIO m'a servi à tester en balayant à intervalles réguliers toutes les combinaisons actives.
Si tu enlèves le #define, tu pourras aussi essayer en vrai ce que ça donne, sans avoir encore le décodage DCC...

Bonjour Thierry

Heu... un peu trop "dure" pour moi de comprendre la signification exacte de ton propos ( peut être un petit tips supplémentaire me permettra de bien maitriser la manip!)

Tu as peut etre progressé de ton coté sur la suite du code pour intégrer la gestion des adresses DCC en // des états et de leur affectation?

de mon coté comme tu as pu le voir sur les photo le "hard" est prêt et il fonctionne bien comme attendu! ( reste donc cette partie signaux complexe SNCF à "sortir"...

Laurent.

[trimarco232]

avec 1.5 1.8 Sec on doit assurer le coup! ( ... )
Pour rappel il est d usage aussi de positionner un léger délai d envoi des instructions DCC de l'ordre de 350ms
( ... )
Actuellement avec 4400uF je vais voir pour monter cette capa et identifier si cela permet des cycles d envois plus courts des ordres de commutation successifs. ( ... )

sur le réseau du club, sur une quarantaine d'aiguilles avec moteur peco, commandées par 1 seule cdu munie d'1 seul condensateur de 2200uF, toutes fonctionnaient sauf 1. Je n'ai jamais compris pourquoi... , d'ailleurs, allonger le temps de conduction ne servait à rien (je suis à 150ms). Je me suis contenté d'ajouter une 2ème capa (emplacement prévu sur le pcb ) et là tout fonctionne
EDIT : la cause a été touvée : la gachette du mosfet commandant cette aiguille était mal soudée ; la commande se faisait sans doute par couplage cacitif ou par résistance de très forte valeur ... soudure refaite, le fonctionnement est nickel, la 2ème capa a pu être définitivement retirée
mon expérience n'est peut-être pas directement transposable au cas général, car j'ai 24v au départ, ce qui fait que mon condensateur a + d'énergie

pour résoudre le problème du temps de recharge du condensateur de la cdu, temps de recharge qui donc varie selon la puissance de l'alim et la profondeur de décharge (elle même variant selon la consommation du moteur) (j'espère être compréhensible), l'arduino lit tout simplement la tension aux bornes du condensateur, et ne déclenche la commande suivante que quand il est rechargé. Avec une alim de 3 ampères, (ce qui est trop), la recharge est ultra rapide, donc un itinéraire d'une dizaine d'aiguilles est mitraillé en moins d'une seconde

le réseau est analogique, ce qui nécessite une alimentation dédiée pour les commandes d'aiguilles. Mais même pour un réseau digital, il vaut mieux une alim dédiée, car la recharge de la capa risque d'écrouler le signal dcc. Si la recharge devait se faire par le signal dcc, qu'il soit dédié aux accessoires ou pire utilisé pour les rails, il faudrait pouvoir limiter / régler le courant de recharge pour éviter le pic de consommation, ce que, me semble-t-il, les concepteurs des cdu du commerce ont négligé
(et moi aussi, mais j'ai prévu une grosse capa pour garantir la continuité de l'alim de l'arduino)


voilà, j'ai dit ce que je sais, en espérant avoir pu t'éclairer