Messages

1

JMRI et Arduino / Re : JMRI (et le C/MRI)

« le: octobre 12, 2020, 01:45:29 pm »

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

2

JMRI et Arduino / Re : JMRI

« le: octobre 12, 2020, 01:16:35 pm »

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

3

JMRI et Arduino / Re : JMRI

« le: octobre 05, 2020, 06:55:32 pm »

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.

4

JMRI et Arduino / Re : JMRI

« le: octobre 05, 2020, 09:43:21 am »

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

5

JMRI et Arduino / Re : JMRI

« le: octobre 02, 2020, 01:20:03 pm »

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.

6

JMRI et Arduino / Re : JMRI

« le: octobre 01, 2020, 02:26:39 pm »

Bonjour,

Je dois dire que tous ces articles DCC++, JMRI, ... je n'aurai même pas ressorti mes vielles locos des années 80 ! Mais là, je me suis lancé.

Si je n'ai eu aucune difficulté pour installer le DCC++ (avec Ali pour le matériel) associé à JMRI "decodeurPRO", je me suis lancé dans la rétrosignalisation. J'ai donc installé sur une planche d'essai avec un oval, que j'ai découpé en 8 sections qui représentent mes cantons. Après avoir équipée la planche d'une interface de 8 capteurs opto-couplés comme suggéré dans les articles de "LOCODUINO" raccordés sur un Arduino dédié, j'ai raccordé le tout au PC sous JMRI (bien sûr j'ai copié les scripts de Dominique ainsi que ses sketchs ; encore merci). J'ai aussi dessiné cet oval dans "PanelPRO" pour suivre l'occupation des cantons (et j'ai bien sûr galéré sur les fameux ':' dans "AR:" => donc un grand merci pour avoir levé ce lièvre).

Mais voilà :
Très rapidement, moins d'une minute après le lancement d'une loco, JAVA se plante sur mon PC (blocage de toutes les fenêtres => utilisation du "Ctr Alt Supp" bien connu des utilisateurs de Windows (pour tuer la tâche). Sans loco, ça marche. Avec une loco, ça marche moins d'une minute.

Après des dizaines d'essais, je me dis que cela serait dû aux multiples rebonds que la loco génère (mais pas à cause de la CEM puisque tout est galvaniquement isolé).

1) Je décide alors de ré-écrire un sketch qui filtre les entrées.
Grossièrement, je teste mes entrées issu des optocoupleurs toutes les 100ms et si la moyenne des valeurs lues implique un changement d'état, je l'enregistre. Il faut donc environ 1s pour changer un état ; on est donc loin des rebonds !

2) Pour mieux déboguer, je transfère la liaison série initiale vers le JMRI sur une liaison virtuelle (VirtualSerial, broches 10 et 11 de mon UNO). Un petit adaptateur à quelques euro, un driver et hop la nouvelle liaison fonctionne avec JMRI. Et je garde ma console Arduino pour voir ce qui ce passe.
Donc :
-> Console Arduino 115200 bauds
-> Liaison JMRI 19200 bauds (comme décrit dans l'article de Dominique). Je n'envoie des données à JMRI que toutes les 0,5s pour le rafraichissement.

Et le miracle à bien lieu : Ça marche avec ma loco qui parcours son ovale et les cantons passent au rouge avec un petit retard (comme indiqué ci-dessus !).

Mais voilà (encore !) : 5 minutes après une utilisation sans aucun accro, c'est l'écran bleu ("bluescreen"), tout s'arrête et le PC redémarre. Et c'est réglé comme une horloge : Après 5 minutes, écran bleu.
Je change d'ordinateur (un PC de 10ans d'age) et là je passe à 10 minutes avant l'écran bleu.
Nota : Je me suis aperçu que cela arrive même sans lancer de loco su l'ovale !

Je ne trouve rien sur ce sujet sur internet. J'utilise Windows 7 PRO, mon 1er PC a 4Go de mémoire et l'ancien n'en a que 2. Ça ressemble à un dépassement de mémoire, mais je n'en sais rien. Sans utilisation de ce script, pas d'écran bleu et JMRI fonctionne normalement. Le problème survient qu'après avoir lancé le script "sensor_scan". Malheureusement, j'ignore tout du Jython et suis bien incapable de modifier quoi que ce soit ou de gérer des erreurs qui proviendraient de son exécution et donc encore moins gérer des fuites de place mémoire.

Alors chers amis, auriez vous une piste d'exploration pour contourner ce problème. Dans quel log ou quel lien trouver de l'information ?

(Quelques photos pour illustrer le message, si ça s'insère car je ne sais pas le faire !)

Au plaisir de vous lire ...