Galerie Photo
- Forum
- Modélisme
- Driving Railway
- DR, versioning et souhaits
- DEMANDE DE MODIFICATION - LOGICIEL DRIVING RAILWAY
DEMANDE DE MODIFICATION - LOGICIEL DRIVING RAILWAY
- admin
- Auteur du sujet
- Hors Ligne
- Administrateur
- fan de TEE
il y a 15 ans 9 mois #1169 par admin
ta trop grande confiance en tes amis sera ta perte (Palpatine à SkyWalker dans l'épisode VI)
DEMANDE DE MODIFICATION - LOGICIEL DRIVING RAILWAY a été créé par admin
Tout est toujours perfectible, aussi avons-nous adressé quelques requêtes concernant le logiciel Driving Railway, sous-entendu que nous parlons de versions postérieures à la 2.34.
R1 : sur un TCO suisse, les boutons sont de couleurs différentes selon qu'il servent à allumer des lanternes d'aiguilles ou à commander l'enclenchement d'un parcours. Nous avons demandé à M. Tronchet de pouvoir utiliser différentes couleurs de boutons sur le même TCO pour retrouver cet esprit. En outre, sur un réseau complexe il est très agréable de pouvoir retrouver rapidement LE bouton qui pourra commander l'aiguille 1030, situé à proximité du bouton allumant l'éclairage de la lampisterie...
R2 : Une version multiposte du logiciel serait un plus indéniable. Dans le cas de notre réseau qui compte 3 gares, chacune pourrait, dès lors, être pilotée de manière individuelle par un des membres du club. Ceci entre tout à fait dans l'esprit où notre club souhaite se diriger, à savoir un modélisme ou chacun peut endosser un rôle précis (mécanicien de locomotive, chef de gare, dispatcher)
R3 : installation possible depuis n'importe quelle unité et n'importe quel répertoire
R4 : installation possible vers n'importe quelle unité et n'importe quel répertoire
R5 : désinstalleur de l'application
R6 : numérotation des locomotives selon numérotation unifiée européenne (prévoir une douzaine de caractères dans la case)
R1 : sur un TCO suisse, les boutons sont de couleurs différentes selon qu'il servent à allumer des lanternes d'aiguilles ou à commander l'enclenchement d'un parcours. Nous avons demandé à M. Tronchet de pouvoir utiliser différentes couleurs de boutons sur le même TCO pour retrouver cet esprit. En outre, sur un réseau complexe il est très agréable de pouvoir retrouver rapidement LE bouton qui pourra commander l'aiguille 1030, situé à proximité du bouton allumant l'éclairage de la lampisterie...
R2 : Une version multiposte du logiciel serait un plus indéniable. Dans le cas de notre réseau qui compte 3 gares, chacune pourrait, dès lors, être pilotée de manière individuelle par un des membres du club. Ceci entre tout à fait dans l'esprit où notre club souhaite se diriger, à savoir un modélisme ou chacun peut endosser un rôle précis (mécanicien de locomotive, chef de gare, dispatcher)
R3 : installation possible depuis n'importe quelle unité et n'importe quel répertoire
R4 : installation possible vers n'importe quelle unité et n'importe quel répertoire
R5 : désinstalleur de l'application
R6 : numérotation des locomotives selon numérotation unifiée européenne (prévoir une douzaine de caractères dans la case)
ta trop grande confiance en tes amis sera ta perte (Palpatine à SkyWalker dans l'épisode VI)
Connexion pour participer à la conversation.
- AriesNoMu
- Visiteur
il y a 15 ans 2 semaines #1438 par AriesNoMu
Réponse de AriesNoMu sur le sujet Re:DEMANDE DE MODIFICATION - LOGICIEL DRIVING RAILWAY
R7 : j'aimerais pouvoir dessiner des élements qui ne servent pas au pilotage mais qui permettent de s'y retrouver entre le TCO Driving et la réalité.
Bon d'accord, je m'exprime pas bien...
Par exemple : matérialiser un poste d'aiguillage, une gare, etc...
Thierry
Bon d'accord, je m'exprime pas bien...
Par exemple : matérialiser un poste d'aiguillage, une gare, etc...
Thierry
Connexion pour participer à la conversation.
- laurentr
- Hors Ligne
- Banni
Réduire Plus d'informations
- Messages : 271
- Remerciements reçus 33
il y a 14 ans 7 mois #1723 par laurentr
Réponse de laurentr sur le sujet Re:DEMANDE DE MODIFICATION - LOGICIEL DRIVING RAILWAY
Si je peux me permettre un point important:
R8: pouvoir avoir 256 caracteres au lieu de 16 pour le nommage description des evenements!!!!
dautres idees dans quelques temps et detaillées pour vous permettre de les apprecier à leur juste valeur
Cdt
Laurent R
R8: pouvoir avoir 256 caracteres au lieu de 16 pour le nommage description des evenements!!!!
dautres idees dans quelques temps et detaillées pour vous permettre de les apprecier à leur juste valeur
Cdt
Laurent R
Connexion pour participer à la conversation.
- admin
- Auteur du sujet
- Hors Ligne
- Administrateur
- fan de TEE
il y a 14 ans 7 mois #1726 par admin
ta trop grande confiance en tes amis sera ta perte (Palpatine à SkyWalker dans l'épisode VI)
Réponse de admin sur le sujet Re:DEMANDE DE MODIFICATION - LOGICIEL DRIVING RAILWAY
Hello,
nous avons également évoqué le problème des libellés trop courts; je rajouterai tes propositions aux nôtres et on essayera ensuite d'orienter la maison Pégase Informatique vers ce post !
nous avons également évoqué le problème des libellés trop courts; je rajouterai tes propositions aux nôtres et on essayera ensuite d'orienter la maison Pégase Informatique vers ce post !
ta trop grande confiance en tes amis sera ta perte (Palpatine à SkyWalker dans l'épisode VI)
Connexion pour participer à la conversation.
- laurentr
- Hors Ligne
- Banni
Réduire Plus d'informations
- Messages : 271
- Remerciements reçus 33
il y a 14 ans 6 mois #1849 par laurentr
Réponse de laurentr sur le sujet Re:DEMANDE DE MODIFICATION - LOGICIEL DRIVING RAILWAY
Bonsoir
quelques idees à vous faire partager:
Ci-dessous quelques remarques sur le logiciel et ses possibilités d’évolution.
L’idée directrice étant de pérenniser un fonctionnement fiable et irréprochable, accroitre sa simplicité de mise en oeuvre, et d’y adjoindre une complémentarité de fonctions nouvelles notamment en conformité avec le mode de fonctionnement de type SNCF…
Fonctionnalités recherchées :
1. Gestion d’un TCO physique :
Je souhaite utiliser le TCO physique de la gare de FLEURY et activer sur celui-ci les différents voyants qui le composent en parallèle avec les informations visibles sur le TCO de Driving Railway.
Ce tableau se compose de voyants indiquant entre autre la position des aiguillages, l’occupation des zones et les signaux présents, de boutons…
Dans cette optique le recours aux cartes de type MOAFF et MOOUT ainsi que MOINPUT et MOCLA est nécessaire. Ces cartes se trouvent à proximité du TCO physique. Le câblage est réduit à sa plus simple expression et les distances sont réduites le plus possible entre voyants, boutons et cartes.
Le mode de test des modules permet de certifier du bon fonctionnement des voyants et des boutons pour chaque entrée/sortie de carte.
Malheureusement il n’est pas possible de restituer le fonctionnement authentique et/ou complet du TCO tel que ceux utilisés par la SNCF avec le logiciel en la version actuelle du fait d’un choix limité de fonctions disponibles.
Utilisation du MOINPUT-MOCLA en mode impulsion:
Avec ces modules les contacts utilisés sont soit de type continu genre inverseur, soit de type momentané genre poussoir.
Il apparaît utile de pouvoir disposer d’une option permettant à partir d’un bouton poussoir et de l’impulsion qu’il donne de transformer cette impulsion en état continu.
Plus précisément, il s’agit d’émuler le fonctionnement d’une bascule de la même manière qu’un telerupteur pour un allumage multipoints dans une habitation. Il s’agit en fait d’un relais bistable géré de manière logiciel avec une ou plusieurs entrées pour l’activation/désactivation.
L’activation du poussoir initialisant la continuité, une seconde impulsion ou un autre élément venant rompre cette continuité d’action. Le recours aux variables dans le logiciel parait être la solution la plus simple et la plus commode à mettre en place pour ce type de modification…
La modification du logiciel dans cette voie permettrait de gérer des enclenchements à partir d’une impulsion depuis un TCO physique comme par exemple l’enclenchement d’un itinéraire…
Cette possibilité de déclenchement à partir d’une impulsion existe déjà dans Driving au niveau du TCO de Driving avec les boutons TCO. Ici le but est de pouvoir permettre ce même type d’enclenchement à partir du TCO physique et d’une simple pression sur un bouton de voir la succession d’actions diverses (notamment gérées par les événements). D’où la possibilité également d’avoir un lien entre ces boutons des TCO physique et Driving…En effet si un bouton est activé on pourrait disposer d’un bouton sur le TCO de Driving avec deux couleurs différentes pour identifier l’état actif ou non du bouton sur le TCO physique. Ceci rejoint le point suivant.
2. Utilisation des voyants témoins et boutons sur le TCO de Driving.
Voyants :
L’esthétique devrait être revue afin que cela soit le centre du bouton et non son contour qui se colore lors de l’activation.
Boutons :
Il devrait être pris modèle sur les voyants afin de visualiser l’état d un bouton par une distinction au niveau des couleurs si actif ou inactif dans le centre même du bouton.
3. Problèmes logiciels détectés : « BUG » ?
Le montage du réseau a permis de réaliser des tests assez poussés du fonctionnement de l’installation. Au cours de ces tests plusieurs « bugs » me sont apparus :
Commutateurs booléens :
L’utilisation de ceux-ci ne pose pas de problème à la condition de n’utiliser qu’un seul type d’opérateur dans l’événement. En effet le mélange de conditions de types ET et OU donne des résultats spectaculairement aléatoires et peu conforme à l’effet recherché. Cela me fait penser à un possible mauvais placement de parenthèses dans une opération incluant somme et multiplication :
(a+b) x2 = 2a+2b
alors que
a+bx2= a+2b !!!
Il apparaît donc qu il faille revoir la copie sur ce point…. Et/ou permettre de gérer le placement de «parenthèses » pour borner les boucles ET/OU.
La solution de contournement passe par la création de variable et des recombinaisons complexes…
4. Nouvelles fonctionnalités envisageables :
Un nouvel « opérateur booléen » pourrait être implémenté dans le logiciel. Il s’agit de l’opérateur SINON. (Sauf si)
Cette condition ouvrirait la porte à de nouveau type de programmation des événements de manière souple, simple et efficace. Plusieurs formes sont envisageables :
Type a :
Conditions d’activation … [1 à 6 possibles]
Action à réaliser… [1 ou 2 possibles]
SINON
Conditions d’activation… [1 à 6 possibles]
Action à réaliser… [1ou 2 possibles]
Ce qui peut aussi se vérifier avec l’utilisation de variables afin d’obtenir ceci :
• dans un événement N° 1 des conditions d’activation créent la variable X. (action variable X marche/arrêt)
• dans un événement N° 2 des conditions d’activation créent la variable Y. (action variable Y marche/arrêt)
• dans un événement N°3 on aurait une structure de ce type :
o conditions d’activation : variable X
o action à réaliser A
SINON
o conditions d’activation : variable Y
o action à réaliser B.
L’exemple concret consiste à remplacer par exemple dans le cas précèdent :
• variable X par : détection globale sur canton 12
• variable Y par : détection globale sur canton 12 avec case inverse cochée (équivaut à pas de détection sur le canton 12)
• action A : activer MOOUT n°xxx1 sortie 4 marche/arrêt
• action B : activer MOAFF n°xxx3 sortie 5 marche/arrêt
On crée ainsi une bascule. Ainsi si on a sur les sorties du MOOUT n°xxx1 à la sortie 4 au MOAFF sur la sortie 5 respectivement une lampe rouge et verte on obtient :
Allumage de la rouge et extinction de la verte et réciproquement, extinction de la rouge et allumage de la verte.
Le choix de la condition SINON et de la condition ET ouvre des combinaisons sur les actions en sortie.
L’opérateur OU est supprimé des choix disponibles pour cet événement car sans intérêt dans le cas du recours au booléen SINON.
L’apparition du type variable implique l’apparition du cadre description pour expliquer brièvement la variable. (Ici en encadré rouge) Avec plus de 15 caractères pour décrire ! 256 semble être un minimum…
Type b :
La gestion des événements pourrait également avoir une structure de ce type :
Conditions d’activation… [1 à 6 possibles]
Action à réaliser… [1 ou 2 possibles]
SINON
Action à réaliser … [1 ou 2 possibles]
On retrouve ici la bascule gérée plus simplement encore si nécessaire que précédemment.
Comme vous pouvez le remarquer l’introduction de l’opérateur SINON aurait pour but de permettre une programmation événementielle plus souple et plus vaste… (Itinéraires sur événements pour dépassement de convois, extinction d’une lampe et allumage simultanée d’une autre…)
Conclusion :
Bien entendu il ne s’agit ici que de pistes de travail mais qui conduirait sans aucun doute à plus de souplesse dans la mise en œuvre et conférerait plus de possibilités au logiciel et à ses composants dans leur fonctionnement et leur interaction…
Laurent
quelques idees à vous faire partager:
Ci-dessous quelques remarques sur le logiciel et ses possibilités d’évolution.
L’idée directrice étant de pérenniser un fonctionnement fiable et irréprochable, accroitre sa simplicité de mise en oeuvre, et d’y adjoindre une complémentarité de fonctions nouvelles notamment en conformité avec le mode de fonctionnement de type SNCF…
Fonctionnalités recherchées :
1. Gestion d’un TCO physique :
Je souhaite utiliser le TCO physique de la gare de FLEURY et activer sur celui-ci les différents voyants qui le composent en parallèle avec les informations visibles sur le TCO de Driving Railway.
Ce tableau se compose de voyants indiquant entre autre la position des aiguillages, l’occupation des zones et les signaux présents, de boutons…
Dans cette optique le recours aux cartes de type MOAFF et MOOUT ainsi que MOINPUT et MOCLA est nécessaire. Ces cartes se trouvent à proximité du TCO physique. Le câblage est réduit à sa plus simple expression et les distances sont réduites le plus possible entre voyants, boutons et cartes.
Le mode de test des modules permet de certifier du bon fonctionnement des voyants et des boutons pour chaque entrée/sortie de carte.
Malheureusement il n’est pas possible de restituer le fonctionnement authentique et/ou complet du TCO tel que ceux utilisés par la SNCF avec le logiciel en la version actuelle du fait d’un choix limité de fonctions disponibles.
Utilisation du MOINPUT-MOCLA en mode impulsion:
Avec ces modules les contacts utilisés sont soit de type continu genre inverseur, soit de type momentané genre poussoir.
Il apparaît utile de pouvoir disposer d’une option permettant à partir d’un bouton poussoir et de l’impulsion qu’il donne de transformer cette impulsion en état continu.
Plus précisément, il s’agit d’émuler le fonctionnement d’une bascule de la même manière qu’un telerupteur pour un allumage multipoints dans une habitation. Il s’agit en fait d’un relais bistable géré de manière logiciel avec une ou plusieurs entrées pour l’activation/désactivation.
L’activation du poussoir initialisant la continuité, une seconde impulsion ou un autre élément venant rompre cette continuité d’action. Le recours aux variables dans le logiciel parait être la solution la plus simple et la plus commode à mettre en place pour ce type de modification…
La modification du logiciel dans cette voie permettrait de gérer des enclenchements à partir d’une impulsion depuis un TCO physique comme par exemple l’enclenchement d’un itinéraire…
Cette possibilité de déclenchement à partir d’une impulsion existe déjà dans Driving au niveau du TCO de Driving avec les boutons TCO. Ici le but est de pouvoir permettre ce même type d’enclenchement à partir du TCO physique et d’une simple pression sur un bouton de voir la succession d’actions diverses (notamment gérées par les événements). D’où la possibilité également d’avoir un lien entre ces boutons des TCO physique et Driving…En effet si un bouton est activé on pourrait disposer d’un bouton sur le TCO de Driving avec deux couleurs différentes pour identifier l’état actif ou non du bouton sur le TCO physique. Ceci rejoint le point suivant.
2. Utilisation des voyants témoins et boutons sur le TCO de Driving.
Voyants :
L’esthétique devrait être revue afin que cela soit le centre du bouton et non son contour qui se colore lors de l’activation.
Boutons :
Il devrait être pris modèle sur les voyants afin de visualiser l’état d un bouton par une distinction au niveau des couleurs si actif ou inactif dans le centre même du bouton.
3. Problèmes logiciels détectés : « BUG » ?
Le montage du réseau a permis de réaliser des tests assez poussés du fonctionnement de l’installation. Au cours de ces tests plusieurs « bugs » me sont apparus :
Commutateurs booléens :
L’utilisation de ceux-ci ne pose pas de problème à la condition de n’utiliser qu’un seul type d’opérateur dans l’événement. En effet le mélange de conditions de types ET et OU donne des résultats spectaculairement aléatoires et peu conforme à l’effet recherché. Cela me fait penser à un possible mauvais placement de parenthèses dans une opération incluant somme et multiplication :
(a+b) x2 = 2a+2b
alors que
a+bx2= a+2b !!!
Il apparaît donc qu il faille revoir la copie sur ce point…. Et/ou permettre de gérer le placement de «parenthèses » pour borner les boucles ET/OU.
La solution de contournement passe par la création de variable et des recombinaisons complexes…
4. Nouvelles fonctionnalités envisageables :
Un nouvel « opérateur booléen » pourrait être implémenté dans le logiciel. Il s’agit de l’opérateur SINON. (Sauf si)
Cette condition ouvrirait la porte à de nouveau type de programmation des événements de manière souple, simple et efficace. Plusieurs formes sont envisageables :
Type a :
Conditions d’activation … [1 à 6 possibles]
Action à réaliser… [1 ou 2 possibles]
SINON
Conditions d’activation… [1 à 6 possibles]
Action à réaliser… [1ou 2 possibles]
Ce qui peut aussi se vérifier avec l’utilisation de variables afin d’obtenir ceci :
• dans un événement N° 1 des conditions d’activation créent la variable X. (action variable X marche/arrêt)
• dans un événement N° 2 des conditions d’activation créent la variable Y. (action variable Y marche/arrêt)
• dans un événement N°3 on aurait une structure de ce type :
o conditions d’activation : variable X
o action à réaliser A
SINON
o conditions d’activation : variable Y
o action à réaliser B.
L’exemple concret consiste à remplacer par exemple dans le cas précèdent :
• variable X par : détection globale sur canton 12
• variable Y par : détection globale sur canton 12 avec case inverse cochée (équivaut à pas de détection sur le canton 12)
• action A : activer MOOUT n°xxx1 sortie 4 marche/arrêt
• action B : activer MOAFF n°xxx3 sortie 5 marche/arrêt
On crée ainsi une bascule. Ainsi si on a sur les sorties du MOOUT n°xxx1 à la sortie 4 au MOAFF sur la sortie 5 respectivement une lampe rouge et verte on obtient :
Allumage de la rouge et extinction de la verte et réciproquement, extinction de la rouge et allumage de la verte.
Le choix de la condition SINON et de la condition ET ouvre des combinaisons sur les actions en sortie.
L’opérateur OU est supprimé des choix disponibles pour cet événement car sans intérêt dans le cas du recours au booléen SINON.
L’apparition du type variable implique l’apparition du cadre description pour expliquer brièvement la variable. (Ici en encadré rouge) Avec plus de 15 caractères pour décrire ! 256 semble être un minimum…
Type b :
La gestion des événements pourrait également avoir une structure de ce type :
Conditions d’activation… [1 à 6 possibles]
Action à réaliser… [1 ou 2 possibles]
SINON
Action à réaliser … [1 ou 2 possibles]
On retrouve ici la bascule gérée plus simplement encore si nécessaire que précédemment.
Comme vous pouvez le remarquer l’introduction de l’opérateur SINON aurait pour but de permettre une programmation événementielle plus souple et plus vaste… (Itinéraires sur événements pour dépassement de convois, extinction d’une lampe et allumage simultanée d’une autre…)
Conclusion :
Bien entendu il ne s’agit ici que de pistes de travail mais qui conduirait sans aucun doute à plus de souplesse dans la mise en œuvre et conférerait plus de possibilités au logiciel et à ses composants dans leur fonctionnement et leur interaction…
Laurent
Connexion pour participer à la conversation.
- Maxime
- Visiteur
il y a 14 ans 4 mois #2063 par Maxime
Réponse de Maxime sur le sujet Re:DEMANDE DE MODIFICATION - LOGICIEL DRIVING RAILWAY
Un petit truc qui me chiffonne:
Alors que DR enregistre toutes les modifications en temps réel en phase conception pourquoi en mode exploitation n'est il pas possible de créer un évènement ? Un peu pénible de voyager entre les modes conception et exploitation pour développer un évènement.
Peut être une idée d'amélioration non ?
Alors que DR enregistre toutes les modifications en temps réel en phase conception pourquoi en mode exploitation n'est il pas possible de créer un évènement ? Un peu pénible de voyager entre les modes conception et exploitation pour développer un évènement.
Peut être une idée d'amélioration non ?
Connexion pour participer à la conversation.
- jack84
- Visiteur
il y a 14 ans 3 mois #2162 par jack84
Réponse de jack84 sur le sujet Re:DEMANDE DE MODIFICATION - LOGICIEL DRIVING RAILWAY
Voici le message que j'ai adressé à Mme TRONCHET (Pegase Informatique) :
Bonjour Chère Madame,
je vous confirme la teneur de mon appel téléphonique de ce matin :
Je suis très heureux que la gestion du croisement sous D.R. soit résolue sur mon réseau armoire. J'ai modifié à la fois le câblage du relais de commande et le paramétrage de D.R.
En pièce jointe le fichier DAT à jour.
Toutefois, il est quand même regrettable qu'il ait fallu l'intervention de Laurent ROEKENS (un de vos clients), alors que je suis en rade depuis 8 mois, entre-autre parce que le branchement d'un croisement ne figure pas dans vos notices et que vous n'avez pas eu 1/4h pour m'envoyer le schéma! Je sais que vous n'êtes pas obligée... Mais ce n'est pas sympa de m'avoir fait poireauter si longtemps.
D'autre part, lors de notre prochaine conversation, ne me soutenez plus que "ça ne peut pas marcher" avant que j'essaye la nouvelle suggestion : c'est fort déstabilisant et en voici un démenti flagrant.
Cela dit, je ne vous en veux pas, ce n'est qu'un hobby, de plus vous êtes toujours disponible et à l'écoute de vos clients. Par contre, peut-être y'a t'il un axe à améliorer, dans l'avenir?
Quoiqu'il en soit et fort de cette seconde expérience, je profite de ce message pour vous informer que nous allons développer, avec le Gruyère Rail Club (un autre de vos clients), une banque commune de données relative à D.R., afin de minimiser ces désagréments à tous vos clients actuels et futurs.
Vous devriez en être largement bénéficiaire, tant par la pub induite, que par la diminution du temps passé au téléphone en SAV.
Très cordialement,
Jacques MICHEL
Bonjour Chère Madame,
je vous confirme la teneur de mon appel téléphonique de ce matin :
Je suis très heureux que la gestion du croisement sous D.R. soit résolue sur mon réseau armoire. J'ai modifié à la fois le câblage du relais de commande et le paramétrage de D.R.
En pièce jointe le fichier DAT à jour.
Toutefois, il est quand même regrettable qu'il ait fallu l'intervention de Laurent ROEKENS (un de vos clients), alors que je suis en rade depuis 8 mois, entre-autre parce que le branchement d'un croisement ne figure pas dans vos notices et que vous n'avez pas eu 1/4h pour m'envoyer le schéma! Je sais que vous n'êtes pas obligée... Mais ce n'est pas sympa de m'avoir fait poireauter si longtemps.
D'autre part, lors de notre prochaine conversation, ne me soutenez plus que "ça ne peut pas marcher" avant que j'essaye la nouvelle suggestion : c'est fort déstabilisant et en voici un démenti flagrant.
Cela dit, je ne vous en veux pas, ce n'est qu'un hobby, de plus vous êtes toujours disponible et à l'écoute de vos clients. Par contre, peut-être y'a t'il un axe à améliorer, dans l'avenir?
Quoiqu'il en soit et fort de cette seconde expérience, je profite de ce message pour vous informer que nous allons développer, avec le Gruyère Rail Club (un autre de vos clients), une banque commune de données relative à D.R., afin de minimiser ces désagréments à tous vos clients actuels et futurs.
Vous devriez en être largement bénéficiaire, tant par la pub induite, que par la diminution du temps passé au téléphone en SAV.
Très cordialement,
Jacques MICHEL
Connexion pour participer à la conversation.
- jack84
- Visiteur
il y a 14 ans 3 mois #2194 par jack84
Réponse de jack84 sur le sujet Re:DEMANDE DE MODIFICATION - LOGICIEL DRIVING RAILWAY
Voilà texto la réponse par mel de Monsieur TRONCHET lui-même :
"Je vous signale que le branchement fait fonctionne mais que si vous avez un train qui circule du canton 6 vers le canton 22, il faudra que le canton 22 soit libre (ou que le train s'arrête) pour que vous puissiez changer le croissement et faire passer un train du canton 21 vers 15 par exemple. En mettant un canton sans za pour les deux branches du croisement, dans que le train libère physiquement le croisement, il est possible de modifier sa position (après le délai de fin de détection bien sur).
Je suis sidéré... Il y a un problème de communication!
"Je vous signale que le branchement fait fonctionne mais que si vous avez un train qui circule du canton 6 vers le canton 22, il faudra que le canton 22 soit libre (ou que le train s'arrête) pour que vous puissiez changer le croissement et faire passer un train du canton 21 vers 15 par exemple. En mettant un canton sans za pour les deux branches du croisement, dans que le train libère physiquement le croisement, il est possible de modifier sa position (après le délai de fin de détection bien sur).
Je suis sidéré... Il y a un problème de communication!
Connexion pour participer à la conversation.
- laurentr
- Hors Ligne
- Banni
Réduire Plus d'informations
- Messages : 271
- Remerciements reçus 33
il y a 14 ans 3 mois #2196 par laurentr
Réponse de laurentr sur le sujet Re:DEMANDE DE MODIFICATION - LOGICIEL DRIVING RAILWAY
Bonsoir
La remarque formulée est judicieuse et va vers une plus grande souplesse à l'utilisation via un canton sans ZA par branche du croisement. Le câblage du cœur dans ce cas reste identique à la seule différence que pour les commutations on aura aux bornes des entrées les alim des cantons sans ZA pour chaque branches respectives.
Cependant il est à noter que comme je te l'ai déjà indiqué il n'y a pas une seule et unique façon de faire...
Pour ma part je prolonge toujours au-delà du croisement dans chaque direction un canton sans ZA de manière a avoir également une zone de taille significative pour la détection... ainsi on optimise la fluidité, les changements possibles d'itinéraires... etc
Tout cela est bien sur déterminé en fonction du résultat que l'on souhaite observer...
Cdt
Laurent
La remarque formulée est judicieuse et va vers une plus grande souplesse à l'utilisation via un canton sans ZA par branche du croisement. Le câblage du cœur dans ce cas reste identique à la seule différence que pour les commutations on aura aux bornes des entrées les alim des cantons sans ZA pour chaque branches respectives.
Cependant il est à noter que comme je te l'ai déjà indiqué il n'y a pas une seule et unique façon de faire...
Pour ma part je prolonge toujours au-delà du croisement dans chaque direction un canton sans ZA de manière a avoir également une zone de taille significative pour la détection... ainsi on optimise la fluidité, les changements possibles d'itinéraires... etc
Tout cela est bien sur déterminé en fonction du résultat que l'on souhaite observer...
Cdt
Laurent
Connexion pour participer à la conversation.
- jack84
- Visiteur
il y a 14 ans 3 mois #2205 par jack84
Réponse de jack84 sur le sujet Re:DEMANDE DE MODIFICATION - LOGICIEL DRIVING RAILWAY
Merci Laurent pour l'explication de texte!
Sauf que 2 cantons sans ZA pour un croisement, cela ajoute encore un module MOHFA ou MOCANA dans les boîtiers...
Pas négligeable en coût, je préfère la solution que tu m'as apportée sur le réseau armoire.
Sauf que 2 cantons sans ZA pour un croisement, cela ajoute encore un module MOHFA ou MOCANA dans les boîtiers...
Pas négligeable en coût, je préfère la solution que tu m'as apportée sur le réseau armoire.
Connexion pour participer à la conversation.
Calendrier du club
Lun | Mar | Mer | Jeu | Ven | Sam | Dim |
---|---|---|---|---|---|---|
1 | 2 | 4 | 5 | 6 | 7 | |
8 | 9 | 11 | 12 | 13 | 14 | |
15 | 16 | 18 | 19 | 20 | 21 | |
22 | 23 | 25 | 26 | 27 | 28 | |
29 | 30 |