Bonjour,

CAtrain fonctionne relativement bien sur mon circuit avec un train. Dès que j'en mets deux, j'ai des fonctionnements corrects pendant un certain temps, et d'un seul coup, il arrive qu'un convoi dépasse un canton sans que Catrain le voit (le train virtuel reste coincé sur la fin du canton précedent.

Si je m'en aperçois à temps j'arrive à relancer le train coincé en cliquant dessus mais la plupart du temps je ne suis pas le nez sur le synop, donc cela se termine en catastrophe ferroviaire. Est que le proecesseur part dans des boucvles et qu'il ne voit pas l'évenement ? c'est possible mais j'ai donc voulu investiguer et j'ai vu qu'il y avait le mode trace. Je l'ai mis (même si je sais que les traces chargent encore plus le CPU, et en regardant rapidement, je vouis des erreurs dont j'aimerais bien avoir une explication (même si je pense qu'elles n'ont rien à voir avec mon problème):

par exemple un bloc de 4 lignessur l'adresse 198 (alors que je n'ai rien à cette adresse):

Must check BrdID at address 198 for possible pulsed outputs
AVERTISSEMENT: pas de réponse à l'adr. 198 sur le bus 1
AVERTISSEMENT: Time-Out USB
Error -103 when retrieving Presence table

Pouvez vous m'aider ?
rémy

Bonjour Rémy,

comme vous le dites, le phénomène vient certainement du fait que le processeur a "loupé" la notification de détection d'entrée du train sur le tronçon suivant. Cet évènement est fourni par le module PWM concerné.
Mettre en route et examiner les traces est bien ce qu'il faut faire. (La surcharge est négligeable pour un PC actuel).
Les erreurs que vous constatez ne sont pas graves si elles se produisent au démarrage. A ce moment le trafic (de données) est maximal. Ce qui serait intéressant serait de d'arrêter immédiatement le trafic (ferroviaire) lorsque le problème se produit et examiner la fin des traces (juste avant les ordres d'arrêt) pour voir si le module PWM a bien transmis l'info, ou si l'évènement est manquant, ou s'il y a eu une erreur de communication USB. Je sais que ce n'est pas facile, moi-même j'ai oublié le formalisme de ces traces...
Si vous disposez encore d'une ancienne machine sous XP, il serait intéressant de voir si le phénomène se produit avec cette configuration.

Cordialement,

Joël

Bonsoir, joel
Merci de votre reponse. Le pc que j'utilise actuellement est un pc sous xp qui ne fait que cela. Je l'ai entierement desarmé.

Je me demande vraiment pourquoi catrain interroge cette adresse 198.
Parfois j'ai aussi des time out usb sur le bus 1 : est ce que les bus sont notés 0 et 1 ou 1 et 2 ? Sur mon installation je n'ai mis qu'un bus car je nai que 5 cartes pwm ( 0 à 20) , 4 cartes device doubles (16 aiguillages), une carte device configurée en simple pour 8 signaux et une carte detecteur pour mes 8 boutons poussoir.
Je pense qu'un bus suffit ?

Comment le pic 2550 sait il s'il y a un bus ou deux ?

Je m'en pose des questions......

Je vais essayer de mettre une VM et catrain sous XP sur un pc super puissant (un i7) pour voir si j'ai de meilleurs resultats.

A bientot

Remy

Bonjour Remy,

5 cartes PWM et 1 carte détecteur sur un même bus ça fait quand même beaucoup. Cela expliquerait les time-outs. Electriquement ce n'est pas un problème, mais le cela représente quand même une charge de scrutation assez importante, donc un trafic de données important sur le bus. Je n'en ai pas autant sur mon réseau et je ne me rappelle plus quelle est la limite pratique. Peut-être d'autres utilisateurs ayant un grand réseau pourraient avoir une idée. Les cartes "devices" ne représentent pas une charge logicielle importante car elle ne sont pas scrutées. Vous pourriez essayer avec deux bus en mettant 3 cartes PWM sur un bus et 2 cartes PWM plus la carte détecteur sur l'autre, l'ajout est peu coûteux.
Si je me rappelle bien, à la mise sous tension le 2550 scrute la présence de modules à toutes les adresses sur les deux bus et crée une table avec ce qu'il a trouvé. Comme cela, il sait quoi scruter et sur quel bus il faut transmettre une commande.
Je ne crois pas que le changement de PC améliorera les choses. J'utilise aussi un XP pour piloter mon réseau. Je n'avais essayé un PC sous Windows 7 qu'à titre expérimental...

Cordialement,

Joël

Merci Joël de ces informations précieuses.
Je vais vite câbler le deuxième bus sur ma carte USB et répartir les cartes PWM sur les deux bus.
J'ai sans aucun doute un problème de temps réel car mon réseau est finalement assez petit (2m x 1,2m avec deux réseaux principaux + une gare cachée de 1,50m et 8 voies en extension d'où les trains vont se garer et ressortent en marche arrière). les cantons sont courts et de ce fait le trafic d'entrée et sortie des cantons est sans doute très soutenu.
J'ai ainsi détecté en analysant les traces des pertes de pédale avec un train qui quitte un canton pour rentrer dans un canton qui n'est pas contigu (une autre voie parallèle), puis qui revient dur le canton initial, etc...

je vais mettre les PWM d'un des deux réseaux sur un bus et les autres PWM sur l'autre bus (avec la gare cachée qui elle n'est pas sollicitée très souvent).



je me suis offert un petit analyseur de réseau boucle de courant avec horodatage des trames et je vais descendre au niveau des trames pour analyser plus en détail le trafic. En tout cas, si je ne vois pas mes trains bien fonctionner actuellement, en échange ce travail de spéléologie est passionnant. En espérant bien entendu que je vais réussir à mettre tout cela au point.

J'ai essayé avec Une VM Windows XP sur un PC costaud : l'initialisation est bien plus rapide, mais j'ai eu les mêmes type de problèmes dans le fonctionnement.

Juste une question : serait il utile de souder une résistance au bout du bus ? je crois que celà se fait sur les réseaux RS485 dans l'industrie pour stabiliser le réseau.

A bientôt

rémy

Rebonjour, Joël

En réfléchissant je me rappelle que j'ai aussi des ratés sur la carte détection (il faut parfois appuyer plusieurs fois sur le même poussoir pour qu'il soit pris en compte), ce qui militerait bien vers un problème de surcharge.

Je vous tiens au courant

Rémy

Bonjour à tous.

Mon réseau H0 utilisait 10 modules PWM, 10 modules accessoires et 2 modules détecteurs. La carte USB n'avait qu'une sortie et tout fonctionnait parfaitement. Joël a développé les cartes USB lorsque Windows XP est arrivé et à l'époque une sortie USB paraissait suffisante pour 20 à 25 modules.

Cela ne résout pas le problème de Rémy, mais je donne mon expérience....

Cordialement,

François

Bonjour Rémy,

comme François nous informe que tout fonctionne bien avec 20 modules connectés sur un même Bus, pas sûr que doubler le bus résoudra vos problèmes...
Reste peut-être le problème des coupleurs optiques, rencontré par beaucoup d'utilisateurs.
La dispersion des caractéristiques des coupleurs vendus "en vrac", est telle que leur gain varie d'un facteur 5, voire plus.
Pour voir si le problème vient de la qualité des signaux électriques. Le plus simple est de charger le bus au maximum et voir ci le problème s'accentue (ou disparait... on ne sait jamais!).
Une résistance de 1K représente la charge électrique de 10 modules. Essayez peut-être des valeurs de 4K7 à 10K. Un utilisateur m'a dit également avoir résolu ses problèmes en remplaçant le TL084 par un LM324, mais je n'ai jamais essayé...

Cordialement,

Joël

Merci François, et Joël pour votre aide.

Je suis un peu circonspect par rapport à tout cela : je pense que j'ai effectivement deux problèmes : un au niveau du réseau des cartes, et peut être un autre au niveau de mon tci.

Les problèmes au niveau du réseau, je vais essayer de vérifier les caractéristiques des opto coupleurs, mais avant tout, je vais modifier le paramètre de CATRAIN (de 1 à 5) et voir si j'ai des résultats (je n'ai pas encore pensé à lui !). je vais recâbler ma liaison avec du câble blindé, je vais mettre une resistance, et je vais espionner avec mon analyseur "boucle de courant".

Par contre je ne m'explique pas certains disfonctionnements qui me semblent plutôt venir du PC et de Catrain (ce qui est present sur les traces) :
1/ le fait que catrain recherche un device à l'adresse 198 alors que je n'y ai rien :
2/ autre disfonctionnement : Sur un block bien précis, les trains s'arrêtent au milieu, grognent puis repartent. Apparement d'après les traces, c'est bien CA Train qui impose cet arrêt et redemarrage. d'ailleurs, l'utilisation de ce block via Modparam est impecable.

Je continue à chercher, et je vous tiendrai au courant.

Rémy

"2/ autre dysfonctionnement : Sur un block bien précis, les trains s'arrêtent au milieu, grognent puis repartent. Apparemment d'après les traces, c'est bien CA Train qui impose cet arrêt et redémarrage. d'ailleurs, l'utilisation de ce block via Modparam est impeccable."

Bonjour,

Je rencontre également cette anomalie sur mon réseau "Z", ce que je n'avais pas sur le réseau "H0". Par endroits la loco s'immobilise 3 secondes puis repart. Contrairement à Rémy, la loco ne grogne pas, mais le grognement vient de moi lorsque ça se passe ! ! !

Trêve de plaisanterie, je rencontre aussi d'autres anomalies, mais je suis tellement peu sur le réseau, et comme je n'ai pas encore réglé correctement tous les paramètres pour l'adaptation correcte entre les trains virtuels et réels, je ne mets pas en cause le logiciel qui fonctionnait très bien en H0.

Cordialement,

François

Bonjour Rémy,

1/ le fait que catrain recherche un device à l'adresse 198 alors que je n'y ai rien :
==> êtes-vous sûr qu'il n'y a pas sur le réseau dessiné, un article qui aurait une étiquette (198 - 128 + 1) = 71 ?
Vous pouvez vérifier ce point avec la fonction "affichage->Informations globales".
De toute façon, ça n'a guère d'importance, il n'y a pas de scrutation des articles, donc pas de trafic de données supplémentaire.

2/ autre disfonctionnement : Sur un block bien précis, les trains s'arrêtent au milieu, grognent puis repartent. Apparement d'après les traces, c'est bien CA Train qui impose cet arrêt et redemarrage. d'ailleurs, l'utilisation de ce block via Modparam est impecable.
==> Le seul moment où CAtrain se permet d'arrêter un train en plein milieu d'un tronçon est le freinage d'urgence lorsqu'un train a été repéré en aval et qu'il n'y a pas de signaux à mettre au rouge entre les deux et que le train est trop proche pour qu'un simple ralentissement suffise, ou que ce train vient dans l'autre sens! ... Bien sûr il peut aussi y avoir un bug qui subsiste!
Peut-être la distance de scrutation est-elle trop longue et CATrain "se méfie" d'un autre train venant en sens inverse, mais ce train est loin et CATrain n'a pas encore anticipé que ce train va changer de direction de par la future modification du positionnement d'une aiguille.

Cordialement,

Joël

Bonjour, Joël et François
1/ Pour ce qui est de mon adresse 198, j'ai effectivement trouvé un signal qui était en adresse 70 sans raison car je n'ai pas de cartes à cette adresse... Je n'avais pas compris qu'il fallait shifter de 128 les adresses des cartes device. Donc j'ai supprimé l'affectation du signal à cette adresse où je n'avais effectivement pas de carte et ce problème s'est réglé.

2/ Pour ce qui est de l'arrêt intempestif, j'ai bien la certitude que c'est Catrain qui demande l'arret mais c'est dans le cadre d'un ralentissement progressif, avec plusieurs ordres de vitesse transmis à la carte pwm. Si c'était un arret d'urgence, je pense que seul un ordre serait transmis ?

Ce problème ne m'arrive que sur un seul canton, je vais essayer d'analyser et de reproduire de manière méthodique sur un tci equivalent, en changeant certains paramètres, etc...


3/ Autre problème qui vient de m'arriver : j'ai éteint le PC Catrain mais je n'ai pas eteint l'alim des cartes et deux moteurs d'aiguillage partis en fumée. Je pense que lorsque le master est perdu, certaines cartes partent peut être en live... J'ai repris la doc et j'ai vu que l'adresse 0 des cartes device étaient utilisées pour un arrêt général : or sans avoir lu cette information, j'ai utilisé cette adresse pour un aiguillage. Pouvez vous me décrire en détail le fonctionnement de cette adresse 0, sachant que je n'ai rien vu dans les traces. Dois je absolument adresser mon aiguillage autrement, et cette adresse 0 peut elle effectivement être utilisée pour un arret général des cartes ?

Merci encore de votre soutien,
je vous tiens au courant.

Rémy

Bonjour Rémy,

De mon côté je n'utilise pas l'adresse "0" pour les modules Accessoires, du fait que l'alimentation est permanente. A mon avis, il n'est pas non plus nécessaire d'utiliser la 1ère sortie du module à l'adresse "0" comme interrupteur général. Je pense beaucoup plus simple d'avoir un véritable interrupteur qui fournit l'alimentation sur les transfos d'alimentation des PWM et Accessoires. En Ho j'avais un seul transfo délivrant 15 V pour alimenter tous les modules. En "Z", J'ai 2 transfos, un pour les PWM, l'autre pour les accessoires et les détecteurs. Ils sont branché sur une multiprise qui a un inter général. Clic, Clac, Ça fonctionne parfaitement !

François

Bonjour, François

ce qui voudrais dire que cette adresse 0 serait purement une convention.

On aurait pu imaginer que lorsque CAtrain démarre et qu'on lance la communication un ordre soit envoyé sur la carte 0 mais c'est idiot... c'est comme si on voulait imprimer sur une imprimante le fait qu'elle est en passe ou qu'il n'y a plus de papier...

Je vais donc laisser mon adresse 0 tranquille et laisser mon alimentation permanente : juste faire attention de couper l'alimentation des cartes device avant de déconnecter CAtrain, pour éviter des commandes parasites.

Rémy

Bonjour Rémy,

Si c'était un arret d'urgence, je pense que seul un ordre serait transmis ?
==> Si je me rappelle bien la commande d'arrêt est transmise plusieurs fois pour une question de sécurité, mais toujours avec la vitesse "0" comme consigne.

Pouvez vous me décrire en détail le fonctionnement de cette adresse 0
==> L'adresse 0 est réservée au gros "switch ON/OFF" bleu, toujours présent à l'écran. Elle est destinée à commander un gros relais de mise générale sous tension du courant TRACTION du réseau pour pouvoir "couper tout" très rapidement, en cas de déraillement ou autre problème. Les Modules et les articles doivent être alimentés de façon permanente pour recevoir les commandes.
Il ne faut surtout pas utiliser l'adresse 0 pour autre chose. Si le relais n'est pas présent, pour éviter de "perdre" une sortie de contrôle d'article je conseille de ne pas placer de module sur les adresses 0 à 3 ou même 0 à 7 et ne commencer la numérotation des adresses au delà.
Il m'est aussi arrivé de griller une bobine d’aiguille en la connectant malencontreusement sur un module programmé en mode "8 sorties permanentes"... Je ne m'en suis pas rendu compte assez vite.
J'ai pu démonter l'aiguillage et le re-bobiner à la main. Ce n'est pas trop difficile. La bobine refaite consomme à peu près deux fois plus que l'originale, mais comme ce n'est que pendant 400ms ça n'a pas d'importance .

Cordialement,

Joël

Bonjour, Joël

Pour l'arret inopiné, Il s'agit bien d'un ralentissement jusqu'à arret complet et redemarrage par la suite (plusieurs commandes mais avec des vitesses degressives).

je vais décaler mon adresse de carte device pour éviter de voir passer à cette adresse 0 une commande permanente. Merci pour le conseil.

Il est vrai que j'ai des moteurs d'aiguillage Fleischmann, fragiles et chers.
Je prévois de les protéger à terme avec un montage qui me permettra de voir si une commande permanente apparaît pour un aiguillage (je vais espionner les sorties des cartes device avec un microcontroleur type pixaxe qui pilotera une alarme (ou déclenchera un relais général d'alimentation des carte devices).

Ce week-end je fouille et reviens vers vous pour mes arretes intenpestifs.


Rémy

Youpiiii, j'ai trouvé : il s'agissait du facteur d'influence des rampes qui arrêtaient carrément mes trains. J'avais une rampe de 20 que je prenais à contresens (le train descendait) comme le coefficient était à 8 le train s'arrêtait et il redémarrait lorsque le train virtuel sortait de la rampe !
Logique ! J'avais voulu expérimenter les coefficient de rampes et j'avais laissé le coefficient a 8, remis à 1 tout marche.

Merci catrain

Rémi.

Je n'avais pas pensé à cela ...!

Joël

Bonjour, je reviens vers vous car je crois avoir tordu le cou à tous les dysfonctionnements que j'avais sur mon réseau. Suite au traitement que j'ai infligé à mon réseau depuis quelques jours, aucun des problèmes aléatoires que je constatais ne se sont reproduits. J'ai mené les actions "coup de poing" suivantes et je pense que si j'avais mieux respecté la doc à la construction, j'aurais gagné du temps :

1/ j'ai câblé le deuxième bus de la carte USB et j'ai réparti mes 14 cartes sur les bus
2/ j'ai blindé la liaison entre la carte USB et les modules
3/ J'ai refait le câblage des alimentations PWM des cantons, car j'avais de temps en temps des trains qui apparaissaient sur deux cantons en même temps, et Catrain n'appréciait pas du tout. J'ai donc respecté le câblage en étoile qui est préconisé dans la doc, alors que j'vais soigneusement réalisé des torons qui faisaient le tour du circuit, bien proprement, mais malheureusement je soupçonne effectivement des inductions entre les câbles. Je conseillerai même de les blinder, mais pour le moment je vais en rester là.
4/ j'ai inversé certains cantons pour avoir une polarité homogène sur tout le circuit : le premier avantage c'est que lorsque vous faites une modification, et que vous devez réinitialiser la polarité, vous n'avez pas à re-modifier sur le dessin les cantons qui sont inversés. Le deuxième avantage (mais là seuls les concepteurs peuvent confirmer ou infirmer) c'est que le logiciel (sur le pC et sur les cartes PWM) a peut-être quelques instructions de moins à parcourir pour envoyer les ordres.

Voilà, avec ce beau câblage, tout semble être rentré dans l'ordre...

Rémy

Bonjour,

je suis content que vous ayez pu résoudre ce problème. Je n'ai pas rencontré de tels phénomènes d'inductions parasites sur mon réseau "z" mais il est cablé "au plus court" (et sur du "z" c'est vraiment court!), mais j'ai eu les mêmes problèmes sur mon réseau HO en Märklin Digital, réseau qui est contrôlé par CATrain mais n'utilise pas les modules. Ce sont des modules originaux de chez Märklin ainsi que des clones décrits dans Elektor.
C'était surtout les commandes des sémaphores à bobine double qui induisaient des perturbations, plus que la commande des aiguilles. Pas de solution miracle, j'ai du revoir plusieurs fois le câblage et le positionnement des points de masse. Pas si facile avec la voie "M" métallique qui couple toutes les masses ensembles et pas vraiment en étoile

Cordialement,

Joël

Bonjour à Vous Tous ,

Un moment que je n'étais pas passé par le forum , je viens de parcourir le fil en cours ( mais heureusement résolu à aujourd'hui Rémy ! ).
Toujours intéressant de lire les problèmes et surtout leurs solutions trouvées !! (

Pour mes antécédents : Soucis avec la saturation des flux sur le module USB --> résolu par une alimentation électrique plus confortable dudit module ; Soucis avec le logiciel lors du passage à un nouveau PC tournant sous Winwdows 7 version 64 bits --> résolu par Joël en contournant habillement les " sécurités intrinsèques " de l'OS .

Pour ce qui est de mon témoignage tardif , j'ai aussi quelques bugs d'erreurs éparses " time USB out " en circulation , sans trop de raison apparente , sans lieu précis et récurent sur le réseau mais plutôt avec certaines locos ( parasitages inefficace ? ) .

Il faut préciser qu'avec mon " usine à gaz " de réseau câblé ( qui est malheureusement encore et toujours en développement par manque de temps ... ).
, cela reste anecdotique au regard du fonctionnement général .

Dans les grandes lignes et pour reprendre le détail , le réseau en HO possèdera ( à terme ) :

- une carte USB " double bus " ( en place ),
- 18 modules PWM ( dont 15 déjà actifs ) ,
- 18 modules d'accessoires ( dont 3 de " réserve " et 13 déjà actifs ),
- 6 modules de détection ( non câblés pour l'instant ) .

Donc , actuellement , 28 modules , répartis sur les deux BUS , dialoguent sans grand soucis . Les câblages sont assez long , traités sans précaution particulière , certains groupes de modules étant carrément " déportés " de plusieurs mètres , il se peut que les bugs occasionnels proviennent de phénomènes d'induction ( ? )... Mais , il est vrai , le tout se déroule avec des circulations quantitatives assez pauvres , par manque de temps ... Je verrai une fois tout en place !..

Je profite du passage pour Vous souhaiter par avance Mes Bons Vœux pour l'année qui se profile dans 4 jours .

Je profite aussi afin de préciser que certains des sujets datant de l'ancien site ont malencontreusement été attribués à un autre que moi lors du basculement vers la nouvelle version du site( mon pseudo d'inscription étant SATOLEMAIRE et non PIRANHAS ) mais le principal est bien de pouvoir lire ce qui est raconté dans les écrits , le reste " on s'en fout " , tant que cela aide et valorise l'utilisation de CA Train .

Bonne Année à Tous

Bien Cordialement .

Antoine ( Satolemaire !! )

Bonjour Antoine et tous mes bons voeux pour 2015 !

Vous avez une très grande configuration et CATrain doit sans doute atteindre ses limites pour gérer autant de modules.
Mon réseau Z n'a rien de comparable et il est encore contrôlé par un PC sous XP.
C'est toutefois mieux que mon réseau HO Märklin Digital, encore géré par un 486 sous Windows3.1!
Notez que les performances du PC entrent peu en ligne de compte, sauf peut-être pour la fluidité du graphisme.
C'est plutôt le transfert sur les bus séries et les capacités "temps-réel" du PC qui sont les facteurs limitatifs.
Et de ce coté, les choses ne font qu'empirer... Windows 3.1 avec ses 10 ms de temps de réponse à travers le BIOS est bien plus
performant que XP qui a une "réactivité" d'environ 100ms.
C'est pour cette raison que l'interface USB a du être développé. Il collecte un maximum d'évènements avant de les envoyer ensembles au PC.
Sur WIndows 7, les choses se sont encore dégradées. Dans mon ancien job, un collègue avait mesuré des temps de "réaction" pouvant atteindre 700ms. Pour cette raison il a modifié ses logiciels pour lancer des "threads" avec une priorité supérieure:
"PriorityClass: HIGH_PRIORITY_CLASS", "ThreadPriority: THREAD_PRIORITY_ABOVE_NORMAL".
CATrain n'utilise pas de telles priorités. Il y aurait sans doute moyen de recompiler le DLL avec ces modifications, mais il faudrait que je remette en route Visual C++ 5.0, sur un PC dédié pour ne pas risquer de "véroller" ma version plus récente. Ou alors il faudrait porter CATrain sur Visual Studio 2010.
Je le ferai peut-être mais ce n'est pas facile.
Je n'ai jamais fait de mesure de réactivité temps-réel sur Windows 8, mais comme j'ai eu des problèmes de blocage de mon "audio DAC" USB et j'ai cherché sur le Web et des utilisateurs recommandent d'augmenter la taille des "buffers" audio pour un délai de 1.5 seconde. (pratique pour le montage au casque!).
Une telle solution n'est pas envisageable pour CATrain, les paquets sont petits et le 18F2550 n'a pas beaucoup de mémoire.
Le principal est que les paquets "ACK" ou "Détection" finissent par être pris en compte, même si un petit train ça fait du chemin en une seconde!
Si le "time-out" se déclenche (je ne me rappelle plus sa valeur), on a au mieux une perte d'évènements, et au pire un blocage de l'USB par perte de synchronisation.
Je pencherais plutôt pour ce problème dans le cas qui vous concerne.
Un phénomène de perturbation électrique n'est pas impossible mais les coupleurs optiques sont censés les éviter! Ces coupleurs sont sources d'autres problèmes de par la dispersion de leurs caractéristiques mais le bus USB et le PC sont galvaniquement isolés du réseau grâce à eux et grâce au convertisseur DC/DC qui alimente le module USB.

Ce ne sont que quelques réflexions théoriques. Mon réseau est trop modeste pour expérimenter le phénomène...

Désolé pour la confusion entre vos mail et ceux de PIRANHAS...
C'est Daniel qui a effectué manuellement le transfert lors de la fermeture de l'ancien site et cela a demandé beaucoup de travail, et sans doute généré quelques erreurs!
Je n'ai malheureusement pas les compétences nécessaires pour manipuler les fonctions d'administrations complexes... j'ai peur de "casser quelque-chose"!

Cordialement,

Joël

Bonjour Joël,

Ta réponse est peut-être une explication à une anomalie que je rencontre parfois (mais trop souvent tout de même!) : lors du passage d'un canton à un autre, il arrive que le train se bloque pour repartir une seconde plus tard. En Z comme il n'y a pas de volant d'inertie, ces arrêts et redémarrages sont particulièrement brutaux.

CATrain est sous XP avec un PC dédié. Mon réseau utilise 6 modules PWM, 2 modules de détection et 5 modules Accessoires.

Cordialement,

François

Bonjour François,

il est possible que ce soit le même phénomène, malgré que ton PC soit sous XP, s’il a subi les mises à jour, ou pire, si un anti-virus est présent.
La réponse "temps-réel" de 100 ms maximum que je mentionne pour XP, a été mesurée sur un antique ACER, originellement sous Windows 95 et porté sous Windows XP lors du développement de l'interface USB.
C'est une version "non officielle" de XP SP1 et les mises à jour sont impossibles. Grâce à cela, ce petit PC est resté très performant.
J'ai aussi un PC Fujitsu plus récent qui a subi toutes les mises à jour XP SP2 et puis SP3.
Cette machine est devenue une véritable "brouette", incapable de contrôler proprement mon réseau Z et incapable de faire tourner d'autres applications audio et video.
Ce phénomène est bien connu, mais je n'ai jamais réussi à remettre ce PC d'aplomb même en suivant tous les conseils prodigués sur le Web. Pourtant elle n'a plus d'anti-virus et n'est plus connectée au réseau. Comme quoi, même une machine sous XP peut devenir très lente et mettre sans doute bien plus de 100ms pour recevoir un paquet USB, le traiter et renvoyer les paquets de contrôle.

D'un autre coté, j'avais observé un phénomène similaire lors d'un choix malencontreux d'itinéraire:
à cause de la mise anticipée des signaux à l'état passant pour éviter que les trains ne s'arrêtent inutilement lorsque la voie est libre, j'avais deux trains qui "se battaient en duel" pour réserver la même section de voie loin devant eux, et d'y imposer leur vitesse et leur polarité.
Il s'en suivait un engorgement du bus pour transmettre toutes les 20 ms des ordres contradictoires aux pauvres modules PCM concernés!
J'ai découvert cela dans les traces. J'ai pu régler le problème en diminuant la distance de supervision, au prix de signaux qui tardent un peu à passer au vert et peuvent ralentir les trains et générer un trafic de données gênant. Tout est une question de "tuning" et de compromis.
Il ne faut quand même pas trop diminuer cette distance de supervision, il vaut mieux renoncer aux itinéraires sur lesquels ce genre de situation de "semi-conflit" ne peut être évitée.
L'optimisation est d'autant plus nécessaire lorsque de nombreux trains circulent simultanément: les trains à grande inertie simulée exigent la transmission de nombreux ordres de contrôle de vitesse et le trafic de données peut engorger les bus.
Sur mon réseau Z, très "ramassé", le maximum testé est de 7 trains mais par précaution je n'en fait circuler que 5 et j’impose volontairement des délais ou l’attente de trains en gare.
Sur un grand réseau, les longs tronçons exigent moins de variations de vitesse et on peut sans doute mettre bien plus de convois.
Sur mon réseau HO - en Märklin Digital, mais aussi contrôlé par CATrain - j'arrive à faire circuler 11 trains.

Cordialement,

Joël