Problème sur pilotage aiguillages par arduino via I2C

[VAUBAN38]

Les fichiers demandés sont prêts, mais malheureusement de taille largement supérieure à ce qui est admis en pièce attachée.

Les réduire et compresser ne résout pas pour autant le problème, et la lecture devient plus difficile !

J'ai donc opté pour les mettre sous Dropbox à cette adresse :

https://www.dropbox.com/sh/dig00xtle310cvi/AAB2YmgfiMhz19SYi1jUsMzha?dl=0

3 fichiers sont présents :
- Le schéma théorique qui reprend uniquement la carte n°1 (seule à être en test à l'heure actuelle) Les autres cartes sont réalisées mais ne sont pas connectées dans l'immédiat. Pour ce qui est de cette carte N°1 seul le MCP1 est mis en test. Le N°2 qui doit gérer des leds sur le TCO n'est pas utilisé (et même pas déclaré dans le sketch de test)
- Le fichier Fritzing de cette même carte mais dans la version réalisée physiquement sur une plaque à bandes cuivrées.
- Le fichier "test avec relais" correspond à la modification réalisée avant hier, "en volant" et avec les moyens du bord, correspondant à l'utilisation de relais intermédiaires pour alimenter en impulsionnel les aiguillages. Au passage l'alimentation en 16V ne transite plus par la carte (remplacée par du 5v)et le 16V peut repasser en alternatif au lieu du continu qu'imposait le passage via les ULN.

Je reste prêt bien sûr pour répondre à toute question complémentaire !

[VAUBAN38]

J'ai réalisé de nouveau des tests dans la configuration "de base" sans relais donc ce matin, et constate toujours les mêmes symptômes : déroulement des mouvements Droit/dévié pendant un temps plus ou moins long, puis blocage d'un aiguillage en Droit, et plus aucune activité physique mais le sketch continue à se dérouler.

En revanche, j'ai constaté tout à fait par hasard que je n'avais pas besoin de réinitialiser l'arduino en coupant son alimentation (comme je le faisais jusqu'alors), mais qu'il me suffisait de fermer la fenêtre du moniteur réseau et de la ré-ouvrir pour que l'activité reprenne ..... malheureusement jusqu'au blocage suivant !

Cela peut-il avoir un lien ?

[Jean-Luc]

Non

En effet quand tu fermes et rouvres le moniteur ça provoque un reset de l’arduino

Je ne vois rien de problématique sur le schéma si ce n’est les découplages des alimentation des 23017. Visiblement la charge inductive des moteurs des aiguillages provoque une fluctuation des alimentations qui plante les 23017 (c’est une possibilité).

Si après ajout des capas, le phénomène persiste, il pourrait être nécessaire d’ajouter des optocoupleurs entre les 23017 et les ULN.

[VAUBAN38]

Ok je ne savais pas que la fermeture du moniteur générait un reset ! J'aurais encore appris quelque chose !

Au moins une satisfaction : mon schéma est juste  !!

Ce que je n'arrive pas à déterminer c'est un peu l'histoire de la poule et de l'oeuf  : Est ce le MCP23017 qui se plante et bloque le déroulement physique (puisque le logique continue sa vie au vu du monitoring) ou les aiguillages qui se plantent et créent le dysfonctionnement ?

Les moteurs d'aiguillages Minitrix sont loin d'être d'une fiabilité à toute épreuve particulièrement quand ils sont positionnés "sous" table (ce qui est mon cas). Il semble d'après ce que j'ai pu voir sur des forums que le contact fin de course pouvait entre autres être plus ou moins fiable. Cela peut-il avoir une incidence ?

Quoiqu'il en soit , je vais donc commencer par ajouter les deux capas préconisées et je te tiens au courant du résultat.

Pour commencer à anticiper aurais-tu une référence d'optocoupleur à me proposer ? (l'idéal serait du 4 canaux pour s'adapter au mieux aux ULN)

Merci en tout cas pour le temps consacré 

Michel.

[Dominique]

Ok je ne savais pas que la fermeture du moniteur générait un reset ! J'aurais encore appris quelque chose !

Plus exactement, c'est l'ouverture du moniteur qui provoque le reset!

Dans mon montage à moi, les relais qui commandent les moteurs d'aiguille sont précédés d'optocoupleurs. Exemple :

http://www.ebay.com/itm/8-Channel-DC-5V-Relay-Shield-Module-for-Arduino-Raspberry-Pi-DSP-AVR-PIC-ARM-TO-/371861713855?epid=552272269&hash=item5694af73bf:g:M6YAAOSwo4pYI~G3

Même avec cette précaution, on n'est pas totalement à l'abris de parasites par induction ou d'une chute de tension au moment des changements d'état. Il faut penser à tout !

Pour moi, un programme ne doit pas se planter, je veux dire qu'il doit tenir compte autant que possible des aléas et être capable de se remettre d'aplomb tout seul. Dans mon cas je surveille l'état des aiguilles et je confirme leur position par un rafraichissement des positions d'aiguilles : 1 toutes les 10 secondes.

La notion de watchdog est très utile aussi pour surveiller le bon fonctionnement du programme. On peut partir de là pour faire un reset software quand il y a quelque chose qui cloche :

https://playground.arduino.cc/Main/ArduinoReset

Dominique

[VAUBAN38]

Dans mon montage à moi, les relais qui commandent les moteurs d'aiguille sont précédés d'optocoupleurs.

Mais ces modules sont activés par quoi ?
Il me semble en effet avoir lu que l'arduino n'offre pas suffisamment de puissance pour attaquer directement un relais ou un aiguillage. D'où l'utilisation des ULN.
Par ailleurs si il n'y a que 8 canaux, cela si je comprends bien ne permettrait donc de piloter que 4 aiguillages (sauf à prévoir 2 modules)
Faudrait-il donc partir sur une architecture MCP23017 / 4 ULN / 2 blocs 8 relais/optocoupleurs ? Cela devient un peu lourd, ou peut on directement passer du MCP aux modules ?
La solution que propose Jean luc d'intercaler un optocoupleur entre MCP et ULN (si j'ai bien compris) permettrait avec le rajout de 4 optocoupleurs 4 voies de piloter les 8 aiguillages via les ULN.

Pour moi, un programme ne doit pas se planter, je veux dire qu'il doit tenir compte autant que possible des aléas et être capable de se remettre d'aplomb tout seul. Dans mon cas je surveille l'état des aiguilles et je confirme leur position par un rafraichissement des positions d'aiguilles : 1 toutes les 10 secondes.

Bien d'accord, mais comment en analogique vérifier le bon positionnement des aiguilles ? D'autant que dans le cas présent le soft en lui même ne se plante pas mais continue à tourner normalement, mais  sans aucune efficacité.......

[Dominique]

Mais ces modules sont activés par quoi ?

Je vois que tu n'as pas lu ce que j'ai écrit !
http://forum.locoduino.org/index.php?topic=290.msg3412#msg3412

Les entrées des cartes relais (j'ai 44 relais !) sont directement connectées à des sorties de l'Arduino

[Dominique]

Bien d'accord, mais comment en analogique vérifier le bon positionnement des aiguilles ?

Avec des contacts de fin de course, par exemple.

le soft en lui même ne se plante pas mais continue à tourner normalement, mais  sans aucune efficacité.....

Ca prouve que le soft ne fait pas tout ce qu'il faut faire et ne vérifie pas qu'il est efficace.
Un soft qui ne se plante pas n'est pas forcément un bon soft.

[VAUBAN38]

Je vois que tu n'as pas lu ce que j'ai écrit !

Simplement perdu au milieu du bus CAN (que je ne connais pas) et du DCC (que je n'utilise pas) je n'ai certainement pas tout saisi, loin s'en faut ! D'ailleurs tu joues dans la cour "projet" et moi dans celle  "Débuter", çà démontre bien le monde qui nous sépare 

Pour le reste bien d'accord avec toi, mais pour rappel, je ne suis qu'en phase de test de la carte et des connexions, et le soft se résume à une simple litanie de High et LOW , porte par porte du MCP afin de vérifier que tout se passe bien .....Ce qui n'est justement pas le cas !

S'il est très efficace pour allumer et éteindre des leds, il bute malheureusement sur le pilotage des bobines, toute la question étant dans l'immédiat de trouver le pourquoi 

[Dominique]

Il n'y a pas de "cour" de débutants ni de confirmés chez Locoduino. Évitons les polémiques !

[Jean-Luc]

D’après les symptômes décrits :

• le programme continue son exécution, donc probablement que les messages I2C sont correctement envoyés,
   
• les aiguillages ne réagissent plus au bout d’un moment,

je pencherais pour un plantage du 23017 du à des fluctuations sur l’alimentation a cause des moteurs d’aiguilles

On en revient donc aux capas pour stabiliser son alimentation.

[VAUBAN38]

J'espère avoir le temps d'aller m'approvisionner demain chez mon fournisseur local habituel pour mettre ça en test.

Je vous donne le résultat dès que c'est fait.

[VAUBAN38]

Il n'y a pas de "cour" de débutants ni de confirmés chez Locoduino. Évitons les polémiques !

Je te rassure, il n'y avait dans mon propos aucune polémique, mais une simple plaisanterie ! (d'ailleurs suivie du smiley qui rit).
Je suis simplement conscient de mes toutes petites connaissances, et j'avoue être bien loin de tout comprendre dans le monde de l'arduino ou de l'électronique.

J'en apprécie d'autant plus les aides que vous me fournissez, et ne demande qu'a apprendre.

Dommage que les neurones vieillissant limitent parfois la compréhension et la mémorisation, mais j'essaye de m'accrocher !

[Dominique]

Bon courage 

[msport]

... toute la question étant ... de trouver le pourquoi ...

je verrais bien une pollution des registres I2C par les pics d'induction des electro-aimants (relais ou bobines).
Comme on a relevé que le protocole I2C n'est pas redondant, il faudrait peut-être compenser cela via programme. Donc de renvoyer l'initialisation E/S des MCP23017 périodiquement.

donc voir si en rappelant :
  mcp.begin();
  pinMode( xx, OUTPUT );

dans le loop, on remet le mcp sur les rails ...