Messages

1

JMRI et Arduino / Re : Projet modules-sorties jmri/canbus

« le: avril 05, 2025, 04:47:11 pm »

Bonjour à tous,

Après plusieurs mois d'absence, je suis revenu à mon projet, que j'avoue avoir laissé un peu dans le tiroir ... Ce n'est pas faute d'envie mais un problème de temps, la vie est ainsi faite ...

Pour rappel, je suis passé de rocrail à jmri en termes de tco.
Mon cahier de charges était de:

• différencier le dcc, uniquement consacré à la commande des trains
• utiliser le stock de composants que j'ai chez moi, entre autres des atmega 8, 328 et 2313
• trouver un moyen d'interfacer jmri avec le bus can

Au départ j'étais parti sur la piste donnée par Geoff Bunza mais je me suis rendu compte que ce n'était pas cela que je recherchais.

J'ai alors découverts un système que je ne connaissais pas, à savoir le protocole C/MRI.

J'ai donc fouillé un peu dans son historique pour voir comment cela fonctionne et j'en ai tiré mon système de base en termes de fonctionnement.

PC-JMRI <--> communique avec un arduino uno(centrale) <--> communique avec des modules(servos, cartes output, cartes input, ...)

Je détourne donc la communication C/MRI, qui au final n'envoie ou reçoit que des 1 ou 0, avec la soft arduino qui transforme les informations pour passer sur le réseau via le bus can.

J'en suis à mes premiers essais qui semblent très concluant. Dès que je reçois mes premiers pcb et que je les aurai montés et testés, je repasse par ici avec photos fichiers voire vidéos pour en expliquer le fonctionnement et vous partager les fichiers.

Belle journée à vous tous.

Marc

2

JMRI et Arduino / Re : Projet modules-sorties jmri/canbus

« le: mai 18, 2023, 11:31:51 pm »

Suite des fichiers 

3

JMRI et Arduino / Re : Projet modules-sorties jmri/canbus

« le: mai 18, 2023, 11:12:58 pm »

Bonsoir à tous.

Voici le résumé de mes avancées 

Petit rappel de mon carnet des charges.
Réalisation d'un réseau de commandes d'accessoires contrôlé par JMRI via le bus can, réseau actuellement indépendant de la détection.
Essayer au maximum de réduire le cablage divers ce qui assurera une certaine robustesse au système et simplifiera grandement la clarté de l'ensemble.
Pour arriver à ce but, relier entre eux les divers modules et les alimenter par du cablage rj45(8 fils) et en profiter pour diffuser un autre voltage pour alimenter les accessoires. J'utilise pour la source du courant, une alimentation de pc, en général très précise, qui peut fournir du 12V, 8A, et du 5V 20A,ce qui pourra largement supporter beaucoup d'accessoires.

J'ai donc réalisé le schéma électronique sur base des pièces que j'ai en stock( tous les fichiers sont joints et si vous trouvez des erreurs, ne pas hésiter à le dire, je ne suis qu'hobbyiste et non professionnel)des cartes module et fait imprimer les platines.
J'en ai monté une pour commencer les tests qui sont positifs. Cela reste un prototype de base comme un arduino sauf qu'ici j'ai utilisé un atmega8 que j'avais également en stock.

Il y a à l'entrée, un étage de régulation de courant avec le classique ams1117 bien connu des arduinistes
En suite les 3 ic, atmega(au choix 8, 88, 328, ...), mcp2515 et le tja050 pour le bus can.
J'ai placé un connecteur pour programmer l'atmega directement sur la platine(j'utilise un programmeur classique USBasp) mais c'est optionnel.
Il y a aussi un connecteur qui permet l'utilisation de l'interrupt ou simplement la sortie. Actuellement, je ne 'utilise pas le système de l'interrupt pas toujours facile à maîtriser, même si indispensable en cas de très gros réseau.
Rien de révolutionnaire donc. A terme, cette petite structure sera utilisée pour des modules à usage précis avec une platine dédiée car un atmega ou arduino ne peut pas alimenter beaucoup de choses (même 15 leds alumées en même temps ...) mais simplement commander. Je pense à par exemple à une carte leds-signaux lumineux, une carte servo-moteurs, une carte son, .....

En ce qui concerne les sketch, j'ai utilisé la bibliothèque autowp-mcp2515 que je trouve vraiment ultra simple d'utilisation et très légèrehttps://github.com/autowp/arduino-mcp2515 même si à terme et si j'en ai le courage, je coderai sans doute en C pour gagner de l'espace mémoire, mais encore une fois, vu la taille du sketch, cet aspect est purement optionnel.

Dans jmri_can_master,il y a un fichier global.h qui permet de définir le nombre de sorties que l'on veut piloter, en rapport avec le nombre de sorties dans JMRI, voir plus bas, et la définition des filtres:

Code: [Sélectionner]

/********************/
/* fichier global.h */
/********************/
#ifndef jmricom_h
#define jmricom_h

#define NBRESORTIESJMRI 69
#define NBRECONJMRI 69

int canFilter[2] = {0x010, 0x011};

#endif
Actuellement je fais des tests avec 69 sorties et deux modules, donc deux filtres.

Dans jmri_can_module,il y a un fichier global.h qui permet de définir le numéro du module à piloter, en rapport avec le nombre de sorties dans JMRI, voir plus bas, et la définition des filtres:

Code: [Sélectionner]

/********************/
/* fichier global.h */
/********************/



#define NUMMODULE 1

const int FILTRE[]={0x000, 0x010, 0x011};

Pour ce qui est de la communication avec JMRI, je passe par le script écrit en python par Geoff Bunza https://forum.mrhmag.com/post/sma29-jmri-turnout-channels-%E2%80%93-direct-jmri-to-arduino-communications-simple-support-for-lots-of-12210817, un article sur locoduino ayant été écrit sur ce sujet(attention, le lien des fichiers dans l'article locoduino nous donne un fichier obsolète. Il faut prendre les fichiers originaux sur le site de Geoff !).

Voilà, cela avance donc et j'espère ne pas être trop brouillon dans mes explications, je suis conscient que c'est pas toujours facile d'être bien clair !

Bonne soirée et au chapitre suivant 

Marc

4

JMRI et Arduino / Re : Projet modules-sorties jmri/canbus

« le: mai 09, 2023, 10:44:38 pm »

Merci pour votre réponse 

Pour l'instant, je suis en attente de quelques composants qui vont arriver d'un jour à l'autre.
Dès réception, je ferai les premiers tests et je posterai le schéma de la carte.
Et bien-sûr, je ne demande pas mieux  d'avoir un coup de main, sachant que je découvre le bus can.

Belle soirée.

Marc

5

JMRI et Arduino / Projet modules-sorties jmri/canbus

« le: mai 06, 2023, 03:59:43 pm »

Bonjour à vous tous,


Pour toutes les personnes que cela pourrait intéresser, j'aimerais vous présenter le petit projet dans lequel je me suis lancé, à savoir la conception et le montage de petits modules de commandes(aiguillages, éclairages et autres) qui tournent sous le protocole canbus et pilotés par JMRI.

Sans être trop long, voici un petit historique du matériel que j'utilise pour mon ancien-futur réseau:

J'ai été très longtemps fidèle et coopérateur à l'équipe Rocrail depuis quasi sa naissance ... Ces derniers temps, j'avoue, j'ai un peu lâché le projet car la ligne directrice actuelle s'écarte un  peu de ma philosophie, notamment par rapport au code source qui n'est plus si accessible qu'auparavant et l'abandon de certains protocoles de communication (ddl, ddx, ...). J'insiste que cela reste mon avis et sentiment et que ce n'est nullement une critique négative vis à vis de Rocrail qui est un programme formidable.
La conséquence de tout ceci est qu'actuellement je découvre JMRI beaucoup plus en profondeur et que j'essaye de le faire tourner avec du matériel issu de la lignée Rocrail. J'ai donc une centrale dcc++ avec un arduino uno couplé à un booster(ORD3-

https://wiki.rocrail.net/doku.php?id=ord3-cs-fr, duo qui fonctionne parfaitement. Pour la rétro-signalisation, j'ai un système basé sur Loconet(https://wiki.rocrail.net/doku.php?id=gca85-en), système robuste qui a depuis longtemps fait ses preuves. Il me manque donc tout ce qui est commandes. J'aurais pu passer via les modules loconet mais je préfère découvrir et concevoir pour le hobby un système séparé et indépendant de la rétro, ce qui est souvent conseillé même si pas obligatoire.

Voici dans les grandes lignes la démarche que j'ai établie:

• J'ai pas mal de pièces électroniques en stock, donc essayer de les utiliser au maximum. Par exemple, j'ai une série de pic Atmega8 que je vais réutiliser. Comment ? C'est simple: au lieu d'acheter x nbre d'arduino, je vais simplement y charger un bootloader arduino ce qui va m'engendrer une série de petits arduino. Les atmega8 et 328 sont tout à fait équivalents dans leur structure. En consultant le datasheet, ce qui diffère, c'est l'espace mémoire. Comme le sketch que je vais télécharger est vraiment tout petit, ce ne sera pas un souci. Cette procédure n'est pas trop compliquée. On trouve de nombreux exemples sur internet, mais je peux l'expliquer si une personne me le demande, ce sera avec plaisir.

• Trouver un système de cablage simple, comme cela s'est déjà fait, via du rj45. Cela réduira le nombre de cables et permettra d'amener partout sur le réseau des sources de 12V et 5V pour les différents besoins(électronique, décors, animations, ...

• Créer le module sur une platine en y intégrant l'atmega8-arduino et le mcp2515 pour la connexion canbus

• Piloter le tout via JMRI

J'ai déjà pas mal progressé dans le projet.



https://www.dropbox.com/s/90cyoerwi3lwu8n/essai1.jpg?dl=0

Dans ce fouillis de cables on distingue un atmega8, module réception1, un uno, module réception 2 qui communiquent avec un mega qui sert d'interface avec JMRI pour piloter des leds qui simulent des feux de signalisation.

Voilà pour les premières bases de cette aventure ... 

Belle journée à vous tous[/list][/list][/list]

6

Débuter / Re : C++ - hiérarchie des fichiers

« le: août 09, 2020, 09:56:55 pm »

Hello à tous,

Courage ou inconscience hahaha 

Plus sérieusement, merci pour ton avis, je commence doucement à entrevoir un peu les principes.
Pour l'instant, je bosse des petits exercices sur les pointeurs, toujours des choses simples avec mes deux leds.
Je suis parvenu à utiliser ma classe hors routine principale dans une autre fonction.
Je ne sais pas si c'est la meilleure façon, mais en tout cas, ça compile sans souci et en plus ça fonctionne 

Belle soirée

Edit:  J'ai corrigé quelques bugs. En fait la boucle finissait par stopper car je n'effaçais pas convenablement les pointeurs (il faut effacer le pointeur et surtout le lien).

Marc

7

Débuter / Re : C++ - hiérarchie des fichiers

« le: août 07, 2020, 12:40:50 am »

Bonsoir à tous,

Sur base des conseils de Cédric (que je remercie encore, cela m'a éclairé l'esprit sur pas mal de choses dans la philosophie objet), j'ai refait mon code.
J'y ai fait quelques changements, principalement pour cette condition

Code: [Sélectionner]

if(a != 0) m_numSdigi = a;.
Je l'ai retirée de la fonctionSdigiInit() pour la placer directement dans le constructeur. J'ai rajouté une fonction ONOff plus des analogWrite.
Va falloir rendre tout ça accessible pour des fonctions hors boucle principale, mais là je dois encore étudier le domaine des pointeurs !

Dernière petite question philosophico-théorique par rapport à  l'accessibilité justement: sachant que je traite dans mon exemple des sorties digitales qui n'auront jamais , d'une part, qu'un état On ou Off, d'autre part, le même numéro de sortie sur l'arduino, est-ce tant une fausse route ou une erreur de conception que de placer la classe qui les traitent en "static", car c'est très simple à écrire, la méthode des pointeurs étant sans doute plus ardue à concevoir ?

Belle soirée

Marc

8

Débuter / Re : C++ - hiérarchie des fichiers

« le: août 06, 2020, 10:09:29 pm »

Merci pour ta réponse Cédric

Pourquoi ton objet est static?

En fait c'est le seul moyen que j'ai trouvé de faire sortir en quelque sorte la classe et de la rendre universelle à tout autre fichier cpp que le ino principal.
En analysant tes conseils, je me rend compte que je travaille un peu à l'envers dans ma conception .....
C'est ce que j'écrivais dans mon premier message, j'ai un peu de mal à rentrer dans cette logique de pensée objet, mais je ne désespère pas d'y arriver en tatonnant.

Code: [Sélectionner]

if(a != 0) m_numSdigi = a;  // Si tu amènes la paramètre facultatif a, c'est que tu veux changer la pin mémorisée, sinon tu utilises m_numSdigi
Alors ça c'est génial ! Ca réduit mes deux constructeurs en un seul .... (j'ai encore du chemin à faire ...).

Pour le reste, les tableaux, je maitrise assez pour ce que je veux en faire, par contre je dois encore bosser la notion des pointeurs, car là j'ai pas encore tout capté.
Allez, un peu de pain sur la planche ...

Je tiendrai le sujet à jour avec mes avancées.

Encore merci et belle soirée.

Marc

9

Débuter / Re : C++ - hiérarchie des fichiers

« le: août 06, 2020, 12:34:44 am »

Bonsoir à tous,

J'avance, j'avance ...... 

J'ai trouvé une façon de pouvoir utiliser une classe en dehors de la boucle principale avec "static".
Par contre, je ne sais pas si les pros de la communauté seront d'accord avec mon code

Quand l'un d'entre vous aura le temps d'y jeter un regard critique (sans les tomates svp )

Belle soirée

10

Le logiciel DCC++ / Re : arduino Mega DCC++ / L9110S

« le: août 05, 2020, 06:17:41 pm »

C'est une bonne nouvelle 

Merci pour les liens.

11

Le logiciel DCC++ / Re : arduino Mega DCC++ / L9110S

« le: août 05, 2020, 02:46:47 pm »

Bonjour à tous,

Je confirme le mauvais fonctionnement des deux nouveaux max371 que j'ai reçus .....
Je crois que je vais abandonner cette piste car s'il faut commander 10 modules pour un qui fonctionne, et encore c'est pas sûr, c'est pas très optimal ... 

Belle journée

Marc

12

Débuter / C++ - hiérarchie des fichiers

« le: août 04, 2020, 11:05:04 pm »

Bonsoir à tous,

Je me suis lancé dans l'étude de l'utilisation des classes et objets pour programmer certaines choses. Les articles sur locoduino étant vraiment bien faits et ayant fait quelques petits exercices, j'ai bien intégré les principes de base.
Il y a juste une chose que je n'arrive pas à à réaliser, malgré les dizaines de tutos que j'ai suivis .... après deux jours je fatigue et je fais appel à l'équipe. Je m'explique:

J'ai un souci en terme de hiérarchie de fichiers. Les exemples, tutos et articles que l'on trouve conçoivent en général des exemples basés sur un fichier principal,

Code: [Sélectionner]

main(), ou encore le fichier .iso pour l'arduino et son IDE. Quand on a une routine qui fonctionne, tous mes essais fonctionnent bien, pas de souci.

Pour l'arduino j'ai par habitude plus utiliser un système modulaire avec des fonctions pour chaque modules, découpé en plusieurs fichiers

Code: [Sélectionner]

.cpp et fichiers entêtes

Code: [Sélectionner]

.h et un dernier fichier

Code: [Sélectionner]

.config.h contenant certaines variables globales comme par exemple les définitions des pin

Code: [Sélectionner]

#define pin A0 par exemple.
Ce que je voudrais réaliser, c'est définir x sorties digitales pour allumer des lampes de décors, maison, routes ou autres, et qui seraient allumées en partie ou dans son ensemble selon des événements (nuits, mouvements aléatoires dans une maison, magasin, ...)

Pour ce faire j'ai crée pour l'essai une class avec un constructeur très simple, c'est un simple

Code: [Sélectionner]

on ou

Code: [Sélectionner]

off avec l'argument dune pin à introduire

Code: [Sélectionner]

LampeMaison LampeMaison(pinLampeMaison).
Encore une fois, dans une routine principale, cela fonctionne sans problème.
Par contre, si je veux faire appel classe à cette via une fonction autre que la routine principale, par exemple un module nuit,

Code: [Sélectionner]

nuit.cpp et

Code: [Sélectionner]

nuit.h avec par exemple une fonction

Code: [Sélectionner]

AllumageNuit(), là cela coince.
Comment parvient-on à rendre une classe utilisable dans une hiérachie de fichiers autres que le fichier principal en l'exportant, un peu comme une variable.

Est-ce possible ?, même si je crois que j'ai encore du mal à concevoir un programme dans son ensemble sous la forme d'objets,étant trop habitué au morcelage en système de modules et fonctions que l'on insère petit à petit un peu "selon la nécessité" du moment et de l'idée.

Merci d'avance et belle soirée.

Marc

13

Le logiciel DCC++ / Re : arduino Mega DCC++ / L9110S

« le: août 03, 2020, 12:40:19 pm »

Hello Jack67 et les autres  ,

Je viens de recevoir les deux nouveaux max471 et le résultat est ....
pareil qu'avec les deux autres ...... pas d'amélioration .....
Je constate exactement les mêmes résultats dans diverses configuration de logiciel ou de connection.
Je n'ai pas encore testé les max de manière séparée, mais je vais arrêter les frais de commande de max471. Sachant que la production du composant est terminée, s'il y en a 1/10 qui fonctionne, cela devient compliqué !
Pour l'instant je vais garder le lmd18200 connecté à mon ancien booster (ord3 de Peter Gilling), cela fonctionne bien.

Malheureusement je ne peux pas t'aider pour la carte  L9110S. Je ne la connais pas. Mais comme nous avons les mêmes résultats avec des différents hardware, je pense que le souci vient des max 471 ....
Je vais encore tenter d'autres config et chercher un autre diviseur, il y a des pistes, et je posterai le résultat.

Belle journée.

Marc

14

Le logiciel DCC++ / Re : arduino Mega DCC++ / L9110S

« le: juillet 29, 2020, 12:28:23 pm »

Bonjour,

Je vois que je ne suis pas le seul à avoir ce problème. Sachant que j'utilise un autre matériel, lmd18200 + max471.
Je constate exactement le même résultat que chez vous avec au démarrage un <p1> suivi de <p2>. Au départ j'incriminais le mauvais fonctionnement des max471 peut-être défectueux. Mais je suis de moins en moins persuadé que cela provient de là, je ne serai convaincu que lorsque je recevrai les nouveaux.
Comme expliqué dans mon post https://forum.locoduino.org/index.php?topic=1035.msg10986#new, ce souci apparait dans toutes les config que j'ai pu tester avec ou sans max471 (par exemple en alimentant directement le lmd18200 à 12v) principalement avec la bibliothèque car le sketch original de Greg semble moins sensible.

Je pense que le souci, sans être encore sûr à 100%, vient du contrôle de surcharge dans le fichier CurrentMonitor.h (CurrentMonitor.cpp qui s'en suit) qui est utilisé dans la fonction loop(). C'est ce qui vérifie tout naturellement les surcharges de court-circuit.

Si vous faites un sketch utilisant les fonctions d'allumage,

Code: [Sélectionner]

powerOn();, et d'arrêt,

Code: [Sélectionner]

powerOff();, normalement vous devriez avoir votre matériel s'allumer et s'éteindre correctement. Le souci provient lorsqu'on lance le loop() puisque cela fait appel au contrôle via CurrentMonitor. Y aurait-il un pic de courant à l'allumage ? J'essaie d'investiguer ...
J'ai modifié le fichier CurrentMonitor.h à la ligne 40,

Code: [Sélectionner]

void begin(int pin, int inSignalPin, const char *msg, float inSampleMax = [b]300[/b]);, en passant la valeur à 400 et depuis le souci a disparu. J'ai pris la valeur de 400 aléatoirement mais je n'ai pas eu le temps encore de tester des valeurs plus petites entre 300 et 400 pour définir où se situe le seuil.
Ce test a été effectué avec le lmd18200 alimenté directement. Encore une fois, dans la même configuration et le sketch original, je n'avais pas de souci.

Prochain test: refaire le montage avec le max471(mais j'attends les nouveaux !)
Je vous tiens informé.

Belle journée 

Marc

Edit: je viens de passer un peu de temps à tester les max471 que je possède, il sont effectivement défectueux ( je pourrai juste récupérer les borniers et connecteurs ....). A voir avec les nouveaux quand je les recevrai

15

Le logiciel DCC++ / Re : Centrale DCC++ avec UNO / LMD18200 / MAX471

« le: juillet 28, 2020, 07:20:27 pm »

Bon ben je viens de tester mon lmd18200 connecté au booster ord3-v2.
Selon les premiers tests, cela semble fonctionner nickel, avec le sketch original !

Je réserve la partie commande dcc au couple arduino-lmd18200 et l'ord3-v2 pour la puissance. C'est un booster qui a fait ses preuves, puissant et qui est complètement isolé électriquement.
Cela me permet de garder une partie de mon matériel, c'est chouette 

Comme j'ai commandé deux nouveaux modules max471, je tenterai des essais pour le rail de programmation quand je les reçois.

Je vous tiendrai informé.

Belle soirée