Sujets

1

Débuter / Téléversement vers Nano

« le: décembre 13, 2024, 08:07:36 pm »

Bonjour,
Mes téléchargements sous IDE vers Arduino Nano, tout à fait fonctionnelles il y a encore une quinzaine de jours , refusent désormais de s’effectuer avec comme message :
 « avrdude: ser_open(): can't set com-state for "\\.\COM4"
Une erreur est survenue lors du transfert du croquis »

Ceci n’affecte pas les téléchargements vers ESP32 que j’utilise aussi et qui sont toujours opérationnelles.
Les indications sur internet mentionnent le rôle de CH340, mais ne me donnent pas la démarche d’un retour à un bon fonctionnement.
Je dois probablement ne pas être le seul à avoir rencontré ce blocage.
Pourriez-vous m’aider ?
D’avance merci

2

Vos projets / Ecran Elegoo 2.8pouces pour boitier de commande DCC

« le: mai 31, 2021, 01:22:18 pm »

Je projette d’effectuer un bond techno avec mon boitier de commande DCC et notamment substituer la face avant (oled 0.9 pouce et des boutons) par un écran tactile 2.8pouces Elegoo (ili9341).
Ce boîtier de pilotage analogique ou digitale (merci aux réalisateurs de DCC++) tout intégré fonctionne avec ou sans automatisme de va et vient, actionne les fonctions, enregistre les adresses des locomotives et je vais lui ajouter la possibilité de modifier les CV. L’article « Réalisation d’un va et vient automatique et réaliste » par Dominique (rubrique Projet 16 fev 2016) décrit une réalisation très similaire.
Je m’interroge sur le choix du Elegoo 2.8 . Pas trop cher (15€) bonne luminosité, rafraichissement convenable (mise à jour de 5 à 6 valeurs numériques en une cinquantaine de millisecondes). Il ne dispose cependant pas de liaisons externes (tous les i/o de la carte UNO sont utilisés) et je dois  détourner les 4 liaisons vers la carte micro-SD  (inutile pour mon projet) pour communiquer. Par ailleurs la bibliothèque Elegoo fournie avec l’écran intègre une seule police de caractères.
Auriez vous d’autres expériences d’écran tactile (environ de même taille) , comment vous communiquez, et comment ajouter une police de caractère ?

3

Le logiciel DCC++ / Cohabitation DCCpp et Adafruit sur UNO

« le: avril 22, 2020, 11:35:50 pm »

En cette période de confinement, du temps m’est donné pour avancer dans mes automatismes. J’ai remplacé quelques diodes (des signalements d’alarme et d’indication de certains états système) par un écran oled SSD1306. Disposer d’une information en clair sur ce qui se passe, là où il fallait se référer à un guide de fonctionnement pour connaître la signification du clignotement de telle diode est d’un confort considérable (voir photo 1). J’utilise la librairie « Adafruit ». Elle est d’un usage simple avec la liaison I2C. J’ai installé le montage de test sur une carte Mega. Mon confinement aurait donc été une période tranquille si je n’avais pas souhaité migrer ce montage sur une carte UNO. Du point de vue I/O, les implantations nécessaires sont respectées et du point de vue mémoire, je n’ai pas atteint les 32K d’espace programme ni les 2K RAM. La librairie Adafruit est cependant gourmande et nécessite à elle seule 15K. La cohabitation des répertoires <DCCpp.h> et Adafruit_GFX et SSD1306 + Wire.h pour avoir une simple exécution des premières lignes du programme m’a obligé à réduire l’espace d’affichage de l’écran oled à 32 x 128 (pour un composant qui dispose de 64x128 pixels). Mais pour avoir un fonctionnement complet de l’automatisme (DCCpp.begin et DCCpp.beginMain), j’ai du réduire à 16x128. Ce qui limite et dégrade bien évidemment l’affichage. Seule la moitié inférieure de l’écran est accessible (voir photo 2). Bien sûr j’ai toujours la possibilité de rester avec une carte Mega (2€ de plus) mais ...  peut être suis-je passé à coté de quelque chose ?.

4

Composants / Alternative aux circuits MAX471 défectueux

« le: mars 19, 2020, 02:55:32 pm »

Ceux qui ont eu à acheter un circuit MAX471 en 2019 l’ont constaté. Les livraisons ont  été dans la majorité des sources (aussi bien asiatiques qu’occidentales) des produits défectueux. Le défaut est toujours le même, la résistance entre Rs+ et Rs-, normalement très faible, c’est un shunt de 0.033mohm, s’avère être un circuit quasi ouvert. De plus, le fabriquant américain, Maxim Integreted, fait savoir sur son site qu’il ne produira plus ce circuit. Quoiqu’il en soit il m’a fallu trouver un montage de remplacement.
Je vous propose le circuit INA169, tout à fait similaire au MAX 471. Son montage est très simple, la résistance de shunt (Rs) est extérieure ainsi que la résistance de charge (RL) qui fixe la dynamique de mesure. Pour simplifier le montage on relie V+ (pin5) à Vin+ (pin3). La tension de sortie de mesure de courant « I » s’exprime ainsi V = Ix (RsxRL/1K). Le fait de pouvoir choisir Rs et RL permet de rester maître de la dynamique de mesure, ce que ne permettait pas MAX471. Ne pas oublier que la puissance dissipée dans la résistance de shunt est un carré de l’intensité (RsxIxI). Pour une résistance  Rs de 1W  0.01 ohm , vous devrez ne pas excéder un courant de 10 A.J’utilise personnellement un shunt de 1W 0.05ohm.

5

Le logiciel DCC++ / Problème avec la version DCCpp1.3.7

« le: février 21, 2020, 11:41:47 pm »

Je rencontre un problème avec la version d’août dernier 1.3.7. Pas le même que celui signalé par Fabien73 il y a qqs mois. Avec les versions antérieures 1.3.5 et 1.3.6, les deux décodeurs Hornby R8249 que j'utilise pour mes tests fonctionnaient parfaitement .  En chargeant la version 1.3.7 les commandes DCCpp::identifyLocoMain() et DCCpp::readCvMain() restent systématiquement infructueuses (retournent -1) et ceci quelques soient les valeurs entrées DCCpp::ackThreshold. C'est en fait pour l’accès à ce dernier paramètre que j'avais chargé cette version. J'ai bien sûr fait marche arrière. Quelqu'un aurait-il des infos sur ce point,   

6

Le logiciel DCC++ / La brutalité de la commande identifyLocoMain()

« le: octobre 19, 2019, 06:41:52 pm »

Bonjour, J'ai une configuration Arduino UNO - LMD18200 - MAX471 + des interfaces spécifiques et un automatisme, Va et Vient entre 2 capteurs à ultrasons. Ceci marche très bien. Mon logiciel s'appuie sur la bibliothèque DCCpp. Au lancement , le programme interroge le numéro de la machine présente, via DCCpp::identyLocoIdMain(). Cette action provoque des secousses sur nos machines ( nous sommes en échelle zéro)  . Ce qui est normal. Ce qui l'est moins c'est la brutalité de ces secousses. L'usage d'un Lockpilot ECOS par exemple pour une même action, ne fait que très légèrement vibrer nos machines et moins longtemps. Il délivre pourtant du 18V alors que mon électronique n'utilise que du 15V. Quelqu'un aurait-il une piste de réflexion ?

7

Discussions ouvertes / 14 ou 28 fonctions ?

« le: mars 24, 2019, 04:33:52 pm »

Bonjour,  Concernant les "Functions", il est mentionné dans NMRA 9.2.2 (ligne 260 et suivantes) jusqu'à 12 Functions sur les CV 33 à 46, avec en plus les Forward et Reverse HeadLight soit 14 Functions, pas plus.  Cependant le logiciel DCCpp mentionne 28 Functions. Quelqu'un pourrait-il m'éclairer sur ce point ?

8

Présentez vous ! / Bonjour

« le: février 23, 2019, 07:39:13 pm »

Je suis modéliste ferroviaire et construit de A à Z mes modèles en zéro (chacun me demande environ 4 ans). Sans réseau, j’ai souhaité réaliser un va et vient pour les animer sur un bout de rail. J’ai monté il ya deux mois un petit automatisme sur une base Arduino UNO, + LMD 18200 + MAX471 + 2 petits capteurs à ultrason, que j’ai fait marcher en analogique (à 66KHz en Fast PWM) . Fort de ce succès et ayant pris connaissance des articles traitant du logiciel DCC++ et de certaines des réalisations associées, notamment un article complet traitant de la réalisation d’ « un va et vient automatique et réaliste », j’ai entrepris d’implanter dans mon électronique décrite ci-dessus son homologue digital.
Dans mes attentes, je recherchais un logiciel qui ne m’oblige ni à tout réécrire, ni a devenir un expert en C++ comportant une procédure d’implémentation et la liste des commandes pour y accéder. Mes difficultés rencontrées ont été les suivantes : Sur le premier point beaucoup d’articles mentionnaient DCCpp.h et me renvoyaient sur le site GitHub où effectivement bien des noms utilisent le terme DCCpp. J’ai finalement trouvé un DCCpp.h au fond d’un dossier zip DcDccNanoControleur. Pour son implantation, j’ai suivi les indications des articles Locoduino. Ils mentionnent l’usage de la « libraries » Arduino sous Windows et les options d’installation présentes dans les commandes d’en tête du logiciel IDE. Pour l’utilisation de ce logiciel, après des hésitations et des tâtonnements, j’ai finalement identifié une dizaines d’ordres dutype : DCCpp :: begin() , DCCpp :: beginMain(),  DCCpp :: loop(), DCCpp :: identifyLocoIdMain(), DCCpp :: setSpeedMain(),.. et leurs homologues Prod. Aujourd’hui, mon automatisme fonctionne (la partie des fonctions de l’automatisme est pratiquement reprise à l’identique de sa version analogique). Cependant des points ne marchent pas. Les commandes DCCpp ::identifyLocoIdMain(), DCCpp ::readCvMain() ne marchent pas et pourtant lors de mes hésitations sur la chargement de tel ou tel autre logiciel à télécharger, ces commandes ont fonctionnées et notamment j’ai pu vérifier que le contenu des CV de mon décodeur Hornby à 20€ était conforme à la notice du fabriquant. La commande DCCpp ::setSpeedMain() marche et a toujours marché.  Je suspecte des versions logicielles chargées inadaptées, ou incorrectement chargées. L’inexpérience de mes premiers pas dans ce domaine y est bien sûr pour quelques choses. Quelqu’un pourrait-il m’aiguiller sur une démarche pour rectifier ce point. Quoiqu’il en soit je salue et remercie les rédacteurs des différents articles traitant du sujet DCC++. Sans eux je ne me serais certainement pas lancé dans cette aventure.