Projet partagé d'un gestionnaire de réseau

[Etienne66]

Ce que j'ai décrit dans mon précédent message c'est le minimum avec un dispatcher humain.
Pour un dispacher automatisé on a besoin d'itinéraires.
3 possibilités :
- On donne juste le point de départ et le point d'arrivée et on laisse l'IA décider. Dans la réalité ça pourrait marcher
mais avec nos circuits qui tournent en boucle avec également des retournements l'IA va rentrer rapidement dans
des boucles sans fin.
- On donne le trajet précis en tant que suite de cantons avec des arrêts éventuels en gare. Le problème c'est que si il y a
un conflit à un moment donné ça va coincer.
- On introduit une couche supplémentaire en définissant des gares avec les trajets possibles pour traverser la gare (ainsi
que des priorités pour l'arrêt, le passage sans arrêt, voyageurs ou fret...) et des lignes pour aller d'une gare à l'autre.
L'itinéraire peut alors comporter une succession de lignes et de gares et l'IA pourra gérer les conflits.

[Etienne66]

@ Etienne

Je pense que la distinction des aiguilles gauche/droite n'est pas la bonne. Je préfèrerait TD/DV (Tout Droit/ DeVié) pour voir la distinction de vitesse entre la vitesse en cas de position tout droit et en position déviée. Il y a les aiguilles enroulées, bien sûr 
On peut aussi dire autrement en donnant carrément la vitesse pour chaque position (120/30) qui serait plus universelle ?

Denis

Tu as raison.

[Etienne66]

Bonjour Etienne

Sur les aiguillages je pense que tu peux ajouter quelques rubriques utiles:

• position par défaut: droite/déviée

• type de moteur ( servo; solénoïdes, moteur lent,...)

• orientation du moteur ( pour les servo)

On peut peut être aussi évaluer si cet aiguillage doit être couplé à d autres (cas de "bretelles")

Enfin on peut envisager aussi une vitesse de circulation selon les directions( MAX, 70, 60, 30,...)

Ltr

D'accord pour la position par défaut et la vitesse.
Pour les moteurs c'est plus un problème à régler au niveau du décodeur. Et il suffit d'une temposisation entre le moment où
on change les aiguilles et l'ouverture du signal pour tenir compte des moteurs lents.

[Pierre59]

Je suis d'accord qu'il manque plein de choses dans le fichier, mais il ne faut pas aller trop vite, tout ce qui est matériel sera pris en compte plus tard (mais il faudra prendre en compte tous les cas : analogique ou digital, commande des aiguilles DCC ou autre, ...)

Mon fichier jison n'est qu'une proposition, j'espère que d'autre formats de fichier seront proposés. Mais on peut et même on doit discuter du format du fichier json.

Concernant les positions des aiguilles, on m'a reproché à juste titre (pour les TCOs) que deviée/directe posait des problèmes notamment avec les aiguilles symétriques, et on m'a proposé gauche/droite.

Pour les itinéraires, comme pour le BAL, ou verra plus tard.

Il est vrai qu'à la SNCF les bretelles sont traitées spécialement, les deux aiguilles sont appairées, elles sont nommées Axa et Axb et toujours manoeuvrées ensembles, pour des raisons de sécurité.as t'on besoin de faire pareil.

Pierre

[Etienne66]

Concernant les positions des aiguilles, on m'a reproché à juste titre (pour les TCOs) que deviée/directe posait des problèmes notamment avec les aiguilles symétriques, et on m'a proposé gauche/droite.

Pour les itinéraires, comme pour le BAL, ou verra plus tard.

Il est vrai qu'à la SNCF les bretelles sont traitées spécialement, les deux aiguilles sont appairées, elles sont nommées Axa et Axb et toujours manoeuvrées ensembles, pour des raisons de sécurité.as t'on besoin de faire pareil.

Pierre

Donc pour les aiguillages il faudra gauche/droite/symetrique, et pour le canton on a la position droite ou déviée donc on peut en déduire la direction.
Pour les aiguilles appairées c'est tout simple : un seul décodeur mais 2 aiguilles dans le logiciel avec la même adresse DCC.

[Pierre59]

Je voudrais ici faire le point sur la manière d'écrire un gestionnaire.


Deux grandes manières :

- écrire du programme comme dans la série d'articles que j'avais proposés
   • avantages on peut faire absolument tout ce que l'on veut, c'est la solution la plus performante et la plus souple
   • inconvénients c'est généralement un gros programme et il faut avoir de bonnes compétences en programmation (object)

- écrire un fichier qui décrit tout ce qu'il faut, avantages : l'utilisateur n'a pas à écrire de programme juste saisir un fichier, inconvénients : difficultées à saisir le fichier en respectant les règles et limitations à ce qui est prévu. Il faut derrière un programme qui prends en compte ce fichier, plusieurs solutions sont possibles :

   • le programme créée des objects en fonction de modèles préétablis, avantages : bonne efficacité, programme assez facile à écrire, inconvenients : le programme qui crée les objects ne sert qu'une fois mais après encombre la mémoire

   • le programme élabore du code (lignes de programme) qui sera ensuite compilé pour produire le gestionnaire, avantage meilleure efficacité si le programme fait des optimisations et non présence du programme qui élabore le code dans le gestionnaire, inconvénients : programme qui élabore le code beaucoup plus laborieux à écrire

Pierre

[laurentr]

Attention avec ce raccourci

Sauf à avoir un décodeur qui permettra des réglages séparés ( distincts) de chaque moteur( cas de servo notamment mais pas que… !) cette topologie est à rejeter.
1 appareil ( simple)  = 1 moteur = 1 adresse
1 appareil complexe (TJD TJS Triple,..) = 2 moteurs (ou plus)  = n adresses (1 par moteur)

Ce n'est pas économique en adresses j'en convient mais on a une maille unitaire.( surement plus universelle à traiter)

1 commande peut adresser plusieurs adresses ou une seule.

Ltr

[Etienne66]

Dans ma proposition précédente j'avais écrit :
- blocs :
--- libre/occupé (donné directement par le capteur)
--- réservé par un train (numero du train)

En fait il faut autoriser plusieurs trains à réserver un bloc pour pouvoir gérer les voies uniques.
En effet dans le cas d'une voie unique un train doit réserver le dernier canton pour éviter q'un autre train vienne à contresens.
Et si plusieurs trains se suivent sur cette voie unique il faut compter le nombre de trains entrés et sortis avant de libèrer la voie.
Donc on aura le nombre de trains ayant réservé le bloc et non pas un numéro de train.
Et il faut ajouter le dernier bloc de voie unique dans la définition du ou des premier(s) canton(s) de ce sens de circulation
et faire la même chose dans l'autre sens.

[Pierre59]

Donc pour les aiguillages il faudra gauche/droite/symetrique, et pour le canton on a la position droite ou déviée donc on peut en déduire la direction.
Pour les aiguilles appairées c'est tout simple : un seul décodeur mais 2 aiguilles dans le logiciel avec la même adresse DCC.

Non c'est gauche/droite dans tous les cas (même pour les cantons).

Je tiens à signaler que tout le monde ne commande pas ses aiguilles en DCC, et qu'il faudrait mieux ne pas parler, pour l'instant, de matériel ni de canton.

Pierre

[laurentr]

@Pierre

Attention pour être efficace si la commande des appareils n'est pas pilotée via DCC ( ce qui respe une implémentation possible)  il faudra à minima que leurs positions soient reçues et connues pour assurer les sécurités.

Sinon... boom!
 

[Etienne66]

Je voudrais ici faire le point sur la manière d'écrire un gestionnaire.


Deux grandes manières :

- écrire du programme comme dans la série d'articles que j'avais proposés
   • avantages on peut faire absolument tout ce que l'on veut, c'est la solution la plus performante et la plus souple
   • inconvénients c'est généralement un gros programme et il faut avoir de bonnes compétences en programmation (object)

- écrire un fichier qui décrit tout ce qu'il faut, avantages : l'utilisateur n'a pas à écrire de programme juste saisir un fichier, inconvénients : difficultées à saisir le fichier en respectant les règles et limitations à ce qui est prévu. Il faut derrière un programme qui prends en compte ce fichier, plusieurs solutions sont possibles :

   • le programme créée des objects en fonction de modèles préétablis, avantages : bonne efficacité, programme assez facile à écrire, inconvenients : le programme qui crée les objects ne sert qu'une fois mais après encombre la mémoire

   • le programme élabore du code (lignes de programme) qui sera ensuite compilé pour produire le gestionnaire, avantage meilleure efficacité si le programme fait des optimisations et non présence du programme qui élabore le code dans le gestionnaire, inconvénients : programme qui élabore le code beaucoup plus laborieux à écrire

Pierre

Je verrais plus le json comme intermédiaire entre le PC et l'arduino et un programme à base de menus sur le PC pour créer ce json.

[Pierre59]

Je verrais plus le json comme intermédiaire entre le PC et l'arduino et un programme à base de menus sur le PC pour créer ce json.

Donc si je te comprend bien on fait un programme sur PC pour aider à la saisie (quel language) du fichier json, puis le fichier json sert pour faire le gestionnaire de l'Arduino, avec quelle méthode  ( il faut sérieusement envisager aussi de prévoir le gestionnaire pour PC ou mini-PC).

Pierre

[Dominique]

Je verrais plus le json comme intermédiaire entre le PC et l'arduino et un programme à base de menus sur le PC pour créer ce json.

Donc si je te comprend bien on fait un programme sur PC pour aider à la saisie (quel language) du fichier json, puis le fichier json sert pour faire le gestionnaire de l'Arduino, avec quelle méthode  ( il faut sérieusement envisager aussi de prévoir le gestionnaire pour PC ou mini-PC).

Pierre

Si le gestionnaire est sur PC (ou miniPC) il commande la centrale DCC (trains et accessoires en DCC) comme d'habitude via USB/Ethernet et il récupère la rétrosignalisation comme d'habitude en S88, Loconet, etc. On continue avec JMRI, RocRail, etc.. C'est juste un gestionnaire de plus avec un mode d'emploi comme les autres.

Alors qu'est-ce que ça change de ne pas utiliser le Can ?

Si le gestionnaire est sur une carte Arduino connectée au CAN, comme les aiguilles, détecteurs, signaux avec un satellite V1 ou V2, alors il y a une innovation réelle par rapport aux solutions courantes et des possibilités de modules distribués sur le Can (TCO, manettes, configurateurs).

Je ne cherche pas d'influencer vos choix, mais je préfère la 2ème solution.

[Etienne66]

Je verrais plus le json comme intermédiaire entre le PC et l'arduino et un programme à base de menus sur le PC pour créer ce json.

Donc si je te comprend bien on fait un programme sur PC pour aider à la saisie (quel language) du fichier json, puis le fichier json sert pour faire le gestionnaire de l'Arduino, avec quelle méthode  ( il faut sérieusement envisager aussi de prévoir le gestionnaire pour PC ou mini-PC).

Pierre

Perso je ne vais pas utiliser un gestionnaire sur Arduino.(J'ai choisi JMRI) je suis juste là pour les conseils.
Objectivement, je pense que la décision de chacun dépend de la disponibilité d'un PC dédié au réseau ou pas.
L'avantage du gestionnaire PC c'est l'interface graphique mais les solutions existent déja gratuites ou payantes donc inutile de réinventer la roue.
Par contre le gestionnaire tout arduino on n'a pas. Donc si vous décidez de vous lancer c'est du tout arduino qu'il faut faire.
Celà dit il faut de toute façon un PC (ou MAC) pour charger les sketches donc pourquoi ne pas utiliser ce PC pour la configuration?
Quant au language, il est clair pour moi qu'il faut utiliser le C++. De cette façon tu définis tes structures de données une seule fois pour
le programme de saisie sur PC et leur utilisation sur arduino. Le PC sera donc utilisé pour toutes les saisies y compris les itinéraires et
une fois que les données sont chargées (USB, Ethernet, Wifi) ton arduino devient autonome.
Et si au bout du compte tu te rends compte que ton réseau est trop lourd à gérer pour un arduino tu pourra faire tourner tout ou partie
du même code sur PC sans avoir à tout refaire.

[Etienne66]

Si le gestionnaire est sur PC (ou miniPC) il commande la centrale DCC (trains et accessoires en DCC) comme d'habitude via USB/Ethernet et il récupère la rétrosignalisation comme d'habitude en S88, Loconet, etc. On continue avec JMRI, RocRail, etc.. C'est juste un gestionnaire de plus avec un mode d'emploi comme les autres.

Alors qu'est-ce que ça change de ne pas utiliser le Can ?

Si le gestionnaire est sur une carte Arduino connectée au CAN, comme les aiguilles, détecteurs, signaux avec un satellite V1 ou V2, alors il y a une innovation réelle par rapport aux solutions courantes et des possibilités de modules distribués sur le Can (TCO, manettes, configurateurs).

Je ne cherche pas d'influencer vos choix, mais je préfère la 2ème solution.

En fait dans un gestionnaire tout arduino on n'a plus la liaison USB donc il faut un lien bidirectionnel. Avec loconet et autres on n'a que le sens retrosignalisation. L'autre sens doit passer par la voie avec la limite de débit que ça impose.
Le CAN étant bidirectionnel il s'impose comme la solution idéale.