Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Sujets - simontpellier

Pages: [1]
1
​Bonjour bonsoir tout le monde,

Suite à ancien post de présentation d'un utilitaire de création de Tableau-de-Commande-Opérationnel... un TCO quoi, voici un lien vers une vidéo qui a vocation de démo et tuto de prise en main.



Après la création, plutôt que de se contenter de l'image brute du TCO créé, il restera à user de créativité pour ajouter une jolie image de fond. Le TCO y affichera uniquement en surimpression les pastilles couleur des statuts d'aiguilles et colorisation personnalisées des occupations de sections.

et voici le lien pour charger le code processing :
https://drive.google.com/drive/folders/18yBdrVHtfe3ZhrG2-hMqoNnGRjOqy5zO?usp=sharing

Bon amusement...

2
Bonjour, bonsoir
et bonne année à tout le monde !

​Sur un réseau, pas possible de faire l'impasse d'un tableau de commande (opérationnel tant qu'à faire), non ?
​Alors pourquoi, sauf à être bloqué à  l'époque III, ne pas ​adopter un TCO virtuel, graphique, sur écran ? Tactile de préférence.
Pourtant les sujets qui en parlent sont peu regardés, étrangement.

Mais je fais partie des rares convaincus et je remercie pour cela les pionniers Pierre59 et DDEFF qui ont développé des codes sous Processing (langage sous java, orienté graphisme)

A leur suite c'est logiquement Processing  également qui fait tourner mon propre TC... OPERATIONNEL!

Opérationnel car :
- il est à priori débogué... mais un bêta-testeur (merci d'avance) y mettra certainement des bémols. Et je tiendrai compte.
- il opère le réseau en permettant la commande des aiguilles et d'un pont-tournant, ainsi que la visualisations temps-réels des occupations de sections/cantons électriques par les différents trains présents.
Il offre de plus une visu globale, temps réel également, des tracés résultants des positions d'aiguilles ainsi qu'un compte rendu visuel des aiguilles en cours de mouvement (lorsque manœuvre par servo) et peut fonctionner en miroir d'un pupitre physique (dans ce cas il est indifféremment maître ou esclave). Ou sans la moindre commande physique associée. De plus, bien plus facilement qu'en câblage physique, il offre la possibilité de commander une aiguille individuellement et/ou dans un groupe d'aiguilles.
Il s'initialise en demandant au gestionnaire Arduino les paramètres de configuration en cours ; inversement il peut demander à "Arduino" de sauvegarder en EEPROM une configuration de réseau spécifique de façon à la retrouver à la prochaine session.

Pour profiter de tout ceci, la première étape consistera à reproduire schématiquement le tracé de son réseau, c'est simple et rapide via les fonctions d'édition (à noter qu'il est possible de représenter un niveau "caché", ceci grâce à un principe génial repris des créations de DDEFF). Puis à l'agrémenter éventuellement d'images de fond (qui pourront utilement comporter des repères ou toute inscription) ainsi que de mp3 ou wav de sonorisation, pourquoi pas ?

Restera ensuite à faire en sorte que le code Processing et le code gestionnaire du réseau se comprennent (les indications pour cela sont en commentaires dans le sketch) et le tour est joué.
(Ou presque... car il manque les compatibilités android  et IOS qui seraient sympa. Dans l'état c'est Windows... or les tablettes sont rares. Mais pas indispensables, un écran + souris ou tactile, et ça marche)

Nota : le dossier inclut un sketch de démonstration (à charger sur un Arduino) qui simule la "vie" d'un pseudo locodrome avec pont-tournant et illustre les infos échangées entre TCO et réseau.

Bonne prise en main, et si besoin j'y aiderai bien sûr.

Le dossier original étant trop gros pour être joint, voici un lien de téléchargement :
https://drive.google.com/drive/folders/18yBdrVHtfe3ZhrG2-hMqoNnGRjOqy5zO?usp=sharing

3
Débuter / l'IDE Arduino dysfonctionne t-il soudainement chez vous ?
« le: juillet 03, 2022, 06:41:20 pm »
Bonjour et SOS...

J'imagine que tout le monde a connu des moments de raz le bol...
là je craque "grave" et ... surprise ! je ne trouve rien ici qui traite de "mon cas" qui ne doit pourtant pas être isolé, ça n'est pas possible !

Voilà
Je suis exceptionnellement resté quelques jours sans éprouver le besoin de retoucher un code ou l'autre... jusque hier. Et là... PLUS RIEN NE COMPILE ! Ni Arduino ni teensy... et ça sur mes deux PC...

Je me souviens vaguement d'une mise à jour des cartes Arduino ? ça ne doit pas être ça car un downgrade n'a rien changé
Ainsi qu'une d'une mise à jour W10...
personne n'a eu de soucis récemment ??

Sur Arduino ça c'est réglé assez facilement... j'avoue que je ne saurais plus dire comment... il me reste tout de même l'étonnement de plus plus pouvoir faire fonctionner un vieux code blink de test qui contenait "byte LED_BUILTIN = 13;" et ça marchait, j'en suis certain !
Or plus moyen de compiler, maintenant seul #define LED_BUILTIN 13 passe la compilation (???). Pas grave.

Sauf que je suis maintenant principalement sur Teensy, 3.5 et 3.2 et là c'est bien pire :
- téléchargement et réinstallation de TeensyduinoInstall.exe... ouf ça marche !
... aïe ("M") une seule fois ! on peut télécharger un code mais la seconde fois produit le message "Une erreur est survenue lors du transfert du croquis - Could not run teensy_reboot.exe (CreateProcess error)"
- nouvelle installation ? Eh non.. refus "unable to write file "harware/tools/teensy_reboot.exe"
- redémarrage du PC et nouvelle tentative... ça marche (une fois. Etc etc)
- enfin ça marche... à peu près ! le code se charge et tourne mais le port USB est "offline"... pas de Serial ! "Unable to run teensy_serialmon"

Bien sûr il y a le forum Teensy... mais le problème semble plus général et peut-être y a-il une piste à laquelle je n'ai pas pensée ? (et puis ici on speak français !)
Ça me remotiverait ! car là j'ai des envies de plutôt de me mettre au tricot !

4
Composants / Benchmark MCU
« le: janvier 16, 2022, 03:03:51 pm »
Bonjour,

Je serais heureux de recevoir de l'aide pour devenir capable de bien choisir une carte, selon ses caractéristiques ET mes besoins propres ... aujourd'hui c'est au petit bonheur la chance !
Pour concrétiser rapidement ce qui a amené ce besoin : après être passé par différents matériels et configurations, mon MCU principal, gestionnaire, est aujourd'hui un Tennsy 3.5. Il est sollicité par beaucoup de tâches et s'en sort fort bien mais prend juste beaucoup de temps pour les communications I2C, au point qu'il serait vite coincé sur un réseau de bonne taille, d'où mon souci et ma question.

Sur le site PJRC, on trouve ce tableau de benchmark :


Je suis malheureusement incapable d'en tirer un enseignement... on y voit cependant qu'un ESP32 surclasse le Tennsy 3.5 (pour 10 fois moins cher !!)

Ayant des ESP32, j'ai donc tenté de retrouver dans des tests simplistes cette supériorité potentielle mais ça n'est pas sauf exception ce qui en ressort. (CPU speed sur : Teensy 120 / ESP 80)
Faudrait-il encore que ces tests aient un minimum de validité... un benchmark rigoureux est probablement une discipline, un art, à part entière...
Il doit néanmoins exister des critères élémentaires pour dégrossir la question ?
Donc grand merci par avance pour toute réponse.

Voici le code des tests perso avec les résultats :
/* POUR TESTS DE PERF */
uint16_t count = 0;
uint32_t timerTests = 0;

void setup() {
  Serial.begin(115200);
  delay(100);
}

void loop() {
  for (int f=0; f<1000; f++) {
/* test calculs*/
    float sqr = sqrt(f);          /* resultat TEENSY : 773 Hz / resultat ESP32 : 244 Hz */
/* test IO */
//    digitalWrite(4, HIGH);        /* resultat TEENSY : 1390 Hz / resultat ESP32 : 4074 Hz */
//    digitalWrite(4, LOW);
/* IO rapide - TENNSY 3.5 */        /*resultat TEENSY : 19633 Hz */
//    digitalWriteFast(4, HIGH);
//    digitalWriteFast(4, LOW);
/* IO rapide - ESP32 */             /* resultat ESP32: 9384 Hz */
//    GPIO.out_w1ts = ((uint32_t)1 << 4);  // HIGH
//    GPIO.out_w1tc = ((uint32_t)1 << 4);  // LOW

  }
  count++;
 
  if (millis()-timerTests >= 3000) {
    Serial.printf("%u Hz \n", count/((millis()-timerTests)/1000));
    timerTests = millis();
    count = 0;
  }
}

cordialement

5
Infos et bonnes affaires / ESP32 "bonne affaire"
« le: juin 03, 2021, 08:55:12 pm »
Bonjour,

ESP32... on lit des choses qui donnent envie d'essayer. Mais ESP32 c'est toute une famille alors qui adopter ? J'ai ...opté pour un 38pins (tant qu'à faire) à 3,20euro pièce :
https://fr.aliexpress.com/item/32959541446.html?spm=a2g0s.9042311.0.0.63916c37cLotyv
plus 3Xrien pour le port (pourtant reçu en moins de 15j) et accompagné, pour simplifier les essais, d'un shield d'expansion :
https://fr.aliexpress.com/item/1005002363013005.html?spm=a2g0s.9042311.0.0.63916c37cLotyv

Sauf que... dans la famille ESP32 certains sont plus costauds que d'autres... et les miens sont trop larges pour les cartes d'extension ! (d'un pas "dupont", 2.5mm, argh...)

Les ESP32 je ferai autrement par contre les shield (il y en a deux) je ne m'en servirai jamais mais je n'aime pas jeter.
Aux dernière nouvelles, ils seraient prévus pour des ESP Vroom (?).
 
Si quelqu'un en à l'usage, je les cède pour rien, juste le prix du timbre pour l'expédition.

Qu'on se le dise.

Cordialement






6
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

7
Bonjour à tous,

Grace à un sujet initié par Minimir09, j'ai compris l'intérêt de Processing 3 pour dessiner un TCO, ceci à un moment où je commençais à réfléchir à cette question dans la perspective d'un projet en gestation.
Processing, mais aussi et SURTOUT les articles de Pierre Lecouffe. Et son code, je le remercie vivement d'avoir mis son travail (dont le niveau bien bien avancé me passe bien bien au dessus de la tête... !) à disposition. Si le code est fort trapu, l'utiliser est un jeu d'enfant !

J'ai vu aussi que l'auteur répond volontiers aux questions "d'après-vente" or j'en ai une. Plus une remarque.
La remarque concerne les pavés d'angle. Lorsqu'on veut paramétrer un rayon supérieur à 1, le pavé d'arrondi inférieur droit pose le problème suivant :
contrairement au coin supérieur droit qui est obtenu par symétrie du pavé "catalogue", l'inférieur droit demande une rotation. Or celle-ci se réserve des cases à droite, autant que la valeur du rayon. Et il n'y a pas moyen de redéfinir ensuite le nombre de colonnes pour récupérer ces colonnes perdues, ce qui est sûrement un peu ennuyeux pour les grands réseaux.

La question concerne en revanche mon utilisation personnelle de ce code. Plutôt que de visualiser l'état des signaux, je voulais afficher les occupations de cantons/sections, par train et par un code couleur. N'ayant pas réussi à "bricoler" le code pour ajouter un attribut à chacun des pavés? à renseigner au moment de la construction du TCO (un attribut contenant donc le numéro de section attachée à ce pavé), j'ai fait quelque chose de certainement peu élégant.
Le "corrigé" m'intéresserait beaucoup !

Dans l'état, ça marche pourtant et je trouve ça très "fun", de plus c'est super pour déboguer le code Arduino !
Voici un mp4... disons que par ces temps confinés il fallait bien s'amuser un peu !



Cordialement
Philippe S
(me voici mûr pour passer au "système de Denis" !)

8
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 Vmax 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" !!)



9
Composants / CJMCU-3216 : Le détecteur de proximité parfait ?
« le: avril 30, 2020, 10:39:52 pm »
Bonjour tout le monde

Premier post, alors je commence par un grand merci à tous les contributeurs et un énorme merci aux locomotives de ce site. En partant de zéro, arduino et C++, c'était mon cas il y a un an, Locoduino est une bénédiction.
Aujourd'hui j'ai peut-être à mon tour une contribution à apporter.

De lien en lien, je suis tombé un jour sur un détecteur I2C encore jamais évoqué ici semble-il, peut-être pas parce qu'il est généralement vendu comme détecteur de luminosité  : le CJMCU-3216.

Mais c'est aussi un DETECTEUR DE PROXIMITE. Long long délai d'attente (chine + premier envoi perdu...) mais la patience valait la peine, je crois qu'il n'a que des avantages !

- Il est MINUSCULE, au point de se glisser sous la voie entre deux traverse MÊME en échelle N ;
- il détecte parfaitement UN ATTELAGE, CONVOI A L’ARRÊT OU NON ;
- il semble indifférent aux conditions de luminosité (ou pas) ambiante ;
- et il coûte presque rien.
Seul petit inconvénient (peut-être), il fonctionne au maximum sous 3,5V.

Voici la merveille. Qui va remplacer les barrières infra-rouge encombrantes, inesthétiques et parfois gaffeuses (petites gaffes mais gros bazar).


(Ça n'est encore qu'un circuit d'expérimentations. Faute de ballast, la planche est décaissée de 2mm pour loger le composant)

Ce détecteur est paramétrable.
A minima il faut le déclarer comme "détecteur de proximité en continu" (paramètre PS). Et ça suffit pour qu'il marche très bien. Je n'ai pas assez testé l'intérêt des autres paramètres sauf celui de la SENSIBILITÉ qui, en la réglant sur 4 plutôt que 2 (réglage par défaut), m'a permis la détection à tout coup des attelages (attention,  Je parle pour le N... doute pour le HO).

Exemple pour "n" détecteurs. Le " tcaselect(i)" se rapporte à l'indispensable multiplexeur vu que le composant n'est pas adressable, ce qui est normal vu sa taille. Puis il faut un proxSensor.init(); par détecteur et donc le déclarer "PS" ; le reste est facultatif.

for (byte i(0); i<n; i++)
    { tcaselect(i) ;
      proxSensor.init();
      proxSensor.setMode(PS);                       // PS: proximity sensor continous
      proxSensor.setPSGain(4);                      // Choose between 4 gain values: 1, 2(default), 4, 8 : higher gain increases sensitivity as well as noise - 2 is good.
      proxSensor.setNumberOfLEDPulses(2);           // Choose between 1(default),2,3,4 pulses of LED IR for proximity : more pulses increase (slightly) the max. distance
      proxSensor.setPSMeanTime(PS_MEAN_TIME_50);    // Meantime (milliseconds) for proximity measurement : _50, _37_5, _25 or _12_5 ; longer meantime provides less spreaded values
      proxSensor.setPSIntegrationTime(8);           // This function helps to increase the max distance. Choose value between 1 and 16.
    }

Bien sûr , on peut préférer un paramétrage individuel, en fonction d'exigences de détection différenciées.

En sortant un peu du sujet mais pas complètement et pour ceux qui auraient des problèmes de lenteur en I2C : je signale qu'avant de réussir à faire fonctionner ce senseur sur mon bus I2C déjà sollicité (transmission de données d'un MEGA vers un NANO + affichage sur OLED) j'ai eu de  gros soucis liés à la library ADAFRUIT des écrans SSD1306. Il y a des références sur le net à des problèmes de lenteur ces afficheurs ; c'est ce que j'ai connu dès le deuxième écran, le MEGA qui faisait "tout" tourner, pourtant pas grand chose, a paru d'un coup très fatigué. D'où le NANO, dédié à l'affichage... faute de bien avoir bien analysé le problème. En tous cas pb réglé... jusqu'à ce que j'ajoute un CJMCU3216 sur le bus (sur un autre multiplexeur TCA9548A avec bien sûr son adresse propre).
Impossible de faire cohabiter le tout. Des conflits sur le bus créaient un proportion importante (+- 20%) de données aberrantes, tant sur les écrans que que les CJMCU.
Avec de plus le problème toujours présent d'un rafraichissement extrêmement lent des afficheurs : 180ms par OLED, soit 360ms pour deux, à l'extrême limite de l'acceptable.
Jusqu'à trouver cette autre library ; SSD1306AsciiWire : (https://github.com/greiman/SSD1306Ascii
- de 360ms m'a loop est passée à 70... puis 40 avec un peu d'optimisation ;
- plus aucun conflit ;
- en prime, disparition de menus problèmes dont des artefacts sur les écrans.

Pour tester de détecteur, voici par exemple où je l'ai commandé : https://fr.aliexpress.com/item/32817340841.html?spm=a2g0s.9042311.0.0.2df16c37QV8oNx

Pour ma part, l'essayer fut l'adopter.

10
Présentez vous ! / Présentation perso et présentation "projet"
« le: septembre 16, 2019, 09:37:24 pm »
....................
sans intérêt


11
Débuter / PMW et timers ... pour débutant
« le: mai 31, 2019, 09:42:45 pm »
Bonsoir,

Ce site est décidément une mine ! Les perspectives que j'y ai entrevues sont... exaltantes ! Merci d'avance à tous les auteurs. Et à ceux des fils et articles que j'ai déjà exploités.

Pour l'instant, mon préalable à tout projet est de disposer d'une alimentation fiable et agréable.
Et j'y suis... presque. Par la grâce de la PWM.
Ayant compris pourquoi nos motrices n'aiment pas trop le 490Hz standard des cartes Arduino, j'ai plongé dans la littérature sur les timer. Assez pour comprendre les tenants et aboutissants... mais sans aller jusqu'à ouvrir le datasheet du processeur (comme parfois recommandé) !

Je suis sur un Arduino Mega. Pour obtenir une PWM à 4Mz ou 31 Kz, j'ai donc intégré à mon code l'une OU l'autre des deux commandes suivantes, opérant sur le timer 3 :   
TCCR3B = TCCR3B & B11111000 | B00000010;
TCCR3B = TCCR3B & B11111000 | B00000001;   

et j'aimerais une explication de ce que je constate, sur une motrice Jouef HO (+/- 1990)

- par rapport à la PWM 490 hz, pas de différence d'un point de vue sonore. (mais j'entends mal les aigus)
- pas de différence non plus en ce qui concerne la capacité à tenir un ralenti très lent.
- mais la grosse différence par rapport au 490 (que ce soit en 4 Mz ou 31kHz) est que la motrice "décolle" beaucoup plus tard : avec un rapport cyclique autour de 30% dans le premier cas, plus ou moins le double pour les hautes fréquences de PWM.

J'imagine que cela tient aux fronts de montée/extinction du signal ? Mais au delà de l'explication théorique j'aimerais savoir si c'est "normal" et surtout, s'il y a une solution car dans l'état, la plage d'utilisation des 256 valeurs de PWM devient fort réduite et la conduite moins agréable.

J'espère ne pas avoir ouvert un sujet intempestivement mais une recherche consciencieuse ne m'a pas permis de trouver une discussion traitant de cette question.
Merci par avance de vos commentaires !

Philippe


Pages: [1]