Levée de boucliers!

[laurentr]

Bonjour

Cela fait un moment que cela cogite dans tous les sens... alors il faut bien produire un petit quelque chose!

Dans les grandes lignes je me suis inspiré de nombreuses lectures sur le net, ici même mais aussi sur les "bonnes adresses" qui vont bien pour ingurgiter" digérer et produire!

Je vous présente donc modestement le fruit des ces nombreux efforts et heurs passées à ces réalisations.
N étant pas du tout un champion de la ligne de code je me suis surtout borné à travailler sur la HARD, et faute d(avoir un "soft maison", j ai repris ici et la quelques très bon exemples qui vont permettre de donner vie au HARD.

J informe qui le veut bien que la ré écriture de ces codes, voir leur reconstruction (évolution etc) sera la bien venue afin d être "sans attache" avec le travail de qui que se soit des codes d'origine.

Sur le modèle des "cartes satellites V2" mais avec une tout autre approche orientée Accessoire DCC et sur les modèles développés par
Geoff BUNZA https://model-railroad-hobbyist.com/blog/geoff-bunza
Nico TEERING (ARCOMORA) https://www.arcomora.com/
MERGE https://www.merg.org.uk/
...

Fidèle à ma philosophie de relier les monde existants* (voir ce sujet: http://forum.locoduino.org/index.php?topic=803.0 j ai donc repris "le meilleur" pour réaliser un ensemble de "BOUCLIERS" complémentaires ( cartes diverses) ayant chacune des affectations techniques dédiées.
Chacune se veut simple à réaliser (composants traversant à 99%), robuste, évolutive dans la partie logicielle ou avec des composants substituables selon les provenances, stocks...

• BOUCLIER DE BASE: support de l'Arduino/ATMEGA328P, gestion des alimentations, du signal DCC et des connecteurs d'extension vers les autres bouclier
  BOUCLIER SERVOS pouvant gérer la connexion de servos jusqu'au nombre de 8.
  BOUCLIER RELAYS pouvant gérer jusqu à 8 relais.
  BOUCLIER RELAYS DC ( double bobine), jusqu à 4 relais double bobine
  BOUCLIER BIG COILS avec CDU pour traiter 4 paires de bobines de forte consommation type PECO intégrant une décharge capacitive (CDU)
  BOUCLIER EXTENSION SIGNAL socle de liaison aux signaux type DECAPOD et autres

Tout d abord le BOUCLIER DE BASE:

Basé sur un design repris d'ARCOMORA et du SMA, il combine une régulation DC 5V (ou 6V) provenant au choix du signal DCC ( option à ne pas privilégier mais possible! ce qui évite de parfois retirer des kilomètres de câbles dans un coin perdu du réseau ou seul passe un FEEDER DCC! Quelle chance!) ou source extérieure de 9 à 18V AC ou DC.
Le traitement du signal DCC vers l'ARDUINO
2 connecteurs "normalisés" indiqués "BAS" et "HAUT"avec une source poistive "+5V" = 4V4 ou 5V selon le régulateur 7805 ou 7806 mis pour la gestion de l alimentation, une MASSE = "GND" et 8 entres sorties numérotées "1","2","3","4","4","5","6","7"et "8" pour la partie "BAS" et de "9" à "18" pour la partie "HAUT"
Nous le verrons plus loin... cette répartition en 2 groupes de 8 n' est pas "innocente" et permet de s'affranchir de nombreuses combinaisons d'usage.
Monté, testé, croquis chargé, paramétré il fonctionne à merveille! (avec une extension de pilotage simple de LED en TOUT ou RIEN sur chaque sortie par exemple)

J attends à ce stade la réception d ici la fin du mois des autres BOUCLIERS actuellement en transit pour poursuivre les montages... et les tests!

Dans cet intervalle, pour ceux qui auraient un peu de temps libre pour cogiter sur quelques lignes de codes qui vont bien... le HARD serait preneur d un code lui permettant de traiter 24 ou 32  (voir plus) combinaisons d affichage des 8 sorties de leds à partir d une commande DCC type ACCESSOIRE pour des signaux type SNCF mais aussi autre ( SNCB, DB , NL, RENFE,...) ( la dernière entrée effaçant l'état précédent, chaque sortie peut être gérée en ÉTEINT, FIXE, FLASHING, et avec graduation progressive montante et descendante (simulation inertie lampe à filament)...

Avis au talentueux!
La suite(tres) bientot...

Laurent

[laurentr]

Autres vues des CI en situation

[laurentr]

Pour "guider " un peu la réalisation du code du décodeur de signaux (complexes) et ce qui me semble être "le truc qui cartonnera",
J essayerai de décrire des blocs algorithmiques qui  me semblent nécessaires sur les fonctions attendues:
 ex
saisie de l adresse de base du décodeur ou du premier numéro de sortie accessoire piloté
saisie du nombre de combinaisons d affichage et déduction du nombre d adresses d accessoires DCC requis ( pour mémo 1 adresse Accessoire DCC= 4 états différents (combinaison d affichages))
saisie du nombre de feux concernés
affectation d'un état à une sortie (éteint, allumé, clignotant)
vitesse de clignotement
vitesse de montée
vitesse de descente
intensité lumineuse

et dans la mesure du possible une petite liaison type IHM qui soit "conviviale" comme pourquoi pas une interface PUTTy comme sur ARCOMORA?
Un beau projet en somme...

Les bases sont la!
Y a plus qu à!!

[Dominique]

Bonjour à tous,

J’ai passé un bon moment avec Laurent au téléphone pour comprendre cette architecture et, en particulier, comment elle se positionne par rapport aux satellites que nous nous avons commencé à décrire dans la version V1 dans les articles, et la V2 à Trainsmania.

Je dois dire qu’il y a à la fois de grosse différence et en même temps beaucoup de points de convergence.
Les points de convergence sont dans la diversité des interfaces avec des appareils de voie (signaux, relais, aiguilles, etc..). Laurent est un pro du circuit imprimé et ils nous a montré ses talents à Lille, en visite sur notre stand.
Il est demandeur coté logiciel et c'est là sans doute que les convergences avec les satellites vont se faire naturallement.

D’abord, les différences : les boucliers de Laurent sont principalement des commandes d’accessoires à partir du signal DCC, inspirées des meilleurs sources (Rudy Boer, SMA de Geoff Bonza, Arcomara et MERG - qui utilise d'ailleurs le bus Can ausi). Alors que les satellites s’interfacent uniquement à un bus Can. Selon Laurent, la grande majorité des modélistes qui souhaitent piloter des accessoires le font à partir du bus DCC par ce que les centrales du commerce ne transmettent que du DCC à partir des gestionnaires de réseaux. Il suffirait d’une passerelle DCC vers Can pour que le satellites soit tout à fait compatibles avec les commandes DCC.
Une autre approche serait d'interfacer les gestionaires avec le bus Can (on pens d'abord à JMRI avec la passerelle C/MRI). Je ne mentionne pas encore les interface Can avec les gestionnaires les plus populaires, qui vont y venir de toute façon.

La démarche de Laurent est de rendre service aux modélistes "déjà équipés" d'une centrale du commerce et veulent éviter de s'équiper de décodeurs d'accessoires chers.

Donc Laurent est prêt (je le pense fortement) à contribuer sur Locoduino avec son talent du HARD et nous allons faire en sorte que le SOFT fasse le  trait-d'union. Il a d'ailleurs plusieurs flèches à son arc, notamment les décodeurs Railcom déjà évoqués et d'autres choses utiles que nous découvrirons.

Un conseil : pour rendre plus compréhensible les présentations des cartes (Boucliers), il serait bien d'adjoindre des schémas.



Amicalement
Dominique

[Dominique]

je n'avais pas vu la contribution de Laurent ici :

http://forum.locoduino.org/index.php?topic=803.msg8741#msg8741

[msport]

... adjoindre des schémas.

Effectivement, impossible d'écrire une ligne de code sans schéma ...

[laurentr]

Bonjour

Pour pallier au plus rapide voici ( faute de dessiner exactement le schéma du PCB réalisé)  la source qui m'a servie pour cette série de boucliers.
Les autres boucliers sont des extensions d utilisation vers des relais, des servos, des leds, des MOSFET, des transistors...

Le BOUCLIER de BASE est une adaptation de ceci avec des options d'alimentation multiples des extensions, et une répartition des sorties en 2 groupes de 8.
Je dessinerai rapidement le schéma correspondant.

https://www.globalvisuals.nl/downloads/Instructions%20de%20montage%20DCCNext.pdf

Plus de détails sur le site éponyme https://www.arcomora.com/ et les excellentes notices qui y figurent (dont versions FR). (rubrique download)

Laurent

[laurentr]

Bonjour

Merci Dominique tu as très bien résumé notre échange et le positionnement pris.

Je compléterai le propos avec quelques précisions pour que tout le monde comprenne bien de quoi on parle:

Les gestionnaires de réseaux sont les logiciels de pilotage des réseau tels que RRTC, CDM-RAIL, ROCKRAIL, JMRI, WINDIGIPET,...
de diffusions commune rien n empêche également des logiciels "maison" des lors qu ils adressent via le protocole DCC les ordres de commandes attendus.

Les accessoires pilotés par le bus DCC le sont par tous les types de centrales industrielles du commerce ou les projets "libres" basés sur ARDUINO ou d'autres composants et supportant la prise en charge du protocole DCC NMRA.

Dire que je suis un professionnel du HARD est un pas que je ne me risquerai pas à franchir! (ma femme non plus!)
Avec plus d'une centaines de réalisations "en amateur éclairé", les retours d'expériences me permettent d être un peu à l aise avec cette partie, mais comme tout le monde il m'arrive encore de commettre quelques erreurs qui vont alors "nourrir" la poubelle!

Une passerelle DCC <==> CAN voila qui aurait un certain panache!!! bien qu il faille ensuite absolument une IHM (Interface Homme Machine = en gros une belle page sur laquelle on configure simplement des trucs compliqués par des icônes simples qui masquent la complexité des codes, variables, ...)  pour la customisation des éléments.
Un premier exemplaire de cette passerelle devrait selon moi récupérer de la trame DCC uniquement les messages à destination des accessoires (dont l’entête du message va être en "128"... ) (sens DCC vers accessoires via CAN) le sens retour lui reposera sur CAN vers des protocole normalises de retrosignalisation tels LOCONET, RS LENZ ou S88n pour les plus courants...

Laurent

[Dominique]

Oui il y a bien 2 sujets :
1) Une passerelle DCC-Can uniquement pour les accessoires, donc un parser DCC qui convertit les ordres DCC en ordres Can pour commander les accessoires reliés aussi Satellites V1 ou V2 (n’oublions pas que les satellites remontent aussi de la retrosignalisation sur Can, ce que ne peut pas faire le DCC.
2) la configuration du réseau (sa topographie) et ses composants ( butées, vitesses, intensités, temps de montée et descente, etc...qui sont adressés par des bibliothèques Locoduino (SlowMotionServo et Lightdimmer entre autres, qu’il serait dommage de ne pas s’en servir). Faire de l’IHM (a fortiori graphique) consomme énormément de place mémoire programme et ne sert généralement qu’une fois à la mise en œuvre des éléments. C’est pour cela qu’il existe des gestionnaires de réseau sur PC que tu cites très bien, dont certains sont onéreux et demandent un temps d’apprentissage et excluent souvent les débutants.
Avec le bus Can, on peut déporter la configuration hors du satellite (j’ai commencé un article sur le configurateur que je dois terminer). Un même Arduino avec une interface Can et un écran simple et quelques boutons peut configurer des tas de cartes simplement en installant des logiciels dédiés, chaque carte gardant sa configuration en eeprom.

Il y à de quoi discuter tout cela,  avec l’avis de tous !

[msport]

Je ne sais pas si créer les PCB avant le soft est la bonne méthode.
En tout cas Rudy Boer a écrit de nombreux softs pour faire des décodeurs de toutes les moutures avec des Arduino Nano.
https://rudysmodelrailway.wordpress.com/software/
puis
https://www.dropbox.com/s/qkhrc147m38llb9/Arduino_DCC_S88.zip?dl=0

Il utilise l'interface de Mynabay comme Arcomora. Cette interface a déjà été évoquée dans ces pages (avec son petit condensateur sur le 6N137 à rajouter)
On a donc des satellites dont le bus de données est le DCC lui-même.
Un PCB a été développé en son temps avec des ULN2803. Ce PCB avait complété un projet de détecteur.

[laurentr]

Bonjour

Voici une trame décrivant ce que l on peut attendre du décodeur d accessoires pour la commande d un signal.


1/Choisir le nombre de combinaisons d’affichages possibles (ce nombre pour simplification doit être un multiple de 4) (ex 24 ou  32)( pour se caler sur les multiples des adresses de base)
2/indiquer les sorties utilisées pour l’affichage des combinaisons (pinoutgroupe= pin XXX pour le groupe 1 et XXX groupe 2
(Pour commencer 8 out pour le groupe 1 et 8 out pour le groupe 2)
(* pour économiser des adresses il pourra être utile d’optimiser l’algorithme pour enchainer les combinaisons de sorties avec moins de 8 feux avec les groupes d’adresses différents)
3/choisir l’adresse de base du décodeur d’accessoires (de 1 à 511)
Chaque groupe de 4 combinaisons correspond à une adresse accessoire soient aussi 2 sorties de 2 états
Qui sont respectivement :
•   0,0
•   0,1
•   1,0
•   1,1

L’adresse de base est incrémentée de +1 pour chaque nouveau groupe de 4 états utilisés.
Prenons ainsi la convention de notation suivante
Accessoire numéro X (notation administrative pour aider au repérage); Adresse de base ; numéro de sortie ; sortie état (actif/non actif= fait partie de la combinaison désirée ; l’état de la sortie sera paramétré plus tard au cas par cas))
Ex :
•   [1 ;1 ;1 à N ;1 à 16 ;0 ou 1]
•   [1 ;2 ;1 à N ;1 à 16 ; 0 ou 1]
•   [1 ;3 ;1 à N ;1 à 16 ; 0 ou 1]  ici 12 combinaisons possibles pour l’accessoire 1 qui occupe les adresses de base accessoires de 1 à 3 ce qui corresponds aux états des sorties de 1 à 12.
•   [2 ;4 ;1 à N ;1 à 16 ; 0 ou 1]  ici 1 combinaison possible pour l’accessoire 2 qui occupe l’adresse de base accessoire 4 ce qui corresponds aux états des sorties de 13 à 16.
A noter que sauf exception les sorties ne doivent appartenir qu’à 1 accessoires sinon leur état sera commandable par 2 adresses différentes ce qui peut entrainer des erreurs d’affichage. (ou permettre des combinaison inédites… !)

4/État des sorties actives
Il s’agit de définir les combinaisons possibles des N sorties utilisées avec X modes possibles avec les états possibles pour chaque sortie
•   ON (mode1)
o   Définir le Fading ON (paramètre mode1)
•   OFF (mode2)
o   Définir le Fading OFF (paramètre mode2)
•   FLASH (mode3)
o   Définir la fréquence du mode de clignotement (pour chaque out concerné) (paramètre A mode3)
o   Définir le Fading ON du flash (paramètre B mode3)
o   Définir le Fading OFF du flash (paramètre C mode 3)
•   ON après x secondes (pour décalage temporel) (mode4)
o   Définir la durée de décalage avant chaque ON (paramètre mode4)
•   OFF après y secondes (pour décalage temporel) (mode5)
o   Définir la durée de décalage pour chaque OFF (paramètre mode5)
On a donc  à remplir pour chaque sortie un état avec son/ses paramètres

5/Combinaisons des outputs
Pour chaque combinaison indiquer l’état et le mode

5/fonctionnement
L’appel à 1 combinaison d un accessoire efface toutes les autres (à un instant T il n y a qu’une combinaison active)


Voila déjà une base intéressante qui offre de très nombreuses possibilités...

A vos lignes de code!

J m'occupe de dessiner le schéma électrique correspondant.

Laurent

[laurentr]

Bonjour

quelques compléments que j avais oublié précédemment

• durée du flash F réglable en ms
  la possibilité d'inverser 2 états
  la possibilité de faire une bascule entre deux sorties
  et par extension la possibilité de gérer des servo-moteurs
  ... d autres bonnes idées à venir mais je pense avoir fait le tour des principales!

Des avis et suggestions?

Laurent

[Thierry]

Pour la partie codage, je signale l'existence du couple de bibliothèques Commanders/Accessories dont la raison d'être est justement le décodage DCC (entre autres) pour la première, et le pilotage de Leds et moteurs au sens large pour la seconde. Toutes les possibilités de paramétrage existent déjà, depuis le light dimming similaire à celui de Jean-Luc, en passant pas la gestion de feux complexes ou le paramétrage des durées de clignotement. Pour les moteurs, les solénoïdes, les moteurs classiques et les moteurs pas à pas sont gérés... De même que les servos.
Commanders de son côté utilise depuis peu la librairie NmraDcc pour le décodage, ce qui lui permet de fonctionner aussi bien sur un AVR qu'un ESP ou un STM...
Et comme l'auteur de ces bibliothèques est gentil, si on lui demande poliment, il pourra ajouter ce qu'il manque et fera ainsi évoluer son produit !

[laurentr]

Bonjour Thierry


Je ne dits pas que tt ces fonctionnalités n'ont pas déjà été écrites et ne sont pas " à disposition" pour adapter aux besoins du "cahier " des charges présenté en quelques lignes avant.

Allumer éteindre des leds parait simple comme "blink" mais ca devient plus "touchy" des lors que tu combines avec des adresses DCC, des combinaisons d'affichage, des états particuliers, des groupes de leds sur des plages d adresses... Et la tu as deja perdu beacoup de monde!

c est plus la combinaison optimale avec une facilite maximale de mis en oeuvre qui est attendue... ce que réussit très bien la gamme de produits ARCOMORA dont je pense qu il faut s inspirer à la sauce LOCODUINO et "Frenchy"!

Je reste encore un peu "hermétique" au code pour "la bonne cause" en ne posant que les bases et en restant sur le HARD.

Apres je pense qu il faut pouvoir apprécier les apports de tt les bibliothèques, avantages, inconvénients, taille prise en mémoire par les programmes...

Ce qu on devrait pouvoir obtenir in fine me semble intéressant à caresser...

Laurent

[Dominique]

La bonne cause ne peut pas être le HARD sans SOFT, ni le SOFT sans HARD 
Il faut attendre de voir les schémas puis évaluer le soft d’Arcomara. Après chacun pourra se faire une idée. Il y a pas mal de contributions sur Commanders et Accessories qui prouvent que c’est un soft pratique et surtout bien supporté par Locoduino (oui Thierry est très gentil  ).
Peut-être que tes cartes seront un bon exemple d’application, j’espere
Le sujet est intéressant, donc, à suivre ...

Dominique