Dcc++

[msport]

Je (re)découvre que FTDI met à disposition des drivers windows et autres pour ses chips.
http://www.ftdichip.com/Drivers/VCP.htm
Ce que fait également le fabricant des CH340G mais le site est pur mandarin.
http://www.wch.cn/download/CH341SER_EXE.html
Manifestement si l'application qui utilise un port COM physique n'intègre pas l'installation du driver USB puis son initialisation comme l'IDE Arduino, il faut le faire manuellement.
D'où le problème rencontré en son temps avec l'apparition des clones à CH340G, problème qui n'existe plus pour l'IDE depuis que celui-ci intègre le dit driver.
Donc quelques tests en perspective quand il y aura un petit moment de libre ...

[msport]

Après installation du driver CH341SER_EXE sur un portable de juillet 2001 sous XP, j'ai testé positivement CDM-Rail avec le Z22 sur un Arduino à CH340. La connexion s'établit correctement après exploration des ports précédents.
De même sur un portable avec W7 x64.
Par contre, je constate que ce driver était déjà installé sur mon fixe avec W10 x64 qui m'a donné des problèmes. Je soupçonne que les différents périphériques en USB (webcam, scanner, imprimante, souris, clavier) et les programmes qui les surveillent en tache de fond ne font pas obligatoirement bon ménage avec le scan des ports.
A voir avec vos retours d'expérience.

[jpp38]

Bonjour,

Intéressant. Merci pour l'info.

Je soupçonne que les différents périphériques en USB (webcam, scanner, imprimante, souris, clavier) et les programmes qui les surveillent en tache de fond ne font pas obligatoirement bon ménage avec le scan des ports.
A voir avec vos retours d'expérience.

Possible. C'est vrai que ça devient une telle jungle, ces drivers, que le pauvre OS doit avoir du mal à s'y retrouver.

J'ai commandé le clone, (6€) et je devrais le recevoir rapidement.
Je pourrais donc faire mes essais sur quelque chose de concret.
Je pense que je vais aussi mettre une fenêtre de paramétrage au lancement, qui permettra de sélectionner le port COM directement si on le connaît, ainsi que le nombre de modules S88.

JP

[msport]

Je pense que je vais aussi mettre une fenêtre de paramétrage au lancement, qui permettra de sélectionner le port COM directement si on le connaît, ainsi que le nombre de modules S88.

Bonjour,
effectivement ce serait bien, la connexion serait plus rapide.
Michel

[msport]

Bonjour Jean-Pierre,
j'ai avancé un peu :
sur la commande des aiguillages en mode RUN :
CDM utilise une adresse unique par aiguille (exemple 10) avec activer 1 = droit et désactiver avec 0 = dévié. Ce qui me pose un problème car j'utilise une adresse par bobine soit 10 pour direct et 11 pour dévié. Est-ce qu'il y aurait une configuration que je n’aurais pas vue ? Mais je peux aussi modifier mes décodeurs.
Incidemment, mon circuit de test joint qui fonctionne en simulation.
Merci d'avance.

[jpp38]

Bonjour,

CDM fontionne comme le DCC, avec une adresse unique par aiguille. Là, il faut vraiment que tu modifies tes décodeurs.

JP

[msport]

Bien noté, ça m'apprendra à lire la norme. Mais je ne suis pas le seul à ne pas l'avoir lue, personne ne m'avait fait la remarque.
Merci.

Edit : pire pour moi, la version (arduino) pour aiguillage existe toute faite, nommée : RB_DCC_Decoder_Solenoid
voir https://rudysmodelrailway.wordpress.com/software/
Reste à revoir mes manettes basées sur le travail de D. Bodnar (à l'origine prévu seulement pour les locomotives) :
http://trainelectronics.com/DCC_Arduino/DCC++/Throttle/.

[jpp38]

Bonjour,

Reste à revoir mes manettes basées sur le travail de D. Bodnar (à l'origine prévu seulement pour les locomotives) :
http://trainelectronics.com/DCC_Arduino/DCC++/Throttle/.

A ce propos, le DCC++ prévoit-il la possibilité de gérer plusieurs appareils de contrôle? Pour le moment, je ne vois pas comment.
Et si c'est possible, il manque alors dans le protocole une remontée (broadcast) de l'évènement de prise de contrôle par une autre manette, vers toutes les autres manettes reliées à la base.

Bonne journée.

JP

[jpp38]

Bonjour,

Bonne nouvelle. J'ai reçu mon clone UNO basé sur le CH340G.
Je suis bien tombé sur les mêmes problèmes de connexion, ce qui m'a permis de voir quels paramètres de la Data Comm posaient problème.
Et, comme je m'en doutais un peu, c'est le contrôle RTS/CTS qui était actif dans la DLL (parce qu'utilisé de cette façon dans une autre interface), et que le CH340G ne digère pas.

Une fois dévalidé ce handshake, ça marche, et sur les deux (le vrai et le faux).

Par contre, l'initialisation est deux fois plus lente qu'avec le vrai Arduino... mais bon.

Je vais faire ma modif de sélection (éventuelle) du port com, et du nombre de modules S88, et je vous le renvoie pour test.

Bon week-end.

JP

PS: j'ai aussi corrigé le bug du callback 51.

[msport]

A ce propos, le DCC++ prévoit-il la possibilité de gérer plusieurs appareils de contrôle? Pour le moment, je ne vois pas comment.
Et si c'est possible, il manque alors dans le protocole une remontée (broadcast) de l'évènement de prise de contrôle par une autre manette, vers toutes les autres manettes reliées à la base.

Bonjour,

Je n'ai pas vérifié ce qui peut remonter de la station vers les manettes, mais ce n'est manifestement pas nécessaire (ou indispensable). La base station traduit en DCC toutes les commandes qu'elle reçoit sur son port série (voire Ethernet). Avec des modules radio, on peut donc multiplier les manettes et leur affecter des rôles différents ou communs : pilotage des locomotives, des aiguilles, des accessoires. Ce qui permet de multiplier les intervenants en manuel. Sous l'autorité du chef de gare, bien sur.
Il me semble que de son coté CDM n'accepte pas de voir passer des commandes en mode RUN ?

J'ai donc revu une manette "aiguillage" et un de mes décodeurs, c'est OK. A partir de là, j'ai fait le test d'un aiguillage depuis CDM. Test positif.
Cap sur une petite navette.

Merci Jean-Pierre et à bientôt.