Messages

91

Débuter / Re : du bon usage de la PWM...

« le: octobre 30, 2020, 05:18:23 pm »

Bonjour "Corail",

En plus de cette réponse, j'ai lu tes contributions et je te vois débuter... j'en suis à peine plus loin... mais avec une expérience et des compétences que je n'ai pas. Avec de plus un parc de locos qui me laisse pantois quand mes 28, pour ma part, me faisaient culpabiliser ! (un peu)
En revanche, je suis probablement plus avancé côté programmation et je m'efforcerai de t'aider de ce côté, éventuellement. Note juste que j'ai choisi l'analogique.

Ce que tu me réponds donc :
- quel moteur, pôles, balais...
Auparavant, autre précision importante je crois : je suis en "N". L'accès à ces informations me paraît (donc ?) bien compliqué sinon impossible, surtout sur des locos d'occasion. Mais même... est-ce que c'est indiqué dans les catalogues ? En tous cas ta question m'a fait y aller voir et, effectivement, il y a en pièces de rechange, des charbons pour moteurs "N" ! Je ne me vois pas aller y bricoler !!

Donc en clair, de quel(s) moteur(s) parle-on, je ne sais pas !
"moteurs bas en gamme"... (bas de gamme ?) je ne sais pas non plus : Fleischmann / Minitrix / Arnold ?

- FCEM :
si je comprends bien tes réponses, une tension élevée sera toujours préférable, vu du moteur. Donc, pour se limiter à des vitesses raisonnables, il n'y a pas de "risque" d'être en continu pur. Aujourd'hui ma tension rails (crête) est réglée à 10V. J'ai donc intérêt à la remonter à 12 ? (voire 14... secondaire de mon transfo, transfo postérieur à 1962 ! ... mais au nominal les locos sont prévues pour du 12V ?)

Ensuite, je décroche !

en fonctionnement analogique, une alim moteur via deux transistors (plutôt darlington) déplace la droite de charge et bride le moteur,

Je ne sais pas traduire mais mes rails sont alimentés par des booster L298N, cad des ponts de MOSFET en H. Voilà ce que je sais, ce que je ne sais pas c'est si ta remarque s'applique. A priori non ? car je suis dans le cas que tu décris plus loin comme un "fonctionnement numérique ?"

Par contre je "prends" ensuite cette remarque :

FCEM: Moteur à balais: elle est générée par le moteur .. selon son régime de rotation .. indépendamment de sa tension d'alimentation,

Une fois dit ça semble logique mais c'était bien de le rappeler ! Sauf que je ne sais toujours pas : balais or not balais. Mais j'ai au moins appris que ça va devenir important.
Pour ce qui est du problème du décrochage (je fais appel à de vieux souvenir... c'est la notion d'angle interne ?), ne pilotant pas en digital j'y serais donc exposé ... sur mes moteurs sans balais alors que j'en suis donc gravement inconscient ?

Merci pour... toutes tes réponses, présente et à venir

Philippe

92

Débuter / du bon usage de la PWM...

« le: octobre 26, 2020, 10:37:45 am »

... et de nos petites locos. Qui roulent comme des folles si l'on s'avise de leur appliquer du 12V, ~9V donnant des vitesses bien plus réalistes et raisonnables.

Alors comment les régulez vous ? (si l'on suppose une régulation par PWM) et que vaut-il mieux entre ces deux options ?
- à gauche du 12V mais une PWM bridée au cran +/- 200 pour obtenir un équivalent 9V
- ou à droite une tension rail limitée à 9V mais une PWM "débridée" ?
(la flèche rouge représente... bien mal... la réponse vitesse de la loco, avec une V_max identique dans les deux cas)



Sachant qu'il faut environ 3V pour que la loco "décolle", ça laisse dans le premier cas 130 à 140 crans effectifs de réglage (ce qui me paraît largement suffisant...)
Mais dans le second cas, toujours avec ce talon obligatoire de 3V (environ), on dispose de +/- 170 à 180 crans.
Ça ne me semble pas vraiment le bon critère ; ce que j'aimerais surtout savoir c'est si ce choix à des conséquences (*) pour le moteur. Par exemple est-il plus (ou moins) sollicité  avec la seconde solution ? moins coupleux ? Pas facile à mesurer ! mais la théorie donne sûrement la réponse ?

Et, car j'aimerais venir à l'asservissement, est-ce que cela aura une influence (*) sur la mesure de la FCEM ? Accessoirement si la valeur de la fréquence timer peut avoir une incidence (*) ?

Merci par avance de vos avis !
Philippe

(* oh pardon... un "impact" !!)

93

Débuter / Re : analogWrite qui ne fonctionne pas toujours correctement avec des LEDs

« le: septembre 21, 2020, 09:04:32 am »

bonjour,

Entrer dans le code d'autrui demande un sacré effort! En coup d'œil rapide, le problème ne se voit pas (d'autant moins que l'écriture est compactée à l'horizontale!) mais...

il est possible, ça arrive!, que les surprises ne viennent pas du code. Par exemple, qu'est ce qui est branché sur les input 2,3,7,8 ? des poussoirs? des détecteurs ? de quel type ? Dans tous les cas, une entrée aime généralement être fixée sur son sort par un pullup (de préférence). A voir peut-être?
(Une autre remarque d'ordre général en passant : les variables de temps ont tout intérêt à être déclarées en "unsigned long")
Bon courage, ça va marcher

94

Débuter / Re : IDE standard Arduino

« le: septembre 03, 2020, 01:39:12 pm »

Bonjour,

Notepad oui mais ça n'est pas la seule (ni plus simple) solution

il y a profusion de "thèmes" disponibles pour Arduino, par exemple :
https://www.dunebook.com/15-best-arduino-themes/

Il s'agit juste de remplacer un dossier


Bonne pioche !

95

Bus CAN / Re : Mémoire circulaire à l'émission pour un Bus Can

« le: août 24, 2020, 01:06:22 pm »

Re bonjour,

Merci pour vos deux réponses, je comprends que le contrôle du flux est impératif... forcément !

Ou en effet revoir la conception, ce qui se traduirait pour moi par un abandon du bus CAN et un retour à l'I2C, du moins sur l'ARDUINO-client problématique.
Qu'il avait fallu ajouter pour pallier le ralentissement, déjà, causé par deux afficheurs OLED 128x32 : avec une connexion I2C - sans "interruptions" donc - le sketch d'affichage se servait avec ce qui venait d'arriver et tout le monde vivait sa vie à son rythme.

Même avec le CAN ça n'est plus la même histoire : des datas qui arrivent à la modeste cadence de 100millis, 6 octets par message, "passent" si la routine d'affichage ne concerne qu'une ligne d'UN écran mais saturent le buffer dès que les deux lignes reçoivent un "oled.print". Avec un taux de rafraichissement dans tous les cas à peu près trois fois moindre qu'avec l'I2C...

Je ne suis pas du tout sûr de bien analyser le problème. Repasser à l'I2C me semblerait une régression mais je ne vois pas d'autre solution : ou peut-être la mémoire circulaire qui continue à me sembler pouvoir un être une ? C'est à dire un buffer FIFO intermédiaire, géré dans l'Arduino ? Si je pouvais avoir une confirmation, je creuserais volontiers.

En tous cas merci par avance pour vos commentaires
cordialement

96

Bus CAN / Re : Mémoire circulaire à l'émission pour un Bus Can

« le: août 23, 2020, 06:45:49 pm »

Bonsoir Monsieur Jean-Luc,

Moi pas blonde mais j'ai quand même vérifié, même AliBaba n'a pas ça, un tampon infini ! Sans parler du temps qu'il aurait mit à arriver car j'aurais aimé une solution plus rapide...

Il n'y a pas dans ACAN une petite astuce pour moi ? J'ai regardé le pdf en "extras" dans la library mais je n'ai rien vu alors que c'est FORCEMENT un problème que les concepteurs du bus CAN ont eu a résoudre et il y a donc... forcément... une solution ! (Hein ? "Non, un tampon == un tampon" ?)

97

Discussions ouvertes / Re : Clavier analogique multiple

« le: août 23, 2020, 06:03:29 pm »

Hello Antoine,
ah ben je suis heureux que ça marche ! Un peu surpris car sans bien savoir ce que ça fait ça me semble miraculeux... mais finalement pas surpris car je n'avais en fait pas besoin de le savoir !
Car c'est TON code et rien que ton code, je n'ai rien fait d'autre que l'organiser différemment.

Avec deux N.B. :
- dans le zip joint j'ai ajouté, juste pour la bonne forme, un "destructeur" car utiliser "NEW" implique de l'allocation dynamique de mémoire, qu'il faut absolument libérer si nécessaire sinon à force d'allouer sans libérer on crée de la "fuite de mémoire". Ça n'est pas le cas dans le présent sketch, on alloue une fois dans le setup et tout se libère automatiquement avec la fermeture du programme. Mais je ne sais pas si tu ne vas pas intégrer ce bout de sketch dans un autre, ni alors, comment, d'où l'avertissement en commentaire.
- et à cause de cette allocation dynamique qui implique des pointeurs pour la localiser, la fonction "switch" de ton code d'origine ne peut pas être utilisée (je saurai peut-être un jour expliquer pourquoi !), voilà pourquoi elle est remplacée par trois "ifs"

C'était vraiment un cas d'école ! Idéal pour te permettre de voir très vite comment passer de ta version à celle-ci car encore une fois, c'est ton code dans les deux cas.
Amicalement
Philippe

98

Bus CAN / Re : Mémoire circulaire à l'émission pour un Bus Can

« le: août 22, 2020, 04:46:52 pm »

Bonjour Patrick,
Peut-être suis moi aussi bon pour passer à une mémoire circulaire ?
J'ai en effet un arduino qui pousse des données plus vite qu'un de ses clients ne les consomme, ce qui fait que je sature très vite le buffer de réception et que le code se bloque. Je n'ai trouvé aucune solution pour consommer plus... produire moins oui, mais c'est pas vraiment le but !
"RingBuffer" est-il bien la solution à ça ? (gain de temps certain pour moi si vous me le confirmez !)

si oui, la seconde question est plus chère !... en regardant rapidement les méthodes (ainsi que le projet "labox" de Thierry), je ne vois pas comment greffer ça pour gérer des buffers CAN de MCP2515...
si vous l'avez fait et que je puisse avoir ce travail comme exemple, le gain de temps exploserait !

Merci par avance
cordialement
Philippe

99

Discussions ouvertes / Re : Clavier analogique multiple

« le: août 22, 2020, 04:25:44 pm »

Bonjour Antoine,
n'étant pas (pas encore je veux dire) un champion du C++ le problème, je le vois pas comme ça... d'autant qu'il faudrait faire le montage pour tester !

Mais une façon de régler ça serait probablement de sauter le pas vers un code "orienté objet" avec une classe très simple, par exemple "Poussoirs", dont tu lancerais 5 objets/instances "huit",

Code: [Sélectionner]

Poussoirs huit[5] la classe contenant deux méthodes :

Code: [Sélectionner]

int Poussoirs::lirePoussoirs()
  {...
      return nouvelEtatPoussoir ;
  }

byte Poussoirs::lireEvenement(int *numPoussoir)
  {...
     return evenement ;
  }
Si ça te branche on peut en parler.
cordialement
Philippe

100

Composants / Re : CJMCU-3216 : Le détecteur de proximité parfait ?

« le: août 13, 2020, 04:04:13 pm »

Attention Dominique,
ce NOA1305 fait uniquement détecteur d'ambiance et pas détecteur de proximité ; ça n'est pas le même capteur.

101

Composants / Re : CJMCU-3216 : Le détecteur de proximité parfait ?

« le: août 11, 2020, 07:16:16 pm »

Bonjour,

Je viens compléter et clôturer (pour ma part du moins) ce fil avec le rapport de mes dernières expériences concernant ce capteur CJMCU-3216.

Et ça n'est que du bon, avec un fonctionnement absolument impeccable.
Ceci en combinant bus I2C et bus CAN.

Ici une parenthèse pour commencer par remercier Jean-Luc sans qui etc... mais c'est "trop" vrai : sans ses articles, les chances de découvrir le CAN et surtout que je parvienne à le mettre en œuvre étaient quasi nulles !

Un "bus" I2C donc, ou plutôt un nœud, pour regrouper les détecteurs sur un multiplexeur TCA9548A (puisque l'adresse des détecteurs n'est pas configurable), en interface avec un nano "satellite", et autant de satellites que de besoin dans une logique de proximité nano-détecteurs. Chaque nano lui-même connecté pas bus CAN pour remonter ses données au "maître".
(une autre solution pour éviter le multiplexage, et à condition que le code ne demande pas une lecture en continu, pourrait être de créer une instance "AP3216" par détecteur et de les utiliser chacun en interruption...? je n'ai pas testé).

En résumé, voici les avantages de ces modules :
- la discrétion : pas plus large qu'une voie N, ils se glissent dessous, le détecteur en lui-même se loge entre deux traverses, au final ils sont quasiment invisibles (peuvent probablement l'être avec un ballastage)
- ceci, allié à leur coût modique, permet d'en mettre "à volonté" : un à chaque frontière de section/canton pour la gestion du trafic + (par exemple) deux autres, de part et d'autres, pour un arrêt précis au signal après approche préalable en marche lente. Ceci sans créer "une forêt" comme ç'aurait été le cas avec des barrières IR classiques.
- autre énorme avantage sur les barrières : la détection est suffisamment fine pour qu'un convoi à l'arrêt reste détecté même lorsque c'est un attelage qui est en surplomb du détecteur. Le risque de "trou" est donc éliminé.
- l'utilisation d'un bus CAN est certes une contrainte, mais remboursée par les communications double-sens qu'il permet par ailleurs et, surtout, elle élimine les aléas des transmissions I2C. Le comportement global est exempt de toute fausse détection au point que tout filtrage logiciel est devenu inutile.

Je pense donc pouvoir répondre définitivement par l'affirmative à la question "CJMCU-3216 : Le détecteur de proximité parfait ?"

Ce qui me semble une excellente nouvelle dans le domaine de la détection!

102

Trucs & astuces / Re : Câblage I2C et servos

« le: juillet 26, 2020, 07:05:35 pm »

... une solution extrême
https://shop.mchobby.be/fr/cartes-breakout/1079-extension-bus-i2c-differentiel-longue-distance-3232100010796.html

Mais bon à savoir tout de même, non?
(pour encore mieux apprécier le CAN)

103

Trucs & astuces / Re : Câblage I2C et servos

« le: juillet 15, 2020, 01:48:21 pm »

Bonjour,

étant ces temps ci particulièrement sensible à ce qui touche à l'I2C, j'étais obligé de regarder de quoi il était question !

et constater que je ne sais pas répondre aux questions, sauf pour la dernière : oui bien sûr, sous réserve que j'ai bien compris la question, peu importe que la tension provienne d'un nœud ou d'une antenne. Et aussi confirmer que, en effet, l'I2C est chatouilleux.
Pour le reste... chaque configuration ayant sa spécificité, j'imagine qu'il n'y a pas de réponse absolue. Je peux néanmoins confirmer qu'un bus I2C n'est pas sans surprises, mais je vois que vous êtes averti. Dans mon cas pourtant, ça n'est jamais sur le PCA9685 que j'ai eu des soucis.

Je signale au passage qu'il y a sur LOCODUINO des articles sur un sujet "satelliteV1" qui donnent à la fois à réfléchir sur l'organisation générale du contrôle commande et une parade possible aux problèmes récurrents des bus I2C. Solution qui répond de plus au souci de réduction du câblage.

Bonne lectures

104

Infos et bonnes affaires / Re : Capteur de proximité VL6180X

« le: juillet 10, 2020, 11:43:02 pm »

Bonsoir Tony
à peu près la même expérience...
Petit réseau de test équipé au départ avec des barrières IR (huit). Sauf que je n'avais pas pensé à la judicieuse mise en travers "haut-bas"...
Ça marchait... ou pas, mais au moins c'était clair : le montage n'étant guère stable, quelque chose avait bougé. Après... pas évident à régler quand même ces barrières !

Et puis passage aux CJMCU-3216 sur lesquels j'ai posté mes commentaires. Produit absolument parfait en lui-même, mais avec juste le défaut de communiquer via I2C, avec les soucis que tout le monde rapporte. Je m'en suis néanmoins tiré avec des lignes de code supplémentaires mais me voilà bien inquiet pour entreprendre un "vrai" réseau avec détection sur la base de ces modules.
Alors "adieu la belle technologie" ?
Et retour aux barrières IR, pas vraiment gracieuses avouons le... ?

Je pense à une solution mixant I2C et bus CAN (que j'ai juste commencé à expérimenter, c'est donc théorique mais sans rien de particulier)
- constituer des groupes avec ces détecteurs, idéalement de 8 (*) mais pourquoi pas moins, groupes basés sur la proximité géographique ;
- chaque groupe émettant sur un indispensable multiplexeur TCA9548A (* à 8 canaux), indispensable du moins pour les modules CJMCU-3216 qui ne sont pas adressables, pas indispensable dans le cas des VL53L0X qui le sont ;
- chaque groupe (ou chaque multiplexeur) étant lu par un NANO dédié ;
- et chaque NANO doublé d'une carte d'interface CAN, déversant sur un réseau CAN.
Une architecture modulaire donc et avec des composants très bon marché.

Ça devrait marcher qu'en penses tu ?
Si je parviens à mettre en pratique, je tam-tam ça tout de suite. (Mais ça n'est pas pour demain !)

105

Infos et bonnes affaires / Re : Capteur de proximité VL6180X

« le: juillet 10, 2020, 12:47:45 pm »

@ Tony04 :

Au sujet de ce problème de double adressage, connais tu ces tutos ?