JMRI

[CATPLUS]

Bonjour,
Ce matin un lapin etc, etc... j'ai lu ce qui suit sur le site de MRH

https://model-railroad-hobbyist.com/node/37319

Certes il n'apporte pas des réponses à la programmation de certain décodeur, mais 2 choses mon interpellé,

1 La configuration des préférences entre Jmri et DCC++ (Arduino)
2 La seconde la valeur des résistances R1 & R2 dans le Shield
Marcel

[Dominique]

La valeur de 0,15 ohms pour la mesure de courant dans les cartes L298 doit être associée au gain de l’ampli op (lm358 en général) de façon à obtenir une relation entre la tension lue sur une entrée analogique de l’Arduino et le courant mesuré :
Mesure de consommation : 1.65V/A

A titre de rappel, la lecture de CVs se fait par la détection d’impulsions de 60mA pendant 6mS, générées par le décodeur qui actionne le moteur pour cela.
Notons que certains décodeurs ne réagissent pas comme on l’attend et ceci n’est pas un problème de JMRI qui doit être d’abord configuré comme il faut !
Sinon les problèmes s’empilent et ça devient compliqué 

[Chris]

Bonjour,
impossible de daire fonctionner les scripts, tout le reste fonctionne, mais dans la console système de JMRI j'ai le message suivant :

2020-09-15 18:17:16,288 jython.RunJythonScript                ERROR - Unable to execute script. [AWT-EventQueue-0]
javax.script.ScriptException: NameError: global name 'extport' is not defined in <script> at line number 86
....
....
Caused by: Traceback (most recent call last):
  File "<script>", line 86, in <module>
  File "<script>", line 22, in __init__
NameError: global name 'extport' is not defined

Ne connaissant pas JavaScript, je suis incapable d'en déduire quelque chose.
j'ai bien mis mon port "COM6" partout,
la même vitesse, toutes les opérations dans l'ordre, rien n'y fait.
Merci d'avance pour vos lumières.

[Dominique]

C’est portant écrit : « export » n’a pas été défini !

[Souris verte]

Extport, pas export...
Erreur de frappe ?

[Dominique]

Extport, pas export...
Erreur de frappe ?

Voilà une piste de recherche !

[Chris]

C'est bien extport (port externe) qu'il y a dans le script .
Pourtant j'ai bien mis mon port "COM6" identifié par l'arduino dans la ligne voulue.

[Souris verte]

Hello,
La compil trouve un pb ligne 86 puis 22...
Sans le script, pas facile de t’aider.

Pour le COM6, je ne vois pas trop le lien.

[Chris]

Le script est le suivant : sensor_scan.py :

# Capture Sensor Data from an Arduino Serial Transmission
# In the form: Character "A" followed by
# 1 byte: bit 7 Sensor ON/OFF bit 6-0 sensor # 1-127
# Author: Geoff Bunza 2018 based in part on a script by
# Bob Jacobsen as part of the JMRI distribution
# Version 1.2
# An Automat object to create a separate thread
# that can sit there, waiting for each character to arrive

import jarray
import jmri
import purejavacomm

class SerialSensorMux(jmri.jmrit.automat.AbstractAutomaton) :
    # ctor starts up the serial port
    def __init__(self, portname) :
        global extport
        self.portID = purejavacomm.CommPortIdentifier.getPortIdentifier(portname)
   try:
            self.port = self.portID.open("JMRI", 50)
        except purejavacomm.PortInUseException:
            self.port = extport
        extport = self.port
        # set options on port
        baudrate = 115200
        self.port.setSerialPortParams(baudrate,
            purejavacomm.SerialPort.DATABITS_8,
            purejavacomm.SerialPort.STOPBITS_1,
            purejavacomm.SerialPort.PARITY_NONE)
        # Anticipate the Port Opening will restart the Arduino
        # Uncomment the following line for use on RPi You may need to fiddle with the 2000
        # msec delay this works on my RPi 3 B+
        #self.waitMsec(2000)
      # get I/O connections for later
        self.inputStream = self.port.getInputStream()
        self.outputStream = self.port.getOutputStream()
        return

    # init() is the place for your initialization
    def init(self) :
        return

    # handle() is called repeatedly until it returns false.
    def handle(self) :
        global ttest
        if ttest == 1 :
                self.outputStream.write('!')
                self.outputStream.write('!')
                self.outputStream.write('!')
                self.outputStream.write(0x0D)
                ttest = 0
        # get next character   
        if self.inputStream.read() != 65 :
                return 1
        sensor_num = self.inputStream.read()
        sensor_state = ( sensor_num>>7 ) & 1
        sensor_num = sensor_num & 0x7f
        mesg = "AR:%d" % (sensor_num)
        if sensor_num == 1 and sensor_state == 1 :
            print "Sensor Read Ends"
            self.inputStream.close()
            self.outputStream.close()
            self.port.close()
            return 0
        s = sensors.getByUserName( mesg )
        if s is None :
                print mesg, " Not Available"
                return 1
        if sensor_state == 1 :
                s.setKnownState(ACTIVE)
        if sensor_state == 0 :
                s.setKnownState(INACTIVE)

        return 1    # to continue 0 to Kill Script

    def write(self, data) :
        # now send
        self.outputStream.write(data)
        return

    def flush(self) :
        self.outputStream.flush()
        return
ttest=1
# create one of these; provide the name of the serial port
a = SerialSensorMux("COM6")

# set the thread name, so easy to cancel if needed
a.setName("SerialSensorMux script")

# start running
a.start();

# setup  complete
a.flush()


la ligne
 "self.portID = purejavacomm.CommPortIdentifier.getPortIdentifier(portname)"

récupère un identifiant du port série portname (ici COM6) pour ensuite ouvrir le port par un open, mais ne le trouve pas (enfin me semble-t-il) d'où le extport non défini.
Mais je ne comprends pas pourquoi... l'arduino communique bien avec mon ordi via ce port puisque je peux televerser le sketch.
Je fais le test de communication entre JMRI et Arduino en lecture de capteurs.
De l'article "Communications entre JMRI et Arduino"

[msport]

Bonsoir,
ça me rappelle une expérience avec un script de JMRI qui établissait une liste des port COM du PC et considérait que c'était le nième qu'il fallait ouvrir. Pas de chance, il y avait un port virtuel(?) qui décalait la liste.
Attention c'est ce dont je me souviens et que les années n'ont pas amélioré. Dominique avec un Mac se demandait ce que problème de port COM pouvait bien être.
Finalement il suffisait de décaler de un dans la liste, donc modifier le script fourni.
Bon, ça n'a peut-être rien à voir, c'est pour faire avancer le schimblick. Bonne chance.

[Dominique]

Chris,

A mon avis vous n’avez pas lu attentivement la totalité de l’article et/ou respecté les indications concernant les ports utilisés, notamment les choix des bons scripts, ce qui pourrait expliquer que la globale « extport » ne doit pas définie.
En tout cas à l’époque de l’écriture de cet article ça marchait bien.
Peut-être une evolution de JMRI a changé quelque script.

Les spécialistes de JMRI pourront sans doute vous dépanner (je n’ai rien pour le faire en ce moment).

[Chris]

Bonjour et merci pour vos tentatives de réponse,
j'ai fini par trouver la raison de mon problème dont je vous fais part... ça peut aider d'autres novices comme moi sur l'arduino, et JMRI.

Alors voilà :
 - J'ai bien configuré ma liaison série dans l'arduino en COM6 et 115200 bauds
 - même chose dans le script Sensor_Scan.py pour JMRI

Mais comme j'ai utilisé  PanelPro pour essayer de commander mes locos, j'avais configuré ce dernier en mode DCC++ sur le port série.
Du coup, en ajoutant mon tableau de capteurs en Internal comme précisé dans l'article de Dominique,
 le script Sensor_Scan.py trouvait toujours le port occupé pour le DCC

La solution est finalement évidente : On ne peut visiblement pas faire les 2 en même temps.
Et en désactivant la liaison DCC++, ça marche !
(A une exception prêt cependant : le script s'attend à gérer des capteurs dénommés "AR:" et non "AR", mais cela a déjà été signalé par ailleurs me semble-t-il)
Voilà.
Donc moi qui voulais utilisé un arduino pour les entrées capteurs et un pour les commandes d'aiguilles+ train, je vais devoir revoir mon schéma.
Peut-être comme suit :
JMRI en gestionnaire sur 2 ports USB relié à 2 arduino :
L'un transmettant les détections, et autres E/S en internal et l'autre en DCC pour les sorties Trains et Aiguillages

Cordialement

[Dominique]

Bravo !
Je suis sûr que ça va aider d’autres JMRIstes.

Merci d’avoir persévéré .

[_N_]

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

[Dominique]

Bonjour _N_,

Ton pseudo est dur à taper sur mon iPhone (8 touches pour 3 caractères !). Aurais-tu peut-être un prénom ?

Félicitations pour ton exposé du problème très clair avec une recherche sérieuse et un câblage impeccable de ton réseau  . Je suis sûr que des « as » de JMRI sur Windows vont te trouver la solution très bientôt.

Ce que je ne vais pas pouvoir faire, j’en suis désolé, car je suis sur Mac (exclusivement) et je ne touche à JMRI que très occasionnellement car je développe mon propre gestionnaire sur Arduino (pas d’ordinateur près du réseau sauf pour programmer les Arduino).