1
Présentez vous ! / Re : Bonjour
« le: juillet 10, 2019, 07:18:00 pm »
Bienvenue sur LOCODUINO ! 
L'Arduino pour le train miniature
Nouvelles:
Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
2
Vos projets / Re : BALDUINO WIFI
« le: juillet 05, 2019, 04:27:11 pm »
Bonjour,
le "/R" est le chemin après l'IP.
Par exemple si le serveur est à l'IP 192.168.1.1, accéder à http://192.168.1.1/R avec ton navigateur te renverra "AV"
Ceci dit, je ne pense pas que faire tourner un serveur web pour communiquer soit la bonne solution (à vrai dire ça n'est pas du tout comme ça qu'il faut faire), il vaudrait mieux communiquer directement avec les sockets. Cherche "ESP32 socket examples" tu trouveras des tutos, par exemple : https://techtutorialsx.com/2018/05/25/esp32-socket-server-controlling-a-relay-remotely/
le "/R" est le chemin après l'IP.
Par exemple si le serveur est à l'IP 192.168.1.1, accéder à http://192.168.1.1/R avec ton navigateur te renverra "AV"
Ceci dit, je ne pense pas que faire tourner un serveur web pour communiquer soit la bonne solution (à vrai dire ça n'est pas du tout comme ça qu'il faut faire), il vaudrait mieux communiquer directement avec les sockets. Cherche "ESP32 socket examples" tu trouveras des tutos, par exemple : https://techtutorialsx.com/2018/05/25/esp32-socket-server-controlling-a-relay-remotely/
3
JMRI et Arduino / Re : Protocole de pilotage
« le: juillet 05, 2019, 09:32:49 am »
Bonjour,
Juste pour info, j'ai entrepris de coder un analyseur C/MRI et une émulation des SMINI dans le but de faire apparaître des satellites V1 comme des SMINI pout JMRI. C'est pas fini, ça ne fonctionne pas encore mais l'analyseur est implémenté (un automate pour le message et un pour le protocole) mais évidemment pas testé.
L'architecture objet permet d'ajouter l'émulation des autres cartes C/MRI par la suite. Ça sera étendu aux satellites V2 dans le futur.
Il y a encore de travail : un peu de code à écrire et beaucoup de test.
Le repository est ici : https://github.com/Locoduino/CMRIParser
PS : J'ai examiné la bibliothèque de madleech : https://github.com/madleech/ArduinoCMRI. Elle ne me satisfait pas.
Au moins deux bugs sont présents : lignes 115 et 130 les tests sont faux
La transmission fait une attente active (appel de delay) de 50ms, bloquant les autres opérations sur la carte
La transmission est monolithique et bloque potentiellement sur le buffer d'émission.
Juste pour info, j'ai entrepris de coder un analyseur C/MRI et une émulation des SMINI dans le but de faire apparaître des satellites V1 comme des SMINI pout JMRI. C'est pas fini, ça ne fonctionne pas encore mais l'analyseur est implémenté (un automate pour le message et un pour le protocole) mais évidemment pas testé.
L'architecture objet permet d'ajouter l'émulation des autres cartes C/MRI par la suite. Ça sera étendu aux satellites V2 dans le futur.
Il y a encore de travail : un peu de code à écrire et beaucoup de test.
Le repository est ici : https://github.com/Locoduino/CMRIParser
PS : J'ai examiné la bibliothèque de madleech : https://github.com/madleech/ArduinoCMRI. Elle ne me satisfait pas.
Au moins deux bugs sont présents : lignes 115 et 130 les tests sont faux
La transmission fait une attente active (appel de delay) de 50ms, bloquant les autres opérations sur la carte
La transmission est monolithique et bloque potentiellement sur le buffer d'émission.
4
Vos projets / Re : BALDUINO WIFI
« le: juillet 03, 2019, 08:57:01 am »
Bonjour,
J'ai fait des test longue durée sur une communication en UDP entre mon Mac et un Weimos Mini D1 (ESP8266) pour un truc qui n'a rien à voir avec le modélisme ferroviaire. Le Mac envoyait un message toutes les 10s avec un numéro d'ordre. Le Mini D1 incrémentait de son côté un compteur et le comparait avec le numéro d'ordre pour voir si un message était perdu. L'ensemble a tourné pendant 3 jours.
Résultat : 12% des messages sont perdus, ce qui est bien au dessus de ce qui est attribuable au fait que l'UDP ne fait pas d'acquittement. On va dire que la communication en UDP sur un ESP8266 marche jusqu'à un certain point mais que bon c'est très très loin d'être fiable.
Donc ne pas hésiter à répéter les messages.
Par ailleurs, j'avais aussi fait quelques tests, mais de manière plus informelle, avec un serveur http sur le même Weimos Mini D1. Le serveur répond un peu quand ça lui chante : des requêtes qui n'aboutissent pas ou qui aboutissent après un délai important. Je ne saurais dire la proportion d'échec mais c'est loin d'être négligeable. J'ai pas encore essayé les websocket.
J'ai fait des test longue durée sur une communication en UDP entre mon Mac et un Weimos Mini D1 (ESP8266) pour un truc qui n'a rien à voir avec le modélisme ferroviaire. Le Mac envoyait un message toutes les 10s avec un numéro d'ordre. Le Mini D1 incrémentait de son côté un compteur et le comparait avec le numéro d'ordre pour voir si un message était perdu. L'ensemble a tourné pendant 3 jours.
Résultat : 12% des messages sont perdus, ce qui est bien au dessus de ce qui est attribuable au fait que l'UDP ne fait pas d'acquittement. On va dire que la communication en UDP sur un ESP8266 marche jusqu'à un certain point mais que bon c'est très très loin d'être fiable.
Donc ne pas hésiter à répéter les messages.
Par ailleurs, j'avais aussi fait quelques tests, mais de manière plus informelle, avec un serveur http sur le même Weimos Mini D1. Le serveur répond un peu quand ça lui chante : des requêtes qui n'aboutissent pas ou qui aboutissent après un délai important. Je ne saurais dire la proportion d'échec mais c'est loin d'être négligeable. J'ai pas encore essayé les websocket.
5
Vos projets / Re : Article 232 - Va et vient
« le: juillet 01, 2019, 06:43:50 pm »
Hello Steve
The project uses the DCCpp library (Thierry is the author). This library is available through the library manager of the IDE. In Tools menu, choose Manage libraries... and type DCCpp in the search box
Best regards
PS: to translate you can use this excellent translator: https://www.deepl.com/translator
The project uses the DCCpp library (Thierry is the author). This library is available through the library manager of the IDE. In Tools menu, choose Manage libraries... and type DCCpp in the search box
Best regards
PS: to translate you can use this excellent translator: https://www.deepl.com/translator
6
Vos projets / Re : BALDUINO WIFI
« le: juillet 01, 2019, 07:50:26 am »
Bonjour,
request est un char, il est déclaré deux lignes au dessus. Ce n'est donc pas un objet et par conséquent il n'a pas de méthode indexOf.
request est un char, il est déclaré deux lignes au dessus. Ce n'est donc pas un objet et par conséquent il n'a pas de méthode indexOf.
7
Modélisation, Architectures logicielles et matérielles / DÉPLACÉ: Protocole de pilotage
« le: juin 28, 2019, 09:13:05 am »8
Le logiciel DCC++ / Re : L9110S Dual Motor Driver pour DCC++
« le: juin 20, 2019, 10:03:01 pm »
Bonsoir,
La doc est dans la datasheet. J'ai fait une bibliothèque il y a quelques temps pour l'utiliser avec l'interruption plutôt que reset : https://github.com/Locoduino/KeepMeAlive
C'est disponible via le gestionnaire de bibliothèques de l'IDE.
La doc est dans la datasheet. J'ai fait une bibliothèque il y a quelques temps pour l'utiliser avec l'interruption plutôt que reset : https://github.com/Locoduino/KeepMeAlive
C'est disponible via le gestionnaire de bibliothèques de l'IDE.
9
Le logiciel DCC++ / Re : L9110S Dual Motor Driver pour DCC++
« le: juin 20, 2019, 02:04:52 pm »
Il y a un watchdog intégré aux Arduino. Il est conçu pour fonctionner de manière indépendante du programme pour construire des systèmes plus sûrs. Il a sont propre oscillateur interne. Donc ajouter du matériel externe n'est pas nécessaire.
10
Le logiciel DCC++ / Re : L9110S Dual Motor Driver pour DCC++
« le: juin 20, 2019, 09:03:21 am »
Il ne s’agit pas de se ronger les ongles mais d’examiner les moyens défensifs contre des pannes qui peuvent survenir. Pour fabriquer des systèmes fiables il est nécessaire de ne pas s’occuper que du fonctionnement nominal. Mais il ne s’agit pas non plus de mettre en œuvre des dispositifs complexes. Programmer le watchdog pour faire un reset du CPU ou bien pour déclencher une interruption qui va couper la génération du signal DCC c’est simple.
11
Le logiciel DCC++ / Re : L9110S Dual Motor Driver pour DCC++
« le: juin 19, 2019, 01:59:43 pm »
Non non non
je veux dire qu'il faut regarder de ce côté pour voir si ce danger existe (surtout quand je vois passer des dizaines d'ampères)
Et si il existe, modifier ou ajouter ce qu'il faut pour rendre tout cela plus robuste. Par exemple mettre un watchdog sur le micro. La procédure de coupure de jus est suffisamment rapide mais si programme principal cesse de fonctionner, ça fera du vilain.
je veux dire qu'il faut regarder de ce côté pour voir si ce danger existe
(surtout quand je vois passer des dizaines d'ampères)Et si il existe, modifier ou ajouter ce qu'il faut pour rendre tout cela plus robuste. Par exemple mettre un watchdog sur le micro. La procédure de coupure de jus est suffisamment rapide mais si programme principal cesse de fonctionner, ça fera du vilain.
12
Le logiciel DCC++ / Re : L9110S Dual Motor Driver pour DCC++
« le: juin 19, 2019, 12:26:58 pm »
Juste une note concernant la réactivité du système quand un court circuit se produit. J'avais discuté de ça avec Dominique.
Le MAX471 a une latence d'environ 5µs
Une conversion analogique numérique nécessite 150µs (mais ça peut aller plus vite en changeant la fréquence de l'horloge du convertisseur)
La latence due au logiciel est difficile à évaluer, je ne connais pas la durée d'exécution de loop de DCCpp ni d'ailleurs où cette mesure est effectuée, dans le programme principal ? dans la routine d'interruption ? (probablement pas car elle serait plus longue que le temps entre deux interruptions sauf si DCCpp change l'horloge du convertisseur). Disons 100µs ?
Ensuite le temps de couper, disons 5µs
Le pont en H lui même est-il protégé par un mécanisme ?
Bon, le court jus dure donc 260µs. Avec 10A et 18V, ça représente pas grand chose : 46,8 mJ
Mais que se passe-t-il si le logiciel plante mais pas l'IT qui génère le signal DCC ?
Le MAX471 a une latence d'environ 5µs
Une conversion analogique numérique nécessite 150µs (mais ça peut aller plus vite en changeant la fréquence de l'horloge du convertisseur)
La latence due au logiciel est difficile à évaluer, je ne connais pas la durée d'exécution de loop de DCCpp ni d'ailleurs où cette mesure est effectuée, dans le programme principal ? dans la routine d'interruption ? (probablement pas car elle serait plus longue que le temps entre deux interruptions sauf si DCCpp change l'horloge du convertisseur). Disons 100µs ?
Ensuite le temps de couper, disons 5µs
Le pont en H lui même est-il protégé par un mécanisme ?
Bon, le court jus dure donc 260µs. Avec 10A et 18V, ça représente pas grand chose : 46,8 mJ
Mais que se passe-t-il si le logiciel plante mais pas l'IT qui génère le signal DCC ?
13
Vos projets / Re : Satellite V2
« le: juin 18, 2019, 03:02:37 pm »
Je suis saturé de boulot en ce moment 
J'ai très peu avancé mais l'été arrive avec plus de disponibilités.
J'ai très peu avancé mais l'été arrive avec plus de disponibilités.
14
Débuter / Re : driver usb pour nano introuvable
« le: juin 15, 2019, 09:37:24 am »
Bonjour,
Il existe plusieurs types d’interface USB-serie : CH340G, FT232, PL2303, ...
Qu’y a-t-il inscrit sur le votre ?
Il existe plusieurs types d’interface USB-serie : CH340G, FT232, PL2303, ...
Qu’y a-t-il inscrit sur le votre ?
15
JMRI et Arduino / Re : Protocole de pilotage
« le: juin 02, 2019, 10:34:26 am »
En résumé si j'ai bien compris (j'ai survolé les docs) :
Le standard C/MRI couvre à la fois du matériel (transmission via RS485 le long d'une chaine de nœuds, chaque nœud assurant la transmission eu nœud suivant si le message n'est pas pour lui) et du logiciel : format de trame.
JMRI supporte un système de configuration des capteurs (et des actionneurs) pour un certains nombre de cartes compatibles C/MRI : USIC, SUSIC ou Smini. La SUSIC par exemple est une carte supportant jusqu'à 64 cartes filles, chacune avec 24 ou 32 lignes. Donc 64 x 32 = 2048 E/S
L'avantage est que JMRI permet de configurer ceci de manière plus conviviale via une interface graphique.
L'idée est donc de faire une carte qui, par exemple, se fait passer pour une SUSIC (enfin un peu moins, 2048 E/S c'est 158 Satellites mais on peut imaginer d'avoir des passerelles CAN-CAN de manière à monter au dessus de 100 nœuds). Elle reçoit des trames de JMRI via la ligne série. Ces trames sont telles que décrites dans un manuel payant mais que j'ai trouvé sur le NMRA : https://www.nmra.org/sites/default/files/standards/sandrp/pdf/S-9.10%20CMRInet%20DRAFT.pdf d'une part. D'autre part, elle transcode ces messages à destination de cartes Satellite V1 (ou V2). À l'inverse elle reçoit les messages des Satellites et les transcodes pour se faire passer pour une SUSIC.
C'est l'idée ?
Le standard C/MRI couvre à la fois du matériel (transmission via RS485 le long d'une chaine de nœuds, chaque nœud assurant la transmission eu nœud suivant si le message n'est pas pour lui) et du logiciel : format de trame.
JMRI supporte un système de configuration des capteurs (et des actionneurs) pour un certains nombre de cartes compatibles C/MRI : USIC, SUSIC ou Smini. La SUSIC par exemple est une carte supportant jusqu'à 64 cartes filles, chacune avec 24 ou 32 lignes. Donc 64 x 32 = 2048 E/S
L'avantage est que JMRI permet de configurer ceci de manière plus conviviale via une interface graphique.
L'idée est donc de faire une carte qui, par exemple, se fait passer pour une SUSIC (enfin un peu moins, 2048 E/S c'est 158 Satellites mais on peut imaginer d'avoir des passerelles CAN-CAN de manière à monter au dessus de 100 nœuds). Elle reçoit des trames de JMRI via la ligne série. Ces trames sont telles que décrites dans un manuel payant mais que j'ai trouvé sur le NMRA : https://www.nmra.org/sites/default/files/standards/sandrp/pdf/S-9.10%20CMRInet%20DRAFT.pdf d'une part. D'autre part, elle transcode ces messages à destination de cartes Satellite V1 (ou V2). À l'inverse elle reçoit les messages des Satellites et les transcodes pour se faire passer pour une SUSIC.
C'est l'idée ?