Connexion LZV200

[jpp38]

Pour la LVZ200, Lenz a changé son protocole sans le documenter , de ce fait presqu'aucun logiciel ne fonctionne avec la 200. Il n'y a que jmri qui a récemment intégré le nouveau protocole.

Ah! Intéressant à savoir. Et le pire, c'est que la LZV200 on en parle depuis 2013!!!!

Bon! On va faire comme JMRI, on devrait y arriver assez vite.... Au moins pour se connecter. Après, s'ils nous ont fait encore des farces sur quelques commandes, ça risque d'être plus dur.

JP

[gily]

les infos sont ici; il est écrit qu'il faut utiliser le driver FTDI pour la LVZ200
https://www.jmri.org/help/en/html/hardw ... nectLzv200

[gily]

Bonjour

Lolo, je viens de trouver un souci avec le programme signaux complexes, qui explique sans doute les échecs précédents de connexion à ta centrale...

voici donc la version corrigée, c'est l'EXE à mettre à la place de l'ancien

Signaux_complexes_GL_exe_1.71.zip

(463.06 Kio) Téléchargé 78 fois

[gily]

Bonjour Jean Pierre

J'ai donc procédé au test à distance sur le PC de lolo pour tester la comm avec le programme signaux complexes. Çà a fonctionné sans problèmes. Les paramètres matériels de connexion sont les suivants:

vitesse 57600 bds
pas de parité
8 bits de données
1 bit de stop

Étonnamment, On arrive apparemment à se connecter avec le protocole RTS-CTS (donc standard chez Lenz) mais aussi sans protocole.

Comme toutes les interfaces USB Lenz, il faut faire précéder les trames de FF FE, et on reçoit des trames précédées de FF FE ou FF FD.

Suite à cette connexion réussie, on a obtenu la remontée des informations de rétrosignalisation correctes en faisant circuler une rame éclairée sur des détecteurs différents,

Pour information, le driver utilisé pour le COM (qui était sur le port 5) est le FTDI, qui est un driver standard pour les tampons USB-série. Donc facile à tester si tu as un convertisseur série USB avec une puce FDTI pour CDM pour au moins ouvrir la com (d'ailleurs peut être qu'il l'ouvre mais le refus de comm de CDM est peut être à un autre niveau)

On a ensuite testé avec CDM Rail, interface XpressNet, auto, mais çà ne se connecte pas avec CDM.
Dans la fenêtre paramètres, il y a l'adresse Xpressnet sur "inchangée", je ne sais pas pourquoi tu as ce paramètre (ds mon prog signaux complexes je n'ai pas cette notion d'adresse XpressNet pour établir la liaison).

J'espère que ces informations vont te permettre d'avancer.

Je ne sais pas si tu pas un mode débug qui permet d'afficher les trames envoyées/reçues à la connexion de l'interface et voir si elle répond. Je n'ai pas demandé à Laurent si la led jaune clignotait sur sa centrale à l'établissement de la liaison de CDM.

[jpp38]

Les deux pistes étaient:
- le fait qu'il n'y a plus de contrôle CTS (ni RTS). Tes essais montrent que ce n'est pas bloquant.

- un doute sur l'envoi de la commande F0 F0. Je ne parle pas des préfixes FF FE: manifestement ça n'a pas changé.

Est-ce que ton programme envoie cette séquence FF FE F0 F0?

Peux-tu me renvoyer le source du module de la partie connexion à la centrale de ton programme (après correction, si j'ai bien compris) , pour que j'essaye de voir la différence?


JP

PS: mon debug démarre après la connexion. Avant, je ne peux pas voir les échanges sans avoir la centrale sous la main.

[gily]

oui je vais te préparer l'extrait de source.

La commande pour avoir la version c'est F0. Le 2eme F0 c'est le checksum de la trame.

A la connexion, je n'envoie aucune commande. Le port est déclaré ouvert quand la fonction renvoie que l'ouverture du com est OK,mais aucune trame n'est encore envoyé à ce moment. La demande de version est faite par l'utilisateur en appuyant sur le bouton demande version àl'interface, et là la trame FF FE F0 F0 est envoyée, et l'interface répond.

[jpp38]

OK, donc cette trame FF FE F0 F0 est reconnue, et passe. Ce n'est pas de ce côté là qu'il faut chercher.

Au fait, l'adresse Xpressnet (inchangée) , est l'adresse par défaut de l'interface (quand elle était extérieure à la centrale).
Chaque périphérique Xpressnet (manette LH100 ou autre, ou interface LIxxx) possède une adresse Xpressnet de 1 à 31. Et chaque périph doit avoir une adresse distincte. Si une interface a la même adresse qu'une manette, ça ne peut pas marcher, et il faut donc allouer une autre adresse.

A partir du moment ou l'interface est intégrée à la centrale, je ne sais plus quel sens ça a. Mais de toute façon, ça doit marcher sans respécifier une adresse Xpressnet, puisque vous vous êtres connectés sans le faire.

J'attends ton bout de code source.

Merci.

JP

PS: ça pourrait aussi être un problème de time-out trop court, au moment de l'établissement de la connexion.

[gily]

Voici le code source avec quelques commentaires. Pour le com usb/série, j'utilise un OCX : MSCOMM dont l'instanciation est ici MSCommUSBLenz pour gérer le port COM. Cet objet, MSCommUSBLenz comporte plusieurs propriétés dont:
(1) settings à remplir par le paramétrage du port : MSCommUSBLenz.settings:='57600,n,8,1'
(2) Handshaking contient le protocole : MSCommUSBLenz.Handshaking:=leprotocole {0=aucun 1=Xon-Xoff 2=rts-cts 3=RTS-Xon-Xoff}
il est ouvert systématiquement par 2 (rts-cts) le 0 ne sert que pour la genli
(3) SThreshold et RThreshold servent à déclencher une transmission si le tampon d'émission contient 1 octet, et déclenche une interruption
si le tampon de réception contient 1 caractère
(4) CommPort contient le numéro du port :MSCommUSBLenz.CommPort:=5 // pour le com5 évidemment
(5) forçage de la ligne DTR
(6) si on utilise la genli (protocole=4) alors j'allume le signal RTS sinon j'éteinds RTS
(7) InputMode = type de trames comInputModeBinary c'est le mode d'échange en binaire
(8) Positionnement d'une variable par défaut sur "le port est ouvert" (on va le mettre à faux si il n'a pas été ouvert)
(9) c'est là qu'on demande l'ouverture du port. Si le port s'ouvre, la fonction try ve termine sans exception
(10) interception de l'exception en cas de non ouverture du port : la variable "le port est ouvert" passe à faux

voila c'est tout... Après on peut envoyer des trames FF FE FO FO , j'attends un peu et je reçois la réponse.

Code: Tout sélectionner

// initialisation de la comm USB
procedure connecte_USB;
var i,j : integer;
begin
    if NumPort<>0 then
    begin
      With Formprinc.MSCommUSBLenz do
      begin
  (1)   Settings:=ConfStCom;
        Affiche('Demande ouverture COM'+intToSTR(NumPort)+':'+ConfStCom+' protocole '+IntToSTR(protocole),CLYellow);
  (2)    if protocole>=4 then Handshaking:=0 {0=aucun 1=Xon-Xoff 2=cts 3=RTS-Xon-Xoff 4=5=protocoles "maison"}
          else Handshaking:=protocole;
  (3)   SThreshold:=1;
        RThreshold:=1;
  (4)   CommPort:=NumPort;
  (5)   DTREnable:=True;
  (6)   if protocole=4 then RTSEnable:=True //pour la genli
        else RTSenable:=False;
  (7)   InputMode:=comInputModeBinary;
      end;
  (8)   portCommOuvert:=true;
      try
  (9)   Formprinc.MSCommUSBLenz.portopen:=true;
      except
(10)   portCommOuvert:=false;
      end;
    end
      else
        begin
          portCommOuvert:=false;
          Affiche('Port Com nul dans le fichier de configuration',clyellow);
        end;

    if portCommOuvert then
    begin
      affiche('port COM'+intToSTR(NumPort)+' ouvert',clGreen);
      With Formprinc do
      begin
        LabelTitre.caption:=titre+' Interface connectée au COM'+IntToSTR(NumPort);
        MenuConnecterUSB.enabled:=false;
        DeConnecterUSB.enabled:=true;
        ConnecterCDMRail.enabled:=false;
        DeConnecterCDMRail.enabled:=false;
      end;
    end
    else
      begin
        Affiche('port COM'+intToSTR(NumPort)+' NON ouvert',clRed)  ;
      end;
end;

[jpp38]

Avant de regarder ton code, j'ai envoyé par MP une DLL d'essai, où j'ai rallongé le Time-out de la requête de version d'interface (F0).
Merci de m'indiquer ce que ça donne.


JP

[gily]

oui je pense que ce n'est pas dans le protocole que le problème se situe puisqu'en utilisant le protocole standard çà fonctionne.