Auteur Sujet: Rétrosignalisation  (Lu 4192 fois)

DDEFF

  • Sr. Member
  • ****
  • Messages: 459
    • Voir le profil
Re : Rétrosignalisation
« Réponse #15 le: mai 20, 2017, 07:23:29 pm »
L'idée principale de Pierre59 est qu'il y a deux diodes tête-bêche dans l'optocoupleur.

Ce qui fait que ce système marche dans tous les cas.

Par contre, si on a un optocoupleur avec une seule diode interne, ça ne peut plus marcher qu'avec du courant alternatif (dont le DCC) et mal : il ne marche que la moitié du temps !
Disons que ça n'arrange rien avec les mauvais contacts.

Je propose :
http://www.tme.eu/fr/details/h11aa4x/optocoupleurs-sortie-analogique/isocom/
En en achetant 65, tu n'est plus qu'à 0,24 € pièce.
Note aussi l'adresse du site : TME (énorme choix, prix très bas et fourniture en 2 ou 3 jours maxi)

Le TLP620 existe toujours, même chez TME, mais un peu plus cher.

Solution la moins chère :
http://www.tme.eu/fr/details/ltv844/optocoupleurs-sortie-analogique/liteon/ltv-844/
Il y a 4 optocoupleurs dans le même boîtier.
Il suffit de faire un circuit imprimé pour 4 zones.

5,20 € d'optocoupleurs pour les 40 zones...  ;D

Tant que tu y est, achète aussi les diodes et les résistances
Et les connecteurs pour tes fils.
Tu as les traditionnels "dominos pour CI"
http://www.tme.eu/fr/details/282834-2/borniers-de-serrage-pcb/te-connectivity/

Mais tu as aussi un truc génial parce que facilement démontable :
http://www.tme.eu/fr/details/tbg-5.0-pw-2p/borniers-de-serrage-deconnectables/xinya/xy2500v-b50-2p/
et
http://www.tme.eu/fr/details/tbw-5.0-k-2p/borniers-de-serrage-deconnectables/xinya/xy2500f-a50-2p/
Bien sûr, c'est un peu plus cher.
Mais quand tu as grillé quelque chose sous le réseau, c'est très facile à démonter. ;D

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1454
  • 100% Arduino et N
    • Voir le profil
Re : Rétrosignalisation
« Réponse #16 le: mai 20, 2017, 11:25:47 pm »
Denis à raison :
Citer
Par contre, si on a un optocoupleur avec une seule diode interne, ça ne peut plus marcher qu'avec du courant alternatif (dont le DCC) et mal : il ne marche que la moitié du temps !
Disons que ça n'arrange rien avec les mauvais contacts.

Mais pour les mauvais contacts, le condensateur chargé dans le circuit d'entrée à transistor de l'opto-coupleur ajoute une constante de temps qui va les supprimer complètement. Il compense aussi le fait qu'une seule alternance est utile.

Je pense que les 2 types de capteurs se valent, et la comparaison est difficile car il faudrait tester les deux.

DDEFF

  • Sr. Member
  • ****
  • Messages: 459
    • Voir le profil
Re : Rétrosignalisation
« Réponse #17 le: mai 21, 2017, 10:04:08 am »
Si on va jusqu'au bout, on peut certainement se passer de condensateur et rattraper le coup par programme.

Souvent, ces circuits ont été inventés avant les Arduinos, à l'époque où on ne jurait que par l'électronique.
Il fallait donc nettoyer électroniquement le signal.
C'est sûrement une bonne idée quand on a un signal complexe à gérer. Un peu de nettoyage ne nuit pas.
Mais pour une détection de présence, on n'a pas plus simple : ON/OFF.

De plus, quitte à acheter des optocoupleurs, autant en acheter des à diodes tête-bêche. ;)
Je pense que le système minimaliste de Pierre59 suffit.

Denis

Pierre59

  • Full Member
  • ***
  • Messages: 118
    • Voir le profil
Re : Rétrosignalisation
« Réponse #18 le: mai 21, 2017, 01:40:08 pm »
Bonjour

Voir ci-dessous l'image d'un exemple de réalisation avec le schéma proposé (8 exemplaires), de droite à gauche on trouve :
- un bornier à vis 9 poles (un commun + 8 entrées)
- huit ponts redresseurs (plus pratique que 8 fois 4 diodes)
- huit résistances de limitation
- deux optocoupleurs quadruples (TLP620) sur support
- une barrette SIL avec les 8 résistances "R" (enfichée)
- un multiplexeur (74HC151)
- des condensateurs de filtrage du 5V et du signal de sortie du multiplexeur (éventuel)
- un bornier à vis (alimentation 5V)
- un connecteur RJ9 pour la connection avec l'Arduino (un fil de donnée et trois fils d'adresse)

Le tout monté sur une plaque à bandes. Cela permet d'équiper huit zones en détection de courant. On peut facilement multiplier ces montages pour multiplier les zones, par exemple avec huit montages on obtient 64 zones qui utilisent 8+3=11 pins d'un Arduino.

Pierre

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1454
  • 100% Arduino et N
    • Voir le profil
Re : Rétrosignalisation
« Réponse #19 le: mai 21, 2017, 04:24:16 pm »
Merci Pierre,

Nous voilà avec une contribution bien illustrée sur les capteurs de présence par consommation.

Un futur article est prévu sur ce sujet, mais sur l'ensemble des capteurs et leurs applications au modélisme ferroviaire.

Merci à Denis d'avoir secoué le cocotier et à Catplus et Tierra Calientes d'avoir posé et alimenté le sujet.

J'espère que ce n'est pas fini  ;D
Amicalement
Dominique

DDEFF

  • Sr. Member
  • ****
  • Messages: 459
    • Voir le profil
Re : Rétrosignalisation
« Réponse #20 le: mai 21, 2017, 08:32:29 pm »
J'irais donc plus loin. ;D
Le problème étant que je veux à tout prix raccourcir les fils, je propose l'idée d'un module qui ferait détection + signaux.

Pour une zone, on constate que le meilleur système, le plus sûr, est celui de la SNCF : la détection par consommation de courant**.
C'est ce dont on vient de parler.
Là, toute autre solution ponctuelle est moins bonne (ILS, photomachin ou photobidule, effet Hall, RFID, ...).
On a toutes les peines du monde à gérer le cas des wagons perdus et d'autres problèmes. Il y a toujours un cas qui foire.
Donc, détection par consommation de courant.

Par contre, on aimerait bien avoir aussi une détection que je qualifierai de "détection de proximité de signal", souvent appelée "zone d'arrêt".

Première idée :
Couper les rails et mettre deux détecteurs de plus, un pour chaque sens si la zone est banalisée.
Problème : ça n'est pas facile à faire, surtout en N (mon cas) et moins on soude de fils sur les rails mieux on se porte : on risque de faire fondre les rails et c'est moche.
Et ce serait une zone de détection courte, donc d'autant plus sujette aux mauvais contacts.

Deuxième idée :
On remarque que cette détection n'a d'intérêt que dans un sens : vers le signal !  ;)
Et là, le défaut majeur des détections ponctuelles disparait.
Au contraire :
Pas de rail à couper, assez facile à planquer (surtout effet Hall).
D'où mon appellation de "détection de proximité du signal" et pas "détection de zone d'arrêt".

Donc, 3 détections par zone : une détection de consommation de courant et deux par effet Hall.
Et 3 entrées de l'Arduino.

Occupons nous maintenant des signaux.

Pourquoi mélanger ?
A cause des fils courts : tout est à peu près au même endroit.

A minima, 6 entrées d'Arduino : 3 feux à chaque extrémité.
Parenthèse : avec du Charliplexing, on diminuerait le nombre de fils. Voir à ce sujet :
http://lestrainsdutertre.redheberg.com/TouteVapeur/Les_trains_du_Tertre/Entrees/2011/1/7_Les_cibles_des_signaux.html
Je trouve ça génial.
Mais un seul et unique défaut : vu le câblage spécifique, vous devez construire vos feux vous même.
Ce qui peut d'ailleurs ne pas être un défaut, vu le prix des signaux.  ;)

Sauf réseau vraiment particulier, vous arriverez à ce qu'on ait pas besoin de plus de 12 fils pour les deux signaux d'une zone banalisée.
Moyennant quoi, un seul Arduino suffit pour une zone.

Un Pro Mini vaut 1,81 €
http://www.ebay.fr/itm/1Pcs-Pro-Mini-Atmega328-3-3V-8M-Replace-Atmega128-Arduino-Compatible-Nano-New-Z-/252408518534?hash=item3ac4b85786:g:l2IAAOSw4GVYHcVd
Un nano vaut 2.45 €
http://www.ebay.fr/itm/Nano-V3-0-ATmega328-16M-5V-Micro-controller-CH340G-board-For-Arduino-no-solder-/351213381226?hash=item51c5f2e66a:g:f3UAAOSwPcJVR3rF

Au passage, j'ai aussi trouvé ça :
http://www.ebay.fr/itm/CH340G-USB-a-UART-TTL-Serial-Adaptateur-Cable-Module-Pour-Arduino-Pro-Mini-BA-/302035588668?hash=item4652b9563c:g:LnYAAOSwHoFXp9mO

Donc, ce module va commander tout ce qui se passe sur une zone.

Reste à le faire communiquer.
Bus CAN à 2.18 € :
http://www.ebay.fr/itm/MCP2515-CAN-Bus-Module-Board-TJA1050-receiver-SPI-For-51-MCU-ARM-controller-FQ-/162331344973?hash=item25cbb3c04d:g:AMMAAOSw65FXqH2G

Personnellement, je suis convaincu de l'usage de câble Ethernet inter-modules et prises RJ.
D'ailleurs, c'est la norme LCC (pour l'instant). :-*

Denis
** Pour être précis, pour la SNCF, c'est plutôt par non-consommation de courant. Cela revient au même, sauf que la non-consommation est plus sûre.
« Modifié: mai 22, 2017, 03:08:54 pm par DDEFF »

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1454
  • 100% Arduino et N
    • Voir le profil
Re : Rétrosignalisation
« Réponse #21 le: mai 22, 2017, 05:08:12 pm »
Ah l'obsession des fils courts !

Citer
Le problème étant que je veux à tout prix raccourcir les fils

Loin de moi l'idée de polémiquer car c'est mieux de toute façon d'avoir les fils les plus courts car ils ramassent moins de parasites  >:(

Cependant il y a un paradoxe : plus ton réseau sera grand et plus il y aura des longs fils, c'est imparable !

La question devient alors "comment connecter les entités éloignées ?"

Tu mentionnes le réseau CAN qui est effectivement fait pour ça. En plus c'est du multi-point qui permet de répartir les entités concernées à plusieurs endroits, donc d'éviter la centralisation.
Le bon exemple, à mon avis, est ce que Jean-Pierre a décrit dans son article "Une Passerelle entre le bus S88 et le bus CAN pour la rétro signalisation" http://www.locoduino.org/spip.php?article180
On y voit des détecteurs de consommation associés chacun à une interface CAN et des concentrateurs (gateways) qui récupèrent les signaux sur le bus CAN (je fais abstraction du protocole S88).

Est-ce mieux que de tirer des fils entre un Arduino en charge de la rétrosignalisation et tous les capteurs de consommation ?
Car la surcharge logicielle n'est pas mince, avec la mise au point. Et pourquoi pas une réseau CAN spécifique rien que pour la rétrosignalisation.

Je ne suis pas contre, mais...

Il y a une autre technique qui se prête assez bien à une gestion centralisée (en étoile) qui est basée sur la faible impédances des liaisons : la sortie d'un optocoupleur est un transitor collecteur ouvert qui peut débiter au moins 10mA. On peut donc le relier au +5V via une résistance de 470 Ω voire 1KΩ. On a donc juste 2 fils (torsadés de préférence) qui relient la sortie du détecteur de consommation à l'Arduino (entre la résistance reliée au 5V et une patte de l'Arduino).

C'est ce que j'ai fait sur mon réseau : un Mega collecte toutes les sorties des capteurs de consommation. Ca peut courir sous le réseau jusqu'à 3 à 4 mètres. Je n'ai jamais constaté de perturbations.

Pourquoi un Méga plutôt que plein de petits Mini ou Nano ?

Parce que c'est plus simple à programmer, qu'il a 80 ports, 256K de Flash et 8K de Ram, de quoi faire de bons programmes sans risque de mémoire insuffisante. Oui il est 2 à 4 fois plus cher qu'un Nano ou Mini, mais il en remplace bien plus que ça.

Mais chacun fait comme il veut ou peut  :D

Je vois sur ce forum et d'autres un certain intérêt pour une gestion "par canton" (un Arduino par canton, voir par exemple http://forum.locoduino.org/index.php?topic=36.0 et http://forum.locoduino.org/index.php?topic=291.0).

Dans ces deux cas c'est justifié car la gestion de chaque canton ne se résume pas à la détection de consommation.

Dans mon cas, j'ai choisi une gestion par fonctions (traction, rétrosignalisation +TCO, commandes d'aiguilles, commandes des signaux, gestion du décor, le tout sus le contrôle d'un gestionnaire). Le bus CAN chez moi relie ces grandes fonctions.

Mais l'un n'empêche pas l'autre ...
Les choix sont multiples et Locoduino est là pour éclairer le lecteur sur les différentes possibilités.


tierra calientes

  • Newbie
  • *
  • Messages: 7
    • Voir le profil
Re : Rétrosignalisation
« Réponse #22 le: mai 23, 2017, 08:45:02 am »
Bonjour, les propositions de DDEFF et Dominique ont retenu mon attention.
DDEFF propose le bus Can qui fait appel à plus de programmation mais pour quelqu'un qui n'en a jamais fait ou à peine il y a très très longtemps sur Commodore 64, c'est peut être un peu compliqué mais avec un peu d'aide peut être que.... . J'ai pourtant lu et relu " Une passerelle entre le bus S88 et le bus Can pour la rétrosignalisation "
En utilisant la proposition de Dominique la détection est un peu plus sophistiquée mais cela ne me dérange pas. En ce qui concerne la programmation
qui pour lui est plus simple, comment y accéder et l'adapter à mon circuit ?
J'ai commandé et attend un kit Arduino Mega 2560 et j'ai trouvé sur le net "Arduino pour bien commencer en électronique et en programmation fetch.php "
J'en suis au début et je rame déjà un peu. Quand le kit sera arrivé j'espère que la pratique m'aidera un peu.
Bonne journée.

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1454
  • 100% Arduino et N
    • Voir le profil
Re : Rétrosignalisation
« Réponse #23 le: mai 23, 2017, 09:14:42 am »
Bonjour,

Du désir à la solution, il y a toujours quelques étapes intermédiaires que vous devez envisager :

- vous familiariser avec l'Arduino et son IDE : lisez, relisez et testez plusieurs exemples tout faits du plus simple au plus sophistiqué, jusqu'à ce que la syntaxe du C, la compilation, le televersement et les tests le soient toujours avec succès.

- décrire en détail votre projet, les entrées, les sorties, les fonctions, en n'oubliant rien, sur du papier, avec un crayon.

- programmer petit à petit en testant fonction par fonction. Réalisez quelques outils de test au passage.

Vous verrez que cela se passe bien.

Bon courage


DDEFF

  • Sr. Member
  • ****
  • Messages: 459
    • Voir le profil
Re : Rétrosignalisation
« Réponse #24 le: mai 23, 2017, 09:25:41 am »
Bonjour tierra calientes,

Je trouve ta réaction très saine : faire au fur et à mesure.
C'est la meilleure méthode.

Le principal défaut de ma solution est qu'elle n'est actuellement que dans ma tête.
Elle suppose en particulier un gestionnaire de réseau complet basé sur le bus CAN, gestionnaire dont je connais les grandes lignes, mais qui n'existe pas encore.
Et nous travaillons en ce moment avec Pierre59 à peaufiner un TCO novateur et simple (... d'emploi !) qui sera lié à ce gestionnaire.
J'ai donc, en ce moment, peu de temps pour terminer d'autres choses.
Mais comme j'en aurai besoin pour mon propre réseau, j'irais jusqu'au bout.

En attendant, le détecteur de Pierre59 a fait ses preuves et celui de Dominique aussi.
Il y a énormément de personnes qui travaillent avec un MEGA, qui en sont tout à fait satisfaites et c'est un bon moyen de débuter.
Tu trouveras de nombreux articles pour t'aider sur le site de Locoduino.

N’hésite pas à revenir vers nous si tu as un problème.

Pierre59

  • Full Member
  • ***
  • Messages: 118
    • Voir le profil
Re : Rétrosignalisation
« Réponse #25 le: mai 28, 2017, 05:48:52 pm »
Bonjour

Voici un programme simple de "filtre numérique" pour le schéma proposé précédemment, le programme est prévu pour une seule zone (mais peut être facilement étendu). L'idée de base est la suivante :

- lors d'une détection d'occupation celle ci est transmise immédiatement à celui qui la traite
- lors d'une détection de libération une temporisation de quelques secondes (1, 2 ou 3 s) est mise en oeuvre avant de la transmettre à celui qui la traite

Quelques complications sont nécessaires pour palier la mauvaise qualité du signal sortant de l'optocoupleur, ainsi que les mauvaises prises de courant des engins moteurs (ou remorqués)

Voici le programme pour un Arduino:

const byte pin=1; // choix de la pin d'entree
const int retard=3000; // retard a la liberation (milis-secondes)
unsigned long temps; // pour la temporisation

void setup() {
  pinMode(pin,INPUT); // mise en entree
  temps=0; // initialisation
}

void loop() { byte x;
  x=digitalRead(pin); // lecture de la pin
  if (x==0) { // occupation de la zone ?
    if (temps==0) Serial.println("occupation de la zone");
    temps=millis(); // re-armement de la temporisation
  }
  else { // liberation de la zone ?
    if (temps!=0 && millis()-temps>retard) { // pas libre et temporisation echue ?
      Serial.println("liberation de la zone");
      temps=0; // re-initialisation
    }
    // else rien (la liberation est toujours temporisee)
  }
}

On a besoin de deux constantes et d'une variable :
- le numéro de la pin utilisée
- le retard à la libération
- un temps qui sert à mettre en oeuvre le retard à la libération (temporisation)

Le setup() règle la pin en entrée et initialise le temps.

Le loop() teste indéfiniment l'état de la pin :

- on lit la pin, si c'est zéro c'est une occupation (le transistor de l'optocoupleur fait une inversion)
   - si le temps est à zéro c'est un début d'occupation, on transmet l'information à celui qui la traite
   - dans tous les cas on mémorise dans temps le temps courant (pour la temporisation de libération)
- sinon (pin à un) c'est une libération
   - on regarde si on est au bout de la temporisation (pour palier la mauvaise qualité du signal sortant de l'optocoupleur, ou les aléas de prise de courant), si oui la libération est transmise à celui qui la traite et on remet le temps à zéro

Celui qui traite les occupations/libérations de zones ne reçoit une information que lors d'une vraie occupation ou d'une vraie libération de zone, ceci grâce au "filtre numérique" mis en oeuvre.

On peut facilement prendre en compte plusieurs zones (plusieurs dizaines, voire centaines) en adaptant le programme et en utilisant plusieurs pins de l'Arduino, on peut aussi utliliser des mutiplexeurs, des registres à décalage, … pour utiliser moins de pins de l'Arduino. Il faut faire néanmoins attention à l'encombrement mémoire, chaque zone a besoin d'une variable "temps" qui fait quatre octets, par exemple pour 64 zones cela fait 256 octets (1/8 de la RAM d'un Uno !).

Avec plusieurs zones le loop() teste une zone après l'autre indéfiniment, il faut que ce temps de traitement soit suffisamment bref, une prise en compte rapide des occupations est par exemple nécessaire pour une poursuite en canton en analogique (voir l'article http://www.locoduino.org/spip.php?article184).

L'horloge de l'Arduino, donc le résultat de millis() repasse par zéro tous les 50 jours environ, lors de ce retour à zéro le filtrage numérique peut avoir un comportement erratique (on pourrait améliorer le filtrage pour palier ce problème).

Quand on démarre un Arduino (mise sous tension ou reset) l'horloge repart à zéro, et il faut un délai de 1 ms pour que le filtrage fonctionne bien (la valeur zéro est utilisée comme cas particulier pour économiser la mémoire).

On pourrait mettre en oeuvre un filtrage plus contraignant, par exemple en exigeant un signal d'occupation pour plusieurs passages successifs dans le loop() (avec un compteur) avant de transmettre une vraie occupation.

Pierre



« Modifié: mai 29, 2017, 02:21:26 pm par Pierre59 »

CATPLUS

  • Full Member
  • ***
  • Messages: 173
    • Voir le profil
Re : Rétrosignalisation
« Réponse #26 le: mai 29, 2017, 01:00:56 pm »
Bonjour Pierre
Je viens d'installer le programme cité ci-dessus. La seule réponse du PC à l'affichage (à une vitesse folle) "libération de la zone"
STP Peux-tu donner un peu plus d'explication.

Cordialement
Marcel
Best Regards

Pierre59

  • Full Member
  • ***
  • Messages: 118
    • Voir le profil
Re : Rétrosignalisation
« Réponse #27 le: mai 29, 2017, 02:28:51 pm »
Bonjour

J'ai corrigé deux erreurs :

- un == à la place d'un = dans l'occupation
- un test supplémentaire dans la libération (pour vérifier que la zone n'est pas déjà libre)

J'ai fait quelques essais, cela a l'air de mieux marcher (je n'avais pas testé !)

Pierre

CATPLUS

  • Full Member
  • ***
  • Messages: 173
    • Voir le profil
Re : Rétrosignalisation
« Réponse #28 le: mai 29, 2017, 07:08:25 pm »
Les nouveaux tests ont l'air concluants
A suivre.  :)
« Modifié: mai 30, 2017, 09:54:10 am par Dominique »
Best Regards

tierra calientes

  • Newbie
  • *
  • Messages: 7
    • Voir le profil
Re : Rétrosignalisation
« Réponse #29 le: juin 04, 2017, 04:29:38 pm »
Bonjour, comme il faut avancer, je vais partir sur "Une Passerelle entre le bus S88 et le bus CAN pour la rétro signalisation".
J'ai reçu mon matériel (mega 2560 et quelques accessoires).
J'ai choisi "fetch.php pour bien commencer avec Arduino" pour les notions de bases et on y va.
J'espère y arriver en y allant calmement.
Merci pour l'aide. ;)