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

[gily]

Bonjour

Oui je me doutais bien avec ce que l'on avait dit que l'on ne pouvait "forcer" les aiguillages ou les signaux gérés par CDM.

Pour l'instant je me suis contenté donc de modifier les vitesses des trains avec la fonction IPC_TrainSpeedCRE() et çà fonctionne

la prochaine étape sera donc de piloter le décodeur de led ; mais pour celà j'attends de recevoir mon matériel...

A plus tard

[jpp38]

Bonjour Fredéric,

ET c'est là où il te faudra cette nouvelle fonction IPC_AccessoryParamCRE().

JP

[gily]

en effet J'attends donc la prochaine version......

[gily]

Bonjour

je suis en train d'écrire du code dans le programme client pour moi gérer les signaux complexes en fonction de l'état des signaux et et aiguillages remontés par CDM. Pour l'instant tout va bien, les simulations donnent satisfaction. Cependant je suis tombé sur le problème de l'initialisation du démarrage du client.

En effet lorsqu'il démarre, le client ne connaît pas les positions des aiguillages ni l'état des signaux. Les informations "arrivent" au fur et à mesure que les trains circulent, et génèrent des évènements vers le client. Je n'ai pas vu dans la documentation une fonction qui interroge l'état des aiguillages ou des signaux.

Par ailleurs je me demande si c'est possible car il faudrait que tous les aiguillages soient rétrosignalés, ou alors il faut que CDM positionne toutes les aiguilles au début du mode RUN (je ne l'ai jamais mis en route donc je ne sais pas car mon réseau n'est pas encore cablé)!

A plus tard

[jpp38]

Bonjour,

Les aiguilles sont en effet positionnées au départ du RUN (et de la simu), selon l'état du contexte de placement de départ.

Et si le client est démarré avant lancement de la simu, en principe, il doit recevoir les commandes de positionnement initial des aiguilles.

La commande de "QUERY" sur l'état des aiguilles n'est pas implémentée. On avisera si c'est nécessaire.

En attendant, je vais mettre aujourd'hui une nouvelle version du kit avec une opération de commande d'accessoire pouvant envoyer une rafale jusqu'à 16 adresses consécutives (menu "Opérations" >> "commande accessoire")

Acc_command.jpg (25.3 Kio) Consulté 868 fois

L'utilisation de la nouvelle commande IPC_AccessoryDCCParamCRE() est visible dans la fonction client.c/IPC_AccessoryCommandDialog()

Je l'ai essayée avec le module d'interface signaux LDT LS-DEC-NS. Ca marche.

JP

[jpp38]

En effet, je viens de vérifier, l'état des aiguilles n'est pas transmis au départ.

Je ferai le nécessaire dans la prochaine version (pas celle d'aujourd'hui).
Et j'ajouterai aussi le "Query".

JP

[jpp38]

Voilà, j'ai mis la nouvelle mise à jour du kit de développement.

Il faut aussi charger la dernière version de CDM-Rail (5.03).

JP

[gily]

Bonjour

Haaaa quel beau tableau de contrôle des interfaces, j'en bave

Je verrais dans la nouvelle version du kit l'implantation du pilotage. Je pourrais éventuellement mettre un exemple de la façon du procédé et le principe utilisé. pour information, j'ai modifié les fichiers suivants dans le kit:
- cl_ipc.h (déclaration de variables globales)
- cl_ipc_specific.c (transfert d'informations)

(je crois que çà fait partie des fichiers que l'on peut modifier)

et le programme principal a son propre fichier.
Bien noté les considérations pour les états initiaux des aiguillages. Pour l'instant, je les mettrai "en dur" dans le client pour le réseau qui me concerne.

A bientot

[jpp38]

Haaaa quel beau tableau de contrôle des interfaces, j'en bave

Sauf que je me suis loupé. Il faut le rappeler après chaque commande.
Ce sera modifié dans la prochaine version.
Mais enfin, ça permet de faire les essais.

Je verrais dans la nouvelle version du kit l'implantation du pilotage. Je pourrais éventuellement mettre un exemple de la façon du procédé et le principe utilisé. pour information, j'ai modifié les fichiers suivants dans le kit:
- cl_ipc.h (déclaration de variables globales)
- cl_ipc_specific.c (transfert d'informations)

Non, pas cl_ipc.h
Le seul fichier préfixé "cl_ipc" que tu peux modifier est cl_ipc_specific.c, de façon à permettre de récupérer directement tous les autres fichiers.

Par contre, tous les fichiers préfixés par "client" sont spécifiques de l'appli et donc modifiables.

Pour ton appli, le fichier destiné aux variables globales de l'appli est "client_glb.c".
Et ne pas oublier de reporter la même déclaration dans le fichier "client_ext.c", précéde du mot-clé "extern".


JP

[gily]

Bonjour

J’ai implanté la nouvelle version du kit et codé les fonctions d’appel au décodeur digital bahn. Ça fonctionne parfaitement donc mission accomplie. Les signaux sont reliés au décodeur digital bahn, lui-même alimenté par JK, piloté par CDMRail et le client modifié avec les règles de logique de mon réseau.
Les signaux s'allument bien en fonction de la logique implantée dans le client.... C'est beau un rappel de ralentissement sur un signal !!

Néanmoins j’ai du déroger à la règle de modification des fichiers pour les variables globales. En effet ta recommandation d’implanter les variables globales dans « client_glb.c" et dans « "client_ext.c", précède du mot-clé "extern" fonctionne pour les variables du module principal (client.c) mais pas pour celles utilisées dans le fichier « cl_ipc_specific.c » ??

D’autre part mais je pense que c’est lié à la nouvelle version du kit et sans modification de celui ci, à la connexion au serveur puis au démarrage des services j’ai la fenêtre « FORMAT ERROR » qui s’affiche. Puis ensuite le fonctionnement est normal. (la V1 ne faisait pas cela).

Je suis ne train de rédiger une petite doc.

Voili voila.

Et merci pour l'intégration de la nouvelle version du client