LOCODUINO

Parlons Arduino => Vos projets => Discussion démarrée par: laurentr le août 08, 2019, 12:30:31 am

Titre: Levée de boucliers!
Posté par: laurentr le août 08, 2019, 12:30:31 am
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 (https://model-railroad-hobbyist.com/blog/geoff-bunza)
Nico TEERING (ARCOMORA) https://www.arcomora.com/ (https://www.arcomora.com/)
MERGE https://www.merg.org.uk/ (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 (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...

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


Titre: Re : Levée de boucliers!
Posté par: laurentr le août 08, 2019, 12:31:21 am
Autres vues des CI en situation
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 08, 2019, 12:49:38 am
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 à!!
Titre: Re : Levée de boucliers!
Posté par: Dominique le août 08, 2019, 09:37:26 am
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
Titre: Re : Levée de boucliers!
Posté par: Dominique le août 08, 2019, 09:43:08 am
je n'avais pas vu la contribution de Laurent ici :

http://forum.locoduino.org/index.php?topic=803.msg8741#msg8741 (http://forum.locoduino.org/index.php?topic=803.msg8741#msg8741)
Titre: Re : Re : Levée de boucliers!
Posté par: msport le août 08, 2019, 09:44:29 am
... adjoindre des schémas.
Effectivement, impossible d'écrire une ligne de code sans schéma ...
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 08, 2019, 10:55:45 am
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 (https://www.globalvisuals.nl/downloads/Instructions%20de%20montage%20DCCNext.pdf)

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

Laurent

Titre: Re : Levée de boucliers!
Posté par: laurentr le août 08, 2019, 11:13:11 am
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


Titre: Re : Levée de boucliers!
Posté par: Dominique le août 08, 2019, 12:11:17 pm
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 !
Titre: Re : Levée de boucliers!
Posté par: msport le août 08, 2019, 11:25:28 pm
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.
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 11, 2019, 12:34:57 pm
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
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 12, 2019, 11:03:43 am
Bonjour

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


Des avis et suggestions?

Laurent
Titre: Re : Levée de boucliers!
Posté par: Thierry le août 12, 2019, 11:36:14 am
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 ! :)
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 12, 2019, 11:56:44 am
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

Titre: Re : Levée de boucliers!
Posté par: Dominique le août 12, 2019, 12:28:49 pm
La bonne cause ne peut pas être le HARD sans SOFT, ni le SOFT sans HARD  :o
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  ;D).
Peut-être que tes cartes seront un bon exemple d’application, j’espere
Le sujet est intéressant, donc, à suivre ...

Dominique
Titre: Re : Re : Levée de boucliers!
Posté par: Thierry le août 12, 2019, 02:34:39 pm
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!

Et justement, Commanders comme Accessories ne sont pas perdus, ils sont faits pour ça ! Pour Commanders, une ligne unique déclare la présence d'un décodeur DCC. Et pour Accessories, chaque Led ou moteur réagit à des événements qui intègrent déjà l'adresse DCC... Je ne force personne, je dis juste que faire mieux qu'allumer une Led, on le fait déjà très bien, et que ce serait dommage de ne pas capitaliser sur ce qui existe et qui marche (et réponds parfaitement au 'cahier' des charges) !
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 13, 2019, 04:59:30 pm
Bonjour Thierry

Effectivement la bibliothèque ACCESSOIRES va pouvoir servir :).

J ai directement pris l'exemple SignalFrench dont je vais modifier le prisme avec les éléments d'approche ci dessous.
Cela me semble jouable... Sauf si tu vois directement des restrictions...???

Cette approche va permettre une plus grande modularité ( tous les tpe de cibles, et des combinaisons de cible SIGNAL FEUX et ID ou autres écrans lumineux
Tenir compte de combinaisons inédites au delà des 16 déja en place (0 à 15 déjà présentes)

Ce que je n ai pas encore identifie c est comment créer "deux groupes" de sorties répondant chacun a une série d adresses DCC... Mais ca va venir!

De même avec cet exemple comment on connait les différentes adresses accessoires utilisées en fonction du nombre de combinaisons que l on pousse...

Je dois encore m y plonger plus avant! Néanmoins si quelqu'un sait m expliquer le mécanisme ( et les lignes du codes associées) j avancerai plus vite!

Voici déjà un début de code review avec les hypothèses de posées.
J attaquerai ensuite la distribution des valeurs dans la classe.

//-------------------------------------------------------------------
// Le feu Francais le plus complexe presente un panneau (ou cible) dit unifie de type dit "H".
// Il est compose d'au maximum 10 lampes (dont l'oeilleton).
// Plusieurs lampes de meme ordre sont allumees systematiquement en meme temps ce qui reduit le nombre des sorties a utiliser a 8 ( RAL et RRAL).
// Tous les autres panneaux SNCF (hormis la cible circulaire) sont des combinaisons simplifiées de ce dispositif.
// Les combinaisons proposees sont toutes de type "mode nominal" et pas de mode dégrade ou en anomalie.( Ex carre brule avec 1 seul rouge et pas d'oeilleton) mais on pourrait ajouter ce cas precis facilement si besoin
// (avec le cablage propose il ne sera pas possible de n allumer qu un des deux jaunes du RAL ou RRAL)
// Les rouges du Carre et du semaphore sont gérés de manière autonome
// le cablage de l'oeilleton est facultatif
////////////////////////////////////////////////
// Panneau unifie type H:
//
//        |7|
//   |6| |6|
//   |5| |7|
//   |4|
//   |3|
//   |2|
//   |1|
//    |0|
//
// Avec
// 0 = oeilleton blanc
// 1 = jaune (Avertissement)
// 2 = rouge ( sémaphore)
// 3 = vert ( Voie Libre)
// 4 = feu rouge superieur du Carre ou Carre Violet
// 5 = blanc (manoeuvre)
// 6 = double jaune horizontal branche montage en parallele
// 7 = double jaune vertical branche montage en parallele
//
/////////////////////////////////////////////////////////////////
// Panneau unifie type I (dite cible 2 feux)(sans oeilleton):
//
//             |5|
// |5||4|   ou |4|
//
// 4= violet (carreviolet)
// 5= blanc (manoeuvre)
//
// I1 = Man,CV
/////////////////////////////////////////////////////////////////
// Panneau unifie type A (dite cible 3 feux)(sans oeilleton)
// A1
//  |3|
//  |2|
//  |1|
//
// A2
//  |3|
//  |2|
//  | |
//
//
// 1 = jaune (Avertissement)
// 2 = rouge (semaphore)
// 3 = vert (Voie Libre)
//
// A1 = Av,VL,S
// A2 = Vl,S
/////////////////////////////////////////////////////////////////
// Panneau unifie type B
// B1
//   |4|
//   |3|
//   |2|
//   |1|
// |0|
//
// 0 = oeilleton blanc
// 1 = jaune (Avertissement)
// 2 = rouge ( sémaphore)
// 3 = vert ( Voie Libre)
// 4 = feu rouge superieur du Carre
//
// B1 = Oe,Av,VL,S,C
////////////////////////////////////////////////////////////////
// Panneau de type E
// E1
//   |6| |6|
//   |4|
//   |3|
//   |2|
//   |1|
// |0|
//
//
// E2
//   |6| |6|
//   | |
//   |3|
//   |2|
//   |1|
// |0|
//
// 0 = oeilleton blanc
// 1 = jaune (Avertissement)
// 2 = rouge ( sémaphore)
// 3 = vert ( Voie Libre)
// 4 = feu rouge superieur du Carre
// 6 = double jaune horizontal (montage en parallele)
//
// E1 = Oe,Av,VL,S,C,RAL
// E2 = Oe,Av,Vl,S,RAL
//
/////////////////////////////////////////////////////////////////////
// Panneau de type F
// F1
//   |6| |6|
//   |5|
//   |4|
//   |3|
//   |2|
//   |1|
// |0|
//
// 0 = oeilleton blanc
// 1 = jaune (Avertissement)
// 2 = rouge ( sémaphore)
// 3 = vert ( Voie Libre)
// 4 = feu rouge superieur du Carre
// 5 = blanc (manoeuvre)
// 6 = double jaune horizontal (montage en parallele)
//
// F1 = Oe,Av,VL,S,C,M,RAL
// ///////////////////////////////////////////////////////////////////
// Cible de type G
// G1
//       |7|
//   |6| |6|
//   |4| |7|
//   |3|
//   |2|
//   |1|
// |0|
//
// G2
//       |7|
//   |5| | |
//   |4| |7|
//   |3|
//   |2|
//   |1|
// |0|
//
// G3
//       |7|
//   | | | |
//   |4| |7|
//   |3|
//   |2|
//   |1|
// |0|
//
//
// 0 = oeilleton blanc
// 1 = jaune (Avertissement)
// 2 = rouge ( sémaphore)
// 3 = vert ( Voie Libre)
// 4 = feu rouge superieur du Carre
// 5 = blanc (manoeuvre)
// 6 = double jaune horizontal (montage en parallele)
// 7 = double jaune vertical (montage en parallele)
//
// G1 = Oe,Av,VL,S,C,RAL,RRAL
// G2 = Oe,Av,Vl,S,C,M,RRAL
// G3 = Oe,Av,Vl,S,C,RRAL
/////////////////////////////////////////////////////////////////
// cible de type H
//
// H1
//       |7|
//   |6| |6|
//   |5| |7|
//   |4|
//   |3|
//   |2|
//   |1|
// |0|
//
// 0 = oeilleton blanc
// 1 = jaune (Avertissement)
// 2 = rouge ( sémaphore)
// 3 = vert ( Voie Libre)
// 4 = feu rouge superieur du Carre ou Carre Violet
// 5 = blanc (manoeuvre)
// 6 = double jaune horizontal (montage en parallele)
// 7 = double jaune vertical (montage en parallele)
//
// H1= Oe,Av,VL,S,C,Man,Ral,RRAL
// H2= Oe,Av,VL,S,Cv,Man,Ral,RRAL
//
//////////////////////////////////////////////////////////////////
// Cible de type D (Disque) ou R (Ronde)
//
// forme circulaire
// C1
//   | |      | |
//      |3|
//   |2*|      |2**|
//      |1|
//
// 1 = jaune (Avertissement)
// 2* = jaune (disque) (en combinaison avec 2**)
// 2** = rouge (disque) (en combinaison avec 2*)
// 3 = vert ( Voie Libre)
//
//
// C2
//   | |      | |
//      |3|
//   |2*|      |2**|
//      | |
//
//
// 2* = jaune (disque) (en combinaison avec 2**)
// 2** = rouge (disque) (en combinaison avec 2*)
// 3 = vert ( Voie Libre)
//
// C3
//   | |      | |
//      |3|
//   | |      | |
//      |1|
//
//
// 1 = jaune (Avertissement)
// 3 = vert ( Voie Libre)
//
//
// C4
//   |6|      |6|
//      |3|
//   | |      | |
//      |1|
//
//
// 1 = jaune (Avertissement)
// 3 = vert ( Voie Libre)
// 6 = double jaune horizontal branche montage en parallele
//
//
//
// C1 = Av,VL,D,RAL
// C2 = TO DO
// C3 = TO DO
// C4 = TO DO
/////////////////////////////////////////////////////////////////////////////////////////////
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 14, 2019, 03:44:15 pm
Bonjour

Il faut installer les biblotheques suivantes:
ACCESSORIES
COMMANDERS
DIO2

J ai progresse dans l écriture mais j ai eu  quelques mauvaises surprises à la compilation!
SPARKFUN1509.h manquant ==> solution installation de la bibliothèque gérant le 1509.
Idem pour le SH74HC595==> installation de la bibliothèque correspondante

Une fois ces désagréments passés la série continue mais sur un autre registre cette fois liée au code proprement dit:

DCCID et DCC ACTIVATION posent problème



...\Documents\Arduino\sketch_aug12a\sketch_aug12a.ino: In member function 'virtual void SignalArduinoPattern::Move(long unsigned int)':

sketch_aug12a:77:25: error: 'DCCID' was not declared in this scope

   int etat = (DCCID(inId) - this->startingDcc) * 2 + DCCACTIVATION(inId);

                         ^

sketch_aug12a:77:72: error: 'DCCACTIVATION' was not declared in this scope

   int etat = (DCCID(inId) - this->startingDcc) * 2 + DCCACTIVATION(inId);

Si certains savent comment resoudre cet élément bloquant on pourra ensuite regarder le reste que je glisse ci dessous...

D avance merci

Laurent.
                                                                        ^

/*************************************************************
project: <Accessories>
author: <Thierry PARIS>
co author: <Laurent ROEKENS>
description: <8 leds for a french railroad signal>
*************************************************************/

#include "Commanders.h"
#include "Accessories.h"

#define NB_LEDS_MAX      16 //LTR modif 20>16 (qui vont etre repartis en 2 groupes de 8 leds
#define PATTERN_NB_LEDS_MAX 4 // sauf cas des ID max = 6ID + 2 Accesoires
#define PATTERN_END_LIST  127
#define DCCSTART      10
// ajout pour compatibilite DR5000 #define kDCC_INTERRUPT 80
#define kDCC_INTERRUPT 80

//-------------------------------------------------------------------
// This class defines a light signal by giving patterns of lights:
// like the state -x--BB-- for a signal with 8 lights (modif LTR).
// - = 0 = OFF
// x = 1 = ON
// B = BLINK
// Where x means light on, - means off, and B is blink.
//-------------------------------------------------------------------

class SignalArduinoPattern : public AccessoryLightMulti
{
private:
  const uint8_t *pPatterns;
  const uint8_t *pRealStates;
  int startingDcc;
  int blinkDuration;

public:
  inline SignalArduinoPattern() {}
  void beginSignal(uint8_t inNbLeds, const int *inpPins, int inStartingDcc, int inBlinkDuration, const uint8_t *inPatterns, const uint8_t *inpRealStates = 0);
  void Move(unsigned long inId);

  static int GetStatesNumber(const uint8_t *pStates);
};

void SignalArduinoPattern::beginSignal(uint8_t inNbLeds, const int *inpPins, int inStartingDcc, int inBlinkDuration, const uint8_t *inPatterns, const uint8_t *inpRealStates)
{
  begin(0, inNbLeds, 0);
  for (int led = 0; led < inNbLeds; led++)
  {
    PortOnePin *pPort = new PortOnePin();
    pPort->begin(inpPins[led], DIGITAL);
    this->beginLight(led, pPort, 255);
  }

  this->startingDcc = inStartingDcc;
  this->blinkDuration = inBlinkDuration;
  this->pPatterns = inPatterns;
  this->pRealStates = inpRealStates;

/*#ifdef DEBUG_MODE
  // Pass through all states during 5s to check
  for (int i = 0; i < SignalArduinoPattern::GetStatesNumber(this->pRealStates); i++)
  {
    this->Move(this->startingDcc + (i / 2), i % 2);
    unsigned long start = millis();
    while (millis() - start < 1000)
      Accessories::loop();
    this->LightOff();
    start = millis();
    while (millis() - start < 1000)
      Accessories::loop();
  }
#endif*/
}

void SignalArduinoPattern::Move(unsigned long inId)
{
  int pospattern = 0;
  int etat = (DCCID(inId) - this->startingDcc) * 2 + DCCACTIVATION(inId);

  // All leds off
  for (unsigned char led = 0; led < this->GetSize(); led++)
    this->LightOff(led);

  char symbText[16];
  for (int i = 0; i < 16-1; i++)
    symbText = '.';

  symbText[15] = 0;

  // Change affected leds in the list
  for (int led = 0; led < PATTERN_NB_LEDS_MAX; led++)
  {
    uint8_t c = pgm_read_byte(this->pPatterns + (etat * PATTERN_NB_LEDS_MAX) + pospattern++);

    if (c > 0 && c <= 100)
    {
      this->SetBlinking(c-1, 0);
      this->LightOn(c-1);
      symbText[c-1] = 'O';
    }
    else
      if (c > 100)
      {
        this->SetBlinking(c-101, this->blinkDuration);
        this->Blink(c-101);
        symbText[c-101] = 'B';
      }
  }

  Serial.println(symbText);
}

int SignalArduinoPattern::GetStatesNumber(const uint8_t *pStates)
{
  for (int i = 0;; i++)
  {
    uint8_t c = pgm_read_byte(pStates + i);
    if (c == PATTERN_END_LIST)
      return i;
  }

  return 9999;
}

//-------------------------------------------------------------------
// Le feu Francais le plus complexe presente un panneau (ou cible) dit unifie de type "H".
// Il est compose d'au maximum 10 lampes (dont l'oeilleton).
// Plusieurs lampes de meme ordre sont allumees systematiquement en meme temps ce qui reduit le nombre des sorties a utiliser a 8 ( RAL et RRAL).
// Tous les autres panneaux SNCF (hormis la cible circulaire) sont des combinaisons simplifiées de ce dispositif.
// Les combinaisons proposees sont toutes de type "mode nominal" et pas de mode dégrade ou en anomalie.( Ex carre brule avec 1 seul rouge et pas d'oeilleton) mais on pourrait ajouter ce cas precis facilement si besoin
// (avec le cablage propose il ne sera pas possible de n allumer qu un des deux jaunes du RAL ou RRAL)
// Les rouges du Carre et du semaphore sont gérés de manière autonome
// le cablage de l'oeilleton est facultatif
////////////////////////////////////////////////
// Panneau unifie type H:
//
//       |7|
//   |6| |6|
//   |5| |7|
//   |4|
//   |3|
//   |2|
//   |1|
// |0|
//
// Avec
// 0 = oeilleton blanc
// 1 = jaune (Avertissement)
// 2 = rouge ( sémaphore)
// 3 = vert ( Voie Libre)
// 4 = feu rouge superieur du Carre ou Carre Violet
// 5 = blanc (manoeuvre)
// 6 = double jaune horizontal branche montage en parallele
// 7 = double jaune vertical branche montage en parallele
//
/////////////////////////////////////////////////////////////////
// Panneau unifie type I (dite cible 2 feux)(sans oeilleton):
//
//             |5|
// |5||4|   ou |4|
//
// 4= violet (carreviolet)
// 5= blanc (manoeuvre)
//
// I1 = Man,CV
/////////////////////////////////////////////////////////////////
// Panneau unifie type A (dite cible 3 feux)(sans oeilleton)
// A1
//  |3|
//  |2|
//  |1|
//
// A2
//  |3|
//  |2|
//  | |
//
//
// 1 = jaune (Avertissement)
// 2 = rouge (semaphore)
// 3 = vert (Voie Libre)
//
// A1 = Av,VL,S
// A2 = VL,S
/////////////////////////////////////////////////////////////////
// Panneau unifie type B
// B1
//   |4|
//   |3|
//   |2|
//   |1|
// |0|
//
// 0 = oeilleton blanc
// 1 = jaune (Avertissement)
// 2 = rouge ( sémaphore)
// 3 = vert ( Voie Libre)
// 4 = feu rouge superieur du Carre
//
// B1 = Oe,Av,VL,S,C
////////////////////////////////////////////////////////////////
// Panneau de type E
// E1
//   |6| |6|
//   |4|
//   |3|
//   |2|
//   |1|
// |0|
//
//
// E2
//   |6| |6|
//   | |
//   |3|
//   |2|
//   |1|
// |0|
//
// 0 = oeilleton blanc
// 1 = jaune (Avertissement)
// 2 = rouge ( sémaphore)
// 3 = vert ( Voie Libre)
// 4 = feu rouge superieur du Carre
// 6 = double jaune horizontal (montage en parallele)
//
// E1 = Oe,Av,VL,S,C,RAL
// E2 = Oe,Av,VL,S,RAL
//
/////////////////////////////////////////////////////////////////////
// Panneau de type F
// F1
//   |6| |6|
//   |5|
//   |4|
//   |3|
//   |2|
//   |1|
// |0|
//
// 0 = oeilleton blanc
// 1 = jaune (Avertissement)
// 2 = rouge ( sémaphore)
// 3 = vert ( Voie Libre)
// 4 = feu rouge superieur du Carre
// 5 = blanc (manoeuvre)
// 6 = double jaune horizontal (montage en parallele)
//
// F1 = Oe,Av,VL,S,C,M,RAL
// ///////////////////////////////////////////////////////////////////
// Cible de type G
// G1
//       |7|
//   |6| |6|
//   |4| |7|
//   |3|
//   |2|
//   |1|
// |0|
//
// G2
//       |7|
//   |5| | |
//   |4| |7|
//   |3|
//   |2|
//   |1|
// |0|
//
// G3
//       |7|
//   | | | |
//   |4| |7|
//   |3|
//   |2|
//   |1|
// |0|
//
//
// 0 = oeilleton blanc
// 1 = jaune (Avertissement)
// 2 = rouge ( sémaphore)
// 3 = vert ( Voie Libre)
// 4 = feu rouge superieur du Carre
// 5 = blanc (manoeuvre)
// 6 = double jaune horizontal (montage en parallele)
// 7 = double jaune vertical (montage en parallele)
//
// G1 = Oe,Av,VL,S,C,RAL,RRAL
// G2 = Oe,Av,Vl,S,C,M,RRAL
// G3 = Oe,Av,Vl,S,C,RRAL
/////////////////////////////////////////////////////////////////
// cible de type H
//
// H1
//       |7|
//   |6| |6|
//   |5| |7|
//   |4|
//   |3|
//   |2|
//   |1|
// |0|
//
// 0 = oeilleton blanc
// 1 = jaune (Avertissement)
// 2 = rouge ( sémaphore)
// 3 = vert ( Voie Libre)
// 4 = feu rouge superieur du Carre ou Carre Violet
// 5 = blanc (manoeuvre)
// 6 = double jaune horizontal (montage en parallele)
// 7 = double jaune vertical (montage en parallele)
//
// H1= Oe,Av,VL,S,C,Man,Ral,RRAL
// H2= Oe,Av,VL,S,Cv,Man,Ral,RRAL
//
//////////////////////////////////////////////////////////////////
// Cible de type D (Disque) ou R (Ronde)
//
// forme circulaire
// C1
//   | |      | |
//      |3|
//   |2*|      |2**|
//      |1|
//
// 1 = jaune (Avertissement)
// 2* = jaune (disque) (en combinaison avec 2**)
// 2** = rouge (disque) (en combinaison avec 2*)
// 3 = vert ( Voie Libre)
//
//
// C2
//   | |      | |
//      |3|
//   |2*|      |2**|
//      | |
//
//
// 2* = jaune (disque) (en combinaison avec 2**)
// 2** = rouge (disque) (en combinaison avec 2*)
// 3 = vert ( Voie Libre)
//
// C3
//   | |      | |
//      |3|
//   | |      | |
//      |1|
//
//
// 1 = jaune (Avertissement)
// 3 = vert ( Voie Libre)
//
//
// C4
//   |6|      |6|
//      |3|
//   | |      | |
//      |1|
//
//
// 1 = jaune (Avertissement)
// 3 = vert ( Voie Libre)
// 6 = double jaune horizontal branche montage en parallele
//
//
//
// C1 = Av,VL,Disque,RAL
// C2 = VL,Disque
// C3 = Av,VL
// C4 = Av,VL,RAL
/////////////////////////////////////////////////////////////////////////////////////////////

// La norme SCNF veut qu'il y ait quatre leds allumées au maximum, oeilleton compris.
// La liste décrit, 4 par 4, les numéros des leds allumées : positif allumé,
// supérieur à 100 clignotant, 0 inutilisé. Ce qui signifie que les numéros commencent à 1.
// Le code texte sur chaque ligne "--x-----" symbolise plus clairement les états.
// Enfin les numéros de chaque ligne sont notés de 0 à 24. Ils vont être réutilisés plus tard.
// ex 101 signifie 1ere sortie clignotante
// ex 102 signifie 2eme sortie clignotante
// etc
/////////////////////////////////////////////////////////////////////////////////////////////
// ordre de distribution
// Oe sortie 1
// Av sortie 2
// S sortie 3
// VL sortie 4
// C ou CV sortie 5
// Man sortie 6
// RAL sortie 7
// RRAL sortie 8
/////////////////////////////////////////////////////////////////////////////////////////////

const uint8_t SignalFrStates[] PROGMEM = {
            //  12345678
  101,102,103,104,              // "BBBB----"       0:(Oe,Av,VL,S)Cli
  105,106,107,108,              // "----BBBB"       1:(C/Cv,Man,RAL,RRAL)Cli 
  0,0,0,0,                      // "--------"       2: ALL OFF
  0, 3, 5, 0,                   // "--x-x---"       3: CARRE
  0, 5, 0, 0,                   // "----x---"       4: CARRE VIOLET
  1, 3, 0, 0,                   // "x-x-----"       5: Semaphore
  1, 103, 0, 0,                 // "x-x-----"       6: Rouge Cli 
  0, 3, 0, 0,                   // "-----x--"       7: Man
  0, 103, 0, 0,                 // "-----x--"       8: Man limitée
  1, 8, 0, 0,                   // "x------x"       9: RRAL 30
  1, 108, 0, 0,                 // "x------B"       10:RRAL 60
  1, 2, 0, 0,                   // "xx------"       11: Avertissement
  1, 7, 0, 0,                   // "x-----x-"       12: RAL 30
  1, 102, 0, 0,                 // "xB------"       13: Jaune Cli
  1, 107, 0, 0,                 // "x-----B-"       14: RAL 60
  1, 104, 0, 0,                 // "x--B----"       15: RAL 160
  1, 4, 0, 0,                   // "x--x----"       16: VL
  1, 0, 0, 0,                   // "xx-----x"       17: RRAL 30 + Av         
  1, 0, 0, 0,                   // "xB-----x"       18: RRAL 30 + Jaune Cli         
  1, 0, 0, 0,                   // "xx-----B"       19: RRAL 60 + Av         
  1, 0, 0, 0,                   // "xB-----B"       20: RRAL 60 + Jaune Cli         
  1, 0, 0, 0,                   // "xB----B-"       21: RAL 60 +Jaune Cli         
  0, 3, 0, 0,                   // "--x-----"       22: Disque
  0, 0, 0, 0,                   // "--------"       23: RESERVE         
  0, 0, 0, 0,                   // "--------"       24: RESERVE         
                   
            //  12345678
  PATTERN_END_LIST  // end of the list !
};

// Pour chaque type de feu, il n'y a que certains états de la liste ci-dessus qui sont utilisables.

// const uint8_t SignalFr3[] PROGMEM = { 0, 1, 2, 3, 4, PATTERN_END_LIST };
// const uint8_t SignalFr5[] PROGMEM = { 0, 1, 2, 3, 4, 5, 6, PATTERN_END_LIST };
// const uint8_t SignalFr7[] PROGMEM = { 0, 1, 2, 3, 4, 5, 6, 7, 11, 12, PATTERN_END_LIST };
// const uint8_t SignalFr9[] PROGMEM = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, PATTERN_END_LIST };

const uint8_t SignalI1[] PROGMEM = { 0, 1, 2, 4, 7, 8, PATTERN_END_LIST }; // I1 = Man,CV
const uint8_t SignalA1[] PROGMEM = { 0, 1, 2, 5, 6, 11, 13, 15, 16, PATTERN_END_LIST }; // A1 = Av,VL,S
const uint8_t SignalA2[] PROGMEM = { 0, 1, 2, 5, 6, 15, 16, PATTERN_END_LIST }; // A2 = VL,S
const uint8_t SignalB1[] PROGMEM = { 0, 1, 2, 3, 5, 6, 11, 13, 15, 16, PATTERN_END_LIST }; // B1 = Oe,Av,VL,S,C
const uint8_t SignalE1[] PROGMEM = { 0, 1, 2, 3, 4, 6, 11, 13, 15, 16, 12, 14, 21, PATTERN_END_LIST }; // E1 = Oe,Av,VL,S,C,RAL
const uint8_t SignalE2[] PROGMEM = { 0, 1, 2, 5, 6, 11, 13, 15, 16, 12, 14, 21, PATTERN_END_LIST }; // E2 = Oe,Av,VL,S,RAL
const uint8_t SignalF1[] PROGMEM = { 0, 1, 2, 3, 5, 6, 7, 8, 11, 13, 14, 15, 16, 12, 14, 21, PATTERN_END_LIST }; // F1 = Oe,Av,VL,S,C,M,RAL
const uint8_t SignalG1[] PROGMEM = { 0, 1, 2, 3, 5, 6, 9, 10, 11, 12, 13, 15, 16, 12, 13, 14, 15, 16, 17,18,19,20,21, PATTERN_END_LIST }; // G1 = Oe,Av,VL,S,C,RAL,RRAL
const uint8_t SignalG2[] PROGMEM = { 0, 1, 2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, PATTERN_END_LIST }; // G2 = Oe,Av,Vl,S,C,M,RRAL
const uint8_t SignalG3[] PROGMEM = { 0, 1, 2, 3, 5, 6, 7, 8, 9, 10, 11, 13, 15, 16, 17, 18, 19, 20,  PATTERN_END_LIST }; // G3 = Oe,Av,VL,S,C,RRAL
const uint8_t SignalH1[] PROGMEM = { 0, 1, 2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, PATTERN_END_LIST }; // H1= Oe,Av,VL,S,C,Man,RAL,RRAL
const uint8_t SignalH2[] PROGMEM = { 0, 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, PATTERN_END_LIST }; // H2= Oe,Av,VL,S,Cv,Man,RAL,RRAL
const uint8_t SignalC1[] PROGMEM = { 0, 1, 2, 11, 12, 13, 14 , 15, 16, 22, PATTERN_END_LIST }; // C1 = Av,VL,Disque,RAL
const uint8_t SignalC2[] PROGMEM = { 0, 1, 2, 15, 16, 22, PATTERN_END_LIST }; // C2 = VL,Disque
const uint8_t SignalC3[] PROGMEM = { 0, 1, 2, 11, 13, 15, 16, PATTERN_END_LIST }; // C3 = Av,VL
const uint8_t SignalC4[] PROGMEM = { 0, 1, 2, 11, 12, 13, 14, 15, 16, 21, PATTERN_END_LIST }; // C4 = Av,VL,RAL


// 0:(Oe,Av,VL,S)Cli
// 1:(C/Cv,Man,RAL,RRAL)Cli 
// 2: ALL OFF
// 3: CARRE
// 4: CARRE VIOLET
// 5: Semaphore
// 6: Rouge Cli 
// 7: Man
// 8: Man limitée
// 9: RRAL 30
// 10: RRAL 60
// 11: Avertissement
// 12: RAL 30
// 13: Jaune Cli
// 14: RAL 60
// 15: RAL 160
// 16: VL
// 17: RRAL 30 + Av         
// 18: RRAL 30 + Jaune Cli         
// 19: RRAL 60 + Av         
// 20: RRAL 60 + Jaune Cli         
// 21: RAL 60 +Jaune Cli         
// 22: Disque
// 23: RESERVE         
// 24: RESERVE 


// Liste des états pour un feu rond.

// const uint8_t SignalFrStatesRound[] PROGMEM = {
  //  123456789012
 // 3, 0, 0, 0, // "--x---------" 0: voie libre
 // 103, 0, 0, 0, // "--B---------" 1: voie libre limitée à 160km/h
 // 101, 0, 0, 0, // "B-----------" 2: Avertissement arrêt très proche.
 // 1, 0, 0, 0, // "x-----------" 3: Avertissement arrêt.
 // 10, 11, 0, 0, // "---------xx-" 4: Conduite à vue (signal rond seulement)
 // 6, 7, 0, 0, // "-----xx-----" 5: Vitesse réduite à 30
 // 106, 107, 0, 0, // "-----BB-----" 6: Vitesse réduite à 60
 // 101, 106, 107, 0, // "B----BB-----" 7: Vitesse réduite à 60 + avertissement
            //  123456789012
  // PATTERN_END_LIST  // end of the list !
// };

// Tous les états sont utilisables, à priori.

// const uint8_t SignalFrRound[] PROGMEM = { 0, 1, 2, 3, 4, 5, 6, 7, PATTERN_END_LIST };

// Four leds on only. First led is 1. Negative led number will blink.

// Liste des états pour un feu horizontal.

// const uint8_t SignalFrStatesHorizontal[] PROGMEM = {
  //  123456789012
//  1, 0, 0, 0,   // "x-----------"   0: Vitesse de manoeuvre (feu horizontal)
//  101, 0, 0, 0, // "B-----------"   1: Vitesse de manoeuvre réduite (feu horizontal)
//  2, 0, 0, 0,   // "-x----------"   2: idem AbsoluteStop mais sur un signal horizontal ou deux feux.
          //  123456789012
//  PATTERN_END_LIST  // End of the list
// };

// Tous les états sont utilisables, à priori.

// const uint8_t SignalFrHorizontal[] PROGMEM = { 0, 1, 2, PATTERN_END_LIST };

SignalArduinoPattern signal;

// Commanders

#ifdef VISUALSTUDIO
ButtonsCommanderKeyboard  push;
#else
ButtonsCommanderPush push;
#endif

// Accessories

// Drivers

// #define signalPattern SignalFr9
// #define NB_LEDS     12

#define signalPattern SignalH1
#define NB_LEDS     8

// int pins[NB_LEDS] = { 3, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33 };
int pins[NB_LEDS] = { 3, 4, 5, 6, 7, 8, 9, 10 };

void ReceiveEvent(unsigned long inId, COMMANDERS_EVENT_TYPE inEventType, int inEventData)
{
  int id = DCCID(inId);
  if (id >= DCCSTART && id < DCCSTART + (SignalArduinoPattern::GetStatesNumber(signalPattern) + 1) / 2)
    signal.Move(inId);

  Accessories::ReceiveEvent(inId, (ACCESSORIES_EVENT_TYPE)inEventType, inEventData);
}

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//
// Setup
//
void setup()
{
  Serial.begin(115200);
  //while (!Serial);    // For Leonardo only. No effect on other Arduino.

  Commanders::begin(ReceiveEvent, LED_BUILTIN);
  Accessories::begin();

  // Commanders setup

  DccCommander.begin(0x00, 0x00, digitalPinToInterrupt(3));

  // UNDEFINED_ID here means that this id is not significant.
#ifdef VISUALSTUDIO
  push.begin(UNDEFINED_ID, '0');
#else
  push.begin(UNDEFINED_ID, 17);
#endif

  int nb_etats = SignalArduinoPattern::GetStatesNumber(signalPattern);

  // Ce petit bouton va permettre de passer en revue tous les codes dcc des feux en séquence...
 
  int dcc = DCCSTART;
  bool etat = false;
  for (int i = 0; i < nb_etats; i++)
  {
    if (!etat)
    {
      push.AddEvent(DCCINT(dcc, 0));
      etat = true;
    }
    else
    {
      push.AddEvent(DCCINT(dcc, 1));
      dcc++;
      etat = false;
    }
  }

  signal.beginSignal(NB_LEDS, pins, DCCSTART, 500, SignalFrStates, signalPattern);
}

void loop()
{
  Accessories::loop();

  Commanders::loop();
}
Titre: Re : Levée de boucliers!
Posté par: Thierry le août 14, 2019, 05:25:38 pm
Accessories comme Commanders se configurent à partir de leur fichier .h respectif.

Dans Accessories.h, enlever le commentaire de la ligne

//#define NO_EXPANDER
et comme ça, l'installation des sous-bib pour le 1509 et le 74HC ne sont plus nécessaires.

A l'inverse, le DCC n'est pas activé par défaut dans Commanders, vu que l'essentiel des usages de la bibliothèque se concentre sur les boutons en tout genre. Il faut donc mettre en commentaire l'une des deux lignes

#define NO_DCCCOMMANDER
#define NO_DCCCOMMANDERNMRA

et ainsi obtenir tout ce qui va avec le DCC, dont les macros dont tu parles. Je conseillerai d'utiliser la bibliothèque NMRA plutôt que celle de base. Elle est plus fiable.

Dans les deux bibliothèques, profites-en pour retirer de la compilation par le même moyen tout ce qui ne te servira pas, comme le shield l293d ou les moteurs pas à pas (stepper) dans Accessories. Pour chacune, tu peux double cliquer sur le fichier extras/Doc/index.html pour avoir une doc détaillée en Anglais des classes, defines et autres fonctionnements obscurs. N'hésites pas à me signaler des manques dans cette doc si besoin.
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 14, 2019, 06:43:58 pm
Merci Thierry

Non sans mal mais c est en place!
J ai du garder la bibliothèque DCCCOMMANDER standard car la DCCCOMMANDERNMRA ne semblait pas fonctionner avec le code.

La compile pousse au bout.

Il (me) reste a comprendre: ( pour mettre en oeuvre)

1/ comment fixer une adresse DCC de base pour le premier état (j imagine que l incrément en fonction du nombre de combinaisons augmentera de fait en mêème temps) ( Est ce que cela serait la ligne DCC Start XX ou X est la valeur de base du 1er etat du decodeur?)
2/ faire le choix du type de signal a commander ( I1, A1,A2,B1, E1,...H1,H2, C1,...C4)

Merci pour votre aide
Laurent


Titre: Re : Levée de boucliers!
Posté par: laurentr le août 15, 2019, 12:48:49 am
Bonsoir

J ai modifie la ligne suivante

DccCommander.begin(0x00, 0x00, digitalPinToInterrupt(2)); pour que la PIN D2 qui reçoit le signal DCC via l optocoupleur soit la PIN d entree du signal

Mais... ensuite ou est la valeur a saisir pour l adresse initiale? ( car rien ne bouge derrière...)

Big questions...

Je ne dois pas etre bien loin du "vrai"... pls help!
Laurent
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 16, 2019, 10:16:51 pm
Bonsoir

L un de vous aurait il les syntaxes  pour

Fixer l adresse dcc de base ( est ce dccsstart?)
Confirmer que D2 peut bien recevoir le signal dcc?
Confirmer que les pins d3 a d10 sont bien des sorties.
Enfin ce qu il peut manquer pour faire fonctionner le tout...

Pour mémoire d3 d4 d5 d6 d7 d8 d9 et d10 doivent être des sorties et correspondre aux états de sorties œilleton av vl s c/cv man ral rral.

D avance merci
Laurent
Titre: Re : Levée de boucliers!
Posté par: Thierry le août 16, 2019, 10:50:26 pm
Bonjour

Ca va fonctionner sur un Mega dont la broche 2 est capable de faire ce boulot, mais pas sur un Uno ou Nano. Je n'ai pas retrouvé dans le sujet de référence à un modèle d'Arduino, donc attention... Les autres broches sont ou des entrées ou des sorties, au choix.

La classe SignalArduinoPattern  repose sur la classe AccessoryLightMulti. Celle ci est une liste de Leds dont le comportement est régit par deux entiers, un pour l'allumage et l'autre pour le clignotement. Ces entiers sont codés sur 16 bits, ce qui signifie qu'un signal ne pourra pas avoir plus de 16 leds. Chaque entier est utilisé comme un champs de bits, chacun représentant une led. Chaque Led est associée à un port qui va permettre de l'alimenter.

L'accessoire contient également une liste d'identifiants qui représentent toutes les combinaisons d'allumage/clignotement possibles. Chaque combinaison est nommée par un identifiant qui, dans le cas du DCC, est un mix entre une adresse DCC de décodeur d'accessoires et un numéro d'accessoire. C'est de rôle de la macro de DCCINT() d'assembler ces deux petits entiers pour en faire un gros qui devient l'identifiant d'une combinaison donnée.

Je suis en train de refaire SignalFrench pour permettre de fixer le code DCC de chaque etat individuellement.
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 16, 2019, 11:41:26 pm
Bonsoir Thierry

Merci pour tes éléments de réponse.
Effectivement étant sur un NANO et utilisant la broche D2 comme entrée ... cela ne peut fonctionner ainsi... comme je l’esperais!

Idéalement il’faudrait Pouvoir dans le code:
Choisir le modèle d arduino (nano,uno ou mega)
Un modèle doit pouvoir gerer 2 signaux de 8 feux.( et jusqu à n combinaisons)( n Max = 3^8 = 6561) (3 = off, on ou blink)  Dans mon exemple plus haut je suis parti sur 24 combinaisons de base ce qui occupe 6 adresses dcc accessoire de base à 4 états ou 12 à 2 états. Donc saisir le nombre de signaux gérés ( ici 1 ou 2)
La dernière entrée saisie affiche sur le signal la combinaison Attendue et efface les autres du même signal)
Avoir l entrée du signal DCC sur D2 ( ce qui est assez commun.)
Saisir le nombre de combinaisons pour le signal 1 idem pour le signal  2
Pouvoir fixer l ID de base du signal 1 ( les ID SUIVANTES S AJOUTERONT simplement tant que des combinaisons sont à compléter, idem pour le signal 2 ( les plages d adresses peuvent être commun ou se superposer.
Si un signal peut au maximum gérer 16 sorties en parallèle ( combinaison a gogo) alors pouvoir en gérer 2 groupes de 8 serait bien mieux! ( combinaisons. A gogo/2!)
Pousser plus loin decoupage c est ouvrir la boîte de Pandore... mais après tout pourquoi pas... ( ex un 5 deux un 3 feux un 6 feux un 2 feux avec chacun leur ID de base etc... C est ici la modularité maximale... qui me semble trop complexe ( dans un premier temps à construire, voyons cela plus tard
pour une version V2.0)

Il reste encore un peu à mouliner... mais le résultat final sera à la hauteur des efforts!

Encore merci
Laurent
Titre: Re : Levée de boucliers!
Posté par: Thierry le août 17, 2019, 10:53:48 am
Je retire ce que j'ai dit ! La broche 2 est bien utilisable sur un Nano, après vérification sur le site de référence arduino.cc .

Le choix du type d'Arduino est fait par l'IDE. Rien à faire dans le code par défaut, mais des adaptations aux bonnes broches pourraient être faites.
Titre: Re : Levée de boucliers!
Posté par: Thierry le août 17, 2019, 11:26:05 am
Un Nano est bien capable de gérer deux feux de 8 leds chacun sans modification. Au delà, il conviendra d'ajouter des multiplicateurs de port, en digital (74HC) ou en PWM (tlc5940)... D'ailleurs, seul un port PWM pourra faire du light dimming (allumage/extinction progressive d'une vieille ampoule), et le Nano ne dispose que 6 broches capables de PWM. Peut être qu'une bibliothèque comme SoftPWM peut rendre ce service...
Titre: Re : Levée de boucliers!
Posté par: Thierry le août 17, 2019, 02:53:09 pm
Ci-joint mon premier jet de ton projet. Ca fonctionne bien sur mon émulateur, mais je n'ai pas câblé physiquement pour voir le résultat...
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...
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 17, 2019, 09:13:21 pm
Bonsoir Thierry

Je viens de jeter un oeil rapidement.
Merci beaucoup. Cela structure bien les éléments déjà en place ou escomptés.

J ai un petit doute pour ce qui est de la valeur dcc+1 pour le second signal...
Car en fait le 1er signal va "bouffer des adresses ( si on part sur 24 etats il en consommera 6 à 4 états ou 12 à 2 états pour les signaux de type H ( moins pour les autres mais la modularite des combinaisons complexe a un impact direct sur les adresses consommées donc pour faire simple on dit que tous les signaux sont de type H et on reserve ainsi le max d adresses possibles.
Si plus tard on est un peu juste alors on pourra regarder pour moduler les affectations au stricte besoin réel des combinaisons à produire ce qui sera un "bon exercice" pour une V2
Dans ce cas précis DCC+1 prendra la valeur DCC de base +5 ou +13 pour la 1ere adresse dispo :) (il me semble)
Reste à voir comment se combinent les adresses et leurs utilisations.

Pour le test grandeur nature il reste donc la partie DCC à intégrer en entrée sur la broche D2 et son traitement pas "la bête"...

le CI est monté
je regarderai cela en fin de weekend/début de semaine

Laurent

Titre: Re : Levée de boucliers!
Posté par: laurentr le août 26, 2019, 09:27:36 pm
Les CI en cours
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 26, 2019, 09:29:36 pm
autres vue des CI en "assemblage par bloc de fonction

ici
CI commande via ARDUINO NANO BASE
EXT 8 SERVOS et EXT 8 relais.
Titre: Re : Levée de boucliers!
Posté par: trimarco232 le août 28, 2019, 10:21:04 pm
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
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 28, 2019, 11:02:45 pm
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


Titre: Re : Levée de boucliers!
Posté par: trimarco232 le août 30, 2019, 02:08:31 pm
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
Titre: Re : Levée de boucliers!
Posté par: trimarco232 le août 30, 2019, 02:21:09 pm
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 ? 
Titre: Re : Levée de boucliers!
Posté par: laurentr le août 30, 2019, 04:39:47 pm
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

Titre: Re : Re : Levée de boucliers!
Posté par: laurentr le août 30, 2019, 04:53:52 pm
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.
Titre: Re : Levée de boucliers!
Posté par: trimarco232 le août 31, 2019, 06:35:22 am
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 8)) 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