Messages

571

Le logiciel DCC++ / Re : DCC++ sur Nano avec LMD18200

« le: septembre 24, 2016, 07:49:19 pm »

Salut Dominique,

Dans la série "Denis barré", je me pose quelques questions :

1°) Tu as trouvé une idée géniale pour lire le CV1 (et d'autres pour les adresses longues). OK. Bravo ! 

Par ailleurs, ne serait-ce que pour la détection d'occupation, le réseau est découpé en cantons.
Cantons sur lequel un train seul fonctionne (sauf cas particuliers). C'est même un peu le but : un seul train par canton.

J'en déduis qu'à chaque fois qu'un train s'arrête (en gare, par exemple), tu peux faire ta mesure sur ce canton là, qui ne contient qu'une seule loco.
Et, donc, savoir quel train est sur ce canton.

La mesure que tu fais sur un seul train pour ta navette (quasi isolée du réseau) peut donc être étendue à d'autres cantons et plusieurs fois, pour re-caler le gestionnaire de réseau qui, normalement, sait quel train est sur quel canton.

2°) Si je lis bien ton post du 31/08 :

Pour ce faire, j’ai ajouté un enregistrement des valeurs de mesure de courant dans toutes les phases de ReadCV_Main (PacketRegister.cpp) et un affichage à la fin de la fonction. Comme cela, ça ne perturbe pas trop les timings.

Je rappelle que la fonction ReadCV envoie 8 fois une commande de lecture pour lire les 8 bits du CV, puis une 9ème commande pour obtenir un bit de vérification.
Aussitôt après chaque commande, le sketch se met en lecture du courant dans une boucle de 500 lectures (ACK_SAMPLE_COUNT qui doit correspondre grosso modo à au moins 6 millisecondes, je n'ai pas mesuré), au cours de laquelle il recherche une valeur qui dépasse le seuil égal au courant de base + 30 (ACK_SAMPLE_THRESHOLD). Si ce seuil est dépassé c’est un bit 1 sinon 0.

Evidemment, il faut UNE SEULE LOCO sur la voie principale et il ne faut pas que la loco roule pour faire cette mesure, moteur arrêté, car c'est en activant le moteur 9 fois pendant 6 ms que le décodeur va "passer son message".

Ces valeurs sont déduites de la norme NMRA http://www.nmra.org/sites/default/files/s-9.2.3_2012_07.pdf

Où il est écrit : Basic acknowledgment is defined by the Digital Decoder providing an increased load (positive-delta) on the programming track of at least 60 mA for 6 ms +/-1 ms. It is permissible to provide this increased load by applying power to the motor or other similar device controlled by the Digital Decoder.

La valeur du seuil (30 dans le soft) peut ou non correspondre à ces 60mA de delta consommation, c’est un truc à étalonner si ça ne marche pas du premier coup. De plus il est évident que c'est différent en N et en HO !?!

Ton système est basé sur une mesure relative d'une tension en environnement fortement bruité.
Et donc fonctionne d'autant mieux que la tension est faible (et donc au mieux à l'arrêt).

Mais comme tu as une alimentation unique pour le réseau, on peut se permettre de la compliquer un peu.
J'ai des souvenirs (théoriques, malheureusement) "d'extraction d'un signal noyé dans du bruit". Cela doit être possible de nettoyer ton signal et améliorer la précision de la mesure, via l'électronique ? 

3°) Encore plus fou : on coupe le courant d'une loco en coupant l'alimentation de ce canton.
On mesure (54 ms) et on remet le courant 

Amicalement

572

Le logiciel DCC++ / Re : DCC++ sur Nano avec LMD18200

« le: septembre 23, 2016, 08:00:59 pm »

Ah que moi aussi 

Je vais quand même un peu décortiquer ce que tu m'as envoyé.
Ce n'est pas parce que tu la fais marcher directement qu'on ne peux pas regarder aussi pour le faire marcher via Processing.

573

Le logiciel DCC++ / Re : DCC++ sur Nano avec LMD18200

« le: septembre 23, 2016, 08:35:51 am »

cette ligne 314 c'est la seule référence à serialEvent :
if (myPort.available() > 0) {
    serialEvent(myPort);
}

dans le répertoire du sketch, il y a un autre sketch : SerialEvents (S et avec un s). Qui est bien lié puisque le premier sketch se plaint quand on renomme le deuxième.

C'est ce que je pensais. Tel quel, seul, ce programme ne fonctionne pas.
Tant qu'il y a un messager d'erreur souligné en rouge, Processing refuse de démarrer.
Or, tu l'as fait marcher : donc, il manquait quelque chose.

Peux-tu envoyer la directory complète (en .zip) STP ?

Concernant les manettes, je suis pour une sorte de GPS pour train que j'ai déjà bien dégrossi. 
http://forum.locoduino.org/index.php?topic=156.0

574

Présentez vous ! / Re : nouveau sans l’être...

« le: septembre 22, 2016, 06:26:57 pm »

Tout arrive ! 

Bienvenue parmi nous.

575

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Denis

« le: septembre 22, 2016, 09:29:48 am »

Merci de l'intérêt porté à mon fil 

Je réponds dans l'ordre :

1°) La programmation objet complète est le Graal de la programmation en C++.
Aussi, je ne préconise absolument pas de créer une matrice pour gérer le réseau.

Je devrait plutôt dire "plus" car c'est ce que je faisais dans SGDD 1 et 2 
Mais je débutais en C++ et je n'avais pas saisi toute la subtilité et la puissance de la programmation objet.

Mais pourquoi suis-je content, alors, d'avoir réussi à créer une matrice ?
Parce que c'est une matrice particulière qui doit me permettre, normalement, d'utiliser n'importe que programme sans avoir à y re-décrire le réseau.
Et, tant qu'à faire, utiliser les programmes des autres qui, eux, maîtrisent parfaitement la programmation objet (Jean-Luc, Pierre59, Thierry, ...) moyennant une adaptation.

Pour l'instant, j'avance à petits pas, mais j'ai la certitude que la solution est possible.
Je teste actuellement sur le réseau que j'ai déjà pris comme modèle dans mes articles SGDD.
Et il traîne encore des bugs que j'élimine un à un.

2°) Quel réseau !  

Deux-trois trucs me font "tilter" néanmoins :

- "Pas d'itinéraire automatique" ?: avec un tel réseau, ça va être coton à gérer !

- "24V continu" : ça me rappelle Pierre Chenevez 

- "Un Arduino DUE par canton" : ça me paraît disproportionné. Je suis sûr qu'on peut faire plus simple.
Via un bus CAN, on en est à un NANO pour gérer 8 aiguilles.

Et un seul DUE pour tout le réseau.
Pour 80 cantons et 50 aiguilles, il en faudra peut être deux (une éventuelle question de temps de traitement), mais ça n'est même pas sûr.

Mais le projet nous intéresse, c'est évident 
Essaie de le détailler dans un fil que tu créerais.

A bientôt.

576

Le logiciel DCC++ / Re : DCC++ sur Nano avec LMD18200

« le: septembre 21, 2016, 05:52:02 pm »

Je vois des message d'erreur dans le .pde, en particulier ligne 314 (serialEvent) ??

577

Le logiciel DCC++ / Re : DCC++ sur Nano avec LMD18200

« le: septembre 21, 2016, 05:09:41 pm »

Je constate qu'il y a bien communication entre l'Arduino et Processing.

Sinon, Processing n'inventerait pas ce qu'il écrit, qui vient bien de l'Arduino :

Serial.list()[0] = COM1
Serial.list()[1] = COM7

Processing l'écrit sur la première ligne :
COM1 COM7

On peut donc considérer qu'il y a bien échange entre l'Arduino et Processing.
Donc, là n'était pas le problème.

Donc, c'est dans le programme Processing qu'il ne va pas plus loin que cet affichage.

Tu peux m'envoyer ton programme Processing STP ?

578

Le logiciel DCC++ / Re : DCC++ sur Nano avec LMD18200

« le: septembre 21, 2016, 04:33:39 pm »

Voilà ton problème : tu veux un port COM précis et, par défaut, Processing ne connait que le port Serial.list()[0];

Ce que tu veux est compliqué en Processing : choisir un port dans une liste.

Processing édite une liste (Serial.list()[n]) avec n = nombre de ports détectés, c'est automatique.

La seule façon que j'aie trouvé, c'est de trier cette liste pour que le port que tu veux soit en Serial.list()[0]; (mais c'est compliqué)
Mais pas de dire "je prends le deuxième"...
Je suis quasi certain qu'on ne peut pas directement.

Peux-tu retirer ce que tu as en COM1, et ainsi ne garder que le port Arduino ?

579

Le logiciel DCC++ / Re : DCC++ sur Nano avec LMD18200

« le: septembre 21, 2016, 03:57:44 pm »

Je serais pour String portName = Serial.list()[0];
Le premier port est le "0"

580

Le logiciel DCC++ / Re : DCC++ sur Nano avec LMD18200

« le: septembre 21, 2016, 10:40:38 am »

Pour info, vu que de nombreux posts traitent de Processing et qu'il est même utilisé dans l'appli populaire de Dominique, je vous signale que je vais faire un article sur les bases de Processing (comment on l'installe, ce qu'il sait faire et ce qu'il ne sait pas faire, la gestion du port Série, ...)

Mais je suis d'accord avec Dominique : les erreurs peuvent être instructives.
Je n'ai pas honte de dire que j'avais un moniteur Arduino à 9600 et un sketch à 115200. Et je me suis demandé longtemps pourquoi ça n'affichait rien...

Attention à ce que tu écris : tu es obligé de lancer l'IDE Arduino (ne serait-ce que pour téléverser le sketch).

Ce qu'il ne faut pas lancer, c'est le moniteur Arduino.

581

Le logiciel DCC++ / Re : DCC++ sur Nano avec LMD18200

« le: septembre 21, 2016, 09:16:07 am »

Bonjour Michel,

A ma connaissance, on ne peut pas modifier "en dur" le port utilisé par Processing. En tout cas, pas directement.
J'utilise un bout de programme dans Processing qui permet de choisir le port, mais je pense que dans ton cas, il n'est pas nécessaire.

Je note dans ce que tu dis que tu as forcé le COM1 dans Processing et dans ton extrait de message d'erreur que java cherche le COM7. C'est sûr que ça ne va pas marcher.

Je vais expliquer en détail, quitte à enfoncer des portes ouvertes. Des fois, on bloque sur des choses évidentes...

Ce que je propose :

D'abord une petite vérification : tu débranches le câble USB de l'Arduino et tu le rebranches. Puis tu téléverses le sketch Arduino. Ne lance pas Processing.

Tu choisis ton modèle d'Arduino dans Arduino outil/type de carte et tu regardes quel port série il t'a attribué dans outil/port.

Si tu as deux Arduino de branchés (c'est mon cas), tu verras que suivant l'ordre dans lequel tu les branches, le choix des ports est croisé.
Tu peux éventuellement choisir toi même ton port via l'interface IDE, mais uniquement parmi ceux que l'USB t'a réservé.
Moi, j'ai souvent le choix entre COM6 et COM7 pour mes deux Arduinos.

Tu lances le sketch Arduino et tu ouvres le moniteur série.
C'est bête à dire, mais il faut que la vitesse du port (en bas à droite) soit la même que celle du sketch (115200 dans ton cas) 

Passons à ton problème.

Bien que ça ne serve certainement à rien, je débranche le câble USB pour être sûr qu'on a bien tout initialisé.
J'ouvre Arduino, je téléverse et SURTOUT je n'ouvre pas le moniteur série !! 
Sinon, le port est occupé et Processing ne pourra pas marcher.

Puis j'ouvre Processing et je lance.
Processing dresse une liste des ports et prend le premier port série par défaut.
Si tu n'as pas 50 ports utilisés en même temps, ça marche du premier coup.

Dis-moi si ça marche, maintenant

Denis (= DDEFF, avec seulement deux D  )

582

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Denis

« le: septembre 20, 2016, 06:08:39 pm »

ça y est, j'ai ma matrice ! 
Il reste encore des bugs, mais ça marche.

A peaufiner, donc 

583

Présentez vous ! / Re : Nouveau dans ARDUINO

« le: septembre 17, 2016, 01:33:56 pm »

Tu as choisi la bonne adresse 

avec une rétro-signalisation de ma composition

Qu'entends-tu par la ?

Quant à Processing, tu as travaillé sur quoi ? Ce n'est pas directement de l'Arduino, mais c'est une bonne interface.

584

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Denis

« le: septembre 17, 2016, 09:29:08 am »

Grande avancée hier : j'ai trouvé pourquoi, par moments, je perdais des cubes.
Et j'ai corrigé. Mais ça faisait "un certain temps" que je me cassais les dents sur ce problème, tant ça paraissait aléatoire... 

J'arrive maintenant à suivre les points particuliers des cubes et je réorganise les cubes de cantons. Très bientôt, les aiguilles.
Plus tard, la fameuse matrice qui permettra d'expliquer l'organisation du réseau aux autres programmes.

Je gère maintenant correctement le choix des fichiers, ainsi qu'une fonction "undo" bien pratique. Et à plusieurs niveaux !

A suivre  :

585

Le logiciel DCC++ / Re : DCC++ sur Nano avec LMD18200

« le: septembre 17, 2016, 09:16:39 am »

Merci Dominique, mais je n'ai fait qu'être curieux. C'est toi qui a fait le travail.
On se reverra, ne t'inquiète pas. 

Dans les fonctions inédites, le fait que ta centrale détecte les CV d'adresses loco. Et ça, ça n'est pas dans le DCC++ (mais on pouvait le trouver : la preuve !)
Je suis certain que sur cette lancée, on peut détecter d'autres choses, via d'autres CV.

Ce que tu proposes n'est pas tout à fait une centrale, mais une centrale particulièrement adaptée à la gestion d'une navette (d'où les détections des 5 zones et les LED correspondantes).

Pour une centrale commandant un réseau, évidemment, ce n'est pas le NANO qui fera les détections (je dis ça pour ceux qui commenceraient le forum là).

Par contre, dans le cas d'une gestion centralisée gérée par ta centrale, il faudrait y ajouter une entrée externe : CS (Consigne de Sécurité).

On en avait déjà parlé : cette consigne sera donnée par le gestionnaire (le DUE) et correspondra à la vitesse maxi autorisée pour ce train.

Il s'agit d'une consigne, c'est à dire qu'elle va dépendre des positions des trains, qui agit sur la couleur des signaux, qui donne donc la consigne de la vitesse maxi autorisée.
Consigne et, donc, variable.

Vivement l'article !
PS : A5, c'est SCL.