Auteur Sujet: Décoduino : une "centrale DCC" dédiée à la voie de programmation  (Lu 34548 fois)

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Décoduino : une "centrale DCC" dédiée à la voie de programmation
« Réponse #75 le: octobre 31, 2020, 01:31:26 pm »
Oui ... mais non.
Je ne doute pas un instant que tu vas réussir à faire un éditeur qui permet d'ajouter, de retirer des lignes.
J'en suis certain, je te fais confiance.

Mais, et tu l'as dit toi même : ce n'est pas la bonne piste.
Même toi, tu te demandais pourquoi on devait faire des choses en dehors du programme...

Non. La bonne solution est d'intégrer ça au programme pour qu'un seul programme s'occupe de tout.
Je m'y mets.

Denis  :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

jfs59

  • Newbie
  • *
  • Messages: 22
    • Voir le profil
Re : Décoduino : une "centrale DCC" dédiée à la voie de programmation
« Réponse #76 le: octobre 31, 2020, 01:45:35 pm »
Citer
Mais, et tu l'as dit toi même : ce n'est pas la bonne piste.
Même toi, tu te demandais pourquoi on devait faire des choses en dehors du programme..
.

Bah oui ca me semble une évidence donc je jette l'éponge je vais pas plus loin même si c'était un challenge (enfin un petit challenge  ::))

J'avais déjà fait le panneau de choix d'images mdr...

je vais continuer a suivre en mode silencieux ++
« Modifié: octobre 31, 2020, 01:53:50 pm par jfs59 »

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Décoduino : une "centrale DCC" dédiée à la voie de programmation
« Réponse #77 le: octobre 31, 2020, 03:06:32 pm »
Merci quand même... Jean-François ?
Tu as fait progresser le projet. ;D

C'est vrai qu'il y avait un manque de ce côté là. Et tu as bien mis le doigt dessus.
Je ne m'étais jamais vraiment posé la question jusqu'au bout. Mais là, c'est clair.

Et il va falloir que je fasse pareil pour les autres programmes (Edite_TCO et Trains_TCO qui souffrent du même problème)

Denis  :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

jfs59

  • Newbie
  • *
  • Messages: 22
    • Voir le profil
Re : Décoduino : une "centrale DCC" dédiée à la voie de programmation
« Réponse #78 le: octobre 31, 2020, 06:31:28 pm »
Citer
Liste les tailles des décodeurs, liste des courants maximaux.
Les deux autres ne sont pas lisibles (ou je n'y suis pas arrivé…)

cvsummary.csv et reservedCVs.csv

contiennent bien les 2897 decodeur mais tres peu d'infos autres

parfois on trouve des trucs du genre

Codigo de Bloqueo de CVs;   Codigo de Bloqueo;                        Compensacion de velocidad minima. Sin BEMF se suma a CV2 (1-100);

pour reserved et du genre

Direccion principal de la locomotora (1-127);   Velocidad minima(1-128);Velocidad minima(1-128);   Aceleracion (0-50);   Desaceleracion (0-50);   Velocidad maxima (0-255);   Velocidad media (50-120);   Version del programa ;   Numero de Fabricante asignado por NMRA;

Primary Address (1-127);      Acceleration Rate (0-255);   Braking Rate (0-255);         Manufacturer Version ID;   Manufacturer ID;

Gaugemaster Opti DCC Loco Decoders   Primary Address;   Start voltage;   Accel Base Rate (CV3);   Decel Base Rate (CV4);   Maximum Voltage;   Midpoint Voltage;   Version ID;   Manufacturer ID;


pour summary

mais c'est vide a 99.99 %

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Décoduino : une "centrale DCC" dédiée à la voie de programmation
« Réponse #79 le: octobre 31, 2020, 08:58:16 pm »
Merci pour ces infos.

En fournissant les données de taille des décodeurs et des courants maximaux, JMRI fournit des infos intéressantes.
Les avoir récupéré est une bonne chose.

Mais je suis encore très loin d'avoir un programme équivalent à DecoderPros :
Il y a en effet énormément de particularités des décodeurs qui sont inscrites directement dans le programme.
Rien que chez Zimo, on peut s'arracher les cheveux sur quelques subtilités qui sont dans les onglets que je n'ai pas encore fait.
Mais je crois que plus on va dans les détails, plus on coupe les cheveux en 4 ! Est-ce vraiment utile ?

Je pense que ce qui pourrait être important, ce serait de gérer les sons. Là, c'est (encore) un vrai manque de mon programme.
Et il faut aussi étudier Loksound d'ESU qui me semble être le meilleur programme à ce sujet.
L'avantage de faire soi-même un programme, c'est que je peux mélanger deux programmes en un seul !

A court terme, je voudrais intégrer une micro alim DCC dédiée à UNE loco sur la voie de service.
Pour l'instant, ma voie de service est un cercle, ce qui permet facilement de chronométrer les locos.
Je poursuis mon idée de connaître la vitesse réelle des trains.

Certains parmi nous jugent inutile de connaître cette vitesse précise. Et je vais certainement les surprendre : la vitesse, en temps que telle, je m'en moque !!
Mais alors, pourquoi cette "marotte" ?
Parce que la vitesse, c'est une distance divisée par un temps !

Et le temps, dans un programme, on le gère avec une précision assez grande.
Il s'ensuit que si on connait aussi la vitesse, on peut en déduire une distance avec précision.
Et faire siffler un train avant un passage à niveau sans mettre d'ILS, par exemple.
C'est ce que fait RRTC, d'ailleurs. Comme quoi ça doit être possible.

L'interface va certainement encore évoluer, mais, ce soir, elle aurait cet aspect (c'est une piste, encore à creuser) :



Denis  :P




« Modifié: novembre 01, 2020, 11:07:21 am par DDEFF »
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

msport

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2218
  • HO avec DCC++ en DIY Réseaux très éphémères
    • Voir le profil
Re : Re : Décoduino : une "centrale DCC" dédiée à la voie de programmation
« Réponse #80 le: octobre 31, 2020, 10:31:18 pm »

C'est ce que fait RRTC, d'ailleurs. Comme quoi ça doit être possible.


Bonsoir Denis,
je ne voudrais pas être rabat-joie, mais pour éviter une déception ultérieure, il faut que tu prennes en compte le patinage, qui en sournois déjoue les calculs les plus élaborés.
J'ai testé un va-et-vient en délivrant des ordres DCC de vitesse en accélération constante (donc rien de plus déterministe que cela) puis en décélération, autant dans un sens que dans l'autre.
Il ne faut pas plus de dix allers-retours pour se retrouver avec 5 cm de décalage dans les arrêts (en HO, pas testé en G).
Mais, bon, je ne vais pas pour autant renier ma devise shadok.
Cordialement

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Décoduino : une "centrale DCC" dédiée à la voie de programmation
« Réponse #81 le: novembre 01, 2020, 12:24:57 pm »
Bonjour Michel,

Je suis parfaitement d'accord avec toi. De nombreux pièges nous guettent :

1°) Le patinage :
On peut, en partie, améliorer les choses en ayant des bandages neufs (mais c'est la plaie à changer)
Puis on peut démarrer doucement et arrêter doucement. Plus c'est lent, plus c'est bon (ça ne rime pas :D)
Mais on ne peut pas supprimer le phénomène.

2°) Les joints de rail :
Il ne faut pas sous-estimer cet aspect qui freine quand même aussi.
Là, on peut agir sur la parfaite planéité du réseau. Par exemple, en coupant les rails en biais (je n'ai jamais vu un réseau comme ça) et que les deux coupures ne soient pas exactement en face les unes des autres.
Dans la même catégorie, les pointes de cœur des aiguilles.

J'ai acheté ça (à l'échelle N) :
https://kalmbachhobbystore.com/product/modeling-tool/84081?utm_source=Yesmail&utm_medium=email&utm_email=denis.deffunt@orange.fr&utm_campaign=SA000_HBS_201025_P36098_ClearAcrylicInspectionCars_MRR-MRV-HBS

3°) Les mauvais contacts qui font que le DCC doit renvoyer plusieurs fois le code pour qu'il soit appliqué.

4°) L'encombrement du bus CAN (quand ça arrivera  ;)) et, à minima, le temps de propagation de l'information variable.
Je pense que cet effet peut être négligé, en première approche.

5°) Le nombre de véhicules, les pentes, dont l'effet est (normalement) amoindri par la gestion de la fcem. A vérifier...

Le seul point positif à ces désagréments c'est qu'ils vont tous dans le même sens :
Ils retardent le train quand on accélère, c'est à dire que le train arrive en retard au point déterminé.
Ils avancent le train quand on freine, c'est à dire qu'on arrive plus tôt que prévue au point déterminé.

Donc, on peut globalement amoindrir leurs effets cumulatifs avec un coefficient pour l’accélération et un autre pour la décélération.

Mais il y a quand même des choses sur lesquelles on a la main :

1°) Patiemment, on peut affecter une vitesse réelle à chaque cran de vitesse.

2°) Tenir compte de tous les CV (ce qui est facile avec Decoduino puisqu'on les a en mémoire dans Materiel.tsv  :D)
En particulier le seuil de démarrage dont il faut tenir compte et qu'il faut adapter à chaque loco.
Comme il s'agit d'un CV, on l'a aussi, adapté à chaque loco. De même, on pourrait avoir le coeff ci-dessus spécifique à chaque loco, dans Decoduino.

3°) L'autre point est la linéarité de la courbe. Si on est sur une courbe en seulement 3 points, c'est facile, puisqu'il s'agit de deux droites.
Si c'est sur 28 points, c'est un peu plus dur, mais on a la fonction mathématique, donc un calcul précis est possible aussi.

Le dernier point, le plus important, c'est de "remettre les pendules à l'heure" à chaque changement de zone de détection.

Je suis sûr qu'on peut améliorer les choses et diminuer considérablement le nombre d'ILS, effet Hall, infrarouge...
Ce que j'aimerais bien, c'est éviter d'avoir 3 zones de détection par canton (Deux zones d'arrêt et une zone centrale).

Enfin, quand je dis que RRTC sait le faire, je me réfère à cette vidéo de Renaud Yver et son fameux réseau Luzy :


Bien amicalement
Denis  :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Décoduino : une "centrale DCC" dédiée à la voie de programmation
« Réponse #82 le: novembre 11, 2020, 07:18:33 pm »
Voilà ma nouvelle version de Decoduino. :D

De nombreux changements par rapport à la version précédente.
Tout d'abord, une volonté de tester les trains sur une voie de programmation … bouclée.

En effet, on peut très bien modifier des CV sur un morceau de rail, ou sur une voie de garage qu'on peut isoler électriquement du reste du réseau. C'est un cas fréquent.

Mais certains paramètres (la vitesse, en particulier) nécessitent de faire rouler des trains sur un circuit qui comporte le moins "d'obstacles" possible.
J'entends par "obstacle" tout ce qui peut faire varier la vitesse du train pendant les tests :
Pentes, aiguilles, courbe et contre-courbes, …
Tout cela pour dire qu'un cercle est la meilleure solution. ;)

Pour faire rouler des trains, il faut une alimentation sommaire et je garde évidemment l'Arduino UNO + MotorShield que j'ai utilisé pour tester les modifications de CV.

J'ai malheureusement dû démonter mon "réseau" pour des travaux chez moi  :( et je le remonte samedi. Je pourrais alors faire de vrais tests de vitesse.

En attendant, je me suis attaché à construire une alimentation dans Processing qui soit assez agréable à utiliser, avec un look "vintage".

Je préviens tout de suite : ce n'est pas la reproduction d'un poste de conduite réel, style "Trains Simulator". J'en ferai certainement un, mais pas tout de suite.
J'aime bien ça :


Donc, on trouve :
-> Un voltmètre,
-> Un ampèremètre,
-> 28 boutons de fonctions
 (si quelqu'un a un besoin irrépressible d'un 29 ème bouton, je verrais pour en ajouter un),
-> La demande de crans de vitesse et son affichage
-> La vitesse elle-même (utile pour les tests). Deux notions différentes
-> L'inverseur de sens
-> L'adresse DCC de la loco et son affichage
-> L'étiquette vieillie donnant l'image de la loco en test

De nombreuses choses ne peuvent pas exister sur une vraie loco :
-> Les boutons de fonctions
-> Les tubes Nixie dont la fragilité aurait interdit l'usage dans une loco, bien connue pour vibrer de partout.
Mais j'aime bien cet affichage… 8)

Il me reste à faire l'interface avec l'Arduino.
Côté DCCpp, ce sera facile, tellement cette bibliothèque est bien faite. ;D
Mais je vais aussi devoir récupérer la tension et l'intensité.
Et … sortir le chronomètre !

Pour le développement, toutes les aiguilles bougent de concert avec la manette des crans de vitesse.
Cela n'a aucun sens, bien sûr. Mais ça m'a permis les réglages des paramètres.

Par ailleurs, conformément à ce que j'ai dit plus haut (01/11), j'ai ajouté 3 champs dans la base Matériel.tsv :
-> La vitesse maximale réelle de la vraie loco qu'on reproduit
-> Un coefficient de freinage (pour tenir compte des patinages et autres)
-> Un coefficient d'élan (pour tenir compte d'une avance par rapport aux ordres transmis)

Je les ai aussi ajoutés dans l'onglet "Fiche".
Et c'est là que je vais mettre l'éditeur permettant de modifier ces nombres et d'ajouter une loco.
C'est aussi à faire.

On passe des véhicules au pupitre en cliquant sur l'image du véhicule, tout simplement.
Pour inverser le sens de circulation : clic GAUCHE.

Voilà les fichiers.
Il faut bien faire attention et mettre le fichier Matériel.tsv au bon endroit ;)
https://www.locoduino.org/IMG/zip/decoduino_v0_14.zip
https://www.locoduino.org/IMG/zip/materiel-2.zip

Denis  :P
« Modifié: novembre 11, 2020, 07:26:46 pm par DDEFF »
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Décoduino : une "centrale DCC" dédiée à la voie de programmation
« Réponse #83 le: janvier 03, 2021, 04:12:20 pm »
Bonjour,

Voici (enfin !?) la version 1.0 de mon logiciel Decoduino.
J'ai tenu compte de toutes les remarques qui m'ont été faites :

- Jusque là, j'avais mis de côté la mise à jour des données, pensant qu'Excel suffisait pour les mises à jour.
Non seulement c'était faux, mais, en plus, il fallait un vrai Excel, payant et fort cher.

Un clone comme Libre Office est très limité et permet seulement la lecture d'un fichier en ".tsv", c'est-à-dire "Tabulation Separated Values" (valeurs séparées par des tabulations).
Or, Processing ne connait que ce type de fichiers externes.
Et, donc, ne pas pouvoir sauver un fichier lu par Libre Office sous ce format est, évidemment, un gros handicap…

Et, maintenant que j'ai un éditeur complet pour gérer toutes les infos, je me suis rendu compte qu'on pouvait faire énormément d'erreurs de saisie, erreurs qui amenaient à un plantage du programme.
L'éditeur permet de valider les saisies, de poser des questions en cas d'erreurs et, de ce fait, limiter les plantages. Je dis "limiter", car il doit quand même en rester.
Mais, au moins, une fois identifiées, on peut corriger les erreurs de saisie.
C'est en testant ce programme qu'on peut y arriver. Et c'est là que vous intervenez.

- Pour rester dans les remarques de Jean-François (merci jfs59), j'ai mis un "?" quand on n'a pas mis de photos.
C'est moche et ça incite à en mettre une belle image.
D'autant qu'on a le modèle en main et qu'il suffit de le prendre en photo…

J'ai simplement pris une feuille de papier blanc, posé mes modèles dessus, "avant à gauche" (c'est important) et on prend une vue latérale.
Nota : une vue latérale est très rare sur internet et, quand elle existe, minuscule.
La photo passe dans un logiciel type "Paint" (gratuit) et on la tronque  avec un rectangle qui doit affleurer le haut, le bas, la gauche et la droite.
Il faut ensuite redimensionner en 200 pixels de haut (c'est impératif)
On retire le blanc autour et c'est fini.

Je ne sais pas sous quelle forme on pourrait les regrouper sur Locoduino, mais ce serait une bonne idée.

- Les fichiers on notablement évolué pour tenir compte de toutes les données dont on a besoin.

Voici les répertoires :



Les images de tous les véhicules sont regroupées dans un répertoire "Vehicules" (sans accent)
L'autre sous-répertoire est "TSV" et il contient les 5 fichiers externes

Le répertoire "Decoduino" contient le programme en cours, aujourd'hui "Decoduino_V1_0.pde"
A chaque nouvelle version, ce programme changera, bien sûr.

Nota important :
Aujourd'hui, je vais vous fournir les 5 fichiers du répertoire "TSV"
Mais ces fichiers sont les vôtres, ce sont vos véhicules, vos décodeurs, vos trains…
Cela n'aurait aucun sens que je vous fournisse les miens par la suite.

Par contre, la Base_decodeurs.tsv n'est pas modifiable par le programme. C'est voulu.
Elle a été initialisée grâce à JMRI et toutes les modifications qui doivent être faites doivent pouvoir servir à tous.
Donc, je vous propose de les mettre sur le forum et on refera une nouvelle base à jour, après validation.

Les fichiers :

Vehicules.tsv :



Le champ "ID" ne doit pas avoir de doublons.
Le champ "ID_CV" correspond au numéro d'enregistrement dans le fichier "Infos_CV.tsv".
Le champ "nom" est libre.
Le champ "image" doit correspondre EXACTEMENT à un nom de fichier image dans le répertoire "Véhicules".
Le champ "marque" est libre.
Le champ "ref" est libre. Ces deux champs correspondent au véhicule, pas au décodeur.
Le champ "htamp" est la longueur (en mm) hors-tampons du véhicule mesurée sur le modèle que vous avez en mains.
Le champ "couleur" correspond à la couleur de fond du véhicule dans la composition des trains.
Comme ce fichier est dans le répertoire "Communs", il sert évidemment aussi à définir la couleur du véhicule du train virtuel dans le gestionnaire de trains.
Le champ "échelle" correspond à l'échelle
Le champ "moteur" contient "1" quand c'est un véhicule moteur.
Quand un véhicule est moteur, sa couleur de fond est toujours #808080.
L'inverse n'est pas vrai.
C'est un booleen dans le programme, mais les fichiers ".tsv" n'acceptent que les entiers et les chaînes de caractères.
Le champ "date" donne la date et l'heure de la dernière modification de l'enregistrement.
Le champ "CV106" correspond au numéro de propriétaire.

Le véhicule 0 est très particulier : on ne peut pas le retirer.
Il a ID = 0,
Il a ID_CV = 0, c'est-à-dire qu'il a le décodeur 0 qui correspond au fait qu'il n'a pas de décodeur.
C'est aussi le cas des wagons et des voitures.
Il a CV106 = 0, c'est-à-dire le propriétaire 0
On pourrait, par contre, changer son nom et son image.

Infos_CV.tsv :



Le champ "ID_CV" correspond au numéro d'enregistrement dans le fichier "Vehicules.tsv".
Les champs "famille", "famille" et "modele" sont sélectionnés dans la "Base_decodeurs".
"fabricant", "famille" et "modele" correspondent aux appellations JMRI du décodeur.
Le champ "v_reelle" est la vitesse maximale du véhicule réél.
Le champ "frein" est un coefficient entre 0 et 1, multiplié par 10 000.
C'est pour tenir compte des frottements, patinages, … pour aller au plus près de l'affichage d'une vitesse réelle à l'échelle.
Le champ "elan" est un coefficient entre 0 et 1, multiplié par 10 000.
C'est pour tenir compte des glissements, … pour aller au plus près de la vitesse à l'échelle.
Pour l'instant, ces deux coefficients sont à "1", le temps d'affiner l'efficacité lors des essais.
Les champs "P0" à "P4" sont 5 paramètres permettant de modeler les courbes de vitesses en 28 points.
Les champs "CV1" à "CV200" correspondent aux 200 premiers CV. La plupart ne sont pas d'un usage courant, sauf si on peaufine les sons et les éclairages (ex : "light dimmer" du décodeur de Laurent)

Auparavant, j'avais tout dans le même fichier "Materiels.tsv", mais ça prenait inutilement beaucoup de place.
Le fichier "Infos_CV.tsv" n'a que deux enregistrements :
- L'enregistrement "0" pour le véhicule "0" et tous les wagons et voitures.
- L'enregistrement "1" pour le seul véhicule que j'aie avec un décodeur.

Proprietaires.tsv :



Le champ "CV106" ne doit pas avoir de doublons. C'est le numéro du propriétaire.
Le champ "prop" est le nom du propriétaire. C'est un champ libre.
"F1" à "F28" correspond aux 28 fonctions possibles de la norme NMRA.
On y met le nom de la fonction.

On n'a pas de choix dans la norme NMRA pour "F0", ce qui fait qu'elle n'apparait pas ici.
J'ai prévu qu'on ait les mêmes noms de fonctions pour un propriétaire donné.
Après, c'est dans le programme qu'on affectera, véhicule par véhicule, la bonne fonction au bon bouton.
Par contre, chaque propriétaire peut avoir ses propres affectations de fonction. C'est souple.
J'ai prévu de mettre le numéro de propriétaire dans le CV106, ce qui donne 255 propriétaires possibles. C'est déjà un beau club…

Compositions.tsv



J'avais besoin des compositions de trains pour mon gestionnaire. D'où sa présence ici.
Un enregistrement par composition, avec un champ "nom" et l'ID des véhicules.
Un maxi de 20 véhicules, ce qui fait déjà un beau train…

Maintenant que j'ai présenté tous les fichiers, je suis toujours aussi curieux et j'aimerai bien voir le ou les fichiers de Marcel (CATPLUS) est ses 600 wagons (!!). Il y certainement d'autres nouvelles infos à ajouter à mon programme.

A suivre dans le post suivant
Denis :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Décoduino : une "centrale DCC" dédiée à la voie de programmation
« Réponse #84 le: janvier 03, 2021, 04:13:46 pm »
Passons au programme lui-même :

Je suis parti des idées de DecoderPro, qui reste LA référence.
Mais, par moments, je le trouve un peu trop "Pro", c'est-à-dire qu'un certain nombre de choses paraissent évidentes dans ce programme et un débutant est parfois perdu.
J'ai donc voulu bien décortiquer les choses, mettre des commentaires, des aides, des demandes de confirmation pour que même une personne qui démarre trouve ses marques.

L'autre référence, c'est LokProgrammer, d'ESU.
Certes, le programme est gratuit, mais il impose de se connecter à une interface réseau payante qui coûte quand même la bagatelle de 149,90 €…

Voyons le fonctionnement de Decoduino :

Au début, on charge les fichiers et on vérifie qu'aucun fichier ".tsv" n'est ouvert dans une autre application, ce qui planterait le programme lors des sauvegardes.
Puis on cherche un Arduino et son Motorshield. Merci à Pierre (Pierre59)

L'innovation de ce programme est qu'on a maintenant un mode "démo", c'est-à-dire qu'on peut le tester sans Arduino.
Mais, évidemment, on ne peut plus alors ni lire ni écrire les CV de la loco.
Ceci dit, on a alors une bonne idée de ce qu'on peut faire avec ce programme. Et pour le développement, ça aide.
Il y a un mode "edit" aussi dans DecoderPro, mais pas dans LokProgrammer.

On a donc, au départ, les informations suivantes :




Puis soit l'un ou l'autre des deux pop-up :




   

Puis on arrive sur la page "Vehicule"



En haut, la case du véhicule. C'est là qu'on apprécie d'avoir fait une belle photo.
En haut à droite, on voit qu'on est sur le véhicule 1/21, puisqu'il y a 21 véhicules.

Puis on a un curseur horizontal et deux boutons à chaque extrémité pour sélectionner le véhicule.
Le nombre de véhicules gérable est lié à la longueur du curseur (1 124 points)

Dans la case "infos sur le véhicule", on a un résumé des principales infos :
Le nom, la marque, la référence, l'identifiant ID, le nom du propriétaire et la longueur hors tampon.

Puis une ligne de boutons pour filtrer les véhicules par échelle, moteur ou remorqué, DCC ou non, marque ou propriétaire.
Évidemment, le compteur dans la case de la photo se met à jour en fonction des ajouts de filtres et le curseur d'affichage aussi.

La deuxième ligne de boutons pour ajouter, mettre à jour ou retirer un véhicule.

Dans la case "Infos sur le décodeur", on a le fabricant, la famille et le modèle.
Puis l'adresse DCC, le nombre de crans de vitesse et la gestion des vitesses (3 ou 28 points)
Puis les boutons pour ajouter, mettre à jour ou retirer le décodeur.

Pour l'instant, le bas de l'écran est réservé à la composition des trains.
Chaque case contient un véhicule et son nom en dessous.
Pour ajouter un véhicule dans la composition, on clique sur le "+", ce qui insère le véhicule dans la composition. Cliquer sur le "-" le retire.
C'est là qu'on comprend pourquoi il faut des véhicules en vue latérale, orientés vers la gauche.
Il y a, pour l'instant, l'affichage de la composition 1 sur 2 en tout, comme l'indique le compteur.
Au dessus, un curseur et deux boutons pour sélectionner la bonne composition.
Puis, en bas à droite, les boutons pour ajouter, retirer et valider une composition.

Nota, on ne peut pas insérer le véhicule 0.

Copie de CV :
Il restait deux boutons dans la case "infos sur le décodeur" : copier et colle les CV



1°) on appuis sur "Copier CV" et la composition des trains disparait de l'affichage, remplacée par la case du véhicule qui contient le décodeur dont les CV sont à copier.
On choisit le véhicule avec le curseur véhicule et les boutons.
Quand il est choisi, on passe à la copie, ce qui ouvre une deuxième case dans la quelle on choisit le véhicule récepteur.

Puis on termine par l'un des deux boutons : "Réaliser la copie effective" ou "Sortir de la copie sans rien faire".

Passons à la "Mise à jour". On atteint l'onglet "Fiche"



Dans les 9 cases du haut, les infos issues de la Base_decodeurs.tsv.
Comme il s'agit d'infos communes, elles ne sont pas directement modifiables mais sont déjà remplies pour 2 895 décodeurs (!)

Suivent les infos du véhicule (rectangle des 8 cases à gauche), puis les 3 cases correspondant au test des locos.

Non modifiable, mais déjà remplies aussi, les CV7 et CV8, en lecture seule, en bas à droite.
Pour être précis, c'est dans le décodeur que ces valeurs sont inscrites et sont non modifiables.
Il faudra aller dans le "tableau des CV" pour mettre à jour le fichier (voir l'onglet correspondant).

Reste la gestion des propriétaires :
- Deux cases correspondant au véhicule affiché.
On choisit le numéro OU le nom du propriétaire dans une liste.
- 5 boutons correspondant à la gestion de TOUS les propriétaires.
Pour l'instant, l'affichage est limité à 43 propriétaires (à cause de la hauteur de l'écran), mais je vais l'augmenter si vous le voulez.
On pourrait aller jusqu'à 255 propriétaires possibles (à cause du CV106)



Un bouton "Validez les choix pour cet onglet" pour sauvegarder les infos dans les fichiers "Vehicules.tsv", "Infos_CV.tsv" et "Proprietaires.tsv".

Mais, c'est le plus important, les CV sont mis à jour dans le décodeur de la loco.
Il apparait alors un pop-up au centre de l'écran qui égrène tous les CV mis à jour.
Le rythme est volontairement lent, pour que tout se passe correctement.

Un bouton pour "Ne rien changer pour cet onglet" permet de récupérer TOUTES les infos qu'il y avait avant qu'on atteigne cet onglet.

Tout ceci sera vrai de tous les onglets (sauf Tableau CV pour les boutons).

Reste deux boutons :

"Retour des CV aux valeurs d'usine" qui permet de retrouver un décodeur qui marche s'il était seulement mal programmé, ce qui ne devrait plus arriver avec ce programme. C'est un "reset light".

"Master reset" qui, là, génère une suite d'actions aptes à récupérer un décodeur complètement bloqué. Cela ne marche pour l'instant que pour le seul décodeur que j'aie : le Zimo MX617.
Mais c'est très efficace.

Onglet configuration :


 
Là, on a toutes les informations, tous les détails pour mettre à jour le CV29.
Nota : j'ai lu plusieurs fois que pour le bit 2, il est recommandé d'interdire le changement de source pour ne pas "planter" au premier faux contact, interprété comme un changement de source.

Onglet adresse :



Il suffit d'indiquer au clavier la nouvelle adresse et tout se met à jour. CV1, CV17, CV18 et CV29.

Onglet moteur :



Pour gérer simplement les CV3 et CV4. Toutes les infos nécessaires sont affichées.
Nota : Dans la norme NMRA, comme on peut régler les CV3 et CV4 jusqu'à 255.
Cela qui correspond à … 3' 48" secondes (!) pour passer de la vitesse 0 à la vitesse maxi, et réciproquement pour la décélération.
J'ai donc limité ce CV à 67 au lieu de 255, ce qui correspond à 1' pour aller de 0 au maximum, ce qui me parait déjà pas mal.

On note qu'il reste de la place dans cet onglet : ce sera pour le CV9 (gestion de la fcem), particulièrement utile pour avoir des ralentis sans saccades.

Onglet Contrôle basique des vitesses :



La gestion des CV2, CV6 et CV5.
Bien sûr, le CV29 se met à jour aussi pour la gestion à 3 points.

Onglet tableau de vitesses :



Voilà le cas d'une loco vapeur. La courbe se dessine en modifiant simplement les 5 curseurs à droite.
La courbe "logistique" est celle qui s'approche le plus de la vraie courbe d'un moteur thermique.



Là, c'est une courbe "logarithmique" qui correspond plutôt aux moteurs électriques. Et donc aux locos diesels aussi.
On n'a besoin que de 3 curseurs pour la modifier.

Si on appuie sur "Boutons libres", on peut faire absolument ce qu'on veut avec les 28 curseurs à gauche.
Bien sûr, le CV29 se met à jour aussi pour la gestion à 28 points.

Onglet Fonctions/Propriétaires :



C'est là qu'on met à jour le fichier des fonctions propriétaires.
On retrouve le sifflet pour "F1" pour le propriétaire 1 (en bas à droite) qu'on avait vu dans le fichier.

Onglet Carte de fonctions NMRA :



C'est là que vous pouvez vraiment adapter vos fonctions à vos boutons.
Notez que, comme il s'agit du propriétaire "1", on a bien "Sifflet" pour "F1.
C'est là que ça sert. Et on met à jour les CV33 à CV46.

J'ai noté les 5 premières couleurs de fils les plus standard pour les décodeurs.
Mais, après, les couleurs dépendent des fabricants.

Onglets Tableau des CV :



On a à l'affichage les 120 premiers CV.
Je pourrai afficher une autre page si nécessaire. Il suffirait d'ajouter un bouton. A voir.

Il est prévu des boutons permettant une mise à jour des CV par rapport aux infos dans les fichiers et réciproquement.
En particulier, il faut utiliser le bouton "Transfert  Fichier" pour mettre à jour les CV7 et CV8 dans le fichier "Infos_CV.tsv" (voir Onglet "Fiche")

Le fonctionnement est un peu particulier pour cet onglet :

Au départ, on a à l'affichage le contenu des 120 premiers CV dans le fichier "Infos_CV.tsv".
Comme les cases sont petites, j'ai, en plus, un "cadre volant" qui suit la souris pour être sûr d'être sur la bonne case.
Si on clique sur une case, on va afficher le contenu du CV correspondant dans le décodeur.
On voit au passage, comme d'habitude, le pop-up de question-réponse du décodeur.
Si les deux informations sont identiques, elles sont maintenant sur fond vert, sinon, elles restent en bleu.
On peut alors choisir l'info à modifier : soit celle du fichier, soit celle du décodeur, en prenant l'autre info comme référence.

Mais, bien sûr, on ne peut pas modifier ICI un CV directement.
Ce serait trop dangereux puisque beaucoup de CV sont liés.
On ne modifie les CV QUE dans les autres onglets.

Pupitre :

C'est un bonus par rapport aux autres programmes, un "Easter Egg".
 


Pour accéder au pupitre, il suffit de cliquer sur la case photo dans la page véhicule.
Évidemment, ça ne marche que si ce véhicule a un décodeur.
Ce pupitre va me servir à tester les vitesses réelles à l'échelle de la loco que j'ai.
Et ainsi définir ses coefficients "frein" et "élan".

Comme, pour l'instant, je ne peux agir que sur le cran de vitesse (la grosse manette), j'ai voulu tester les aiguilles de tous les cadrans qui bougent ainsi de concert, ce qui n'a absolument aucun sens.
Mais ça m'a permis de définir les paramètres de 0 à maxi pour chaque cadran.

Pour l'instant aussi, appuyer sur un bouton fonction ne fait qu'allumer la lampe au dessus.

Il reste donc encore du travail sur cette page !

Pour revenir à la page véhicule, on clique sur la petite photo en haut.

Branchements :

Voilà mon branchement :


 
Au lancement du programme, je suis sur "VDS" (Voie De Service) et je programme mes CV.
Puis je bascule sur "POM" (Programmation On Main), c'est-à-dire le réseau, et j'utilise le pupitre.

J'ai une question concernant DCCpp (que je connais finalement assez mal) :

Dans ce sens là (VDS -> POM), tout va bien.
Je passe de commandes du type <W … > avec une réponse <r … > à une commande de type <t…>

Mais quand je reviens sur "VDS", quand j'envoie <W …>, j'ai une réponse <T …>

Il doit falloir envoyer une commande en même temps que je bascule le double inverseur. Laquelle ?

Enfin, comme je n'ai pas tous les composants pour LaBox, je n'ai pas testé.

Les fichiers Zip :
https://www.locoduino.org/IMG/zip/decoduino_v1_0.zip
https://www.locoduino.org/IMG/zip/vehicules.zip
Le fichier TSV.zip est en PJ.

Voilà, c'est tout pour aujourd'hui.

Denis  :P
« Modifié: janvier 03, 2021, 05:19:39 pm par DDEFF »
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Jean-Paul

  • Newbie
  • *
  • Messages: 28
  • Z
    • Voir le profil
Re : Décoduino : une "centrale DCC" dédiée à la voie de programmation
« Réponse #85 le: janvier 10, 2021, 09:57:28 pm »
Bonjour,

J'utilise pour la programmation une BaseStation dédicacée (UNO + motorshield standard) avec la sortie de programmation reliée à une petite (je suis en Z) boucle (un simple ovale) de programmation permettant de programmer et de faire rouler la locomotive (surtout pour tester les résultats vitesse - accélération). La sortie de la voie principale du motor shield n'est pas utilsée ici.
Au lieu du branchement POM/VDS par commutateur, j'ai le même résultat par programmation en modifiant DCCpp pour rediriger les commandes t et f vers les 2 premiers registres de la voie de programmation.
J'utilise habituellemment  DecoderPro sans problème dans cette configuration

Pour ce qui du problème:
Dans ce sens là (VDS -> POM), tout va bien.
Je passe de commandes du type <W … > avec une réponse <r … > à une commande de type <t…>
Mais quand je reviens sur "VDS", quand j'envoie <W …>, j'ai une réponse <T …>
Il doit falloir envoyer une commande en même temps que je bascule le double inverseur. Laquelle ?


cela ne produit pas chez moi. Je passe de R ou W , puis t ou f, puis de nouveau R ou W de manière correcte, aussi bien directement en introduisant les commandes dans le Serial Monitor que via DecoderPro.

L'installation de la version en Processing est une des prochaines activités pour lesquelles j'espère trouver un peu plus de temps ... Je ne manquerai pas d'en informar ici.

Amicalement
Jean-Paul.

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Décoduino : une "centrale DCC" dédiée à la voie de programmation
« Réponse #86 le: janvier 11, 2021, 09:38:05 am »
Bonjour Jean-Paul,

Merci d'avoir lu ce (long) post !
C'est agréable d'avoir des lecteurs  ;D

Tu as résolu mon "problème" d'une manière surprenante : modifier DCCpp.
J'aimerais bien avoir l'avis de Thierry là dessus.

C'est, indirectement, la question que je posais : pouvoir se passer d'un commutateur physique dont je suis bien convaincu que c'est du "bricolage".
Il devrait exister une commande DCCpp qui permette de faire la modif que tu proposes.
Bien qu'en N, je suis exactement dans ton cas : une voie de programmation bouclée qui me permettra des essais de vitesse, et d'un d'arrêt à un point précis sans ILS.

Quant à Processing, c'est très simple : j'ai même fait un article dessus :
https://www.locoduino.org/spip.php?article219&var_mode=calcul
En fait, pour faire marcher Decoduino, seul le début de l'article sert : installer Processing. Le reste n'est utile que si on développe en Processing.

Comme tu connais déjà DecoderPro, ton avis sur Decoduino m'intéressera beaucoup, sachant que je n'en suis qu'au début.

Bien amicalement
Denis :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)