Client Comm:IP pour la gestion de la signalisation complexe

Re: Client Comm:IP pour la gestion de la signalisation complexe

Messagepar philippe30 » 08 Avril 2016, 18:45

Bonsoir Gily,

Oui comme tu le dis la difficulté est bien d’intégrer un signal dans l'environnement. Je constate avec mon premier signal que son fonctionnement est différent entre le mode Run sur un itinéraire et le mode Run TCO. Même si en TCO j'emprunte le même trajet que l’itinéraire. Bon je continue à chercher à comprendre.
Une question : dans ta doc concernant les actionneurs, tu identifies les adresses des actionneurs qui s'activent et qui se désactivent : je ne vois pas ce que cela signifie concrètement ( page 28) .
Je croyais comprendre que sur une zone comprise entre 2 actionneurs A et B, lorsque qu'un train passe sur l'actionneur A alors il est alors présent dans la zone ( alors l'activation de A -> Mem_A_B =true) jusqu'à ce qu'il passe sur B (l'activation de B --> Mem_A_B = false). Mais A et B ne sont actifs qu'au moment ou on passe dessus. L'état d'activation est fugace selon moi. Peux tu m'éclairer sur ce point? Merci.
philippe30
 
Messages: 64
Inscrit le: 14 Novembre 2014, 19:12

Re: Client Comm:IP pour la gestion de la signalisation complexe

Messagepar gily » 08 Avril 2016, 18:59

Bonjour

Voici comment il faut utiliser les actionnneurs. Je rappelle qu'ils ne servent qu'à mémoriser la présence d'un train entre deux actionneurs.

1. la variable entière "AdressActionneurActivation" prend la valeur de l'adresse de l'actionneur qui s'active au passage d'un train.
Par exemple, celà signifie que si un train passe sur l'actionneur d'adresse 819, alors AdressActionneurActivation prend la valeur 819
pendant un tour de programme seulement (une itération de programme).

2. La variable entière "AdressActionneurDesactivation" prend la valeur de l'adresse de l'actionneur qui s'active lorsque le train quitte l'actionneur.
Par exemple, celà signifie que si un train quitte l'actionneur d'adresse 820, alors AdressActionneurDesactivation prend la valeur 820
pendant un tour de programme seulement (une itération de programme).

Donc dans le programme, pour mémoriser qu'un train se trouve entre les actionneurs 819 et 820, il faut écrire:
if (AdressActionneurActivation==819) Mem_819_820=TRUE;
if (AdressActionneurDesctivation==820) Mem_819_820=FALSE;

Ainsi la variable booléenne Mem_819_820 prend la valeur TRUE quand le train se trouve entre les deux actionneurs.

Cas particulier: en cas d'aiguillage, il faut ajouter deux actionneurs avant et après l'aiguillage, puis mettre dans la condition de montée de la mémoire booléenne, l'état de l'aiguillage dévié ou non.
Exemple:
if ((AdressActionneurActivation==831) && (tablo_aiguillage[24]!=0)) Mem_831_829=TRUE;

Voilà finalement c'est assez simple :D (enfin dans ma tête).
Je rajouterai cette description dans une prochaine version de la doc.

Concernant le fonctionnement avec ou sans itinéraire, c'est normal. Voir page 16 de la doc en haut "restrictions et spécificités"

A bientot
gily
 
Messages: 1207
Inscrit le: 25 Juillet 2014, 14:32
Localisation: nord

Re: Client Comm:IP pour la gestion de la signalisation complexe

Messagepar philippe30 » 03 Mai 2016, 19:55

Bonsoir Gily,

je me suis remis au travail maintenant que j'ai reçu les signaux supplémentaires. Je progresse dans la compréhension du logiciel et du langage C++et aussi dans la mise au point du programme client. Mais que de travail!!
Cependant encore des zones d'ombre :
- Par exemple sur un décodeur CDF en mode 4 j'ai un signal 4 feux et un signal 2 feux. Lorsque que je le teste avec le LH100 et avec la fonction commande accessoires du programme client signaux complexes : j'ai un bon fonctionnement. C'est à dire que les 2 signaux répondent bien selon les adresses spécifiées. Mais lorsque les signaux sont pilotés par le programme client avec les mêmes adresses et bien il n'en est plus de même. Lorsque je demande par exemple de mettre un carre sur le signal 4 feux avec la bonne adresse et bien non seulement le signal concerné réagit correctement mais l'autre signal (2 feux ) sur le même décodeur réagit aussi..... J’espère être clair. Je n'ai pas vu l'erreur mais je n'ai pas non plus étudié le contenu de la fonction "IPC_AccessoryDCCParamCRE(NULL,adresse+1,1,IPC_COMMAND) ;". Est il nécessaire d'investiguer à ce niveau la ou faut il que je cherche ailleurs l'erreur ?
Merci de ton conseil d'expert en la matière.
philippe30
 
Messages: 64
Inscrit le: 14 Novembre 2014, 19:12

Re: Client Comm:IP pour la gestion de la signalisation complexe

Messagepar gily » 04 Mai 2016, 09:25

Bonjour Philippe

Pour adresser les feux, chaque feu doit avoir son propre pilotage, ils sont évidemment différenciés par leur adresse sur le décodeur.
le code ressemble donc à ceci pour les deux feux:

Extrait de la procédure envoi_CDF( ) :
(...)
switch (adresse)
case XXX: // pilotage du signal 4 feux à l’adresse XXX
{
if (code==carre) IPC_AccessoryDCCParamCRE(NULL_XXX,2,IPC_COMMAND);
if (code==semaphore) IPC_AccessoryDCCParamCRE(NULL_XXX,1,IPC_COMMAND);
if (code==vert) IPC_AccessoryDCCParamCRE(NULL_XXX+1,2,IPC_COMMAND);
if (code==jaune) IPC_AccessoryDCCParamCRE(NULL_XXX+1,1,IPC_COMMAND);
}
break;

case YYY: // pilotage du signal 2 feux à l’adresse YYY
{
if (code==vert) IPC_AccessoryDCCParamCRE(NULL_YYY,2,IPC_COMMAND);
if (code==semaphore) IPC_AccessoryDCCParamCRE(NULL_YYY,1,IPC_COMMAND);
}
break;
....

donc ici , le signal 4 feux est à l'adresse XXX et le signal 2 feux à l'adresse YYY.

Ensuite tu appelles la procédure comme suit:
Envoi_CDF(XXX,semaphore);
Envoi_CDF(YYY,vert);

remplacer XXX et YYY par les adresses des feux dans ton décodeur

A bientôt
Dernière édition par gily le 05 Mai 2016, 10:23, édité 2 fois au total.
gily
 
Messages: 1207
Inscrit le: 25 Juillet 2014, 14:32
Localisation: nord

Re: Client Comm:IP pour la gestion de la signalisation complexe

Messagepar philippe30 » 04 Mai 2016, 11:30

Bonjour Gily,

Merci de ta réponse.
J'ai trouvé une erreur dans mon code ce qui explique en partie les dysfonctionnements.
En fait j'ai modifié le câblage d'un feux sur le décodeur CDF après avoir pris contact avec CDF Informatique ( car le signal complexe en ma possession à un oeilleton , en plus des 6 feux,que je voulais utiliser ). Mais je n'ai pas modifier correctement le programme client d’où les écarts. Ton explication m'a mis sur la voie.
Merci de ton aide et de ta disponibilité.
Philippe
philippe30
 
Messages: 64
Inscrit le: 14 Novembre 2014, 19:12

Re: Client Comm:IP pour la gestion de la signalisation complexe

Messagepar gily » 04 Mai 2016, 20:43

bon, çà avance :bravo1:
gily
 
Messages: 1207
Inscrit le: 25 Juillet 2014, 14:32
Localisation: nord

Re: Client Comm:IP pour la gestion de la signalisation complexe

Messagepar philippe30 » 08 Mai 2016, 15:31

Bonjour Gily,

Je poursuis toujours la mise au point du kit client IP pour les signaux complexes sur un réseau d'essai et je constate un écart entre le fonctionnement d'un même signal avec la LH100 et avec la fonction "commande accessoire" du kit client IP.

J'ai un décodeur CDF en mode 5, câblé selon l'exemple de la page 9 du document du fournisseur. Sur le décodeur sont montés 2 signaux :
- Sorties S1, S2 (adresse 97) : signal 2 feux
- Sorties S3, S4, S5, S6, S7 et S8 (adresses 98,99 et 100) : signal 6 feux dont rappel ralentissement 30 et 60.
En utilisant la LH 100 les feux du signal 6 feux fonctionnent ainsi :
adresse 98 / + et – (S3 et S4 => carré et sémaphore
adresse 99 / + et – (S5 et S6) => vert et jaune
adresse 100 / + et – (S7 et S8) => rappel ralentissement fixe et rappel ralentissement fixe clignotant

En utilisant la fonction « commande accessoire » du client signaux complexes (sans lay) pour les adresses 98 et 99 les résultats identiques à ceux avec la LH100.
Mais ils sont différents pour le ralentissement fixe et pour le ralentissement clignotant.
ainsi en mettant les paramètres suivants voilà les résultats obtenus
adresse de base = 98 et AD+2 /out 1 => ralentissement fixe
adresse de base = 98 et AD+2 / out 2 => ralentissement fixe
adresse de base = 98 et AD+3 / out 1 => ralentissement clignotant
adresse de base = 98 et AD+3 /out 2 => ralentissement clignotant

Sur mon réseau d'essai l'adresse 101 n'existe pas.
As tu un avis ou une idée sur cette différence de fonctionnement ? Merci
A bientôt
philippe30
 
Messages: 64
Inscrit le: 14 Novembre 2014, 19:12

Re: Client Comm:IP pour la gestion de la signalisation complexe

Messagepar gily » 08 Mai 2016, 18:01

bonjour
tu as écrit:
"adresse 100 / + et – (S7 et S8) => rappel ralentissement fixe et rappel ralentissement fixe clignotant"

heu il doit y avoir une erreur: rappel ralentissement fixe =rappel 30
mais "rappel ralentissement fixe clignotant" çà n'existe pas :lol:

peux tu corriger la terminologie stp.

En tout état de cause, je pense que tu as du mal remplir le tableau de la commande d'accessoires: si l'adresse 101 n'existe en effet pas,
une commande sur cette adresse ne peut avoir absolument aucun effet.

A bientot
gily
 
Messages: 1207
Inscrit le: 25 Juillet 2014, 14:32
Localisation: nord

Re: Client Comm:IP pour la gestion de la signalisation complexe

Messagepar gily » 24 Octobre 2016, 18:22

Bonjour

ci joint une nouvelle vidéo filmée sur mon réseau montrant quelques exemples concrets sur le fonctionnement des
signaux complexes avec le signal client.

http://www.dailymotion.com/video/x4yufz2

Bonne projection 8-)
Dernière édition par gily le 25 Octobre 2016, 19:53, édité 1 fois au total.
gily
 
Messages: 1207
Inscrit le: 25 Juillet 2014, 14:32
Localisation: nord

Re: Client Comm:IP pour la gestion de la signalisation complexe

Messagepar jpp38 » 25 Octobre 2016, 19:15

Bonjour,

Merci pour cette vidéo.

Une question: est-ce que les problèmes de temps de réponse que tu as eus à un moment donnés (avec la génération du fichier de log), ont complètement disparu en ne générant plus ce fichier "log"?

JP
jpp38
 
Messages: 11187
Inscrit le: 31 Mars 2009, 10:15
Localisation: Grenoble (Isère / Rhône Alpes)

PrécédentSuivant

Retourner vers Fonctionnement en réseau: Comm/IP

Qui est en ligne ?

Utilisateurs parcourant actuellement ce forum : Aucun utilisateur inscrit et 1 invité