L’interface de pilotage d’une loco est peu fonctionnelle, car peu lisible et super moche. J’ai l’impression d’avoir un ZX-81 (j’en parle parce que le Z-80 qui l’animait vient de sortir du marché …)
L’ergonomie et l’expérience utilisateur du logiciel est très trop complexe et on voit bien que c’est fait par des développeurs pour des développeurs.
Et en plus je pense qu’il y a une architecture totalement dépassée. Un aiguillage devrait avoir une interface publique (commande : Droit ou Dévié) et ensuite autant d’implémentation que de variantes sur le marché avec pour chaque variante juste ce qu’il faut pour le paramétrer (par exemple entre un aiguillage marklin et un aiguillage DCC Cobalt). C’est un exemple car là j’ai un objet aiguillage avec la somme de tous les paramétrages de toutes les variantes, ça devient incompréhensible même avec la doc.
Et surtout, je te dis pas le test d’un tel objet informatique … c’est évident qu’il est buggé.
Quand j’ai du Marklin et que je vois pour un aiguillage : Identifiant, Short Identifiant, Numéro, Accessoire#, Identifiant du noeud (UID), Nom de l’UID, Adresse 1, Port 1, Paramètre 1, Valeur 1, Paramètre … je mets où le numéro de l’aiguillage MM2 ? ok j’ouvre la doc …
Un aiguillage marklin, je devrais juste avoir à saisir son numéro MM2. Et éventuellement un temps de commutation (encore que 100ms c’est bien par défaut).
Ce que décrie Julie est précisemment la (ou les) raison(s) qui me tiennent a distance de l’automatisation, basé sur mes recherches préliminaires. Je ne pense pas être un naze en IT, j’ai pas mal programmé durant mes études, et dans mes 1er jobs, je peux toujours lire du code pas trop complexe et le débuger, mais franchement je n’ai pas envie de me faire c**ier dans mon loisir du WE avec un outil crée par des informaticiens, pour des informaticiens. Je ne jette pas encore l’éponge avec l’automatisation, mais il faut reconnaitre qu’on est pas gaté avec l’IT dans le train électrique. Les interfaces sont assez ignobles, contre-intuitives, dans bien des cas. ESU a fait un effort notable avec son Lokprogrammer, c’est bien interfacé avec le soft dédié et intuitif pour les fonctions importantes (mais pas pour toutes). Bref, je ne veux pas polluer le fil de Julie plus longtemps, on va vite dériver par rapport au sujet, qui est son réseau !
Je suis d’accord avec vous
Vous décrivez exactement ce que je reproche à l’informatique mais c’est valable pour tous les domaines !!
Cela a commencé avec la fumisterie qu’on nous a asséné pour le passage à l’an 2000 et l’argent qui a été dépensé pour remplir les poches des S2I .
On a toujours rasé gratis en informatique
le « user » on en a rien à fiche
il doit s’adapter
Le plus navrant étant le slogan : wysiwyg
En résumé ce que vous écrivez est ce qu’on nous dit depuis 30 ans sauf que c’est toujours aussi buggé et unfriendly juste plus rapide et plus compliqué et sans possibilité de revenir en arrière
La dernière avancée à mourir de rire est le « UX designer »
L’aveu qu’on t’a vendu un produit qui n’est pas bon (ou mal pensé) et qu’il nécessite donc d’être modifié moyennant finance bien évidemment
Utilisateurs de tous pays réveillez vous
Perso concernant les logiciels train je ne serai pas aussi critique compte tenu de ce qui précède , au moins ça marche !
À vous lire
On peut scinder le sujet
Sinon je me tais promis !
Pour ne pas polluer plus le fil de Julie !!
PS : et curieusement c’est souvent les informaticiens qui sont les plus critiques envers les réalisations de leurs collègues …
Toute honte bue, et malgré le fait de passer pour un pur béotien, ma question est "quel est l’intérêt d’une telle solution de pilotage ?
J’ai déjà du mal à passer au digital “simple”, même si j’en comprends très bien les avantages par rapport à l’analogique …
En fait j’attends LA solution digitale pour les nuls car j’aimerai avoir un système aussi simple que mon ancien transfo bleu avec mes deux fils : “le fil rouge sur le bouton rouge, le fil brun sur le bouton brun”
Sinon professionnellement parlant je vends du software …
Soyons sincères : cette interface n’est qu’une bécquille. La plupart des centrales sur le marché sont dotées d’une interface propre avec un bouton à tourner (parfois un glisseur, que j’apprécie moins) et des boutons pour les fonctions principales. Si tu branches la MS2 sur la Gleisbox qui elle est connectée à Rocrail via CC-Schnitte, Rocrail suivra tout ce que tu fais sur MS2 (et vice-versa, je crois). Cette interface est faite pour faire de petits essais occasionnellement, pas pour exécuter les manoeuvres en gare.
Ça fait quelque temps que je n’ai plus configuré d’aiguillage sur Rocrail, mais je n’ai pas trouvé qu’il y avait énormément de paramètres… OK, les trois manières différentes de gérer les adresses, c’est un peu bizarre pour un dilettant comme moi, mais à part ça c’était facile. Plus difficile la gestion des feux de signalisation du moment qu’on a plus que deux positions à y mettre…
Tout le monde n’y trouve pas d’intérêt. Je le dis d’emblée pour éviter tout malintendu, et pas qu’on puisse comprendre “digital sans ordinateur n’est pas digital”.
Pourquoi une gestion par logiciel ?
Pour faire fonctionner un réseau sans beaucoup d’interventions humaines.
C’est inévitable pour les grands réseaux aux nombreux trains circulant en même temps, sauf si on veut créer sa boucle séparer pour chacun d’eux et juste les faire tourner, tourner, tourner… mais c’est lassant à la longue. Si on veut voir des trains différents emprunter la même voie, il faut des gestions automatisées, que ce soit en analogique (et là, c’est vraiment fastidieux à concevoir, même avec le concours de l’électronique) ou en digital (et alors on a le concours de l’ordinateur).
C’est intéressant pour les mêmes raisons même quand le réseau est petit et menu, à condition qu’on aime observer et regarder passer les trains en broutant son herbe ou en sirotant son café - ou son verre de rouge, comme c’était proposé dans un autre fil, il n’y a pas longtemps, accompagné d’un bon concerto de Vivaldi ou d’autres musiques qu’on apprécie.
Accessoirement, pour un réseau qui dépasse une certaine taille c’est intéressant aussi d’employer l’ordinateur comme TCO électronique, ce qui est plus facile à configurer vu qu’on reprend une structure “hardware” déjà existante pour pouvoir gérer des itinéraires pouvant inclure des dizaines d’aiguillages, des passages à niveau et des postes de signalisation, ce qui serait beaucoup plus difficile à mettre en place par des matrices de diodes ou autrement, sachant qu’il ne faut pas créer de réciprocités (si en itinéraire x je mets aiguillage a en rond et aiguillage b en droit, il est possible qu’ils soient en droit tous les deux pour un itinéraire y).
Si tu veux un système qui ne fait pas plus que ce qu’on pouvait faire avec ce que tu décris - eh bien, ça existe depuis longtemps. Ça se trouve dans les coffrets de démarrage pour enfants, ça peut quand même gérer 4 locos mais pas plus que deux en mouvement sinon surcharge, et ça ne fait rien d’autre que commander les locos, même sans fils puisque la commande est à infrarouge.
Après il y a la MS2 qui, avec deux fils, permet de commander des locos et basta, les aiguillages restant en manuel comme avec ton transfo aux deux bornes, brune et rouge.
(Oui, on peut commander des aiguillages avec la MS2, mais c’est laxatif, si quelqu’un veut mon avis. Et à mon avis très personnel la commande digitale des aiguillages pour un petit réseau n’a de sens que si on veut automatiser, autrement c’est juste cher à payer.)
Parce que j’aimerais avoir quelques mouvements de train en automatique mais surtout un joli synoptique sur un écran.
Belle transition …
Allez hop les travaux du jour …
D’abord la mise en route du GleisReporter Plus qui est l’équivalent d’un S88 avec 16 ports et qui se branche sur le bus CAN. Donc moins de pb de fiabilité probablement pour un cout équivalent.
Ensuite j’ai joué avec le mode de détection en configuration “Master” et j’ai fini par comprendre l’ordre de démarrage des différents éléments (Gleisbox, Logiciel, Mise sous tension, Découverte) pour que ça marche ; sans oublier le petit paramètre dans un coin pour que la locomotive détectée survive dans la liste des locos suite à un redémarrage du logiciel, etc…
Bon en vrai je n’ai pas encore tout compris et ça reste erratique même si je suis arrivée à détecter les 4 locos MFX et que j’ai pu ajouter une loco (la Diesel 216 FS) en mode DCC.
J’ai eu le temps aussi de mettre la commande d’un dételeur. Sympa. Et le synoptique du dépôt avance tranquillement au fur et à mesure de mes découvertes.
En principe oui, pas encore arrivée à le faire (j’ai pas vraiment vu si les affichages MS2 et RocRail étaient vraiment synchro).
Mais oui mon intention est de garder la manette MS2 pour piloter en manuel. Et pour les aiguillages je te rejoins, et c’est pour cela que j’utilise un pupitre Stellpult.
Le logiciel permet un enchaînement de trajets sécurisés ( vu le prix du matériel …c’est important ) soit via des itinéraires décidés par l’utilisateur ( je veux aller de à vers b en passant par c etc…) soit en automatique ( je regarde mes deux ou trois trains rouler sur le réseau s’arrêter repartir etc … bref une pause sympa entre la construction du décor )
Mais aussi beaucoup plus si on est passionné comme JohnjeanB… voir ses vidéos qui sont top
Bon j’ai vraiment gratté le sujet hier jusqu’au fin fond du forum RocRail (lire CC-Schnitte + RocRail : mode Master ou non? - #5 par Julaye) et mon cas semble désespéré (et non, même si j’en ai la capacité, je n’ai pas envie de déverminer le code de RocRail, je cherche du Plug & Play pas du Plug & Pray).
Du coup je vais essayer iTrain qui supporte “nativement” CC-Schnitte (c’est à dire sans bricoler une interface MBUS prévue pour CS2/CS3 à l’origine …).
J’ai tout téléchargé ce matin, lu la documentation (introduction et annexe C sur les interfaces) et ma première impression est : c’est beaucoup plus simple et rationnel et l’interface est nettement plus joli.
Déjà pour le paramétrage de l’interface, pour chaque type d’interface un écran spécifique avec seulement les informations requises … et la doc est à jour et compréhensible. Ok c’est un produit commercial mais pas si cher que ça et si ça permet de faire ce que je dois faire sans y passer des journées entières …
Dans la documentation il est écrit que CC-SChnitte implique d’avoir le protocole MFX d’enregistrement des locos dans le logiciel. Ah tiens, c’est justement mon problème avec RocRail …
Alors iTrain va-t-il réussir là où RocRail merdouille ?
Malheureusement pour vous, il va falloir attendre dans un intolérable suspens, je pars en “tournée” et je vous reviens pour les prochains essais début Juillet !
Sauf erreur de ma part c’en sont quatre, mais bon.
Le “général” décrit la fonction de l’aiguillage dans le réseau, c’est important pour la gestion des itinéraires. Tu n’en a pas pour l’instant ? Pas grave, ça se corrigera par la suite, ou se remplira aussi au fur et à mesure que tu en créeras. Idem pour les blocs (je n’en ai pas vu dans ton début de plan).
Le “interface” décrit la connexion de commande. S’il y a la possibilité de renseigner plusieurs moteurs c’est qu’il y a des aiguillages à deux moteurs, triple et TJD notamment. Ce que tu n’as pas besoin de renseigner, tu laisses libre - comme dans la déclaration d’impôts.
Le “câblage” m’est nouveau, mais il me semble qu’il sert pour la rétrosignalisation éventuelle : l’aiguillage a-t-il bien tourné, en quelle position se trouve-t-il ? En bas, je ne sais pas si ce n’est pas l’action à exécuter si tu cliques sur l’icône de l’aiguillage dans ton plan. À vérifier dans le wiki. Tu laisses vide pour l’instant. Tout comme le “contrôle”.
Coeur d’aiguillage - hum. C’est inutile en voie C, mais pour les 2railiens c’est important tout comme pour les 3railiens qui polarisent les rails par lesquels passe le frotteur. Rocrail ne peut pas savoir et n’a pas besoin de savoir quel type d’aiguillage tu utilises, mais si le coeur (ou les rails internes de l’aiguillage) est polarisé, il peut gérer la polarisation. Je ne sais pas pourquoi c’est là parce que tous ceux que je suis qui utilisent la polarisation, le font par des contacts supplémentaires sur le moteur servo…
Ça devrait pourtant. Je crois me souvenir d’avoir lu qu’il faut configurer Rocrail en slave et la MS2 en master… sans garantie.
Justement, c’est bien le sens de mon coup de gueule. Ce que je n’ai pas besoin de renseigner ne devrait meme pas apparaitre.
L’objet Aiguillage est trop générique et ça devient une usine à gaz. Si je mets protocole MM2 tout ce qui est inutile devrait disparaitre.
Et je serais pas étonnée du nombre de bugs dans sur un tel objet avec la combinatoire. Alors qu’un objet AiguillageMarklin héritant de Aiguillage pourrait simplifier l’ensemble du dispositif.
Bref pas envie de poursuivre cette discussion qui devient stérile. Cette interface je la considère merdique car aujourd’hui on sait modéliser bien mieux que ça et faire des ergonomies simples même pour des situations complexes.
Hello
Pour en avoir le cœur net tu peux poster un message avec ta question dans le forum Rocrail anglais
Même si ce sont des informaticiens qui répondent ils sont très sympa et aidants
À ce propos il faut consulter la doc en anglais c’est celle qui est régulièrement mis à jour
Sauf que le protocole ne définit à priori que la rangée d’adresses - et que personne ne peut savoir si tu utilises un aiguillage C simplissime ou si tu commandes en MM un aiguillage Peco avec coeur polarisé et tout le tamtam. Donc, il n’y a pratiquement rien qui s’avère inutile par le simple choix du protocole.
Effectivement la conception de Rocrail part du principe qu’avant de remplir les cases tu auras lu la documentation et tu sauras donc ce qu’il faut renseigner et ce que tu peux laisser libre. Tout comme la déclaration d’impôts où tu as toujours une case “conjoint” même si tu ne t’es pas mariée et que tu n’as pas renseigné de changement d’état civil. C’est là, mais tu sautes la ligne et vas au point suivant.
La priorité est mise sur les fonctions du locigiel et non sur un accès “aveugle” aux configurations.
Mais alors, il faut créer une multitude d’objets similaires pour chaque fabricant de rails et chaque ligne de produits, et continuellement tenir à jour la base de données au fur et à mesure que les marques changent leur programme… c’est là que je parlerais d’une usine à gaz.
Je préfère alors que le focus soit mis sur ce qu’on utilise au quotidien, et pas sur les cartes de configuration qu’on remplit une fois par aiguillage, qu’on peut si ma mémoire est bonne même recopier d’un objet à l’autre, et qu’on ne touche plus après.
Oui, RRTC fait des choses beaucoup plus spécifiques - mais il se le fait payer cher, et il y a bon nombre même de centrales que le logiciel ne supporte pas, alors que RocRail se veut le plus ouvert possible, sauf pour raisons techniques, documentées, par exemple concernant la connexion USB.
iTrain aussi a triplé son tarif au cours des dix ans passés, et tu paies aujourd’hui la montée en version aussi cher que jadis la licence entière.
Mais bon, chacun a ses propres attentes, ou comme le dit l’adage, chacun voit midi à sa porte.
Reprise des activités avec l’installation de iTrain. C’est tombé en marche : CC-Schnitte connectée, aiguillages fonctionnels et rétro-signalisation opérationnelle.
Le seul hic : aucune locomotive MFX détectée. J’ai du rater quelque chose grrr.
A suivre avec le forum de iTrain.
J’ai refait aussi des essais avec Rocrail qui m’a bien détecté mon petit locotracteur HLD donc le pb vient bien d’une configuration ou d’une manipulation dans iTrain.
Au premier abord, iTrain a l’air plus simple mais je n’ai pas pu tester le mode de pilotage ni la synchronisation avec la MS2 puisque je n’ai aucune locomotive dans l’interface
@+
Edit : j’ai pu obtenir un défilement de MFX UUID en bas à gauche de l’écran iTrain en forçant une valeur dans un champ nommé “Nouveau compteur MFX”. Cela semble correspondre à mes trois locomotives Mfx qui sont sur le réseau mais aucune locomotive n’est créé dans iTrain.
Si je rentre manuellement une locomotive avec un des UUID, je ne sais pas quoi mettre comme Adresse (nécessaire pour valider le formulaire) et la locomotive n’est pas adressée. J’ai essayé différentes valeurs y compris l’adresse qui a été attribuée à cette loco dans RocRail lol …
Vraiment étrange et cela semble être lié au fait d’utiliser CC-Schnitte et non pas une CS2/CS3 (dans ce cas, les locos sont importées depuis la base de données de la CS2/3).
Je ne connais pas itrain mais Rocrail et CC-Schnitte. Ce dernier ne joue aucun rôle dans la détection de locomotives. C’est une passerelle USB/CAN, point barre !
As-tu enregistré la locomotive dans la MS2 ? Ce n’est sans doute pas la solution la plus élégante mais la MS2 (une fois la locomotive enregistrée) cherchera à créer une communication avec elle et je suis à peu près certain que ce message circulera sur le bus CAN et itrain le verra ! Qu’en fera t’il ? Dans tous les cas, ce n’est pas compliqué à faire, ça peut payer.
Sinon, tu peux aussi te confectionner un sniffer CAN. Avec l’identifiant du message CAN tu connaitras l’adresse. Le sniffer te sera bien utile après pour d’autres besoins.
Tu peux aussi “forcer” la recherche de l’adresse. Un peu comme le sniffer, une carte (Arduino) sur le bus CAN qui envoie un message CAN d’identification. la Gleisbox retournera un moment donné l’adresse de la loco que tu saisiras manuellement. Pas top non plus mais ça permet d’avancer.
Le CAN est très souple pour ça et on peut avec collecter facilement nombre d’informations très utiles.
Le problème se situe dans iTrain (j’ai indiqué que cela fonctionne avec Rocrail dans la même configuration) qui ne détecte pas les locos. Ou plutot qui les détecte (il m’affiche les UUID) mais ne crée pas les objets Locomotives correspondant. Et si je les crée manuellement, cela ne fonctionne pas et je soupçonne un problème d’adressage.
Il y a un module qui trace les communications avec la Gleisbox. les messages échangés ont l’air normaux (j’ai une trace similaire avec Rocrail).
J’ai mis un message dans le support de iTrain.
Lu dans le forum iTrain, à partir de la version 2.04 :
CC-Schnitte: MFX registration improved with better timeouts and more logging.
Donc ça devrait fonctionner grrr j’ai la dernière version 5.1 …
Comme tu l’as soulevé quelque part, c’est certainement du côté de maître/esclave qu’il faut chercher. Le protocole de Marklin dit en effet : [le MFX Discovery] est toujours déclenché par le processeur de l’interface utilisateur graphique. Le déclenchement d’un Discovery ne devrait être effectué que par le pupitre de commande maître.
Il n’y a pas d’adresse locale (loc-ID) pré-enregistrée. Tu as la liberté de choisir l’adresse que tu veux. Si tu ne peux pas saisir une adresse quelconque dans Itrain, c’est que très probablement, s’il est vu comme un esclave, il respecte scrupuleusement la règle.
Peut-être alors, si tu ne l’as pas encore essayé, enlever la MS2 du bus CAN et redémarrer Itrain et la Gleisbox pour que la Gleisbox ne reconnaisse que Itrain et l’accepte donc comme master.
Tu pourrais alors faire un bind. Ce que tu as fait précédemment, c’est-à-dire entrer une adresse manuellement, est possible quand cette commande vient du master, c’est à dire reconnu comme tel par la Gleisbox
Par ailleurs, si tu n’as pas de résultats, est-ce que tu serais prête à faire cela par programmation avec un Arduino en CAN sur le bus. Je l’avais fait, le principe maitre/esclave n’est qu’une directive du protocole mais n’empêche pas d’être forcé. Un Arduino donc peut faire un bind avec l’adresse que tu lui donnes et tu saisis ensuite cette adresse dans Itrain.
J’ai fait ce code qui est quelque part sur mon ordinateur mais je mettrais peut-être moins de temps à le réécrire.
PS : Certainement faut-il aussi déprogrammer le mode MASTER sur la MS2 !
J’ai tout supprimé dans la MS2 et dans iTrain et j’ai juste détecté ma fidèle ML003. Sans succès concernant iTrain, toujours rien dans Locomotives.
Je suis retournée sur Roctail et effectivement j’ai un bind dans la MS2 et cela fonctionne direct dans RocRail qui s’adresse ensuite à l’équipement avec cette adresse 5 !
11:37:36 9999 bind loco UID=0x7CFCCD97 to SID=5 (id=0x00056B1F)
J’ai réessayé d’utiliser cette adresse 5 dans iTrain mais il ne veut rien savoir.
J’ai débranché les MS2 et j’ai relancé iTrain … et ce coup ci la locomotive est bien détectée et ajoutée automatiquement !
En fait c’est ou bien iTrain ou bien la MS2 … contrairement à RocRail qui permet d’avoir les deux …
Assez de temps perdu, je vais utiliser RocRail et pour le problème que j’ai identifié, je jetterais un oeil plus tard sur le code open source …
Donc ça fonctionne ! Pas de manière satisfaisante car tu ne sais pas précisément pourquoi. Comme tu disais, c’est tombé en marche.
Maitre/Esclave existe forcément dans Itrain, c’est peut-être caché à l’utilisateur et donc non modifiable, mais c’est le protocole Marklin qui l’exige et je n’imagine pas que Itrain ne le respecte pas.
C’est la Gleisbox qui arbitre quels sont le maitre et les esclaves, probablement dans l’ordre de connexion, c’est sans doute le 1° connecté qui est le maître, ça me paraitrait logique et les suivants esclaves. Mais est-il toujours question de logique ici ?
Pense peut être aussi à ce que je t’ai dit de déprogrammer le mode MASTER sur la MS2, c’est dans les settings.
Je suis en train de programmer un sniffer très complet pour analyser les trames CAN échanger et pouvoir les interpreter facilement, je veux dire du style “Message en provenance de la Gleisbox : bind de locID = 5”. Donc, même si cela fini par fonctionner, c’est toujours intéressant de savoir qui fait quoi, à quel moment et dans quel ordre.
