RAILROAD TRAIN CONTROLLER

Logiciels d'ordinateur
21

pappy-Märklin a écrit :
Windigital est un WDGP avec possibilité de creer ses propres macros avec un langage genre “basic”. Le langage “PAPS” a l’air sympa.
Mais je crois bien que Windigital ne permet pas de se connecter en TCP/IP via une CS. Uniquement RS232 avec 6051 ???
De toute manière, il semble qu’il n’y a plus de suivi depuis que Märklin l’a retiré de son catalogue, depuis qq temps.
A moins que Abbink Software continue seul dans son coin. En cherchant sur internet, il semblerait qu’il existe une version pour Mac OS X…

Daniel (DJ) :wink:)

22

Mais je crois bien que Windigital ne permet pas de se connecter en TCP/IP via une CS. Uniquement RS232 avec 6051 ???
Je sais que je suis vieux, que je ne connais plus rien, … Mais qu’est ce que lis là, la CS se connecte en TCP/IP !!!

Le TCP/IP est très bien pour recharger une nouvelle version de logiciel dans la CS, mais ce n’est pas un protocole adapté pour la relier à un PC destiné à faire de la commande :no:

Le TCP/IP est un protocole dont le temps de réponse n’est pas garanti et n’est pas vérifié, il n’a jamais été conçu pour faire des échanges “temps réel”.

Pour remplacer le RS232, on utilise aujourd’hui du IEEE 1394 ou de l’USB qui sont des protocoles dont on connait à l’avance les temps de réponse, on utilise pas du TCP/IP.

Allez, le vieux grincheux retourne à sa quincaillerie :laughing:

Bonne journée :sunny:

J.L.

23

ta_prohm a écrit :
Le TCP/IP est un protocole dont le temps de réponse n’est pas garanti et n’est pas vérifié, il n’a jamais été conçu pour faire des échanges “temps réel”.Que tu le veuilles ou pas, que ça te plaise ou pas, c’est comme ça.
Le PC donne ses instructions à la CS. La CS les exécute et je présume qu’il y a des “time-out” si la CS ne répond pas dans les délais…
C’est largement suffisant et ça marche très bien. Nettement mieux qu’en RS232 à 2400 bauds (6051), voir 9600 pour les + perfectionnés (IB) !
Et c’est pour ça que LDT a fait comme Ducros avec le HSI-88 via RS et maintenant USB.

On ne contrôle pas un process de cracking ! :laughing:

Daniel (DJ) :slight_smile:)

24

On ne contrôle pas un process de cracking ! :laughing:
Ah bon !!

Compte tenu de la débauche de matériel utilisé, je pensais qu’on faisait voler un A380 :laughing: :laughing:

Bonne journée :sunny:

J.L.

25

Bonjour à tous,

Les adresses decalées: un feu trois positions utilisera par exemple l’adresse 15 rouge, 15vert, et…
Avec RRTC 16rouge obligatoirement, avec WDGP n’importe laquelle, comme par exemple un canal laissé libre par un deteleur!.

La liaison PC/reseau: une interface est necessaire, mais qu’elle soit RS machin ou TC truc, si la moindre surcharge réseau apparait, la centrale s’ecroule voire disjoncte et n’a plus assez d’energie pour gerer l’arrivée des infos PC. Et puis apres c’est la loterie, infos recues, oui ou non, bonnes ou mauvaises ??? J’ai chercher longtemps pourquoi mon programme buggait tjrs au meme endroit??? Ma BR53 avec ses gros boudins faisait un court circuit tres partiel à chaque passage d’essieu, et j’ai été obligé de limer un picot de l’aiguille en cause (j’ai joué de l’oscillo pour decouvrir ce pb!!!). Depus, plus aucun pb avec une bonne vieille RS232 à 9600bds (intellibox). La haute technologie n’eliminera jamais les problemes de base que l’on oublie trop facilement.

Bon train à tous
happy marklin

26

pappy_marklin a écrit :
La liaison PC/reseau: une interface est necessaire, mais qu’elle soit RS machin ou TC truc, si la moindre surcharge réseau apparait, la centrale s’ecroule voire disjoncte et n’a plus assez d’energie pour gerer l’arrivée des infos PC.Il semblerait, d’après certains utilisateurs, que l’ECos d’ESU se mette à “pédaler dans la choucroute” dès qu’elle est obligée de gérer à la fois qq locos et un bus s88 un peu chargé (2 à 3 zones par canton remontant sur le bus s88).
Donc, la CS1, cousine directe, doit présenter les mêmes symptômes…

Les mêmes utilisateurs préconisent d’utiliser un HSI-88 de LDT pour “soulager” la centrale de la gestion du bus s88 (en USB ou RS machin).

Cordialement,

27

pappy_marklin a écrit :
La liaison PC/reseau: une interface est necessaire, mais qu’elle soit RS machin ou TC truc, si la moindre surcharge réseau apparait, la centrale s’ecroule voire disjoncte et n’a plus assez d’energie pour gerer l’arrivée des infos PC.Il semblerait, d’après certains utilisateurs, que l’ECos d’ESU se mette à “pédaler dans la choucroute” dès qu’elle est obligée de gérer à la fois qq locos et un bus s88 un peu chargé (2 à 3 zones par canton remontant sur le bus s88).
Donc, la CS1, cousine directe, doit présenter les mêmes symptômes…

Les mêmes utilisateurs préconisent d’utiliser un HSI-88 de LDT pour “soulager” la centrale de la gestion du bus s88 (en USB ou RS machin).

Cordialement,
Bonjour Patrick et Daniel, :laughing:

Cela me réconforte et m’encourage à continuer mon petit travail de bidouilleur du dimanche. Toute cette discussion est très, très intéressante, elle me permet de prendre en compte des éléments que je ne soupçonnais pas au départ.

Il faut savoir que le protocole Motorola 2 demande, suivant le réglage des temps de pause choisis (SW3 sur une 6021), de 160,8 à 224,8 millisecondes pour envoyer une commande complète à une loco, presque 1/4 de seconde pour une seule petite loco :laughing: :laughing:

Si on rajoute le temps pour les commandes d’appareils de voie, le temps pour la rétrosignalisation mfx, le temps pour gérer le bus S88, le temps de communication avec un PC via un protocole TCP/IP et qu’on programme tout ça sur un système Linux sans savoir gérer des interruptions, je n’ai pas besoin d’un petit dessin pour imaginer le résultat.

Quand je vois que sur une CS ou une MS, ils ne sont même pas foutus de suivre le bouton rouge si l’utilisateur le tourne un peu vite, on peut imaginer que le reste est fait de la même façon.

Heureusement pour Märklin et les autres, la majorité des gens sont contents quand ils font rouler 5 trains à la fois :laughing:

Comme dit Daniel: “On ne contrôle pas un process de cracking !”
Mais je constate qu’on a quand même besoin d’une petite usine à gaz: un PC, une CS, une interface S88 additionnelle, des boosters, des transformateurs, …
Qu’est ce que j’oublie encore? :scratch: :study:

C’est bien finalement, cela fait marcher le commerce et pendant que les gens cherchent à faire fonctionner tout ça, on a le temps de mettre une autre nouveauté sur le marché :laughing:

Bonne journée. :sunny:

28

Qu’est ce que j’oublie encore? :scratch: :study:
Un HSi-88 pour la rétrosignalisation :smiling_imp: :smiling_imp: sinon…Bug :bom: ,Bug :bom: ,Bug :bom:

A+,
Amitiés :sunny: ,
Christian

29

ta_prohm a écrit :
Si on rajoute le temps pour les commandes d’appareils de voie, le temps pour la rétrosignalisation mfx, le temps pour gérer le bus S88, le temps de communication avec un PC via un protocole TCP/IP et qu’on programme tout ça sur un système Linux sans savoir gérer des interruptions, je n’ai pas besoin d’un petit dessin pour imaginer le résultat.C’est peut-être bien pour ça que Märklin préconise une pause entre deux activations successives d’éléments électromagnétiques dans un route. Je cite :
4.5.1.1.2 Cadence
Lors de la commutation de la route, la Central Station transmet les différents ordres aux articles électromagnétiques concernés de manière séquentielle. Si vous le souhaitez, la cadence établit alors une pause entre les différents ordres de commutation. Les articles électromagnétiques dont la consommation de courant est particulièrement élevée représentent parfois une telle charge pour la tension d’alimentation qu’une pause s’avère judicieuse et permet d’assurer le bon fonctionnement du réseau.
La valeur par défaut proposée par Märklin est de 500ms…

on programme tout ça sur un système Linux sans savoir gérer des interruptionsSi le processeur est suffisament rapide pour pallier au manque d’interruption, ça peut se concevoir. Fallait bien faire comme ça dans le temps, quand il n’y avait pas de “stack” ! (DEC PDP-8 une interruption, R2E S80 PAS d’interruption du tout !)
Mais avec le proc. utilisé (y doit pas être bien rapide) + la “consommation” du système, (au fait, Jean-Louis, es-tu sûr de Linux sur la CS1 ?), ça doit se rapprocher de la vitesse de la “brouette”, sinon de celle de l’“escargot”…

Enfin, faut faire avec ! Mais j’aimerais bien que des possesseurs de “grands réseaux” témoignent. Et j’hésite à utiliser une 2ème centrale pour ma gare terminus ou la caténaire…

Daniel (DJ) :wink:)

30

C’est peut-être bien pour ça que Märklin préconise une pause entre deux activations successives d’éléments électromagnétiques dans un route.
Non, c’est simplement pour que les condos de filtrage de l’alim aient le temps de se recharger et éviter des chutes de tension trop importantes.

Ce que je trouve aberrant, c’est que les commandes envoyées aux aiguillages fonctionnent sur une fréquence double de celles envoyées aux locos, donc le message passe deux fois plus vite et comme le message est 8 fois plus court, il faut 16 fois moins de temps.
Cela aurait été plus judicieux de faire l’inverse et de faire fonctionner les locos sur la fréquence des aiguillages et les aiguillages sur celle des locos. Encore un mystère :laughing:

Si le processeur est suffisament rapide pour pallier au manque d’interruption
Même avec un proc rapide, si on programme comme un gland et qu’on met des wait () un peu partout pour attendre que Pierre ou Paul ait fini de faire quelque chose, on attendra toujours le plus lent; un processeur rapide n’est pas toujours la solution au problème :laughing:

La preuve: même avec un processeur à 4 Core cadencé à 3,3 GHz avec 8Gb de RAM, Vista ne va pas beaucoup plus vite que Win95 sur un Pentium à 150 MHz avec 4Mb de RAM pour faire pas grand chose de plus.

Bonne soirée :drunken:

31

ta_prohm a écrit :
même avec un processeur à 4 Core cadencé à 3,3 GHz avec 8Gb de RAM, Vista ne va pas beaucoup plus vite que Win95 sur un Pentium à 150 MHz avec 4Mb de RAM pour faire pas grand chose de plus.Oui, Jean-Louis ! Mais, c’est PetitMou ! Il faut éliminer les exceptions ! :laughing: :laughing: :laughing: :laughing: :laughing:

Daniel (DJ) :wink:) :drunken:

32

Bonjour à toutes :wink: et à tous :smiley: ,

Suite à mes nombreuses lectures sur le sujet et les expériences des utilisateurs de RRTC, il appert que la CS1 (tout comme l’ECOS) est une peu “courte” au niveau rétrosignalisation et qu’il est fortement recommandé d’y adjoindre un HSI-88.
L’utilisation du HSI-88 pose-t-elle problème ou apporte-t-elle vraiment un plus?

A+,
Amitiés :sunny: ,
Christian

33

Ma config est un peu différente, 6021 + interface, et j’ai été obligé d’ajouter un HSI88 car la 6021 était complètement à la traine au niveau rétro. Depuis aucun problème à signaler avec 20 trains sous dispacher dont 7 à 9 en circulation, une 40aine d’aiguillages et une 60aine de cantons.

Sur le forum RRTC des pb similaires ont été mentionnés par des propriétaires d’Ecos et résolus par l’ajout d’un HSI88. L’Ecos et la cs1 étant plutôt semblables, il y a de fortes chances que la solution fonctionne aussi.

34

Le pb. peut aussi tout à fait venir de RRTC si le logiciel gérer mal les ressources de la console (CS ou Ecos).

Car il n’y a pas de pb. de lecture du bus s88 au niveau de la CS, la remontée des ports des 6080, 5217 ou 5233 s’effectuant correctement.

Le pb. peut donc venir du processus de lecture lancé par RRTC (trop rapide, trop fréquent, mal documenté, …), tâche que la CS ne juge pas prioritaire !

Daniel (DJ) :slight_smile:)

35

Bonjour,

Je viens juste de finir ma bidouille pour piloter les locos et les appareils de voie directement par le PC; comme cela marche bien je voudrais y rajouter un bus S88 :laughing: :laughing:

Je commence donc à regarder dans le détail comment cela fonctionne et je me pose des questions :question: :question: :question:

90% de l’électronique du S88 est là pour mémoriser des évènements fugitifs jusqu’à ce que l’instrument qui le gère les lise et fasse une remise à zéro.
On peut effectivement capturer des contacts longs mais c’est utilisé les 10% restants :no:

Cela me paraît inutilement compliqué, contraignant, onéreux et plus sensibles aux parasites que quelque chose qui serait conçu pour capturer des contacts longs.

Je pense donc que je passe à côté de quelque chose que je ne vois pas … Si quelqu’un peut m’éclairer …

Qui a t-il d’autre que le S88?

Bonne soirée :sunny:

36

Prenons une voie de contact et posons un vagon dessus.

Tu verras que le contact n’est pas parfait, loin de là ! Etonnant mais vrai…
D’ailleurs, pourquoi fait-on du trois rails et pourquoi les deuxraillistes passent-ils leur temps à astiquer leur voie ?

Il faut donc que le s88 “absorbe” les faux contacts, dans le cas de la détection par voie de contact.

Daniel (DJ) :wink:)

37

Prenons une voie de contact et posons un vagon dessus.

Tu verras que le contact n’est pas parfait, loin de là ! Etonnant mais vrai…
D’ailleurs, pourquoi fait-on du trois rails et pourquoi les deuxraillistes passent-ils leur temps à astiquer leur voie ?

Il faut donc que le s88 “absorbe” les faux contacts, dans le cas de la détection par voie de contact.

Daniel (DJ) :wink:)
OK, mais de là à utiliser des mémoires et des registres à décalage, c’est vraiment sortir la grosse artillerie pour tuer (je suis poli :laughing: ) des mouches

Les contacts ne sont pas aussi désastreux que ce que tu dis, comment ferait un Kof pour fonctionner sur une voie K dont un seul rail est à la masse?

Même les BB avec leur 4 essieux bandagés devraient mal fonctionner, je n’ai jamais rien remarqué dans ce sens.

Au fait au cas où cela serait utile à certains, j’ai une BB9200 digitalisée qui fonctionnait très mal, aujourd’hui je me suis attaqué au problème et j’ai rajouté une rondelle ressort (venant d’une BB26000) entre le bogie et le châssis et le problème est complètement résolu :laughing: …

Bonne soirée :sleep:

38

ta_prohm a écrit :
Même les BB avec leur 4 essieux bandagés devraient mal fonctionner, je n’ai jamais rien remarqué dans ce sens.
Mes quatre BB 9200 (1 mfx et 3 digitales Tams) circulent mal sur les voies de contact. Si tu leur rajoutes 2 ou 3 vagons Märklin à 2 essieux non isolés, le pb. est résolu. Je n’ai pas ce pb. avec une 26000 et une 7200 Märklin (Tams et Uhlenbrock respectivement). Ni avec la 27000 Mehano, la 65500 Electrotren et la 68500 Roco…

Par ailleurs, j’ai effectué des essais en connectant des relais 12V CC entre les deux rails. Tu t’aperçois que les relais “cafouillent”. Il faut rajouter une 1000µ aux bornes des relais pour résoudre le pb.

Pour moi, il y a donc un pb. de contact.

Daniel (DJ) :slight_smile:)

39

Mes quatre BB 9200 (1 mfx et 3 digitales Tams) circulent mal sur les voies de contact.
Les miennes aussi, mais il n’y a pas qu’un problème de contacts entre les roues et les rails, c’est surtout un problème de contact entre le bogie et le châssis. Il suffit de dévisser le bogie et de rajouter une rondelle ref 401640 de chez Märklin et tes BB9200 fonctionneront comme tes BB26000 :laughing: :laughing:

Quant au S88 pour résoudre ces problèmes, cela ne me paraît pas être une solution très astucieuse (avis tout personnel!!) car chaque faux contact est interprété comme un évènement et nécessite donc un flux d’informations dans le bus et un traitement de la part du calculo !!! Rien de surprenant dans ce cas qu’il y ait surcharge soit du bus, soit de la centrale, soit du calculo.

Enfin une fois de plus, c’est mon point de vue personnel.

Bonne journée :sunny:

40

Bonsoir Jean-Louis

je me demande si tout ce système monté dans les S88 ne soit en relation avec le programe pc de Marklin qui te permet de définir même sur un rail-pédale ou un ils soit un contact temporisé soit un contact permanent !

A+ Andec