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 - bobyAndCo

Pages: [1] 2
1
Bus DCC / Passerelle CAN/WiFi-TCP/Serial
« le: novembre 05, 2019, 03:05:08 pm »
Bonjour à tous,

Je viens de finir ma passerelle entre les réseaux CAN et TCP (WiFi) et aussi série sur base d'ESP32. L'ensemble est disponible sur le Github de Locoduino : https://github.com/Locoduino/CAN_WiFi_gateway32

Ce projet avait été initialisé pour Orléans 2018 sur la base d'ESP8266. Ici, il s'agit d'un ESP32 et d'un module CAN SN65HVD230 qui simplifient considérablement le montage et son cout puisque cette passerelle me revient à 6€ au total !

Il est donc possible de lire les trames CAN qui circulent sur un bus avec des applications reliées, soit en WiFi, soit en Ethernet ou soit encore en série. Et il est inversement possible d'envoyer des trames CAN avec ces mêmes applications.

J'avais présenté à l'époque un TCO sous forme de page Web qui, relié avec les 8 satellites du Locoduinodrome, se mettait à jour dynamiquement. J'utilise toujours ce projet qui est visible ici

J'utilise pour cette vidéo un sketch chargé sur un autre Arduino qui envoi en boucle et à raison d'un message par seconde les mêmes messages que les satellites avec les détecteurs d'occupation (consommation et ponctuels). J'ai poussé le débit des messages au rythme de 1 message toutes les 100ms et la réception TCP n'a pas bronchée.

J'avais aussi montré comment il était possible de faire les réglages des satellites à partir d'une page web :

Pour ma part, c'est un outil très important et mes futurs recherches vont aller dans le sens d'une gestion automatisée de mon réseau sur une base de données (qui existe déjà) et qui va être en interaction directe avec les périphériques CAN (satellites).

C'est aussi ce type de passerelle qui pourra être mise en œuvre par ceux qui voudraient interfacer JMRI avec le bus CAN et les satellites par exemple.

Je ne dispose que peu de temps malheureusement pour faire des présentations plus détaillées (voir cependant sur le Github), mais je peux au travers de ce fil apporter des précisions à tous ceux qui souhaiteraient mettre en œuvre une telle architecture.

Je suis intéressé également par toutes les propositions d'amélioration.

Christophe.






2
Trucs & astuces / Cohabitation 5V - 3,3V
« le: août 22, 2019, 08:49:42 am »
Bonjour à tous,

Ma question concerne la cohabitation de courants en 5 et 3,3V dans un même montage et devrait concerner de plus en plus de monde avec le développement des cartes en 3,3V.

Je viens de terminer l'automatisation de mon pont tournant avec un ESP32 (en 3,3V donc).



J'utilise comme carte moteur un Pololu 4990 qui peut s'alimenter de 2 à 5,5V pour ce qui est du courant de commande (VCC).

https://www.pololu.com/product/2137/pictures#lightbox-picture0J5015

J'ai placé sur mon montage (alimenté en 12V) deux convertisseurs, un en 5V, l'autre en 3,3V. Le 5V me sert pour 2 capteurs à effet Hall et 2 LEDs. Jusqu'ici, j'ai fait touts mes tests en alimentant la carte Pololu à la même tension que l'ESP32 (3,3V) mais il serait bien que je puisse mieux équilibrer les charges et j'ai pensé alimenter la carte Pololu en 5V.

Pour mes capteurs à effet Hall (5V) vers ESP et mes LEDs, j'ai des transistors, mais pour les quatre sorties moteur de l'ESP vers Pololu, je n'ai pas vraiment la place pour mettre des transistors.

Pensez vous que ce soit dommageable pour l'ESP si j'alimente la carte Pololu en 5V sachant que le courant est "sortant" de l'ESP vers le Pololu ? Est-ce que les broches de l'ESP sont tout de même exposées au 5V ?

Merci pour vos réponses ou autres propositions.

Bien cordialement.

Christophe



3
Bonjour à tous,

J’ouvre ce nouveau fil suite à un commentaire à l’article sur Une station DCC complète, polyvalente et économique avec JMRI : http://www.locoduino.org/spip.php?article253 où Jean évoque des problèmes de lecture et de programmation de CV avec JMRI, mais qui est en réalité relèvent de DCC++.

C’est un problème que j’avais soulevé il y a maintenant plus de trois ans, que Dominique aussi à rencontré, et puis comme on a toujours plus ou moins réussi à contourner le problème, c’est quelque chose que l’on a jamais approfondi et pour lequel, de fait, on n’a jamais trouvé de solution.

Si quelqu’un a la solution, nous sommes bien sûr preneur. Dans la négative, je souhaiterais que ceux qui connaissent ce problème puissent contribuer à établir un inventaire des marques de décodeurs concernés et éventuellement des modèles. Il semble bien que cela ne concerne que certains fabricants et pas d’autres.

Il est intéressant de savoir si ces problèmes sont cantonnés à la seule voie de programmation ou concernent aussi la voie principale, et de savoir également, sur la voie principale, quels sont les CVs qui peuvent être reprogrammées.

Enfin, toute proposition qui pourrait contribuer à trouver la réponse est bien sûr la bien venue.

Merci par avance.

4
Vos projets / DÉPLACÉ: Interface Arduino JMRI Cats
« le: juin 23, 2019, 07:40:57 am »

8
Bibliothèques / DÉPLACÉ: Bibliothèque C/MRI
« le: juin 21, 2019, 03:03:39 pm »

10


JMRI (Java Model Railroad Interface) est un projet de contrôle de réseaux ferroviaires par ordinateur au travers d’une suite d’applications comme PanelPro pour piloter des locomotives et assurer la gestion de réseau ou DecoderPro, un puissant outil de programmation des décodeurs.

Dans l’esprit et la philosophie, JMRI a de nombreuses affinités avec l’Arduino et Locoduino bien sûr. C’est tout d’abord un projet open source qui se développe grâce à un certain nombre de contributeurs.

JMRI permet de tirer pleinement parti de DCC++, autre projet open source particulièrement puissant et apprécié à Locoduino.

Cette nouvelle rubrique a été créé à la demande de membres de Locoduino qui sont utilisateurs de JMRI et contributeurs actifs, en particulier sur le forum. Un premier article, mais certainement pas le dernier, a été co-rédigé par Nopxor qui est un utilisateur expert : http://www.locoduino.org/spip.php?article240

L’idée est de déplacer et regrouper ici les différents fils répartis sur l’ensemble du forum et concernant JMRI. Que les initiateurs de ces fils n’hésitent pas à nous faire savoir si nous avons oublié d'en déplacer certains.

Par la suite, les contributeurs dont le sujet touche essentiellement à JMRI pourront créer leurs fils dans cette rubrique.

Ce premier fil pourra être utilisé quand la création d’un nouveau fil ne se justifie pas, l’annonce d’une nouveauté ou la mise à disposition de liens vers les très nombreux articles disponibles sur le web et concernant JMRI et l’Arduino par exemple.

Bien amicalement à tous et profitez pleinement de notre passion commune.

Christophe

11
Le logiciel DCC++ / L9110S Dual Motor Driver pour DCC++
« le: juin 18, 2019, 02:18:33 pm »
Bonjour à tous,

Dominique m'avait fait découvrir il y a quelques temps cette carte moteur tout à fait impressionnante et, comme vous le voyez, très économique qui s'adapte vraiment bien à un environnement DCC++



La carte est vraiment parfaite visuellement ce qui est un apriori favorable sur ses qualités intrinsèques.

Un atout et non des moindres, c'est que cette carte existe en 10A et en 15A ce qui est intéressant pour des réseaux qui comptent entre 10 et 20 locos actives simultanément (en HO).



Elle dispose de deux entrées (DIR et PWM) et de deux sorties distinctes ce qui veut dire qu'elle peut alimenter à la fois les voies principales et une voie de programmation ce qui en fait une carte très complète à l'instar de la POLOLU MC33926 qui coute trois fois plus cher et est trois fois moins puissante !

Vous veillerez cependant à modifier le câblage ou le programme car il n'est possible de monter qu'un seul MAX471.

Il n'y a en effet qu'une seule entrée de courant de puissance (fil rouge et fil noir sur la photo). Aussi, la sortie AT du MAX471 devra t'elle être distribuée sur A0 et A1 ou mieux, le programme modifié dans le fichier DCCpp.h

  #define CURRENT_MONITOR_PIN_MAIN A0
  #define CURRENT_MONITOR_PIN_PROG A0

Pour exploiter la carte avec des tensions importantes, vous aurez aussi à régler le seuil d'intensité maxi dans CurrentMonitor.h

La valeur par défaut de 300 correspond approximativement à 2A de charge, vous pouvez donc augmenter selon vos besoins, mais tout en restant prudent.
#define  CURRENT_SAMPLE_MAX         300

7A à 8A me semblent des charges raisonnables, au delà, il faut, à mon avis, se poser la question de diviser le réseau donc les sources d'alimentation.

12
Discussions ouvertes / Pour servos d'aiguillages en impression 3D
« le: novembre 06, 2018, 09:08:05 pm »
Particulièrement pour ceux qui ont des imprimantes 3D, je trouve ce principe intéressant et facile à mettre en œuvre pour fixation sous le plateau. Il n'est certainement pas très difficile non plus d'ajouter un système de butées de fin de course si l'on souhaite alimenter les cœurs d'aiguillage.


https://blog.arduino.cc/2018/10/29/linear-movement-with-arduino-and-3d-printing/


13
Le projet :

Le projet s’inscrit dans l’ensemble du projet Locoduinodrome et en liaison tout particulièrement avec le développement des cartes satellites.
 
Il s’agit d’un TCO très interactif qui offrira une représentation précise et en temps réel de l’état du réseau.

Ainsi par exemple, les segments de voie qui sont occupés sont représentés par une couleur particulière avec l’icône de la locomotive concernée.

La représentation de la signalisation lumineuse elle aussi sera très fidèle à ce qui est affiché sur le réseau. Et cela vaut également pour les positions des aiguillages.

Il est également prévu que ce TCO puisse permettre de piloter certains accessoires du réseau comme les aiguillages et donc de modifier en conséquence la signalisation ferroviaire.

L'architecture générale :

Le TCO s’alimente des différentes informations qui circulent sur le bus CAN du réseau.

Il peut bien sûr filtrer les seuls messages qui l’intéresse et dispose de sa propre base de données de correspondance de messages. Il peut donc mettre à jour la représentation graphique de chaque objet en fonction des informations qui circulent sur le bus.

Lorsque l’on agit sur l’un des éléments graphiques du TCO comme une aiguille, le message correspondant est envoyé sur le bus CAN et l’aiguillage change effectivement de position.

L'architecture logicielle est somme toute assez simple et grandement facilitée par l'usage du bus CAN. J'envisage en effet de placer sur le bus une passerelle CAN/WiFi qui serait également un serveur WebSocket.

C'est l’ESP8266 dans sa version de prototypage Node MCU E12 qui sera retenu. Il dispose en effet d’un grand nombre de bibliothèques qui seront utiles et ses performances sont de taille pour l'exercice.

Ainsi, tous les messages circulants sur le bus CAN du réseau seront envoyés à une page HTML (la représentation du TCO) gérée par du code en JavaScript en ayant largement recours à la POO. Chaque élément du réseau (aiguille, loco, feux...) étant lui-même un objet informatique. Tout résidant en mémoire et propulsé par le moteur V8 de Google, c'est un fonctionnement ultra rapide.

Ce TCO fonctionne avec tous les gestionnaires puisqu'il est indépendant de toutes plateformes pour peu, bien sûr que les informations transitent par un bus CAN.

Comme vous pourrez vous en rendre compte, l’intérêt des solutions techniques mises en œuvre dépasse largement le cadre d’un TCO et dont pourront s’inspirer de nombreux autres projets.

1° - On y trouve une passerelle CAN/WiFi-Ethenet
2° - Le Node MCU dispose d’un espace de stockage de fichiers qui sera utilisé ici pour héberger un serveur web assez complexe. Mais on pourrait tout aussi bien y stocker des fichiers son par exemple comme on le fait sur une carte SD.
3° - Pour communiquer entre l’ESP8266 et le navigateur web, nous utiliserons la technologie des websocket qui constitue aujourd’hui la plus performante des solutions d’échanges sur le web.
4° - Le TCO sera conçu comme une application à part entière disposant de ses propres bases de données objets stockées en mémoire RAM de l’ordinateur ou de la tablette. Là encore, l’assurance de performances accrues.

Parmi les nombreuses applications possibles, je pense à une centrale DCC++ hébergée sur l’ESP8266 à laquelle on pourrait accéder en CAN et Wifi. Une manière de contourner Processing assez « lourd » à mon sens pour le développent d’applications graphiques de commande comme peuvent l’être un TCO ou un contrôleur.



14
Shields et Modules / L’ESP8266 : « Une drôle de petite bête »
« le: septembre 10, 2017, 07:21:38 am »


Bonjour à tous,

Ne me dite pas que vous n’ayez jamais entendu parlé de ce composant qui fait déjà « pas mal de bruit dans le Landerneau » du DIY et de ce qui gravite autour !

A la base, l’ESP8266 est un simple module WIFI destiné à étendre les possibilités de cartes à microcontrôleurs comme les Arduino et d’établir avec elles des connections WIFI en TCP/IP. Mais l’ESP8266 disposant lui-même de son propre microcontrôleur, il est vite apparu à une petite communauté que l’on pourrait se dispenser de la carte « maitresse » pour peu que l’on dispose de l’environnement logiciel pour sa programmation.

C’est ce à quoi va rapidement « s’atteler » son fabriquant chinois, ESPRESSIF en proposant (entre autres) une solution en C/C++ au travers de l’IDE Arduino ; de l’Arduino sans Arduino ! Vous pouvez en effet comparer l’ESP8266 à un Arduino Mini ou Nano qui serait doté de la WIFI. Avec des performances pourtant supérieures :

Fréquence 80MHz pour l’ESP8266  contre 16MHz pour un Arduino UNO R3,
Flash Memory 4MB pour l’ESP8266  contre 32Kb (sic) pour un Arduino UNO R3.

L’ESP ne dispose pas par contre d’EEPROM ce qui nécessite d’utiliser la Flash Memory mais on voit bien qu’avec 4MB ce n’est pas un problème.

Mais ne nous y trompons pas tout de même. Si tout a été fait pour que la programmation soit aussi proche que possible de celle d’un Arduino, parfaitement intégrée dans l’IDE, utilisant même le langage spécifique de l’Arduino comme « digitalWrite » ou « analogRead », l’ESP n’est pas un Arduino. Les processeurs tout d’abord sont différents : ATmega pour la plupart des Arduino contre ESP8266.

Cependant, j’ai fait quelques tests de comparaisons sur digitalWrite justement. L’ESP donne une vitesse d’exécution environ 1,5 fois supérieure à un UNO !!! Et à mon grand étonnement, l’utilisation des routines de bas niveau spécifiques à l’ESP : (GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS, 1 << outPin) comparables aux manipulations de ports sur Arduino (PORTD = b10101000) n’apporte pas de gains significatifs en vitesse (+7 à 8%). Mais il ne s’agit que de tests théoriques portants sur des point très spécifiques. Il faudrait comparer si c’est possible l’exécution d’un programme bien réel.

Alors l’ESP, est-il de l’Arduino sans Arduino et mieux que l’Arduino ? Il faudra aviser selon ce que l’on souhaitera réaliser. Arduino vient de sortir un UNO en WiFi, mais il est certain que lorsque le gain de place est recherché, un ESP est plus facile à embarquer qu’un UNO. Et nous ne devrions pas attendre longtemps je pense pour voir apparaître des Nano ou autres Mini en WiFi chez Arduino.

Quoiqu’il en soit, l’ESP a de nombreux atouts et peut apporter beaucoup à la richesse et aux fonctionnalités des projets de modélisme ferroviaire.

Je suis personnellement en train de terminer une réalisation de pont tournant automatisé sur la base d’un FLEISCHMANN 6152 en HO et aucune autre solution Arduino embarquée n’était envisageable. Vous trouverez rapide aperçu ici et pourrez vous rendre compte du degré de miniaturisation :



Nous sommes assez nombreux à avoir initialisé des projets à base d’ESP. Encore plus nombreux sans doute sont ceux qui voudraient mais ne le connaissent pas bien. On peut penser que l’ESP ne sert qu’à faire des serveurs internet, ce qui est largement faux. Quoique, cela peut-être bien utile si l’on souhaite développer une application riche et pilotable à distance via un ordinateur, une tablette ou un smartphone.

Voilà, j’ai souhaité ouvrir ce nouveau fil pour que vous puissiez poser toutes vos questions et que la communauté Locoduino puisse partager une expertise déjà importante semble t’il sur le sujet.

Bien amicalement.

Christophe

15
Le logiciel DCC++ / Controller DCC++ Ethernet On-Line
« le: mars 04, 2017, 06:57:24 pm »
Bonjour à tous,

Dans le prolongement des articles sur DCC++ :

•   Réalisation de centrales DCC avec le logiciel libre DCC++ (1) - Comment adapter ce très bon logiciel à ses besoins propres
•   Réalisation de centrales DCC avec le logiciel libre DCC++ (2) - Mise en œuvre d’un contrôleur pour BaseStation en HTML.
•   Réalisation de centrales DCC avec le logiciel libre DCC++ (3) - DCC++ : Quel matériel et quelle mise en œuvre ?

J’ai adapté une version on-line d’un Controller Ethernet. Son principal intérêt est qu’il est simple d’utilisation. Il n’y a rien à télécharger, rien à installer sur son ordinateur.

Tout en étant simple, il n’en est pas moins très complet. Possibilité de créer un nombre important de locomotives, accès aux fonctions F0 à F28. La possibilité de scanner les valeurs des cv des locomotives (jusqu’à 512 cv), possibilité de programmer toutes les cv, programmation simple des adresses longues etc…

Ce projet est principalement destiné à tous ceux qui souhaitent mettre en œuvre rapidement et simplement une configuration DCC++ avec ARDUINO sur leur réseau sans entrer dans des configurations compliquées.

J’espérer que ce projet permettra au plus grand nombre d’utiliser DCC++ et qu’il permettra d’en appréhender les principales fonctionnalités.

Il ne demande qu’à évoluer pour répondre toujours mieux à son ambition. J’ai ouvert ce fil pour cela mais aussi pour que vous puissiez formuler des attentes et pour partager les expériences.

N’hésitez pas à essayer, je pense vraiment que vous serez surpris !

Accéder à DCC++ Controller Ethernet On-Line :http://176.154.165.92/locoduino/controller_dccpp/controller.php

Accéder à l'aide en ligne : http://176.154.165.92/locoduino/controller_dccpp/dccppController/index.php

BobyAndCo

PS : Cette configuration nécessite un ARDUINO MEGA et un shield ethernet.

Pages: [1] 2