Kit de développement Client Comm/IP: questions/réponses

[gily]

Bonjour

Bon je viens de comprendre pourquoi çà ne fonctionnait pas...

En fait la représentation en mémoire des données n'est pas la même suivant les langages. Par exemple en Delphi, un booléen est représenté par un octet de valeur 0 ou FF (pour faux ou vrai), et en C, il est représenté par un long mot (4 octets) de valeur 0 ou 1 (pour faux ou vrai)... Et je ne parle pas des chaînes.

Donc j'ai adapté mes variables pour l'interfacage à la DLL et j'arrive au connecter le serveur CDM rail.

Maintenant, j'attaque le passage des paramètres de la fonction
GET_NEXTMESSAGE et là c'est pas de la tarte

Donc c'est très difficile de vouloir utiliser une DLL écrite dans un autre langage que celui que l'on utilise dans le programme principal.. Il n'y a pas de standardisation des données....

A plus tard

[jpp38]

Bonjour,

Oui, bien sûr. Il y a le format des données, et la convention de passage: par adresse ou par valeur.
Le plus problématique, ce sont les structures, parce que les compilateurs ne mettent pas forcément les champs dans le même ordre.
Mais en fait, comme la seule structure que j'utilise est au démarrage du serveur, ça ne devrait plus poser problème après.

JP

[gily]

bon, après avoir passé une semaine sur le pc j'ai pris la décision d'abandonner. Il y a trop de structures différentes entre langages pour interfacer la dll avec une autre plateforme.

Donc j'ai téléchargé l'environnement de dvt C préconisé dans la documentation et je reprends la base du fichier client C que je modifie pour mes besoins....
Evidemment c'est plus facile...

Mon but c'est de récupérer les message CDM pour pouvoir ensuite piloter les feux de signalisation complexes avec le décodeur de leds de chez bahn..
mais je n'ai toujours pas reçu ma centrale Lenz commandée depuis 1 mois je suppose que ce sont les vacances pour tout le monde....

A plus tard

[jpp38]

Bonjour,

Du coup, là je peux t'aider.
N'hésite pas à demander si tu veux des tuyaux.

JP

[gily]

Ok merci.. A ce sujet je me demandais quelle fonction utiliser dans l'interface pour aller écrire dans un accessoire dont on connait l'adresse sur le réseau JK.
il existe des fonctions IPC qui permettent de piloter les aiguilles ou les feux, donc suppose qu'il faut les utiliser comme par exemple IPC_SignalChangeCRE()

Je me pose également une question sur le fichier du kit "ipc_protocole spécification" qui décrit comment échanger via des chaînes de caractères. D'après ce que j'ai compris, la chaîne de commande/longueur/nbparam/listeparam est à mettre dans le champ sName de la fonction. C'est bien celà?

A plus tard

[jpp38]

Bonjour,

Au fait, peux-tu nous donner ton prénom? C'est plus convivial.

Ok merci.. A ce sujet je me demandais quelle fonction utiliser dans l'interface pour aller écrire dans un accessoire dont on connait l'adresse sur le réseau JK.
il existe des fonctions IPC qui permettent de piloter les aiguilles ou les feux, donc suppose qu'il faut les utiliser comme par exemple IPC_SignalChangeCRE()

Bonne question. En fait, j'attendais qu'elle arrive, ce qui me montre que tu as bien lu la doc., et compris la philosophie.
Il y a deux approches, et aucune des deux n'est totalement implémentée aujourd'hui.
- La première est en effet d'envoyer la commande IPC_SignalChangeCRE(), avec un type "COMMAND".
Mais ça pose pas mal de problèmes, à commencer par le fait que la commande actuelle repose sur la transmission d'état de signaux qui reflètent ce que gère CDM-Rail.
Il faudrait donc étendre cette convention de passages d'états d'une façon non définie aujourd'hui.
- La deuxième serait de créer une fonction IPC_SignalDCCParamCRE(), un peu similaire à IPC_TrainDCCParamCRE(), qui fasse la transmission directe des paramètres
DCC vers le serveur, qui retransmettrait sans interprétation à le centrale. Le danger, c'est que CDM-Rail est court-circuité, et ce sont des failles potentielles de sécurité.

Je vais réfléchir pour mettre les deux types de fonctions à disposition, aux deux niveaux. Mais il faut que je réfléchisse aussi aux gardes-fous dans CDM-Rail.

Je me pose également une question sur le fichier du kit "ipc_protocole spécification" qui décrit comment échanger via des chaînes de caractères. D'après ce que j'ai compris, la chaîne de commande/longueur/nbparam/listeparam est à mettre dans le champ sName de la fonction. C'est bien celà?

Non, là tu n'y es pas du tout. La syntaxe du protocole de base est tellement lourde qu'il ne faut pas chercher à l'utiliser directement. En fait, le champ sName dans les fonctions de l'API correspond la plupart du temps à un paramètre particulier du protocole qui s'appelle NAME, c'est tout.
Le but de cette API est justement d'éviter d'avoir à se peler le détail du protocole.
Trois fonctions génériques de l'API permettent de passer directement:
- les commandes sans paramètre IPC_GenericNoParamCREQ()
- les commandes avec un seul paramètres entier IPC_GenericIntParamCREQ()
- les commandes avec un seul paramètres "chaine de caractère" IPC_GenericStrParamCREQ()

D'une façon générale, dans l'API, les arguments de chaque fonction correspondent aux paramètres utilisés dans la commande du protocole.

Pour en revenir aux signaux
========================

Dans le cas des évènements de signaux:
nIndex (paramètre OBJ) est le numéro de référence interne CDM-Rail du signal
sName (paramètre NAME) est la chaine de caractère qui représente le même numéro. Aucun intérêt dans le cas de CDM-Rail. Mais si un autre logiciel qui nomme explicitement le signaux adoptait le protocole, il pourrait y passer le nom des signaux.
nAddress (paramètre AD) est l'adresse du signal.

En fait, dans ton cas, si tu utilises IPC_SignalChangeCRE(), tu mets nIndex à 0, et sName à "" (chaine vide). Seule d'adresse nAddress/AD est nécessaire dans ce cas.

A suivre.

JP

[gily]

Rebonjour

Bon je vois qu'avec ma tentative d'utiliser le kit de dvt C, je m'engage dans des chemin pas tout à fait débroussaillés mais bon çà permet d'écrire un peu l'histoire de CDM aussi.. Je me doutais aussi que l'interface n'était pas tout à fait terminée mais disons plutot en cours d'implantation.

C'est vrai que j'ai lu et relu la doc plusieurs fois, elle donne des informations brutes sans forcément avoir ni les tenants ni les aboutissants ; mais je sais aussi que c'est un premier jus et que faire une doc qui soit claire et éclectique est difficile, et elle a au moins le mérite d'exister

Je pense qu'en ce qui concernant le pilotage des accessoires par une foncion IPC_xxx en direct qui serait "moins élégante" serait plus facile à implanter pour toi. Evidemment on shunte toute la sécurité de CDM, mais l'utilisateur qui utilise ceci a, je pense, bien conscience du "danger" de piloter en direct les périphériques (enfin çà dépend lesquels). Pour mon cas, je compte juste de piloter un décodeur de leds en fonction de l'état des aiguilles et des détecteurs. C'est pour celà que je te propose de commencer par celà.

Enfin, Il est plutot difficile de mettre à disposition des interfaces logicielles de pilotage en direct et de gérer des sécurités. On pourrait par exemple avoir une option qui pourrait activer ou désactiver la sécurité.. etc..

mon prénom c'est Frédéric...

A bientot

[jpp38]

Bon je vois qu'avec ma tentative d'utiliser le kit de dvt C, je m'engage dans des chemin pas tout à fait débroussaillés mais bon çà permet d'écrire un peu l'histoire de CDM aussi.. Je me doutais aussi que l'interface n'était pas tout à fait terminée mais disons plutot en cours d'implantation.

Mais là, il faut que ça soit tout-à-fait clair: même si tu descendais au niveau du protocole lui-même, ce serait pareil. C'est potentiellement énorme, et je développe le protocole et les fonctions au fur et à mesure des besoins, et donc, par voie de conséquence, mes besoins persos puisque jusqu'à maintenant, je suis le seul à avoir
développé des clients Comm/IP. Mais il faut voir que je m'efforcerai de mettre la priorité sur les requêtes des gens qui acceptent d'essayer.

C'est vrai que j'ai lu et relu la doc plusieurs fois, elle donne des informations brutes sans forcément avoir ni les tenants ni les aboutissants ; mais je sais aussi que c'est un premier jus et que faire une doc qui soit claire et éclectique est difficile, et elle a au moins le mérite d'exister

En fait c'est un boulot énorme. Et il faut voir que j'ai la même chose qui m'attend en Java.
Et le but de mettre ce kit à disposition, c'est précisément de savoir si ça vaut la peine d'insister, ou non.
C'est bien que tu t'y intéresse: ça va permettre de voir si c'est viable ou non.

Je pense qu'en ce qui concernant le pilotage des accessoires par une foncion IPC_xxx en direct qui serait "moins élégante" serait plus facile à implanter pour toi. Evidemment on shunte toute la sécurité de CDM, mais l'utilisateur qui utilise ceci a, je pense, bien conscience du "danger" de piloter en direct les périphériques (enfin çà dépend lesquels). Pour mon cas, je compte juste de piloter un décodeur de leds en fonction de l'état des aiguilles et des détecteurs. C'est pour celà que je te propose de commencer par celà.

Enfin, Il est plutot difficile de mettre à disposition des interfaces logicielles de pilotage en direct et de gérer des sécurités. On pourrait par exemple avoir une option qui pourrait activer ou désactiver la sécurité.. etc..

OK avec tout ça. C'est aussi ce que je pense.
OK donc pour partir là-dessus. Ce qui est assez facile à faire, c'est de créer la commande standard de pilotage d'accessoire (sans distinction entre aiguille et signal). Ce serait la fonction IPC_AccessoryParamCRE(), qui envoie un 1 ou un 0, sur une sortie ou l'autre.
Après, pour un signal, complexe, il faut évidemment plusieurs adresses, et donc, envoyer plusieurs commandes de ce type pour un seul changement d'état de signal.

Par contre, j'ai pas mal de choses à faire en ce moment. Ca va être difficile avant un mois.

JP

[gily]

Rebonsoir

Pour rebondir, je suis bien conscient que c'est effectivement exact que ton boulot représente un temps de dvt et de tests en tous genres énorme. De plus c'est vrai que peu de personnes doivent utiliser l'interface. Après tout, dans le monde du modélisme ferroviaire, tout le monde n'est pas informaticien ou n'a pas le besoin de l'utiliser.

Bon pour en revenir à des discussions plus informatiques, j'ai utilisé les fonctions d'après les informations de ton précédent msg. J'ai utilisé La fonction IPCçSignalChangeCRE pour changer le signal d'adresse 35 en mode simulation , mais il ne change pas d'état (quelle que soit la valeur du State d'ailleurs 0=rouge 1=avertissement jaune ou 2=vert.

sName="";nIndex=0;Ad1=35;Ad2=0;nState=1;
IPC_SignalChangeCRE(NULL,sName,nIndex,Ad1,Ad2,nState,IPC_COMMAND);

Peut être que çà ne fonctionne pas en mode simulation mais en pilotage réel si????

[j'ai essayé aussi avec IPC_TurnoutChangeCRE et çà ne change pas la position de l'aiguillage non plus]..

[jpp38]

Ca rejoint ce que je disais juste avant.

Il est absolument hors de question de changer l'état des signaux de cantonnement ou des aiguilles depuis un client, en simulation.
Les seules opérations autorisées sont celles qui prolongent ce que CDM-Rail ne sait pas faire: typiquement piloter un signal complexe dont CDM-Rail ne connait même pas l'adresse.
Mais il est hors de question de bypasser le contrôle du logiciel: ça emmène beaucoup trop loin.

En fait, le protocole jusqu'ici a surtout été développé dans l'optique des services, qui permet à un client de récupérer les évènements du réseau.
Et en fonction de ces évènements, il peut générer des actions:
- soit sur des accessoires extérieurs: c'est de ça qu'il était question.
- soit sur des trains (redémarrage, arrêt, fonctions, vitesse).

Autrement dit, le client fonctionne vraiment en mode esclave du serveur CDM-Rail, pour compléter ce que CDM-Rail ne sait pas faire. Mais en aucun cas il ne peut se substituer à CDM-Rail pour l'algorihme de sécurité.

JP