Messages

46

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: mai 04, 2021, 08:11:10 pm »

Bonsoir,

Très content, ça se présente très bien.
D'abord, moteur bloqué ça fait bien FCEM zéro. C'était facile à vérifier puisqu'il pouvait y avoir un petit doute.

Mais surtout : le pont de diode est coulant. Sur un essai très basique certes, une seule loco, uniquement de la mesure (pas de rétro-action), FCEM prise directement sur un pont, la fourchette de valeurs est  plus favorable qu'espéré : +/-500 (sur 1023) à 200kmh vitesse vraie rapportée à l'échelle, +/- 20, assez constant, à 15kmh, ce qui laisse une bonne latitude de régulation. L'allure footing (soutenu!) doit être possible, faut-il qu'à basse vitesse la régulation ne pompe pas.

L'alternative avec deux lectures analogiques, je testerai sérieusement ; je suis bien d'accord que

C'est sans doute mieux

En attendant, 15kmh ça me semble déjà un ralenti impressionnant ? Est-ce au dessus de ce qui est couramment obtenu ?

Grosse campagne d'essais en perspective pour optimiser tout ça. Et d'abord, chic, du tricotage au plafond, entre deux tréteaux de 75cm.

Pour ce qui est de modelleisenbahn, je connais... quasiment depuis que je suis venu au monde (le monde arduino !) et les "quelques dizaines de kHz" c'était précisément une citation !
(Apparemment mes aimants ne sont pas néodyme !)

Et concernant ces relais qui ne devraient pas trop stresser, je ne dirai pas le contraire mais la question n'est pas celle là... c'est celle de MON stress  !

Merci pour tous ces retours.
Cordialement

47

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: mai 03, 2021, 02:20:36 pm »

Bonjour,

pour répondre à msport :
vitesse moteur 0 => FCEM=0, oui, mais vitesse 0 MOTEUR BLOQUE et FCEM=0... je n'ai pas fait attention et je ne me souviens pas ; je ferai le test car j'ai l'impression que si ça n'est pas le cas ça invaliderait toute autre mesure, c'est bien ça ?

et à Jean-Luc :
Le pont de diode est une évolution en cours d'essais ; précédemment OUT1 était lu sur A0 et OUT sur A1 (un "if" dans le code lisant la bonne pin, fonction de la (*)polarisation). Petit inconvénient, il faut 2x plus de fils et pins mais gros avantage : aucun seuil.
(*) Le pont H vient du choix de départ de n'employer aucun relai... mauvais vécu professionnel

Le pont de résistances : faute de compétences pour mettre en œuvre ton principe, je peux au moins les recalibrer si nécessaire pour diminuer le puissance consommée. Les essais in-vivo vont me renseigner.

Je ne comprends pas le choix d'une fréquence de 40Hz

mais moi pas vraiment ! elle provient historiquement de l'idée de tester un pca9685 et ses 16 PWM pour régler par la bande le problème du non synchronisme des timers Arduino.

Or ces modules produisent des PWM 60Hz... et ça a parfaitement fonctionné, je n'ai pas été chercher plus loin. Jusqu'à, sans refaire toute l'histoire, que je découvre qu'à 40Hz les locos "respiraient" mieux, meilleurs ralentis, plus rapides à PWM égale. Peu importe, 60Hz ou 40Hz la question est la même : comment est-il possible que ça fonctionne alors que "quelques dizaines de kHz" sont recommandées... ()

48

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: mai 02, 2021, 06:09:19 pm »

Bonjour,
Merci pour vos réponses ! C'est très stimulant, par les questions que ça ouvre et parce que je ne suis donc pas engagé dans une impasse.
Elles pointent aussi le fait que tout est dans tout ! Et c'est vrai qu'il y a loin entre des essais avec une loco sur banc (d'autant que dans mon cas, c'est indécent j'en rougis, banc veut dire loco sur le toit roues en l'air avec deux pins Dupont qui les lui chatouillent) et une loco au pas sur ses rails.

Point par point, je me permets de nouvelles questions/remarques sur vos observations.

MSPORT - Reste à vérifier qu'en fonction de la fréquence PWM adoptée, la rapidité de la conversion A/D (...) Mais j'imagine que cela a été pris en compte.

Eh bien non ! et j'avoue même car c'est grave que ça ne m'avait même pas effleuré !
Mais juste pour ceux qui n'auraient pas acheté ma précédente aventure, co-éditée avec Trimarco, je précise que j'ai refilé au CPU le soin de fabriquer sur mesure mes PWM (nativement synchrones donc... on partait d'un sujet sur ce problème) et à la fréquence très étonnante de 40Hz, optimum vérifié et revérifié. Cad 10 à 20 fois plus faibles que les PWM hardware... elles même encore au moins 10 fois trop faible par rapport à ce qui est universellement préconisé (il y a la un grand mystère que j'aimerais beaucoup qu'on m'aide à lever... il n'est pas possible qu'on parle de la même chose !)
Donc, partant d'essais OK faits avec des PWM à 490Hz, je ne redoute pas la transposition sur des ponts travaillant à priori sous 40Hz.

MSPORT - Un petit test à faire : un moteur bloqué (pas trop longtemps, je n'assume aucune responsabilité)

Le moteur avait déjà survécu au jeu du foulard, je ne chercherai donc pas de tiers responsable. Le but était de tester le coef de l'intégrale mais je crois que vous pensiez à autre chose ?

Jean-Luc - La grosse différence, au sens physique, est que dans le schéma que j'utilise la FCEM ne produit presque pas de courant (résistance de 100kΩ) et la tension reste aussi stable que possible pendant les mesures

Oui, gros souci. Ce qui est à redouter dans les résultats de l'expérimentation en réel, c'est une différence, à l'arrivée (des signaux tension reçus) suivant les sections électriques du fait de... contacts plus ou moins francs, incidence des longueurs de fils, différence de potentiel entre masses, parasitages etc... et pour en effacer le plus possible j'avais visé un courant relativement élevé (mauvais raisonnement?). Mais je peux facilement si vous le conseillez modifier le pont diviseur pour abaisser le courant sans modifier le ratio diviseur, cad la tension récupérée ?
(Pensez vous que pour le meilleur compromis pour la justesse des mesure soit de faire les relevés aux points d'alimentation rails ou plutôt sur les bornes des boosters ?)

Jean-Luc - Ici elle dissipe dans 1,22 kΩ. Et donc cette charge va contribuer à ralentir la loco pendant la mesure. Je ne sais pas si ça peut poser un problème

Je ne crois pas, parce qu'on parle de 400 micro-secondes et 4% du temps total ce qui rend déjà le ralentissement imperceptible et que si on parle de la marche "visible", sous 12V mes locos (N) vont toutes tellement trop vite qu'elles subissent un paramètre de bridage PWM individualisé. Il y en a donc sous le pied. Elles supporteraient d'ailleurs aussi d'être alimentées sous un peu plus que 12V, je ne pense donc pas qu'il puisse y avoir un problème.

Jean-Luc - La seconde différence est que lorsque la FCEM est inférieure au seuil de la diode, elle devient nulle du point de vue de la mesure. J'ai peur que le système ne soit pas capable de faire un ralenti très bas

Alors ça c'est ennuyeux ! d'autant que ça n'est pas une mais deux diodes que le courant de FCEM doit vaincre successivement n'est ce pas ? Pour le ralenti au pas, ou même "petit footing" qui m'aurait bien convenu, j'ai peur que ça soit cuit et que les essais le confirment. Mais il y a une parade car le pont de diode est facultatif, il a pour intérêt essentiel de n'avoir plus besoin que d'une pin quelque soit le sens de marche. La décision sera facile à prendre. D'autant qu'un réseau c'est, quoi?, au minimum 20 sections électriques et qu'il faudra de toutes façons multiplexer les entrées. (à moins que ça ne soit une nouvelle source de perturbation de la mesure ? à priori je ne pense pas)

Jean-Luc - Pour protéger l'entrée analogique, tu peux mettre une diode schottky entre A0 et 5V de manière à ce que si la tension sur A0 dépasse 5V + seuil, ça part dans l'alimentation au lieu de casser l'entrée A0

Ne pouvant être complètement rassuré sur le fait que ça n'arrive pas, c'est donc ce que je vais faire, je découvre, merci pour le conseil.

49

Vos projets / Asservissement de vitesse pour les (trains des) nuls

« le: mai 01, 2021, 07:56:35 pm »

Bonsoir,

deux ans (déjà!) de découverte et initiation et me voilà devant une difficulté redoutée : l'asservissement de la vitesse.
Pourtant indispensable car la conduite par la PWM c'est vraiment pas ça pour des ralentis ou des arrêts maîtrisés, trop de paramètres bougent, décidément impossibles à encoder en dur.

Le vrai problème, pour moi, c'est d'être sérieusement/gravement crasse pour tout ce qui touche à l'électronique/la théorie des moteurs, respectivement.
Impossible malgré du temps passé dessus de comprendre les schémas proposés par Jean-Luc dans le fil "un arduino par canton" ; j'ai renoncé à m'y frotter. J'aurais donc bien besoin d'un coup de main pour aboutir, quand-même, alors voilà où j'en suis.

A partir de cette page http://www.train35.fr/commande_moteur.html
et par tâtonnements j'ai pu arriver à ce montage, qui à l'air de marcher bien qu'on dise que "ce qui est trop simple ne peux pas marcher" (et ce qui est trop compliqué ne marche jamais)
voilà le schéma :


LA question est : est-ce que c'est viable ??
ensuite il y a d'autres question de détails, mais importants, est-ce que par exemple le Nano est protégé contre des risques imprévus ? Le calage un peu au pif du pont diviseur permet de ne pas dépasser 2.5V sur l'entrée analogique ce qui laisse une bonne plage de valeurs pour les calculs de correction mais est-ce que une zener par exemple ? ou un optocoupleur ?

Il est possible que l'expérience intéresse d'autres que moi ? je joins deux sketchs, le premier qui permet de tester la FCEM mesurée en fonction de la PWM appliquée à la motrice, le second qui à l'inverse conduit celle-ci par une consigne de FCEM et ajuste la PWM en conséquence.
(précision : je dois à Jean-Luc les variables de temps et la logique de filtrage des valeurs mesurées, merci à lui car c'est beaucoup de temps de gagné et surtout quelque chose que sans oscillo je n'aurais probablement pas pu déterminer)

Je me languis de vos conseils, avant de me lancer à passer de la paillasse à la planche !
bien cordialement, merci par avance

50

Discussions ouvertes / Re : Problème pour utiliser l'horloge externe du PCA9685

« le: mars 26, 2021, 09:35:59 pm »

Bonsoir...
ça fait donc deux bonnes idées, il est vrai qu'un coup de tamis fera du bien. Désolé d'avoir floodé !

51

Discussions ouvertes / Re : Problème pour utiliser l'horloge externe du PCA9685

« le: mars 22, 2021, 07:00:33 pm »

... ouf pas de sortie grillée ! (sur ma Teensy3.5 dont les pins RX/TX alternatifs sont brochés au recto, ce qui est heureux !)
j'avais ce matin déjà une réponse de Pierre Molinaro, dont cette version courte : Réponse courte : il faut que la patte STBY du MCP2562 soit à 0, sinon, par défaut, une résistance de tirage interne au MCP2562 la met au niveau haut, qui est le mode standby.

(La solution était toute bête, comme toujours ou presque, et ce qui est surtout bête de ma part c'est qu'elle était contenue dans un schéma récent de Dominique : https://forum.locoduino.org/index.php?topic=922.msg12443#msg12443 ) (réponse #418)

En cherchant les occurrences "teensy" sur le forum, je m'aperçois qu'elles sont très peu nombreuses et presque chaque fois très furtives, sans fil réellement dédié.
Je vais réfléchir s'il y a matière à en créer un, par exemple une fois que j'aurai bien en main la librairie CAN Teensy citée ici par Jean-Luc mais comme on est très loin du sujet originel c'est une info qui ne profitera pas comme elle pourrait. Façon de compléter par des aspects pratiques l'article du site sur ces cartes Teensy.

(et vivement l'opus 3 des articles ACAN !)
Merci pour ces interventions
cordialement

52

Discussions ouvertes / Re : Problème pour utiliser l'horloge externe du PCA9685

« le: mars 21, 2021, 06:18:18 pm »

Merci M Jean-Luc pour l'info ACAN pour Teensy. Je regrette d'avoir raté votre post mais pas grave puisque j'ai découvert cette librairie par ailleurs il y a ... deux heures !
Et je me suis permis de faire dans la foulée un mail à Pierre Molinaro (pour autant que l'adresse soit active) car je rencontre avec sa librairie exactement le même souci qu'avec "flexCAN", à savoir un Teensy qui lit sur le bus sans problème, et acquitte, mais ne sait pas écrite... j'ai mis tous mes moyens intellectuels sur le coup, ils n'y ont pas suffi et je n'ai plus de cartouche à tirer sauf d'acheter une autre carte "pour voir" !

Une petite question si je peux à propos de ACAN (celle des Arduino) ? J'y vais régulièrement voir sur site s'il y a des nouvelles de la note de renvoi 4: [4] Nous verrons les messages remote dans un prochain article aussi comme j'imagine que vous en serez l'auteur, eh bien je languis de cette publication à venir !

53

Discussions ouvertes / Re : Problème pour utiliser l'horloge externe du PCA9685

« le: mars 19, 2021, 09:46:43 pm »

@trimarco232 :
Bon plan merci ! (Pour pas trop cher!)
(le mega CORE était également une bonne suggestion, je ne connaissais pas non plus)

L'objectif en cours est néanmoins basé sur le Teensy 3.5 qui repousse très loin toutes les limites. Les librairies Arduino passent comme qui rigole, le code "shift-register-PWM" transféré sur Teensy tourne à une vitesse faramineuse... mais reste le problème du bus CAN. La librairie n'a rien en commun avec ACAN, les exemples sont peu nombreux, et abcons, et il y a 4 "variants" (tous anglais) de ladite librairie... j'ai eu beau labourer le web, pas moyen de se faire parler la teensy (via son CAN intégré) avec un Arduino, je suis au bord de l'appel au secours.

54

Vos projets / Re : Taille caractères sur afficheur "Arrivée Départ"

« le: février 16, 2021, 12:28:38 pm »

Bonjour,
ça semble être quatre lignes en 2X... paramètre par défaut ? Je n'ai pas vérifié. En tous cas la taille de caractère n'est pas paramétrée dans le .ino.

Vous aurez probablement vos huit lignes en y ajoutant :
    display.set1X();

Mais ça fera tout petit !!

55

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: février 09, 2021, 08:32:32 pm »

A signaler à toutes fins utiles... il semblerait qu'on puisse même se passer tout simplement de transceiver !

https://forum.pjrc.com/threads/43684-CAN-bus-Teensy-Teensy-communication-without-transceiver
https://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf

56

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: février 06, 2021, 04:47:15 pm »

Bonjour Dominique (c'est presque un message privé...)

Cette semaine, je cherchai un transceiver CAN pour interfacer non un ESP32 mais un TEENSY, ce qui ne change rien sur le fond.
Le souci que tu rencontres avec les CJMCU-230 n'est pas isolé, il y a des cas sur d'autres forum (mais tout de même, 1/5 c'est pas banal !)
(D'après ce que j'ai lu, le problème serait fonction du débit : https://esp32.com/viewtopic.php?t=380&start=170 )

Parce que j'étais impatient et avec le sentiment probablement illusoire d'un risque moindre, j'en ai trouvé UN (le dernier !) chez un vendeur France, relativement pas cher, toujours très rapide : commandé jeudi reçu ce midi : https://www.ebay.fr/itm/CJMCU-230-module-communication-%C3%A9metteur-r%C3%A9cepteur-bus-CAN-SN65HVD230-1345Z/293132899616?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2648

Pas de DCC ni donc de LaBox dans mon cas, je ne pourrai donc pas apporter de réponse à ta question.
Mais c'est moi qui en ai une ! Je ne peux pas utiliser ton code pour tester mon module. Mais y aurait-il un test tout simple, un test "de paillasse", qui distingue celui qui marche des 4 autres ? Car il serait trop beau que l'adaptation du code ne réserve pas aussi des surprises et alors comment savoir !
Si tu as une idée, merci d'avance !

57

Composants / Re : Décodeur sonore Hornby pour locomotives vapeur

« le: janvier 31, 2021, 09:17:29 pm »

Bonsoir,

Ben non, pas d'expérience approchante.
Mais faute d'autre réponse et parce que ça pourra quand même p'être servir (et plaire au petit fils ?), personnellement j'utilise la possibilité offerte par processing de jouer des sons.
Il faut donc un TCO sous processing, quelques conditions dans le code (quel son, quel loco, quelle moment) et les sons qui vont avec. Deux exemples en PJ (pour les voix, j'utilise google translate : il suffit d'écrire le texte voulu et d'enregistrer la lecture vocale)
C'est pas localisé dans la loco mais les possibilités sont infinies et tout ça c'est aussi gratuit que si c'était le père Noël

58

Discussions ouvertes / Re : Problème pour utiliser l'horloge externe du PCA9685

« le: janvier 21, 2021, 08:12:39 pm »

quoique...
un certain "milwind" fait remarquer que la pin XCK qui est en 48  est tout près de la pin de la pin 50 qui, elle, sort sur une broche et qu'il suffit juste d'un petit pont de soudure. Faut oser ! Il a osé.
https://forum.arduino.cc/index.php?topic=257506.0

(Mais pourquoi une PWM de pourrait-elle pas plutôt être utilisée comme signal d'horloge ?)

(et OK j'ai corrigé : je fais confiance à l'analyseur logique à 10 balles de Trimarco)

59

Discussions ouvertes / Re : Problème pour utiliser l'horloge externe du PCA9685

« le: janvier 20, 2021, 09:25:07 pm »

...while/if... le problème ne s'est finalement pas posé. Je pense que ça s'explique par la gamme de (basse) fréquence qui m'intéresse.

Je reviens donc pour déposer le code final : ça va décidément très très vite : avec une fréquence bridée par interruptions à 60Hz vérifiés/oscillo et pour 40PWM, la loop tourne elle à ...160 kHz! (perso, avec un petit réseau école c'est vrai mais toutes les fonctions d'un grand, ma loop prend 6ms... 6 comparé à 160, y'a de la marge ! et je suis d'ailleurs de plus en plus étonné par ce qu'un Arduino Mega a dans le ventre).
D'autres paramètres (prescaler etc) permettraient une plage de fréquence bien plus haute sans étouffer le CPU ; je fais confiance à l'estimation l'analyseur logique à 10balles de Trimarco.
 
Le SPI étant largement susceptible d'avoir d'autres usages que de la PWM logicielle, pour l'exemple le code pilote en parallèle des registres indépendants de ceux de la PWM, par exemple pour les pins de polarisation des boosters, pour des signaux etc.

Juste dommage que tout ça ne puisse marcher qu'à condition de ne pas avoir besoin du (seul) SPI harware pour un bus CAN (et très dommage qu'il manque juste une broche au Mega pour pouvoir en créer un second). Mais un SPI logiciel, même moins véloce, pourra quand même abattre du boulot.

Le code en pièce jointe (encore merci à Trimarco)

Bien cordialement

60

Discussions ouvertes / Re : Problème pour utiliser l'horloge externe du PCA9685

« le: janvier 19, 2021, 06:53:43 pm »

les "while" en effet mais le code ne tourne pas sans. On peut les enlever mais il faut alors ajouter un petit delay avant le latch, 10us au moins. En principe c'est pas très bon mais dans ce cas il y a un petit gain et le résultat égale quasiment des "SPI.transfer". Ce qui offre un choix

Là bien sûr c'est une performance brute avec une loop qui ne fait que ça (même pas vrai car j'ai testé l'ajout d'un second esclave, en prévision d'un "general purpose", rafraîchi toutes les 10ms, et c'est quasiment sans incidence).
Au final, le réglage de la fréquence PMW effective se fera par le timer2 et interruptions, ce qui a marché va resservir !

(Et comment on fait pour vérifier que les transferts sont effectués ?)