Canton toujours occupé

Bonjour,

Cela faisait plusieurs mois que je n'avais pas lancé de circulations sur mon réseau car fatigué de problèmes à répétition dont celui des cantons qui restent occupés sans raison et n'importe où sur le réseau pourtant desservi par 2xHSI-USB. Et très rarement l'inverse : un convoi non détecté.

Hier je relance et ça recommence. Le même canton qui reste occupé 2 fois dans la même séance de jeu mais pas toujours (1/10 environ). Ce canton est relié à un RMGB-8-N qui est le seul sur la sortie milieu du HSI. De plus ce RMGB-8-N ne dessert que 4 cantons. Donc problème de charge à écarter. D'autant plus qu'il m'est arrivé qu'une loco soit non détectée lors d'un profil de vitesse sans aucune autre activité réseau.

En me remémorant les incidents précédents j'ai tendance à penser que ce problème survient souvent sur le dernier RMGB-8-N d'une chaîne. Et en lisant la contribution

bernard35 a écrit:

Je viens de lire sur un site (il faut que je retrouve le lien) que raccorder à la masse le Data In du dernier module (celui où il n'y a rien de branché) pouvait améliorer la situation. Cela a du sens car une entrée en l'air, ce n'est pas très sain en électronique.

je me suis mis à chercher sur le Net et j'ai trouvé sur cette page de LDT une phrase qui dit que si la protection du bus nécessite une mise à la masse on peut souder sur le capot de la prise RJ45 un fil relié à la masse. Pour compenser un câble mal foutu ? mais c'est vague. J'ai envoyé un courriel à LDT pour demander des éclaircissements, mais sont peut-être fermés en ce moment.

Je vais donc essayer cela, au moins sur le dernier qui m'a causé des soucis.

J'ai aussi une autre piste qui concerne le lien USB entre le PC et les périphériques. Mes HSI et la centrale sont connectés via un HUB car je n'ai pas assez de prises directes sur l'ordi. J'ai de temps à autre des déconnexions et des bizarreries que je suppute venir de là. J'ai eu des locos qui ne s'arrêtaient jamais continuant à vitesse de seuil au delà du marqueur d'arrêt, elles n'avaient probablement pas reçu le dernier ordre. Et je ne pense pas que TC ou la centrale soient en cause.
Donc j'ai du ménage à faire dans ma config, faut changer le PC, un portable qui a bien 8 ans mais qui fonctionne très bien par ailleurs.

A+

Alain

Bonjour,

DiCoS69 a écrit:

Le Loconet est un bus véritable, contrairement au S88 qui n'est en fait qu'un gigantesque régistre à décalage, où les bits circulent en chaîne, avançant d'un cran à chaque coup d'horloge.
Rien ne garanti l'exactitude de la transmission.
Un vrai bus transmet les données en blocs (ou mots) et généralement, un mot ne respectant pas le protocole est rejeté.

DiCoS69 a écrit:

... le bus CAN est un bus industriel dont la sécurité est obligatoirement très élevé, alors que le Loconet est juste un bus développé pour le train miniature.

Et le bus RS de LENZ, c'est quoi ? Un vrai bus ou pas ? Perso, je ne rencontre pas de problème avec ce type de bus ...  

Larist a écrit:

... J'ai de temps à autre des déconnexions et des bizarreries que je suppute venir de là. J'ai eu des locos qui ne s'arrêtaient jamais continuant à vitesse de seuil au delà du marqueur d'arrêt, elles n'avaient probablement pas reçu le dernier ordre. Et je ne pense pas que TC ou la centrale soient en cause...

Par contre j'ai des déconnexions de centrales... La Lzv100 (DCC voies) raccordée en ethernet et la Redbox (DCC accessoires) raccordée en USB. A priori, quand l'une se déconnecte, l'autre suit ??? Dans ce cas, TC me semble "suspectable", non ? ...  
Suite à un court-circuit, j'ai aussi des trains (qui étaient en phase de décélération pour arrêt) qui ne s'arrêtent pas. Je pense que TC ne leurs envoie pas (ou plus) l'ordre d'arrêt ...

A+
Georges

Geo69 a écrit:

Et le bus RS de LENZ, c'est quoi ? Un vrai bus ou pas ? Perso, je ne rencontre pas de problème avec ce type de bus ...  

Oui, Georges, c'est un vrai bus puisque tu peux adresser chaque module comme bon te semble.

Geo69 a écrit:

Suite à un court-circuit, j'ai aussi des trains (qui étaient en phase de décélération pour arrêt) qui ne s'arrêtent pas. Je pense que TC ne leurs envoie pas (ou plus) l'ordre d'arrêt ...

Dès lors que le train est déjà dans le canton d'arrêt, s'il y a un court-circuit, les données de calcul de distances sont perdues et TC ne prend plus le train en charge.
J'ai donc établi un protocole de remise en route.
Chaque fois que j'ai un court-circuit en exploitation auto : Si c'est avec tableau horaire, j'arrête d'abord l'horloge, puis je passe en mode "Edition", je mets manuellement, avec la centrale, toutes les vitesses des locos en court de trajet à 0.
Quand le problème du C.C. est résolu, je remets la centrale sur "Go", aucun train ne bouge. Je repasse alors en mode "Exploitation" et à la question "Voulez vous redémarrer tous les trajets en cours avant l'arrêt", je répond "Plus tard".
TC passe en mode exploitation mais rien ne bouge.
Je peux alors à loisir emmener un train presque arrivé à son point d'arrêt, puis relancer un à un les trajets en cours avec les symboles qui vont bien (groupe "trajets" du bandeau), puis redémarrer l'horloge.

En continuant mes recherches sur les problèmes avec le bus S88, je suis tombé
- sur des pages en anglais de OpenDCC fort intéressantes   S88 analyzed avec des pistes d'amélioration
- sur  le produit µCon-S88-Master. Il est interfacé à TC via Ethernet. Je n'ai à priori rien trouvé sur le forum sur ce produit. Le connaissez-vous ?

Mise à jour : je viens de trouver ma réponse sur µCon-S88 dans le sujet "Interface entre PC et réseau avec une Ecos V.2"

Geo69 a écrit:

Par contre j'ai des déconnexions de centrales... La Lzv100 (DCC voies) raccordée en ethernet et la Redbox (DCC accessoires) raccordée en USB. A priori, quand l'une se déconnecte, l'autre suit ??? Dans ce cas, TC me semble "suspectable", non ? ...  
Suite à un court-circuit, j'ai aussi des trains (qui étaient en phase de décélération pour arrêt) qui ne s'arrêtent pas. Je pense que TC ne leurs envoie pas (ou plus) l'ordre d'arrêt

Bonsoir Georges,

Si effectivement et Ethernet et USB se déconnectent en cascade on peut s'interroger sur TC. Est-ce USB ou Ethernet qui se déconnecte en premier ?

Pour ma part étant uniquement USB j'ai aussi parfois des déconnexions en cascade mais rarement. Ce problème peut aussi venir du système de routage vers les ports COM. Cette couche de port COM qui s'attelle à l'USB me rappelle que sur un autre ordi une imprimante en port COM se trouve parfois inaccessible et qu'il faut relancer W10 pour la voir réapparaitre. Et elle est branchée directement à l'ordi, pas de HUB. Perte de connexion similaire à celle vécue avec TC.

Ce soucis a fait l'objet de plusieurs échanges sur le forum de Freiwald qui a toujours soutenu que le problème était côté matériel. Les plaintes concernaient des déconnexions de rétro au bout d'un certain temps d'inactivité ce qui a conduit certains à mettre des automates pour solliciter la rétrosignalisation à intervalle régulier avec succès d'après eux.

Les trains qui ne s'arrêtent pas suite à court-circuit j'ai aussi et là TC cafouille dans la reprise. Ce que je signalais c'était des arrêts non respectés en exploitation normale sans qu'il y ait une charge particulière. C'est heureusement très rare.

A+

Alain

DiCoS69 a écrit:

Quitte à changer, c'est le bus CAN qu'il faut choisir, le R-bus étant seulement une adaptation du S88...

J'ai vu qu'il exister tout un environnement Digital basé sur CAN Das CAN-digital-Bahn-Projekt. Est-ce connu ? Est-ce un projet ou des produits existants ?

DiCoS69 a écrit:

Les problèmes surviennent seulement quand il y a des changements simultanés d'états, c'est à dire lorsqu'il y a plus de 4 ou 5 trains en circulation simultanée... c'est pour ça que c'est totalement aléatoire...

J'ai l'impression qu'il y a deux catégories de problèmes avec S88
- c'est un transfert de données en série sans détection / correction d'erreur. Les erreurs doivent plutôt liées à des perturbations électromagnétiques et indépendantes de la charge (nombre de changement d'états simultanés). Les recommandations trouvées sur le site OpenDcc et LDT devraient aider.
- si c'est lié au nombre de circulations simultanées, c'est à mon avis au niveau de la conversion des données série du bus S88 en messages vers TC que cela doit se situer soit dans le traitement dans le HSI, soit dans l'envoi des messages via l'interface  vers TC, soit à la réception au niveau du PC. Théoriquement, une levée de doute pourrait se faire en mettant trois HSI avec un seul bus S88 chacun au lieu d'un HSI avec trois bus S88. Cela devrait diviser par trois la charge de traitement au niveau des HSI. Enfin remplacer le HSI par le µCon pour passer d'USB à Ethernet

A creuser

Je viens de faire un essai après mise à la masse du capot de la prise RJ45 IN libre du module qui dessert le canton qui me pose problème. Tout a bien fonctionné alors que le réseau était chargé. Au moins une trentaine de passages impec. A la fin il ne restait plus qu'un seul train en roulement et patatras au moment de terminer sa rotation finale le canton ne s'est à nouveau pas libéré au TCO.

La suite (étape par étape) :
- interversion de la connexion avec un autre canton pour éliminer un éventuel problème lié à la voie
- déplacement de ce module qui se trouve à 15 cm d'une multiprise 220V
- changement du câble le reliant au HSI

J'ai aussi eu un train non détecté sur un canton d'un autre module sur une ligne différente du même HSI. Appui flèche verte : rien ne change canton toujours non occupé, appui sur "connecter" idem, passage en mode édition puis exploitation et là canton occupé.

A+

Alain

Larist a écrit:

Ce que je signalais c'était des arrêts non respectés en exploitation normale sans qu'il y ait une charge particulière. C'est heureusement très rare.
Alain

J'ai aussi ça de temps à autres, mais je pense quand même que cela provient de la détection dont l'information est transmise trop tard, ou pas du tout...
A moins que TC soit en train de faire ses courses...

Tous ces problèmes ont pour origine une gestion "antique" de la rétro à cause de vitesses de transmission trop basses, ou d'un principe ne permettant pas la répétition des données ou l'élimination de celles qui sont erronées.
Pour moi, la rétro a 30 ans de retard sur le plan technique (S88 Marklin années 80 !!)... il faudrait que les constructeurs de modules se bougent le cul au lieu de peinardement fabriquer ces vielles choses, améliorées certes, mais dépassées...
Évidemment, créer un nouveau protocole demande de l'investissement, et dans le monde de notre petit train, les industriels préfèrent essayer de se remplir les poches avec les sous de ces cochons de modélistes, râleurs de surcroît... sans trop en dépenser pour assurer l'avenir...
En plus, tout les modélistes n'utilisent pas la rétro... ça fait pas beaucoup de clients potentiels...

Roco a donc fait un bel effort (avec l'aide de Zimo) en introduisant le bus CAN... ESU aussi avec son Ecoslink... mais ça se voit sur les prix...
Il nous faudrait maintenant un "gestionnaire de bus CAN" pour remplacer le fameux HSI88, et des modules adaptés... alors, Digikeijs, on s'y colle...!?

Nouvelles investigations :
Suite aux conseils sur ce forum, j'avais dévalidé le railcom car cela n'apporte pas grand chose quand TC à la main et je ne voulais pas mélanger les problèmes entre l'apprentissage de TC et les infos railcom. Sans maitriser complétement TC, je pense maintenant être capable de faire la part des choses
Hier j'ai réactivé le railcom et pour avancer pas à pas, je n'ai validé que le retour de l'adresse, j'ai invalidé le retour du sens de circulation.
Et le défaut est toujours présent !
Par contre et ça je ne comprends pas, le canton qui est resté occupé sur TC (rose) n'avait plus l'identification du train, donc l'information de retour de l'adresse est bien arrivé et bien traitée mais par contre l'information de libération n'est pas  arrivée ?
Y-a-t-il un traitement différent entre les informations d'occupation simples et les messages, je supoose plus complet des retours d'adresse des loco.

Une autre question sur le "bus" loconet. Il n'y a pas d'adressage à faire au niveau du bus côté module, il suffit de chainer les modules et ça se "débrouille". On ne renseigne que les adresses des capteurs que l'on reporte dans TC. Ca ressemble donc plutôt à du S88 qu'à un vrai bus ?

DiCoS69 a écrit:

Roco a donc fait un bel effort (avec l'aide de Zimo) en introduisant le bus CAN...

C'est bien plus simple, Roco soustraite à Zimo la partie numérique de son activité ! Et comme Zimo utilise ce bus dans sa production, Zimo n'allait pas aller chercher ailleurs un truc différent.

Bonjour,

DiCoS69 a écrit:

... Évidemment, créer un nouveau protocole demande de l'investissement...
Il nous faudrait maintenant un "gestionnaire de bus CAN" pour remplacer le fameux HSI88, et des modules adaptés...

DiCoS69 a écrit:

Geo69 a écrit:

Et le bus RS de LENZ, c'est quoi ? Un vrai bus ou pas ? Perso, je ne rencontre pas de problème avec ce type de bus ...  

Oui, Georges, c'est un vrai bus puisque tu peux adresser chaque module comme bon te semble...

Alors pourquoi ne pas investir dans une centrale Lenz (LZV100 d'occase. Il y en a avec la sortie de la LZV200) et des modules RS8 de LDT uniquement pour remplacer le HSI88 et les modules S88 ? ...

A+
Georges

Précision sur un message précédent où j'évoquais les ports COM qui pourraient provoquer la grouille.
Les ports COM ne s'appliquent qu'à ma centrale ZIMO et au SPROG qui pilote les aiguilles.
En ce qui concerne les HSI ils sont directs en USB.

Quand j'ai des déconnexions je perds la centrale ou le SPROG puis parfois le reste. Je n'ai pas souvenir que ce soit les HSI en premier.

Par contre au lancement de TC parfois les HSI sont invisibles même en reconnectant les systèmes numériques. Il faut faire un boot du PC.

A+

Alain

Bonjour,

Ouais, tout cela confirme que nous ne sommes que dans la tentative d'automatisation d'un jouet !...         Avec Windows, Lenz/Roco/ESU/LDT/Zimo/Marklin/Uhlenbrock/Tams/Digitrax/Digikeis etc... et le meilleur logiciel ( ), heureusement que nous ne devons pas envoyer des hommes sur la lune !...    

A+
Georges

Larist a écrit:

Je viens de faire un essai après mise à la masse du capot de la prise RJ45 IN libre du module qui dessert le canton qui me pose problème. Tout a bien fonctionné alors que le réseau était chargé. Au moins une trentaine de passages impec. A la fin il ne restait plus qu'un seul train en roulement et patatras au moment de terminer sa rotation finale le canton ne s'est à nouveau pas libéré au TCO.


Alain

Bonjour Alain
Tu te connectes le capot RJ45 à quelle masse ?
Merci

Geo69 a écrit:

Bonjour,

Ouais, tout cela confirme que nous ne sommes que dans la tentative d'automatisation d'un jouet !...         Avec Windows, Lenz/Roco/ESU/LDT/Zimo/Marklin/Uhlenbrock/Tams/Digitrax/Digikeis etc... et le meilleur logiciel ( ), heureusement que nous ne devons pas envoyer des hommes sur la lune !...    

A+
Georges

Franchement depuis que j'ai abandonné Massoth, même avec windows, j'irai volontiers sur mars avec TC !

bernard35 a écrit:

Tu te connectes le capot RJ45 à quelle masse ?
Merci

La masse d'une prise 220V. Je me suis confectionné une prise mâle qui n'a qu'un fil de terre relié au capot R45.

LDT viens de m'informer que le spécialiste rentre le 17 novembre.

A+

Alain

Larist a écrit:

bernard35 a écrit:

Tu te connectes le capot RJ45 à quelle masse ?
Merci

La masse d'une prise 220V. Je me suis confectionné une prise mâle qui n'a qu'un fil de terre relié au capot R45.Alain

Tu veux dire à la terre...!?
Tu as intérêt à ce qu'elle soit bonne, parce qu'il y a pas mieux pour ramasser des parasites... et sur un coup d'orage... Pchhhhiiiittt...
As-tu regardé si le blindage de la prise n'était pas déjà soudé à la masse du montage ?

DiCoS69 a écrit:

Tu veux dire à la terre...!?
Tu as intérêt à ce qu'elle soit bonne, parce qu'il y a pas mieux pour ramasser des parasites... et sur un coup d'orage... Pchhhhiiiittt...

Ben ...ouais.
Bon ben j'avais pas vu ça sous cet angle, comme de toute façon ça n'a rien changé je vais appuyer sur la touche annulation.

DiCoS69 a écrit:

As-tu regardé si le blindage de la prise n'était pas déjà soudé à la masse du montage ?

Non , je ne l'ai pas ouvert, faudrait que je le sorte de son emplacement. Je vais attendre la réponse de LDT.

Ce soir j'ai interverti les sorties du RMGB entre le canton à problème et celui qui lui est parallèle. 2 séances avec au moins 7 à 8 trains en même temps et aucun problème.       A confirmer.

A+

Alain

DiCoS69 a écrit:

Larist a écrit:

Ce que je signalais c'était des arrêts non respectés en exploitation normale sans qu'il y ait une charge particulière. C'est heureusement très rare.
Alain

J'ai aussi ça de temps à autres, mais je pense quand même que cela provient de la détection dont l'information est transmise trop tard, ou pas du tout...
A moins que TC soit en train de faire ses courses...

J'ai eu 2 cas de figure
- un train qui s'arrête 50 cm trop loin et là un problème de détection tardive est probable mais souvent c'était avec un réseau peu chargé (2 ou 3 trains maxi). Cas assez rare
- un train qui ralentit normalement jusqu'au marqueur d'arrêt mais qui continue indéfiniment à vitesse de seuil. Cas rare également et en exploitation tout à fait normale. Où est la perte d'info ?

A+

Alain

Larist a écrit:

J'ai eu 2 cas de figure
- un train qui s'arrête 50 cm trop loin et là un problème de détection tardive est probable mais souvent c'était avec un réseau peu chargé (2 ou 3 trains maxi). Cas assez rare
- un train qui ralentit normalement jusqu'au marqueur d'arrêt mais qui continue indéfiniment à vitesse de seuil. Cas rare également et en exploitation tout à fait normale. Où est la perte d'info ?
Alain

Dans ce cas, c'est l'ordre de V = 0 qui n'est pas passé, cela arrive avec n'importe quelle centrale...
Ce peut être TC qui ne l'a pas donné, la transmission TC=> centrale qui l'a perdu, la centrale qui ne l'a pas transmis à la voie...
Va savoir...!
Pour le reste de la chaîne, c'est peu probable, car les ordres de vitesse sont répétés continument sur la voie.
Cela arrive aussi suite à un arrêt intempestif alors que le train est déjà sur son canton d'arrivée... à la remise en route, TC envoie une commande à la vitesse de seuil pour ce train... parfois il l'arrête après un délai, parfois pas... (voir message plus haut)

Il m'est arrivé également d'avoir une perte quasi complète de contrôle, suite à des mises à jour en fond de tâche sur le PC, surtout la nuit...
Dorénavant, je déconnecte donc systématiquement la connexion internet quand je fais tourner.
J'ai aussi eu un truc marrant ... lorsque quelqu'un active un bouton de télérupteur (uniquement un du lot de 4) dans le couloir qui borde la pièce du réseau, cela me fait tourner une aiguille... toujours la même... commandée par un servo.
Là, j’interdis l'usage de ce bouton quand le réseau est en exploitation...

Comme quoi, il faut se méfier de tout...!

Bonjour,

DiCoS69 a écrit:

... lorsque quelqu'un active un bouton de télérupteur (uniquement un du lot de 4) dans le couloir qui borde la pièce du réseau, cela me fait tourner une aiguille... toujours la même... commandée par un servo.

Elie, il ne fallait pas utiliser une position du décodeur d'accessoires pour commander l'éclairage du couloir !...

A+
Georges

Bonjour,

Christophe a écrit:

... Franchement depuis que j'ai abandonné Massoth, même avec windows, j'irai volontiers sur mars avec TC !

Adieu Christophe, je t'aimais bien tu sais ...

A+
Georges

Geo69 a écrit:

Bonjour,

Christophe a écrit:

... Franchement depuis que j'ai abandonné Massoth, même avec windows, j'irai volontiers sur mars avec TC !

Adieu Christophe, je t'aimais bien tu sais ...

A+
Georges

Merci c'est sympa ! Je suis touché !

DiCoS69 a écrit:

- Il m'est arrivé également d'avoir une perte quasi complète de contrôle, suite à des mises à jour en fond de tâche sur le PC, surtout la nuit...
- Dorénavant, je déconnecte donc systématiquement la connexion internet quand je fais tourner.
-

Sage précaution, un PC connecté à Internet est régulièrement en train de se connecter pour les mises à jour pour toutes les applis (et elles sont nombreuses) où on autorise la vérification périodique des mises à jour.

DiCoS69 a écrit:

J'ai aussi eu un truc marrant ... lorsque quelqu'un active un bouton de télérupteur (uniquement un du lot de 4) dans le couloir qui borde la pièce du réseau, cela me fait tourner une aiguille... toujours la même... commandée par un servo.

Dans le même style j'ai eu une loco Rivarossi des années 70 qui basculait un servo sur son passage. Ca faisait couic en arrivant sur l'aiguille prise en talon. Elle a été garée en réparation différée.

A+

Alain