Client CDM-Rail Remote

[MathieuA]

Bonjour,

Visiblement je t'ai trouvé du travail (comme si tu en manquais)

Mathieu

[MathieuA]

Bonjour,

Après quelques essais chez mon oncle hier il s'avère que tout fonctionne bien chez lui aussi
Mais il avait calibré ce fameux timer, donc je vais ajouter une note sur le premier poste au cas ou où même sur la page d'accueil du soft.

Mathieu

[CC72000]

Bonjour Mathieu,

Tant mieux si cela marche chez ton Oncle, dans sur une configuration DCC-S88.

En Lenz sur XpressNet-RS cela ne marche pas au niveau des vitesses. Il faut trouver pourquoi.

Les investigations que j'ai faites par rapport à plusieurs sujets qui se mélangent et se percutent sont les suivantes :

1- retrouver le Log du serveur COM-IP, comme c'est du WINDOWS mâtiné cochon dinde, le log est parfois sous l'exécutable, parfois sous le layout, et parfois nul part
dans ce LOG on voit bien la demande vitesse ==> il faut que je trouve pourquoi elle n'est pas exécutée.

2- sur l'émulation de RUN, cela marche bien quand il y a des adresses > 512. Pour des adresses 1, 2, 3, ... c'est aléatoires. J'avais déjà rencontré ce problème c'est pourquoi dans le MENU "... / General Debug / Dump / +512 S88" il y a un outil pour faire +512 sur les adresses de détecteurs. (je l'ai amélioré pour faire + ou -...)

3- En DCC la nouvelle DLL permet de passer en émulation de RUN mais cela ne marche pas à tous les coup (cf point ci-dessus) et en exécution sous Debuger, l'exécution stop sur l'exécution d'une fonction concernant l'état d'un détecteur.

EDIT
4- La notion de TCO intervient aussi dans l'affaire...

Pour le moment je vais me concentrer pour trouver la cause sur une conf LENZ / EXPRESSNET.
Il y a des choses à comprendre au niveau SPD_CheckSpeedRequests() et SPD_ExecOpTrnThrottleUpdate()

[CC72000]

Bonsoir Mathieu,

Houlala, et ben celui là il était pas facile à trouver...

Déjà une précision, ce n'est pas dépendant de la DLL XpressNett ou DCC, il y a le même comportement dans les deux cas.

Le problème est le suivant : la commande de vitesse ne marche pas si la première commande envoyée est une commande de FONCTION.

Attaché au descripteur de contrôleur il y a une liste de TCSource susceptible de passer des commandes, le premier est toujours de Type LOCAL, c'est celui-ci qui passe les commandes du contrôleur virtuel de CDM. Le second est toujours de Type BUS, c'est celui de la centrale, il est utilisé pour/par les contrôleurs physiques.
Ces 2 sources sont créées au lancement du RUN pour chaque Train.
Et ensuite, un TCSource de Type IPC est créé à la première commande venant d'un client IP-COM, les TCSources sont ensuite conservés et réutilisés...

Le BUG :
pTC_SOURCE SPD_AddTCSource(pTHROTTLE_DESC pThrottleDesc, TC_SOURCE_TYPE nType, int nClientNum, BOOL bPercent)
{
. . .
if (nType == TC_LOCAL || TC_BUS) <== Ce OU est mal écrit, ce IF est toujours VRAI
pTCSource->bSpeedPercent = bPercent;

else /* TC_IPC */
{
if (pThrottleDesc->pOpTrn == NULL)
pTCSource->bSpeedPercent = FALSE;
else
pTCSource->bSpeedPercent = TRUE;
}

return pTCSource;
}

Normalement pour un TCSource de Type IPC le paramètre bPercent ne sert à rien, puisque le bSpeedPercent ne dépend que du fait qu'un Train soit attaché ou non au descripteur.
Mais à cause du BUG sur le OU, on ne passe jamais dans le ELSE concernant les IPC, et le booléen est initialisé par le paramètre passé en appel.

Paramètre qui est à TRUE dans le cas d'un commande de vitesse :
pTCSource = SPD_AddTCSource(pThrottleDesc, TC_IPC, pTag->nSocketNum, TRUE);

Mais qui est à FALSE dans le cas d'une commande de Fonctions
pTCSource = SPD_AddTCSource(pThrottleDesc, TC_IPC, pTag->nSocketNum, FALSE);

La correction est d'écrire correctement le OU, et ceinture et bretelle, de faire les appels IPC toujours avec TRUE.

Donc à partir de là, le client Remote fonctionne correctement

Je vois une suite en 2 phases :
1- discuter de ce que l'on veut/peut faire avec ce client.

2- continuer d'explorer les nébuleuses qui tournent encore autour du TCO, de l'émulation de RUN, des adresses de détecteurs, la localisation des LOG ... c'est un peu plus clair, mais pas complétement.

[MathieuA]

Bonjour Michel,

Content que tu aies réussis à éclaircir la chose !

Je serais d'avis d'explorer les possibilités du client avant toute chose, car, je pense, il pourrait avoir une énorme valeur ajoutée à CDM.

En fait, pour révéler quelques secrets , je l'ai développé dans l'optique de pouvoir afficher autant de contrôleurs que voulu et aussi de pouvoir manipuler les aiguillages.
Mais pour l'instant toutes ces options sont désactivées. L'idée c'était de lancer une version minimal "proof of concept".

Maintenant, ce qui serait intéressant ça serait d'une part pour voir utiliser les itinéraires, et aussi (le must pour les grands enfants) de pouvoir jouer avec l'accostage.

Ensuite si on veut pousser la chose encore plus loin, on pourrait développer une petite DLL qui expose un mini serveur Web avec ce client. Ce serait ainsi directement intégré à CDM et éviterait à l'utilisateur toutes les étapes fastidieuses du "démarrer le client IPC, démarrer le client, connecter le client, ouvrir la page du client" etc.
Ça lui éviterait aussi d'avoir à télécharger un autre programme aussi.

Mais j'extrapole un peu

Mathieu

[gily]

Ce serait ainsi directement intégré à CDM et éviterait à l'utilisateur toutes les étapes fastidieuses du "démarrer le client IPC, démarrer le client, connecter le client, ouvrir la page du client" etc.

Oui à ce propos, pourquoi ne pas ouvrir par défaut le serveur COM/IP dans CDM?

Quant à manipuler les aiguillages depuis un client, on se retrouve confronté à la gestion de la sécurité, qui n'est pas prise en charge actuellement par CDM en cas de pilotage des aiguillages par un client.

[CC72000]

Bonjour Mathieu,

Je serais d'avis d'explorer les possibilités du client avant toute chose, car, je pense, il pourrait avoir une énorme valeur ajoutée à CDM.

Je pense comme toi, c'est un gros + pour CDM

En fait, pour révéler quelques secrets , je l'ai développé dans l'optique de pouvoir afficher autant de contrôleurs que voulu et aussi de pouvoir manipuler les aiguillages. Mais pour l'instant toutes ces options sont désactivées. L'idée c'était de lancer une version minimal "proof of concept".

Maintenant, ce qui serait intéressant ça serait d'une part pour voir utiliser les itinéraires, et aussi (le must pour les grands enfants) de pouvoir jouer avec l'accostage.

Moi j'y vois surtout cela comme le déport d'un Throlle de CDM sur une smartphone, pouvoir tenir dans sa main la cabine d'une loco qui permet de faire rouler celle-ci.
Je le vois avant tout comme conducteur d'une LOCO. Un conducteur de loco ne manipule pas les aiguillages.
Maintenant pour faire des accostage / débranchement, on peut imaginer que le conducteur soit accompagné de son agent de manœuvre qui manipule l'aiguille juste devant le train...

Ensuite si on veut pousser la chose encore plus loin, on pourrait développer une petite DLL qui expose un mini serveur Web avec ce client. Ce serait ainsi directement intégré à CDM et éviterait à l'utilisateur toutes les étapes fastidieuses du "démarrer le client IPC, démarrer le client, connecter le client, ouvrir la page du client" etc.
Ça lui éviterait aussi d'avoir à télécharger un autre programme aussi.

Démarrer le serveur COM-IPC... c'est facile... c'est même déjà fait bon c'est vrai que je n'ai pas beaucoup communiqué sur les options possibles au lancement de CDM...

[gily]

bonjour

Démarrer le serveur COM-IPC... c'est facile... c'est même déjà fait bon c'est vrai que je n'ai pas beaucoup communiqué sur les options possibles au lancement de CDM...

Ha bon?! interessant !! mais comment donc ?!

[CC72000]

Bonjour gily,

Ha bon?! interessant !! mais comment donc ?!

cf ce PDF

CdmRAIL V8.00.pdf

(234.73 Kio) Téléchargé 19 fois

qui date de la V8, mais Jean-Pierre n'avais pas trop accroché.

Dedans tu verras l'option -f NomDeResau.lay mais il est préférable d'utiliser l'option fichier de démarrage qu'avais développé Mathieu

l'option -i XpressNet ne fonctionne qu'avec la DLL XpressNet, il faudrait faire la même chose pour les autres DLL... d'ailleurs si tu mets -i TOTO c'est toujours XpressNet qui sera utilisée.

pour le serveur COMIPC c'est donc -s COMIPC ou -s TOTO... je vais le transformer en -COMIPC

Il y a aussi -EmulRun pour sélectionner émulation de RUN... parce que lorsque tu lances CDM des milliers de fois pour un BUG, c'est pratique

Donc avec un fichier de démarrage + la ligne de commande : -c _RUN_CTXT -i XPRESSNET -s COMIPC
tu économiseras quelques CLIC's

[gily]

Merci Michel pour toutes ces infos.
En fait je démarrais le serveur IPC en simulant les touches au clavier. Ca marche mais c'est tiré par les cheveux.

En effet il serait intéressant aussi de démarrer les autres serveurs d'interface (je le fais aussi avec la méthode des cheveux )

Bon je vais intégrer tout çà !

merci a bientot