Messages

1

Modélisation, Architectures logicielles et matérielles / TUTO TCO en vidéo

« le: août 11, 2023, 12:06:01 am »

​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

Trucs & astuces / Re : Du vécu

« le: janvier 03, 2023, 12:36:58 pm »

oups ça craint en effet !
MERCI pour l'info, je commande et je brancherai !

3

Modélisation, Architectures logicielles et matérielles / Re : Pourquoi pas un Tableau de commande Opérationnel sous processing, clé en main !​

« le: janvier 02, 2023, 04:00:06 pm »

Bonjour,

Denis : merci pour ton retour.
Peut-être plutôt une question d'environnement qu'un problème de partage ? Chez moi, W10 et Firefox, ça fonctionne.
Autre explication possible : le lien n'avait pas les balises.

J'ai en tous cas modifié mon post pour y inclure des zips, deux premiers zip du moins car il en faudra deux autres que j'ajoute ici.

Christian : ton post m'avait échappé - je vais y aller voir ; on dirait bien qu'on a travaillé dans des directions voisines !

et mort aux relais !!

EDIT : lien corrigé, fonctionnel maintenant

4

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Denis

« le: janvier 01, 2023, 11:30:14 pm »

Oh!  le fil ressuscite ! Super car c'est bien surprenant qu'il n'y ait pas plus de monde sur un tel sujet... un TCO processing c'est pourtant vraiment top !

Le message de JPap (bienvenue à toi !) m'incite à mettre un partage mon sketch perso... Qui a tout de même hérité d'un ou deux gènes du "système de Denis" puisque l'interface graphique a gardé comme un air de ressemblance !
Mais il a une finalité et donc des fonctionnalités différentes de train-TCO, (raison pour laquelle j'ai finalement fait ma propre cuisine) qui sont expliquées brièvement dans le fil que je viens de créer.

Je vais toutefois vite regarder les développements de train/edit_TCO ! (je pensais que le projet était arrêté !?)

Et puis... bonne année tout le monde​ !

https://forum.locoduino.org/index.php?topic=1493.0

5

Modélisation, Architectures logicielles et matérielles / Pourquoi pas un Tableau de commande Opérationnel sous processing, clé en main !​

« le: janvier 01, 2023, 11:24:27 pm »

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

6

Débuter / Re : l'IDE Arduino dysfonctionne t-il soudainement chez vous ?

« le: juillet 16, 2022, 03:55:55 pm »

trouvé !

7

Débuter / Re : l'IDE Arduino dysfonctionne t-il soudainement chez vous ?

« le: juillet 04, 2022, 07:24:21 pm »

Merci... !
merci notamment à msport.. le grand moment de solitude hihi c'était exactement ça ! et j'ai remarqué que vous êtes bien souvent là sur le forum pour adoucir de tels moments de façon positive !
merci aussi à Jean-Luc pour son explication rationnelle du phénomène blink. C'est au moins un point réglé... mais ça n'est hélas qu'un point de détail. Le phénomène que je rencontre est bien plus exaspérant. Et ça n'est pas lié au PC puisqu'il affecte mes deux PC de la même façon, il y a donc un mode commun quelque part. Or rétrograder vers la dernière mise à jour n'est plus possible, je viens de regarder, car elle a plus de 10j... pourtant j'y croyais.

J'imagine que d'une façon ou d'une autre le problème sera réglé, encore une fois... mais que de temps et d'énergie mentale perdue (je crains qu'un jour le sursaut nécessaire pour "entretenir" ne devienne une aliénation insupportable. Dommage pour le plaisir de la bidouille et de la création... )
Je reviendrai dire comment. Ce qui me surprend et m'embête beaucoup est de m'apercevoir que je serais le patient zéro ? (nul à ce point ??)

8

Débuter / Re : l'IDE Arduino dysfonctionne t-il soudainement chez vous ?

« le: juillet 03, 2022, 08:08:01 pm »

Bonjour Dominique...

Le projet ? ça peut être du modélisme ferroviaire en pleine voie de tout mes posts ici... ou du tricot selon l'aide que je recevrai (j'espère). Mais pour le tricot je changerai bien sûr de forum !

Quant-au problème...
je reformule : un "truc" a changé dans la configuration de l'IDE Arduino et/ou, plus vraisemblablement de l'environnement Windows et je ne sais pas où chercher.
Je me suis donc mis en mode "débutant" incapable de configurer son Arduino.
Car peu importe la nature des codes (mais promis c'est du "ferroviaire"), le constat tel que je l'ai détaillé est indépendant du code et a concerné autant Teensy que AVR (moins gravement ces derniers)

j'ai voulu un titre accrocheur... mais d'accord pour le "modérer"

9

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 !

10

Débuter / Re : PCA9685

« le: février 11, 2022, 09:40:57 pm »

hihihi... +1 ! 

(on a tous débuté !)

11

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

« le: février 11, 2022, 09:35:54 pm »

... comparer les valeurs des interruptions n-1 et n ?
Oui je vois l'idée mais... non... ça donnerait juste une tendance ; il la faut pour les asservissements les plus performants, sinon c'est sans intérêt. C'est la comparaison instant "t" entre mesure et demande ("consigne") qui indiquera le sens de la correction à effectuer. Charge à  l'asservissement de calculer son intensité et à partir de là, palier de vitesse, accélération, ralentissement, pas de différence, c'est toujours le delta mesure_consigne qui sera la base de calcul de la juste PWM à appliquer.

Quant-à la problématique "capteur de présence"... bonne et déterminante question ! Sauf qu'elle est tellement vaste, je n'oserai qu'une qu'une réponse sommaire...
Déjà on peut éliminer les réseaux digitaux car sauf possible cas particulier je ne vois pas la place que pourrait y avoir un L298N... mais je ne connais rien au digital.
Côté analogique... ? Je n'ai jamais vu de post sur un réseau qui utiliserait le Vsensor des L298... je pense que ça s'explique comme cela :
- si on utilise des L298N en nombre égal à celui des trains possiblement en circulation - dans ce cas, la PWM(+polarisation) d'un train donné doit être adressée à la section électrique qu'il occupe au moyen d'une batterie de relais. Il n'y a donc plus de lien entre la mesure Vsensor et l'occupation ou non d'une section précise. (quid de la FCEM ? ça marche si c'est une motrice... pas si c'est un wagon, donc c'est mort)
- si c'est en nombre égal à celui des sections électriques : là c'est le code qui à mesure de l'avancement du train adresse chaque PWM/train "perso" au(x) pont(s) affecté(s) à la (aux) section(s) occupées. Et donc dans ce cas, si telle ou telle section est occupée, le code le sait déjà !

Le problème primordial de la détection demeure donc ! Et c'est choisir la technologie, puis les capteurs, mais aussi la façon dont seront utilisées les informations le but étant que le code puisse toujours se faire une représentation exacte du réseau.
Disons juste qu'il y a deux grands principes, qu'on peut d'ailleurs combiner :
- une détection par capteurs de consommation de courant. Mais problème avec les wagons... il faut graphiter les essieux (et prier) sinon le détecteur ne voit que les motrices ! Pour avoir une vision temps réel du réseau ces capteurs impliquent aussi je crois de les interroger en continue ;
- une détection par détecteurs de passage. Dans ce cas motrice ou wagon peu importe. On peut dire que le détecteur prend une photo => à partir de ces clichés, charge au code de tenir à jour un tableau des sections occupées, ça n'est pas sorcier. Mais la détection doit être infaillible sinon la catastrophe guette (la aussi).

Ni le Vensor ni la FCEM n'ont donc d'intérêt en tant que détection.
Mais...
il n'a été jusque là question que de l'occupation des sections. Outre réguler la vitesse, ce que la FCEM peut faire en prime c'est indiquer la POSITION d'un convoi dans une section donnée ! En effet, la FCEM renseignant en continue sur la vitesse, il suffit d'introduire la variable temps pour obtenir une distance parcourue (à partir par exemple du dernier détecteur de passage).

De quoi cogiter !

12

Débuter / Re : PCA9685

« le: février 10, 2022, 10:19:52 pm »

normalement cette seule instruction "pwm.setPWM(...)" devrait en effet fonctionner... à condition toutefois de ne pas avoir oublié (?) deux lignes dans le setup :

    pwm.begin();
    pwm.setPWMFreq(x);

Côté "hard", il est bon effectivement de se référer à l'article indiqué par msport pour que le pont soit correctement câblé, borne "enable" sur la sortie pwm "0" (dans ce cas du moins) du PCA et les deux pins de polarisation en boolean inverses, l'une à "1" et l'autre à zéro. (Et interconnecter tous les GND !)

13

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

« le: février 10, 2022, 09:56:00 pm »

Bonsoir,
msport a donné la version courte ;
une précision si besoin en est : le Vsensor renseigne sur la force électromotrice fournie au moteur (qui n'est pas précisément corrélée à son régime tr/mn)
Alors que ce que l'on cherche est la force CONTRE électromotrice, réinjectée par le moteur, en mode génératrice du fait de son inertie, lorsque le pont L298 ne l'alimente (brièvement) PAS. Or là, la tension recueillie représente parfaitement son régime.

14

Vos projets / Re : L298 et relais

« le: janvier 23, 2022, 12:00:06 pm »

merci de citer vos sources lorsque vous affirmez quelque chose

40 kHz c'est exact et je suis confus : l'information était corrompue, comme ma mémoire qui n'avait retenu que le fait qu'il était conseillé de ne pas utiliser les L298N au dessus de 25kHz.
La source était là : https://passionelectronique.fr/tutoriel-l298n/

Asservissement versus compensation de charge ?
Disons que dans votre auto, si vous mettez en route le régulateur de vitesse (supposons), c'est un asservissement - le système à partir d'une seule information initiale, la consigne vitesse, agit pour la maintenir constante en toute circonstances (dans certaines limites bien sûr)
Maintenant imaginons un système plus limité : 1) vous restez maître de la vitesse à tout moment 2) le "système" traduit cette consigne temps réel (enfoncement de l'accélérateur) en vitesse cible et "appuie" en renfort lorsque la vitesse constatée est insuffisante. C'est donc une compensation, qui intervient notamment lorsque la charge moteur augmente.

15

Vos projets / Re : L298 et relais

« le: janvier 22, 2022, 05:51:18 pm »

? Que désignent PWM1 et PWM2 ? La PWM étant de la "Modulation de la Largeur de l'Impulsion", le principe ("hachage") reste, quelque soit la fréquence adoptée
(une note à l'intention de babskwal qui utilise des L298 : ceux-ci ne pouvant pas commuter plus vite que 25 kHz, il faut oublier le 32Kz). EDIT : faux !! voir posts suivants
Je crois qu'il me manque de comprendre ceci : "je synchronise mes cantons sur le secteur redressé double alternance, soit 100Hz" ; s'agit-il de ce que cet article de l'AFMN appelle "alimentation à découpage à partir de l'alternatif" (voir lien plus bas) ? Dans ce cas ça n'est pas de la PWM mais ça doit ne pas faire de différence (?) pour ce qui de mesurer une FCEM.

Sur le sujet "asservissement", le fil de référence ici est celui-ci : http://forum.locoduino.org/index.php?topic=36.0

Ayant pour ma part échoué à le mettre en pratique, j'ai bifurqué vers de la compensation de charge ; une aventure développée ici : https://forum.locoduino.org/index.php?topic=1217.0
(La compensation de charge est d'ailleurs ce que sait faire couramment le décodeur d'une motrice digitale en mesurant "in situ"sa propre FCEM)

Hors Locoduino, L'AFMN traite également de l'asservissement de vitesse : http://amfn.nice.free.fr/alim.htm