Warning dans véhicule HO / animation de décor réseau

[BB9004]

Bonjour

voici un mini projet , présenté sur le forum Arduino de LocoRevue :

- cadre : animation de décor sur réseau HO
- objectif : créer une animation visuelle, éventuellement variable
- Contexte : Un incident technique ferroviaire (machine en panne, aiguille cassée, signalisation HS, etc...) nécessite la présence de techniciens de maintenance sur les lieux, avec le matériel dans leur véhicule
- moyens : un véhicule HO pouvant être équipé de Leds oranges (ses clignotants en mode warning)
- carte Arduino : Nano ? Uno ?
- petits "+" possibles :
  > option 1 : pourrait être pilotée par un décodeur DCC accessoire, à 4 fonctions (sinon : bouton ON/OFF ou rotatif à 4 sorties ??)
  > option 2 : pourrait avoir une lampe de cligno grillée sur demande si DCC
  > option 3 : pourrait avoir un rythme d'allumage du warning selon le mode "SOS" en morse (reprise du programme Titanic, esprit farceur / étonnement des spectateurs attentifs)
  > option x : ...

- le véhicule pouvant être déplacé, ses connexions (au décor) doivent être facilement démontables, et éventuellement être existantes à plusieurs endroits du réseau, si besoin, mais pilotées par la même carte Arduino
- si le châssis du véhicule HO est identique pour plusieurs caisses différentes, on optimise les effets d'animation

- L'objet de ce mini projet est d'accompagner les différents apprentissages Arduino à mettre en oeuvre (je débute).

Budget minimum estimé au départ : moins de 30€.

 version 0.2: Warning "simple" (ou warning en mode morse SOS, actuellement mis en commentaire //)  :

Code: [Sélectionner]

/*
 * Programme pour arduino Nano ou Uno : à préciser
 * par LLG Juin2018 V0.2
 * Licence GNU GPLv3 - Version IDE 1.8.5
 *
 * Ce programme fait fonctionner des feux Warning sur un véhicule HO, plus 3 options (a ecrire)
 * option 1 : gestion d'1 ampoule HS : a ecrire
 * option 2 : cycle du warning de type "SOS" : a ecrire
 * option 3 : liaison et pilotage du warning par un decodeur d'accessoires 4 fonctions DCC : a ecrire
 * 4 LED (oranges ou rouges) sont reliees aux sorties 4 a 7
 * Les sorties 4 a 7 sont indépendantes, afin de simuler eventuellement (en option # 1) une ampoule cassée
 */
     
// Initialisation des variables
const byte AVD = 4 ;  // cligno AVD
const byte AVG = 5 ;  // cligno AVG
const byte ARD = 6 ;  // cligno ARD
const byte ARG = 7 ;  // cligno ARG
const byte TOUS = 7 ;  // les 4 clignos ensemble

//Delai du Warning normal : duree on = off, rythme d'environ 1/2 seconde
const long TempsON = 500;
const long TempsOFF = 500;
// a completer pour l'option SOS (cf Titanic) et la condition IF, si decodeur DCC installe : ??
   
// Initialisation des lignes 4 a 7 en sortie
void setup () {
  pinMode (AVD, OUTPUT) ;
  pinMode (AVG, OUTPUT) ;
  pinMode (ARD, OUTPUT) ;
  pinMode (ARG, OUTPUT) ;
}
     
// Fonction loop
void loop () {
  // Extinction de toutes les LED au depart
  digitalWrite (AVD, LOW) ;
  digitalWrite (AVG, LOW) ;
  digitalWrite (ARD, LOW) ;
  digitalWrite (ARG, LOW) ;
     
  // Allumage des leds, en meme temps
  digitalWrite (AVD, HIGH) ;   
  digitalWrite (AVG, HIGH) ;   
  digitalWrite (ARD, HIGH) ;
  digitalWrite (ARG, HIGH) ;
     
  // Debut de cycle 0 : mode warning Normal
   
  delay (TempsON) ; // 4 Feux allumes
 
  digitalWrite (AVD, LOW) ; // Extinction AVD
  digitalWrite (AVG, LOW) ; // Extinction AVG
  digitalWrite (ARD, LOW) ; // Extinction ARD
  digitalWrite (ARG, LOW) ; // Extinction ARG
 
  delay (TempsOFF) ; // 4 feux eteints
       
  // et on boucle, jusqu'à la décision d'extinction DCC

   // option 1 : gestion d'1 ampoule HS : a ecrire
   // option 2 : cycle du warning de type "SOS" : a ecrire
   // option 3 : liaison et pilotage du warning par un decodeur d'accessoires 4 fonctions DCC : a ecrire
 
}
/* warning sur rythme SOS : à ré-ecrire , copie du SOS Titanic
//
void loop() {
 digitalWrite(pinLED, HIGH) ; // allumage du S = 3 fois point, avec delai entre chaque allumage
 delay (point) ;                     // durée d'allumage de la led
 digitalWrite (pinLED, LOW) ; // extinction
 delay (interPointTrait) ;           // attente
 digitalWrite(pinLED, HIGH) ;
 delay (point) ;
 digitalWrite (pinLED, LOW) ;
 delay (interPointTrait) ;
 digitalWrite(pinLED, HIGH) ;
 delay (point) ;
 digitalWrite (pinLED, LOW) ;
 delay (interPointTrait) ;
// fin du 1er "S"

 delay (interlettres) ;             // delai entre 2 lettres

// on allume pour le "O" : 3 fois trait de 0,6 s
 digitalWrite(pinLED, HIGH) ;
 delay (trait) ;
 digitalWrite(pinLED, LOW) ;
 delay (interPointTrait) ;
 digitalWrite(pinLED, HIGH) ;
 delay (trait) ;
 digitalWrite(pinLED, LOW) ;
 delay (interPointTrait) ;
 digitalWrite(pinLED, HIGH) ;
 delay (trait) ;
 digitalWrite(pinLED, LOW) ;
// delay (interPointTrait);

// pause entre 2 lettres :
 delay (interlettres) ;

// on allume le 2é S (recopie de la premiére fois)
 digitalWrite(pinLED, HIGH) ; // allumage du S = 3 points, avec delai entre chaque allumage
 delay (point) ;
 digitalWrite (pinLED, LOW) ;
 delay (interPointTrait) ;
 digitalWrite(pinLED, HIGH) ;
 delay (point) ;
 digitalWrite (pinLED, LOW) ;
 delay (interPointTrait) ;
 digitalWrite(pinLED, HIGH) ;
 delay (point) ;
 digitalWrite (pinLED, LOW) ;
//delay (interPointTrait);
// fin du 2é "S"

// on attend entre 2 SOS
 delay (entre2sos) ;

}
*/

Edit : ce fil présentera les différentes étapes d'apprentissage Arduino (questionnements, instructions utilisées, etc...) et l'avancement du projet.
 

[BB9004]

bonjour

je butte sur ceci : peut-on "piloter" 4 sorties avec une SEULE variable définie ?
(par paresse, je voudrai éviter de répéter trop de ligne... but : 1 seule instruction pour allumer les 4 clignos ensembles, dans l'option SOS)

exemple :

const byte TOUS = x ;  // les 4 clignos seraient gérés ensemble >> comment le faire, si c'est possible ?

>> soit à l'origine : il y a une sortie par cligno (pour permettre de simuler, sur une autre option, 1 ampoule grillée dans les 4) :
const byte AVD = 4 ;  // cligno AVD
const byte AVG = 5 ;  // cligno AVG
const byte ARD = 6 ;  // cligno ARD
const byte ARG = 7 ;  // cligno ARG

merci

[Jean-Luc]

Bonjour,

Oui c'est possible mais il faut descendre dans les tréfonds du microcontrôleur et ça suppose que toutes les broches correspondent à un même registre du GPIO.

En l'occurrence les broches 4 à 7 (sur un Uno je suppose) correspondent aux bits 4 à 7 du port D (coup de pot). Donc en écrivant :

Code: [Sélectionner]

PORTD |= 0xF0;

on met à HIGH les 4 broches simultanément et en écrivant

Code: [Sélectionner]

PORTD &= ~0xF0;

On les met à LOW

Mais est-ce nécessaire ? On y perd en lisibilité et en portabilité et l'application ne nécessite pas d'aller vite

De manière plus portable, tu peux écrire :

Code: [Sélectionner]

for (byte broche = 4; broche < 8; broche++) digitalWrite(broche, HIGH);

Par ailleurs, pour éviter de répéter de nombreuse fois la même séquence, tu peux faire une fonction :

Code: [Sélectionner]

void clignotant(byte etat)
{
    for (byte broche = 4; broche < 8; broche++) digitalWrite(broche, etat);
}

Il suffit ensuite d'appeler la fonction :

Code: [Sélectionner]

clignotant(HIGH);
delay(2000);
clignotant(LOW);


[BB9004]

Merci beaucoup Jean Luc de ton aide !
c'était d'abord sur une Nano, mais finalement c'est une Uno "RPC" (puce Atmel  mega 328P) pour les facilitées de branchement avec la breadboard

aide précieuse : ça me conduit vers des "couches" plus profondes d'IDE : génial !
et des "astuces" d'optimisation des lignes et fonctions ...

> j'étudie tes propositions, je les digère ... , puis je les mettrai  ai mises dans le prog

(j'ai changé le rythme d'allumage à 1/2 seconde > plus réaliste pour un warning  !
 

edit : maintenant que les "sorties" sont en cours de résolution..., je m'interroge sur la sélection des entrées ... (via digitalRead ? )
- choix 1 : warning normal
- choix 2 : warning "SOS"
- choix 3 : warning avec 1 ampoule cassée
- choix 4 : pas défini

> en attendant d'étudier (ultérieurement) les choix via un DCC, faut-il prévoir de passer par un bouton rotatif à 5 positions  (0 = éteint) pour piloter ces entrées ? (pour aller du plus simple vers le plus compliqué)

Pour le moment, j'écris les 3 premiers sous-programmes (testés individuellement, c'est OK) en les mettant en commentaire... en attendant de savoir par quelles instructions les sélectionner
> pas de test possible sur la BB, par manque de résistance 220 ou 330 ohm pour tester les 4 leds ensemble ...

PS : si quelqu'un est intéressé, je peux mettre le prog compilé ici (fait)

[BB9004]

hello

Dans le prog "Warning", je m'interroge sur la logique de gestion des entrées : vos avis seraient utiles ...

Q1 : il y a un choix multiples d’entrées, la majorité est exclusive ("OU") (1 entrée = 1 seule action de sortie), mais il y aura éventuellement 1 entrée = 2- ou 3 - actions/sorties simultanées ("ET")
 (ex : warning + phares allumés) et même "warning + phares + éclairage cabine" : possible ?
> est-ce le moment de s’intéresser aux bibliothèques, afin de ne pas ré-écrire ces sous-ensemble à chaque fois ?

>> les choix potentiels actuels :
* option 1 : warning normal : rédigé : à tester
 * option 2 : cycle du warning de type "SOS" : rédigé : a tester
 * option 3 : gestion d'1 ampoule HS : rédigé : a tester
 * option 4 : liaison et pilotage du choix du warning par un decodeur d'accessoires 4 fonctions DCC : a ecrire
 * option 5 : allumage des phares seuls : a ecrire
 * option 6 : allumage des phares ET du warning normal : a ecrire
 * option 7 : éclairage de la cabine du véhicule : a ecrire

Q2 > si la sélection en entrée se fait par un bouton rotatif sur TCO : le "pôle" choisi alimentera une SEULE Pin dédiée, en entrée, qui, elle, conditionnera la Pin de sortie : possible ?
>nota : cette option semble empêcher les choix "ET" : ?

Q3 > si la sélection en entrée se fait par différents boutons sur le TCO : risque de superposition des choix si on oublie, par fonction, "d'éteindre" l'ensemble avant de lancer la fonction choisie
> petit inconvénient : plus de cablage sur le TCO
> avantage : devrait permettre les choix "ET" : ?

Q4 > si la sélection se fait par décodeur DCC (je n'ai pas encore étudié les possibilités du décodeur Locoduino, que j'envisage de mettre en oeuvre), le nombre de choix possibles sera limité au nombre de possibilités de fonction de ce décodeur .
L'idée est d'associer 1 choix "warning" à une fonction DCC : réaliste ?

- Autres questions, concernant les "loop" :

L1 : peut-on conditionner leur "lancement" par un "index" ?
> genre : IF xx= YY, alors GOTO loop1, sinon goto loop2, etc ... : possible ?

L2 : peut-on avoir plusieurs loop dans un même programme ?
si oui, comment les gere-t-on ?
le IF le permet-il ? (si le "goto" est impossible)

Merci de vos conseils, bonne journée à tous

[Jean-Luc]

Bonjour,

Dans le prog "Warning", je m'interroge sur la logique de gestion des entrées : vos avis seraient utiles ...

Q1 : il y a un choix multiples d’entrées, la majorité est exclusive ("OU") (1 entrée = 1 seule action de sortie), mais il y aura éventuellement 1 entrée = 2- ou 3 - actions/sorties simultanées ("ET")
 (ex : warning + phares allumés) et même "warning + phares + éclairage cabine" : possible ?
> est-ce le moment de s’intéresser aux bibliothèques, afin de ne pas ré-écrire ces sous-ensemble à chaque fois ?

>> les choix potentiels actuels :
* option 1 : warning normal : rédigé : à tester
 * option 2 : cycle du warning de type "SOS" : rédigé : a tester
 * option 3 : gestion d'1 ampoule HS : rédigé : a tester
 * option 4 : liaison et pilotage du choix du warning par un decodeur d'accessoires 4 fonctions DCC : a ecrire
 * option 5 : allumage des phares seuls : a ecrire
 * option 6 : allumage des phares ET du warning normal : a ecrire
 * option 7 : éclairage de la cabine du véhicule : a ecrire

Q2 > si la sélection en entrée se fait par un bouton rotatif sur TCO : le "pôle" choisi alimentera une SEULE Pin dédiée, en entrée, qui, elle, conditionnera la Pin de sortie : possible ?
>nota : cette option semble empêcher les choix "ET" : ?

Q3 > si la sélection en entrée se fait par différents boutons sur le TCO : risque de superposition des choix si on oublie, par fonction, "d'éteindre" l'ensemble avant de lancer la fonction choisie
> petit inconvénient : plus de cablage sur le TCO
> avantage : devrait permettre les choix "ET" : ?

Je vais faire une seule réponse à toutes :

Peu importe ces choix du point de vue fonctionnel puisqu'au bout du compte le programme décidera de la combinaison d'entrées qui sont valides. Je ne pense pas qu'il y ai besoin de bibliothèques.

La question est plutôt de savoir si l'utilisateur a besoin d'une information retour sur le TCO ou pas ? Observer le véhicule suffit-il ou non ?

Si la réponse est non, il ne suffit pas d'observer le véhicule, alors deux options :

• commutateur qui fournit un retour physique
• affichage géré par le programme (LEDs, LCD)

Dans le premier cas, tu as le choix entre un commutateur à l'ancienne qui nécessite autant de sorties (fils) que de fonctions ou bien un codeur qui sort l'information codée en binaire (16 positions/fonctions = 4 fils par exemple) :



Comme tu l'as souligné, ne permet pas à priori de choisir une option mais on peut aussi décider que les combinaisons valides sont prédéterminées et dans ce cas une position du bouton leur est affectée.

Dans le second cas, une paire de boutons poussoir et des LED font l'affaire.

Si observer le véhicule suffit, une paire de poussoir fait l'affaire. Après tout, les LED dans le véhicule peuvent servir à renseigner sur l'option sélectionnée. Par exemple 3 flash rapide pour signaler qu'on passe en DCC.

Q4 > si la sélection se fait par décodeur DCC (je n'ai pas encore étudié les possibilités du décodeur Locoduino, que j'envisage de mettre en oeuvre), le nombre de choix possibles sera limité au nombre de possibilités de fonction de ce décodeur .
L'idée est d'associer 1 choix "warning" à une fonction DCC : réaliste ?

Là je pense que tu es large

- Autres questions, concernant les "loop" :

L1 : peut-on conditionner leur "lancement" par un "index" ?
> genre : IF xx= YY, alors GOTO loop1, sinon goto loop2, etc ... : possible ?

L2 : peut-on avoir plusieurs loop dans un même programme ?
si oui, comment les gere-t-on ?
le IF le permet-il ? (si le "goto" est impossible)

Merci de vos conseils, bonne journée à tous

Les GOTO c'est mal.

Il n'y a qu'une loop, mais tu peux mettre chacune des options dans une fonction et, dans loop, appeler la fonction correspondant à l'option sélectionnée.

[BB9004]

Merci again !

je digère tout ça (j'essaie de comprendre et de mettre en oeuvre) ...

Quand tu écris, pour l'option DCC : "tu es large" : que veux tu dire ?
(j'imaginais que le DCC supprimerait du cablage au TCO, puisque piloté par une manette type roco, via la centrale DCC)

ps : le "goto c'est mal " m'a bien fait rire, sans en comprendre la raison !

[Jean-Luc]

Quand tu écris, pour l'option DCC : "tu es large" : que veux tu dire ?
(j'imaginais que le DCC supprimerait du cablage au TCO, puisque piloté par une manette type roco, via la centrale DCC)

Je veux dire que tu as un choix beaucoup plus large de valeurs envoyées via une trame DCC. Au programme d'en déduire l'option.

[msport]

ps : le "goto c'est mal " m'a bien fait rire, sans en comprendre la raison !

le goto c'est pas structuré, ça part dans tous les sens, mais pour devenir un real programmer, lire aussi :
http://www.bernstein-plus-sons.com/RPDEQ.html

[Thierry]

Je m’immisce dans la conversation...
Le GOTO représente la façon de programmer des années 80 parce qu'il n'y avait pas le choix, en assembleur ou en Basic.
Et puis sont venus les langages évolués comme le C et ses descendants qui offraient de bien meilleures possibilités de structuration du code avec les fonctions, les while(), do-while(), switch, etc... Si le GOTO reste possible et peut être justifié dans de très rares cas comme la gestion d'erreur si on ne veut pas utiliser d'interruptions, il est reconnu aujourd'hui comme un générateur du code 'spaghetti', du code qui part dans tous les sens avec une lisibilité et une maintenabilité faible.
Donc oui, je pense que le code bootloader de l'Enfer est plein de GOTOs, que celui de Trump aussi, ce qui rend sa pensée aussi volatile et imprévisible...
Le GOTO c'est LE mal !

Grillé par msport...

[Rob1]

Pour abonder dans le sens de Thierry et faire un peu d'humour.

Ce n'est pas par hasard que GoTo se traduit en français par " aléas " 

Amicalement Roland

[BB9004]

 
Goto Hell , donc !
merci de vos explications détaillées, utiles !

(c'était bien un résidu de vieille mémoire, programmation des années 80 en GAP IBM... La règle était : si tu ouvres un Goto, veille à bien le fermer ! - Toujours fermer la boucle ! )

Bon, faut se mettre aux techniques modernes maintenant 
je m'y replonge, donc
 

[msport]

Un succédané : le break, au moins on sait d'où on revient.

[BB9004]

le goto c'est pas structuré, ça part dans tous les sens, mais pour devenir un real programmer, lire aussi :
http://www.bernstein-plus-sons.com/RPDEQ.html

Belle histoire    

+ wiki : https://en.wikipedia.org/wiki/Real_Men_Don%27t_Eat_Quiche

Bon, assez rigolé (pinaise, ça fait du bien !), au boulot !

 

[BB9004]

bonjour

Pour la gestion des entrées :
la réflexion du moment est partie de cette proposition de Jean Luc :
"Il n'y a qu'une loop, mais tu peux mettre chacune des options dans une fonction et, dans loop, appeler la fonction correspondant à l'option sélectionnée"

* Précision  > il n'y aura pas de retour d'informations au TCO : pilotage du warning "à vue" sur le décor
(je garde l'idée du "3 flash pour signifier le passage au DCC:  )

OK... Pour la Loop :

SI l'information d'entrée est donnée par un mini clavier (car le nb de possibilité augmente, il est de 14 actuellement, et donc un bouton rotatif - même en binaire - ne semble plus une solution - ou bien ce Pavé 16 fonctions), on a donc un chiffre "frappé" en entrée (paramètre "clavier" : ?).
Edit : je n'ai pas encore étudié les possibilités d'un Clavier numérique , qui semble plus approprié : ?

Puis- je alors utilisé la fonction "IF" pour gérer les actions fonctions ?
> du style : "IF le numéro choisi au clavier est 7, alors réaliser l'action la fonction n° 7"

exemple :
  if (clavier==7){
    digitalWrite(action7,HIGH); //ça active le "scénario" 7
    return;                             //sortie de la fonction
  }
et on enchaîne toutes les actions possibles à la suite les unes des autres : ?

et donc il y aura autant de IF que de choix possibles au clavier : ?? > maintenance / portabilité aisée ...

 plus une action "ce code n'est pas opérationnel" si l'opérateur choisi un nombre non associé à une fonction (ce qui conduit à gérer un petit LCD ... ça va finir en usine à gaz...) , ou plus simplement on l'envoie à la fonction "tout est éteint" ! (plutôt que de proposer un...  "GOTO Fin" !) 

-------------------------------
nota : état actuel du cahier des charges :
- - Pour les entrées : la liste des possibles s'allonge ...
> gestion manuelle :
- bouton rotatif à choix multiples, au TCO, ou proche de la scène d'action : cette possibilité s'éloigne vu le nombre de possibilités envisagées
- boutons poussoirs (1/choix) sur le TCO (idem) : mais trop de boutons = confusion, + cablages...
- clavier numérique
> gestion automatique :
- toutes les possibilités se déroulent en séquence (fixe OU aléatoire) , selon une période individuelle fixe (à déterminer - 30 secondes, pour ne pas lasser le spectateur ?), ou modifiable à volonté, par un curseur linéaire - ou un mini clavier - (au TCO) par exemple
- animation permanente, ou par cycle (timer)
> gestion via DCC :
- un décodeur, piloté par une multimauss par exemple, permettrait un choix parmi l'ensemble des possibilités

- - pour les sorties : la liste s'allonge aussi...
* option 1 : warning normal
* option 2 : cycle du warning de type "SOS" en morse
* option 3 : gestion d'1 ampoule HS (à l'avant, D ou G)
* option 4 : liaison et pilotage du choix du warning par un decodeur d'accessoires multi-fonction DCC
* option 5 : allumage des phares seuls
* option 6 : allumage des phares ET du warning normal
* option 7 : éclairage de la cabine du véhicule
* option 8 : "rampe" de lampes (bleues ?) sur le toit (avec, ou pas, variation d'intensité de la puissance d'éclairage) mais alors : époque 5 ou 6, pas avant
* option 9 : RIEN (je l'avais oubliée !) à mettre en premier : ne pas oublier la sacro sainte PAUSE des ouvriers !
* option 10 : warning + phares + cabine
* option 11 : soyons fou : avec sonorisation d'alarme ?
* option 12 : je n'ose même pas envisager  un ouvrier en train de réaliser une soudure à l'arc à l'arrière du véhicule... que
 l'on devinerait par la demi-porte ouverte ... Le prog de Christian Soudure à l'arc est tout prêt à intégrer la caisse à outil : faut "juste" lui trouver une place dans le fond de la camionnette... et à le compléter avec le buzzer proposé par Cardeau ... ?
* option 13 : warning + rampe de toit (bleue, avec variation d'intensité "faible/forte" - pour remplacer le mode "girophare")
* option 14 : phares + rampe de toit
* etc...

> Ce qui donne en nombre de Leds à gérer (et donc de PIN) : 12 leds > 12 fils + 1 masse : 1 nappe (Dupont) de 13 brins à passer de la caisse HO à la carte Uno (les résistances seront installées sous le plateau) :
- 4 leds oranges pour les Warning
- 1 led blanche (faible) pour la cabine
- 2 leds blanches (ou jaunes selon l'époque !) pour les phares Avant
- 2 leds rouges pour les feux Arrières (pas sur qu'il y ait assez de place pour tout loger dans une caisse HO...)
- 1 led blanche puissante pour la soudure à l'arc / ou une WS2812B, à calibrer au mieux, pour refléter cette intensité particulière ??
- 2 leds bleues pour la rampe de toit
- et 1 buzzer ? (pour accompagner les crépitements de la soudure)

> hum ?
(merci de vos avis, suggestions, commentaires, critiques, conseils  ...)