JMRI

[nopxor]

Bonjour _N_,

Lorsque Luc a connu des problèmes avec ses scripts, http://forum.locoduino.org/index.php?topic=610.0 (réponse 5), je lui ai conseillé de  contacter l'auteur Geoff Bunza de Model Railroad Hobbyist (MRH):
https://model-railroad-hobbyist.com/node/34392
Il a ainsi eu une solution rapidement.
Je pense que cela vaut la peine de faire chauffer le traducteur.
Tiens nous au courant.
Sinon pour éviter les scripts et un fonctionnement sans soucis de JMRI: 
http://forum.locoduino.org/index.php?topic=507.0

[_N_]

Bonjour,

... Si "Fred" vous convient mieux, que "_N_" alors soit, je ne voudrais pas vous imposer l'équivalent d'un pseudo tel "Nabuchodonosor" en nombre de manipulation !
En tout cas merci pour vos promptes réponses.

Oui, je vais lire et prendre contact avec Geoff Bunza au cas où il aurait une piste à étudier. Merci.

Sur la réponse concernant CMRI : Actuellement j'ignore tout de cette communication. Je sais qu'il y a de la littérature sur le sujet mais il me faut du temps pour creuser chaque sujet. Cependant, je note que cette solution permet de "se passer" des scripts de JMRI. Est-ce parce que le modèle/protocole/communication est intégré nativement à JMRI ? Si oui, il va y avoir nécessairement des limitations ? Mais en attendant d’apprendre le Python/Jython, cela pourrait bien accélérer mes apprentissages du DCC.

Concernant votre solution HW, j'admire votre travail et en comprends bien l'utilité et l'esprit. Cependant, je me suis fixé un objectif HW un peu différent quoique récent et donc peut être pas très abouti. Après avoir "trainé" à l'association de l'AFAN (dont je fus membre dans la fin des années 70), j'ai cessé toute activité ferroviaire au milieu des années 80 et remisé le tout dans une malle. A cet époque, quelques marques dont JOUEF qui était bien Française, tentaient timidement d'introduire des commandes électroniques au milieu du règne des relais et autres automatismes électromagnétiques et interrupteurs à bascule. L'ensemble de mon parc est alors 100% analogique et comme c'est du N, c'est petit.
Aujourd'hui (maintenant que la relève se manifeste au sein de ma famille et que je ressorts mes trésors miniatures), je découvre avec stupeur les changements opérés sur le modélisme ferroviaire et comprends qu'en trente ans le monde a changé ! Mais c'est aussi devenu super intéressant !
Du coup, je cherche à concevoir un système où le numérique côtoie l'analogique, ce qui me parait possible aussi bien d'un point de vue des interfaces HW que des applications SW. Par exemple, mes capteurs de présence utilisent des optocoupleurs bidirectionnels pour assurer l'inversion de polarité des locos analogiques. J'alimente mes locos DCC en 12Vac (14Vac max) de telle façon que les interfaces LMD18200 ou L298 puissent alimenter en DC les voies sans risque pour les locos analogiques (non-transformables facilement en DCC). Outre une alimentation propre à chaque tronçon (un module "pont en H"), je cherche également à y intégrer un disjoncteur automatique. Pour cela j'ai utilisé un ACS712 et cherché avec un Arduino à différencier l'occupation du CC mais le composant n'est pas assez stable ni précis en dessous de l'ampère (j'ai une autre référence plus précise à tester mais je ne l'ai pas encore commandée car elle est rare et chère). Enfin, je souhaite pouvoir répartir des petites cartes sur des modules dont je ne connais pas nécessairement l'ordre d'assemblage mais qui doivent communiquer en transmettant de proche en proche les informations (là, la RS485 me titille, mais j'aimerai me frotter au CAN).

J'en profite (@Dominique, mais pas seulement !) : J'ai cherché à utiliser un L278 (qui me parait apte à faire du DC ou de l'AC) connecté à DCC++ (en suivant point à point l'article : merci) mais je n'ai pas été encore capable de comprendre comment les sorties de commande du LMD18200 sont manipulées dans le code, mon but étant d'utiliser une autre broche pour avoir l'état complémenté pour piloter le L278. Alors, si quelqu'un sait m'indiquer vers quel endroit du code de l'Arduino il faut regarder, je l'en remercie d'avance !

Encore une question : lorsque j'utilise JMRI en Ethernet filaire, quelque soit le PC utilisé (ou lorsque deux PC sont simultanément utilisés) la communication Ethernet passe son temps à alterner entre "erreur de com..." (écrit en rouge) et "connectée .." (écrit en vert) avec une petite tendance à rester sur le rouge ; pourtant cela ne semble pas affecter l'envoi des commandes. Pourquoi ?

Bonne journée.

[nopxor]

Bonjour Fred,

C/MRI (Computer/Model Railroad Interface) est un standard qui date de 1985.
Il est largement répandu aux USA et a été adopté par la NMRA.
Il est commercialisé par JLC: https://www.jlcenterprises.net/
L'existence des librairies Arduino CMRI et RS485 a permis le clonage de la carte 24/48 I∕O à moindre coût et avec très peu de lignes de code.
Ce standard est reconnu nativement par JMRI, et rend son utilisation très facile, sans scripts et sans limitations.
Le bus RS485 issu de l'industrie, tout comme le CAN, est très robuste.

L'utilisation d'un pont en H (driver PWM) par DCC++ se fait classiquement par une broche DIR et une broche PWM (et la broche GND).
Je n'ai pas trouvé d'infos sur le driver L278. S'agit-il du L298 ?

Pour ton problème d'utilisation de JMRI en ethernet, je n'ai pas de réponse car je l'utilise en USB.
Je te conseille de poser la question au groupe d'utilisateurs de JMRI:
https://groups.io/g/jmriusers

[msport]

Bonjour,

on a identifié le problème de la sortie calée à VCC/2 pour l'ACS712 :
https://forum.locoduino.org/index.php?topic=983.msg10292#msg10292

Ce qui ne l’empêche pas d'être utilisé pour la détection de C/C mais pas pour les 60 mA des réponses des décodeurs pour les CV.
Et sa destination vouée à la mesure des courants alternatifs (donc + et -) peut être un avantage en DC (donc dans les deux sens).

Et actuellement l'utilisation des MAX472 est la solution pour le DCC.
https://forum.locoduino.org/index.php?topic=1038.msg11032#msg11032

Pour avoir un montage compatible DC / DCC, regardez la réalisation de Thierry Bibliothèque DcDccNanoController :
https://www.locoduino.org/spip.php?article224

Mais le plus simple pour avoir un signal complémenté, c'est d'utiliser un simple transistor comme nous l'avons fait pour remplacer le LMD78200 (qui n'a pas besoin d'un signal complémenté) par un L6203 comme dans LaBox.
https://forum.locoduino.org/index.php?topic=922.msg11228#msg11228

[_N_]

Bonjour,

Merci à tous pour ces réponses et pistes de travail.

>>> Oui L298 ! <<< (1000 excuses).
J'ai bien pensé au transistor, mais avec un µ-contrôleur disposant d'IO non utilisées, c'est quand même dommage.

Pour la solution de Thierry (Bibliothèque DcDccNanoController), je me sentirai à l'étroit mais c'est excellent pour une planche de test. Or j'envisage l'exploitation de plus d'une loco DCC.

En fouillant un peu et en lisant l'abondante littérature de Geoff Bunza, il s'avère qu'il a upgradé son script "Sensor_Scan.py" à la version V2.0.
On y remarque :
-> Un nouvel appel à une bibliothèque "java.beans"
-> La correction d'une variable "extport = self.port" (j'espérais que cette correction puisse limiter la fuite mémoire, mais non)
-> L'ajout de ":" à la chaine "AR" (Nota : si vous utilisez cette version et que la table des "sensors" est déjà remplie par vous -donc que vous y avez déjà ajouté à la main les ":" à la suite des "AR"- il faut retirer ces ":" pour que cela fonctionne correctement sinon JMRI verra "AR::" au lieu de "AR:" !)
-> La temporisation de 2s devient obligatoire pour les système d'exploitation ("self.waitMsec(2000)").
Mais donc, sur mes PC,  l'écran bleu continue d'arriver après 5 à 10 minutes d'utilisation du script.
Peut-être que malgré tout cela vaut-il le coup de mettre à jour sur Locoduino le téléchargement de ce script ?

En parallèle j'ai regardé le C/MRI, je vais faire un essai. C'est bien documenté. Si le résultat est probant, je n'aurai pas de raison de continuer avec les scripts Jython (au moins dans un premier temps).

Pour finir, l'ACS712, je cherche à me procurer le "ACS70331E0LCTR-2P5U3" très exactement. Sur le marché, je trouve le "ACS70331EESATR-2P5U3" mais il est trop difficile à câbler sans faire un PCB dédié. Il est unidirectionnel mais c'est bien ce que je cherche car il est galvaniquement isolé. Alors si quelqu'un sait où se procurer 10 pièces ... !
Pour information, sur AliExpress on le trouve, assez cher d'ailleurs, mais le marquage est tel qu'il est difficile de savoir ce qui est réellement vendu par ces marchands.

Fred

[CATPLUS]

Bonjour

http://forum.locoduino.org/index.php?topic=660.0

Dans JMRI il y a une commande dans le Help "Controle System JMRI"  qui te donne toutes les phases d'échange entre le PC et le l'arduino.

http://forum.locoduino.org/index.php?topic=660.msg7534#msg7534

Marcel

[Dominique]

Pour finir, l'ACS712, je cherche à me procurer le "ACS70331E0LCTR-2P5U3" très exactement. Sur le marché, je trouve le "ACS70331EESATR-2P5U3" mais il est trop difficile à câbler sans faire un PCB dédié. Il est unidirectionnel mais c'est bien ce que je cherche car il est galvaniquement isolé. Alors si quelqu'un sait où se procurer 10 pièces ... !
Pour information, sur AliExpress on le trouve, assez cher d'ailleurs, mais le marquage est tel qu'il est difficile de savoir ce qui est réellement vendu par ces marchands.

Fred

Chez Digikey, l’ ACS70331EOLCTR-2P5U3 doit être approvisionné fin Novembre.
Mais j’en vois chez Aliexpress.

[nopxor]

Bonjour Fred,

Le driver L298 a deux entrées IN1 et IN2 et une entrée de validation Enable EN (EN=1 motor ON, EN=0 motor OFF).
Pour faire varier la vitesse du moteur, il faut appliquer un niveau bas sur une des deux entrées IN1 ou IN2 (cela permet de configurer le sens de rotation) et un signal PWM sur l'autre entrée IN1 ou IN2.
Le programme DCC++ utilise lui une pin PWM et une pin DIR pour le sens de rotation ce qui est incompatible en l'état avec le mode de fonctionnement du L298.
Il va être compliqué de modifier le code source pour une telle adaptation.
Néanmoins positron96 semble avoir utilisé un L298 avec DCC++: https://github.com/Locoduino/DCCpp/issues/3
Essaye de le contacter sur ce fil.
Sinon le LMD18200 convient lui parfaitement à DCC++.

[msport]

Chez Digikey, l’ ACS70331EOLCTR-2P5U3 doit être approvisionné fin Novembre.
Mais j’en vois chez Aliexpress.

Chez Aliexpress, ce sont des B bidirectionnels,
Chez Digikey, est-ce qu'il ne faudrait pas en prendre 6000 ?

Toutefois, d'après les caractéristiques, le modèle U unidirectionnel a 0.25V d'offset pour un courant nul (1.5V pour le B).

[_N_]

Bonjour,

Chez Digikey, l’ ACS70331EOLCTR-2P5U3 doit être approvisionné fin Novembre.
Mais j’en vois chez Aliexpress.

.
Oui, 6000 c'est la quantité minimum, ça fait beaucoup pour un test !
Chez AliExpress, il y a des "B" et depuis que j'ai interrogé des vendeurs pour savoir s'il y avait des "U", instantanément, j'ai reçu des liens qui en proposaient ! Soit, mais le marquage annoncé pour ce composant ne me permet pas de juger de leur bonne foi (à moins que quelqu'un sache trouver la correspondance entre la référence du constructeur et le marquage sur le composant SO8).

Pour le L298, je sais cela et c'est bien un LMD18200 que j'ai utilisé pour envoyer la puissance depuis l'Arduino DCC++ (comme le suggère un très bon tuto sur le sujet !! encore merci).

Mais pour l'instant je me concentre sur l’apprentissage de C/MRI ! (après je suivrais les recommandations de CATPLUS à propos de CATS)

Bonne soirée.

[_N_]

Bonjour,

Écran bleu sous JMRI (Windows 7) : Verdict.

J'espérais bien avoir trouvé LE sketch qui aurait permis de planter à lui tout seul un PC sous Windows en 5 minutes : Que nenni ! =>
Ce sketch fonctionne bien et normalement, donc rien de ce côté.
J'ai alors vérifié plein de chose du côté de JMRI (version, utilisation, scripts, ...), mais rien non plus.
... Mais j'avais omis un élément intermédiaire le convertisseur USB-RS232(TTL) !

Le problème est apparu lorsque j'ai voulu garder la liaison USB de mon Arduino pour d'une part télécharger les sketchs au fur et à mesure des développements et de toujours bénéficier de la console. J'avais lu qu'il fallait que l'Arduino soit sous tension AVANT que le script Jython ne soit lancé dans JMRI (ce qui s'avère exact) et que donc toutes les modifications que j'apporterais à mon sketch nécessitaient de quitter JMRI, puis de télécharger l'Arduino avec la nouvelle version, puis de fermer la console (si elle était ouverte), puis de redémarrer JMRI, et enfin de tester à l'aveugle la dite nouvelle version. J'ai donc décidé de déporter sur une autre liaison série la communication avec JMRI ... d'où ce nouveau problème qui est apparu : "l'écran bleu" de Windows fort joli mais peu très gênant pour l'exploitation des trains.

Pour faire court :
Ce qu'il NE faut PAS utiliser pour une telle liaison : Les modules qui utilisent le driver PL2303. Il est de très mauvaises facture et ne supporte pas du tout l'envoi en grande quantité de données (voir la photo "Exemple_Module USB-RS232TTL_PL2303_R.jpg") <-- A BANNIR.

En revanche les modules à base de CH340/341 fonctionnent bien ; ils équipent d'ailleurs les Arduino clonés Chinois.
Mais mon choix s'est porté sur les modules à base de FTDI voir les deux photos "Exemple_Module USB-RS232TTL_PL2303_R.jpg" et "Exemple_Module FocaPro USB-RS232TTL_CP2102_R.jpg" (celui-ci est un très bon module). Ces modèles utilisent un pilote équivalent au FTDI dont le nom est CP2102. Ce pilote est même parfois directement reconnu par Windows 7. Si ce n'est pas le cas, il faudra aller le chercher chez le fabriquant de la puce "Silab" (https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers).

Autre information : Pour recevoir mais aussi envoyer les données à JMRI, j'utilise (encore pour l'instant) la bibliothèque <SoftwareSerial.h>. Mes tests sont limités à l'envoi vers JMRI de 8 informations en provenance des capteurs de présence sur les voies, et de la réception d'une seule données  en provenance de JMRI et redirigée sur la LED de l'Arduino (broche 13) que je fais clignoter à 0,5hz environ. Et ça tient la route.
Je vais quand même tester la bibliothèque <AltSoftSerial.h> qui semble moins gourmande en ressource et plus fiable pour le fullduplex (malgré la perte du PWM).

Et depuis, tout fonctionne !

Voilà, si ça peut dépanner quelqu'un !
Fred

[_N_]

Bonjour,

... Et du coup, hop une modification du sketch et me voilà sous C/MRI.

Quid de la liaison du type 8N2 (donc avec deux bits de 'stop') : Après y avoir réfléchi ce deuxième bit de stop s'apparente à un bit 'stop' une once plus long donc à une mini tempo pendant laquelle la ligne physique de la liaison série reste à '1'. J'ai volontairement omis cela ce qui m'a permis d'utiliser la bibliothèque "<SoftwareSerial.h>" qui ne sait faire que du 8N1. Et bien ça fonctionne plutôt bien.
J'ai aussi passé la vitesse de 9600 bauds à 19200 bauds et ça fonctionne aussi très bien. Cela permet de libérer un petit peu de temps machine car les transmissions sont plus courte (en temps) ... Et c'est très agréable de trouver dans JMRI le protocole déjà implémenté, en tout cas pour moi, bien mieux que les scripts Jython (sans compter les outils disponibles pour débugger cette liaison). Il n'y a KA se concentrer sur le sketch de l'Arduino !

Seul bémol, je ne maitrise pas JMRI et j'ai du mal à lui faire enregistrer mes configurations qui se perdent régulièrement. Bon, vu le peu que j'ai à saisir pour mes essais, je vais vite à tout retaper!
Et je ne sais pas paramétrer la liaison série du côté de JMRI (par exemple pour lui faire changer le 8N2 en 8N1) ou pour régler intervalle entre deux pooling).

En tout cas merci à Nopxor pour cette suggestion : Je l'adopte.

Fred