Voir les contributions
16
Modélisation, Architectures logicielles et matérielles / Les grandes lignes de mon projet d'automate DCC
« le: décembre 23, 2016, 03:23:45 am »
Sur la demande de Dominique, je vous présente mon projet en quelques lignes. Je pourrais en parler longuement, mais je veux avant tout vous donner l'idée générale.
En fait, je pourrais résumer mon projet en trois mots: machine à états. Chaque noeud est une machine à états qui reçoit des évènements, réagit en effectuant une action et renvoie un autre message au système. Jusque là, rien de bien sorcier...
Ensuite: le système est répartit entre plusieurs noeuds, ce qui permet de gérer suffisamment de code sans nécessiter l'utilisation d'un ordi ou un logiciel externe. Pour le moment, j'en suis environ à 1500/1600 lignes de code pour chaque arduino. Et c'est là tout l'avantage de ce système: de petites fonctionnalités un peu partout et finalement tout tient dans quelques arduinos.
Le système fonctionne grâce au CanBus configuré à 500kbit/s. Ce qui est rapide (si on fait le calcul, cela représente quasiment 4000 messages à la seconde). J'ai fait des tests à plus basse vitesse et il y a encore de la marge... Disons que je n'ai pas encore rencontré de situation qui nécessite cette vitesse aussi rapide.
Pour les noeuds: comme je l'ai déjà mentionné sur mon blog, le tout s'organise autour de 4 types de noeuds:
- le DCC, gestionnaire de la position des trains et de la topologie du réseau (rails). Il génère aussi les messages DCC.
- le LOCO, il contient le script de la loco. C'est lui qui va demander au système s'il peut aller de tel à tel canton, demander l'état de la signalisation au modules CANTON, etc...
- le CANTON, il a la responsabilité d'un canton (3 zones de détection) et de la signalisation (2 feux complexes)
- enfin, les autres noeuds: aiguillages, animations, etc...
Un exemple de fonctionnement: un train entre sur une zone, le canton le détecte et met à jour la signalisation. Celui-ci envoie l'info d'occupation au DCC qui sauvegarde la position et autorise la poursuite du script si rien ne s'y oppose. Le module train, une fois entré dans un canton, demande l'état de la signalisation et ajuste sa vitesse en fonction... etc...
A chaque fois, il s'agit d'évènement qui entraine une action puis une réaction (nouveau message...). Le secret: bien manager le principe de message/réponse de façon atomique, et ne pas envoyer plein de messages dans tous les sens et espérant que les noeuds pourront gérer le tout en parallèle... Mon premier prototype semblait "plus intelligent" mais je me retrouvais dans des situations de "dead lock" parce que deux messages attendaient deux réponses simultanées et le système perdait les pédales...
A part cela, mon réseau une fois équipé devrait compter une douzaine de cantons, mais pas tous avec signalisation complète. Certaines branches de manoeuvres n'en utilisant pas.
Voilà, difficile d'en dire plus, ou alors ce serait vraiment beaucoup plus...
Si vous avez des questions sur des détails bien précis, je pourrai essayer d'y répondre.
Au plaisir,
Patrick
En fait, je pourrais résumer mon projet en trois mots: machine à états. Chaque noeud est une machine à états qui reçoit des évènements, réagit en effectuant une action et renvoie un autre message au système. Jusque là, rien de bien sorcier...
Ensuite: le système est répartit entre plusieurs noeuds, ce qui permet de gérer suffisamment de code sans nécessiter l'utilisation d'un ordi ou un logiciel externe. Pour le moment, j'en suis environ à 1500/1600 lignes de code pour chaque arduino. Et c'est là tout l'avantage de ce système: de petites fonctionnalités un peu partout et finalement tout tient dans quelques arduinos.
Le système fonctionne grâce au CanBus configuré à 500kbit/s. Ce qui est rapide (si on fait le calcul, cela représente quasiment 4000 messages à la seconde). J'ai fait des tests à plus basse vitesse et il y a encore de la marge... Disons que je n'ai pas encore rencontré de situation qui nécessite cette vitesse aussi rapide.
Pour les noeuds: comme je l'ai déjà mentionné sur mon blog, le tout s'organise autour de 4 types de noeuds:
- le DCC, gestionnaire de la position des trains et de la topologie du réseau (rails). Il génère aussi les messages DCC.
- le LOCO, il contient le script de la loco. C'est lui qui va demander au système s'il peut aller de tel à tel canton, demander l'état de la signalisation au modules CANTON, etc...
- le CANTON, il a la responsabilité d'un canton (3 zones de détection) et de la signalisation (2 feux complexes)
- enfin, les autres noeuds: aiguillages, animations, etc...
Un exemple de fonctionnement: un train entre sur une zone, le canton le détecte et met à jour la signalisation. Celui-ci envoie l'info d'occupation au DCC qui sauvegarde la position et autorise la poursuite du script si rien ne s'y oppose. Le module train, une fois entré dans un canton, demande l'état de la signalisation et ajuste sa vitesse en fonction... etc...
A chaque fois, il s'agit d'évènement qui entraine une action puis une réaction (nouveau message...). Le secret: bien manager le principe de message/réponse de façon atomique, et ne pas envoyer plein de messages dans tous les sens et espérant que les noeuds pourront gérer le tout en parallèle... Mon premier prototype semblait "plus intelligent" mais je me retrouvais dans des situations de "dead lock" parce que deux messages attendaient deux réponses simultanées et le système perdait les pédales...
A part cela, mon réseau une fois équipé devrait compter une douzaine de cantons, mais pas tous avec signalisation complète. Certaines branches de manoeuvres n'en utilisant pas.
Voilà, difficile d'en dire plus, ou alors ce serait vraiment beaucoup plus...
Si vous avez des questions sur des détails bien précis, je pourrai essayer d'y répondre.
Au plaisir,
Patrick
Que veux-tu dire?
