LOCODUINO
Parlons Arduino => JMRI et Arduino => Discussion démarrée par: Dominique le janvier 02, 2019, 04:17:11 pm
-
Suite à la parution de l’article Communications entre JMRI et Arduino
https://www.locoduino.org/spip.php?article240 (https://www.locoduino.org/spip.php?article240),
ce sujet est ouvert pour recueillir vos réactions et suggestions.
Il est évident qu’une présentation de JMRI pour les débutants serait la bienvenue maintenant. J’appelle donc ceux qui se sentiraient volontaires pour la didactique à bien vouloir me contacter.
Bien cordialement
Dominique
-
Bonjour @ tous !
Pour faire echo à l'excellent article de Dominique et Nopxor, voici pour débuter et déverminer l'approche de JMRI (prononcez JIMRI et non J M R I ;) )
Le descriptif in french in the text de JMRI : http://jmri.sourceforge.net/help/fr/webtoc.shtml (http://jmri.sourceforge.net/help/fr/webtoc.shtml)
Je dirai pour faire simple :
Vous voulez commencer par faire rouler des trains :
Utilisez Decoder Pro http://jmri.sourceforge.net/help/fr/html/apps/DecoderPro/index.shtml (http://jmri.sourceforge.net/help/fr/html/apps/DecoderPro/index.shtml) qui relié à votre DCC++ vous décodera vos machines, fournira une manette de commande, et même sur tablette/smartphone avec Engine Drive sous android (désolé je suis open source jusqu'au bout ::) ) https://play.google.com/store/apps/details?id=jmri.enginedriver&hl=fr (https://play.google.com/store/apps/details?id=jmri.enginedriver&hl=fr)
Déjà vous roulez.
Après allez-y step by step dans Panel Pro http://jmri.sourceforge.net/help/fr/html/apps/PanelPro/PanelPro.shtml (http://jmri.sourceforge.net/help/fr/html/apps/PanelPro/PanelPro.shtml) : il est composé de plusieurs types de panneaux. Vous pourrez dessiner votre réseau, ses aiguillages, ses capteurs, ses itinéraires...
Un tuyau dans l'ordre des choses : Créez vos aiguillages, puis vos capteurs, puis vos cantons, et enfin votre réseau.
Voila de quoi bien démarrer.
Pour préciser ma configuration JMRI sur un PC Portable en WiFi / Engine Driver sur tablette en WiFi / ma DCC++ en ethernet (non Bobbyandco toujours pas sur WiFi j'ai planché sur JMRI ;) )
(Edit: correction des accents)
-
J’ajoute qu’il faut regarder cette réalisation qui va dans le même sens :
http://forum.locoduino.org/index.php?topic=507.0 (http://forum.locoduino.org/index.php?topic=507.0)
... pour ceux qui sont bien plus expérimentés.
-
A peine l'article paru, déjà installé dans un Arduino.
Tout semblait bien se passer, connexion USB d'un UNO, relevé du port, vérification des AAAAAAAAAAAAAA, modification du script, création du tableau, suppression des 0 et 1, sauvegarde du panneau. Lancement du script. Ah, juste une partie passe en actif/inactif. Test d'un changement d'état d'un "inconnu", bon il passe en actif.
Mais de là plus rien, la sauvegarde du panneau ne récupère rien. Le tableau ne réagit pas. On teste le SensorSerialClose modifié pour le port USB. On refait le tableau. Le tableau ne réagit toujours pas.
Passage à un Mega sans plus de résultats.
Test effectué sur un portable i5 W7 qui a déjà fait tourner JMRI avec DCC++ et manette wifi.
Je vais tester sur une autre configuration, à suivre.
(Edit: rectif des accents)
-
Et on peut rappeler ce fil, avec plein de liens utiles ...
http://forum.locoduino.org/index.php?topic=476.0
-
Bonjour Michel,
Je ne comprends pas ces problèmes.
As-tu bien exécuté le script SensorSerialClose.py avant de relancer le script Sensor_Scan.py ?
Je viens de refaire des tests chez moi avec un Mega et cela fonctionne correctement.
-
Mais de là plus rien, la sauvegarde du panneau ne récupère rien. Le tableau ne réagit pas. On teste le SensorSerialClose modifié pour le port USB. On refait le tableau. Le tableau ne réagit toujours pas.
Passage à un Mega sans plus de résultats.
Test effectué sur un portable i5 W7 qui a déjà fait tourner JMRI avec DCC++ et manette wifi.
Je vais tester sur une autre configuration, à suivre.
(Edit: rectif des accents)
Sur mon Mac, à part quelques cases qui restent « inconnu » après l’execution du script « sensor_scan », je récupère bien le tableau avec ses éléments. Et les changements sur l’Arduino se répercutent bien sur le tableau.
On devrait pouvoir améliorer le programme et le script qui sont très simples.
-
As-tu bien exécuté le script SensorSerialClose.py avant de relancer le script Sensor_Scan.py ?
Oui, oui, pas la première fois mais à l'occasion des nouvelles tentatives. Je revérifierai ce point.
Mais la question de base c'est testez vous sur Mac ou sur Windows ? Avec un vrai clone ou sa copie ?
J'ai déjà souffert des problèmes de communication entre Arduino et Windows (en particulier avec le driver du CH340G)
Avec CDM-rail et processing, mais pas que.
-
J'utilise Windows 7 et un clone Mega avec CH340G.
-
Donc nouvelle tentative RÉUSSIE avec un mega, un PC fixe, W10 et un port USB direct de la carte mère.
Tous les ports en l'air sont passés Inactifs, et un port mis au GND est passé Actif.
Bien qu'un peu inquiet car le test via l'IDE donnait des AAAAAAAAAA avec de la friture.
Nota un deuxième port USB était connecté sur un UNO avec la BaseStation, reconnue en DCC++ par JMRI.
Mais il ne faut pas rater une étape ! Je vais réessayer sur mon portable.
-
Les AAAAAAA avec de la friture c'est normal, le messages pour chaque port commence par un "A" suivi de l'état !
Voilà ce que j'ai :
(https://www.locoduino.org/local/cache-vignettes/L610xH225/capture1-e105d.jpg?1546266995)
-
Bon, donc OK aussi sur le portable après mise à jour de Java, avec les mêmes éléments (Mega).
Effectivement, il faut utiliser impérativement le reset du Mega et le script SensorSerialClose.py
J'imagine qu'on peut mixer sensors et turnouts sur le même Mega en choisissant des plages ad hoc ?
-
Bonsoir et bonne année 2020 a tout les locoduinistes
Je me permet de poster sur ce topic car j'ai testé séparément et avec succès les scripts Sensor_scan 14 et jmriturnoutchannels1_1
Je souhaiterais maintenant fusionner les 2 scripts si possible mais mes connaissances en python laissent à désirées
Avant d'aller plus loin et d'envahir inutilement le forum: Est ce que quelqu'un pourrait m'aiguiller sur la marche à suivre
Merci d'avance et bonne soirée à vous
-
Bonjour,
Il vaudrait mieux utiliser une carte arduino pour les entrées et une autre pour les sorties et garder les programmes séparés.
-
Merci pour votre réponse,
J'imaginais cela possible, je vais faire comme vous me l'avez indiqué
Cordialement
-
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
-
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é :P
-
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.
-
C’est portant écrit : « export » n’a pas été défini !
-
Extport, pas export...
Erreur de frappe ? ;)
-
Extport, pas export...
Erreur de frappe ? ;)
Voilà une piste de recherche !
-
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.
-
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.
-
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"
-
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.
-
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).
-
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 ! :D :D :D
(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
-
Bravo !
Je suis sûr que ça va aider d’autres JMRIstes.
Merci d’avoir persévéré .
-
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 ...
-
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 ;D. 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).
-
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: 8)
http://forum.locoduino.org/index.php?topic=507.0
-
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.
-
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
-
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
-
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
-
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
-
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.
-
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++.
-
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).
-
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.
-
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 (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
-
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