Messages

1

Vos projets / Re : Re : TCO arduino Xpressnet

« le: janvier 17, 2017, 04:10:51 pm »

pour moi les projets arduino étant libre

Salut,

Le design de l'Arduino est "Open Hardware", signifiant que l'on peut le reprendre, le modifier, l'utiliser, etc... Par contre, le contenu n'est pas soumis aux mêmes règles. La communauté autour d'Arduino a tendance à donner librement le code, mais ce n'est pas pour autant "Open Source". C'est une idée reçue qui a la vie dure. Si tu développes un programme et tu veux le vendre, libre à toi. De même si tu trouves du code et que tu veux le réutiliser dans un produit commercial, ce n'est pas garanti que tu en as le droit. Tout dépend de chaque développeur.

Patrick

2

Modélisation, Architectures logicielles et matérielles / Re : Les grandes lignes de mon projet d'automate DCC

« le: janvier 10, 2017, 05:19:33 pm »

Bonjour Marcel, bonjour à tous,

J'ai regardé tes réalisations => c'est top

Merci beaucoup. Heureux de voir qu'il y a de l'intérêt!

mais hélas j'ai cherché des plans et programmes, mais rien trouvé

C'est une vaste problématique... Je prends quelques minutes pour répondre...

Autant je lève mon chapeau devant tout le travail accompli par l'équipe de Locoduino car la volonté d'être pédagogue est bien présente, autant, dans mon cas, je suis très frileux à l'idée de faire la même chose. Cela demande énormément de travail et de temps. Il ne suffit pas d'écrire des articles, il faut aussi que le code soit bien présenté, clair, "bug free" autant que possible. De plus, il faut supporter les utilisateurs qui pourraient avoir des problèmes avec celui-ci, etc... Mon boulot me demande déjà beaucoup d'investissement personnel et je préfère consacrer le peu qu'il me reste à avancer sur mon projet...

Mais bon, je ne dis pas que les choses ne changeront jamais, bien au contraire... Mais pour l'instant, je peux difficilement en faire plus.

J'espère ne décevoir personne.
Au plaisir,
Patrick

3

Modélisation, Architectures logicielles et matérielles / Re : Re : Les grandes lignes de mon projet d'automate DCC

« le: janvier 09, 2017, 02:52:33 pm »

Juste une question : pourquoi, au démarrage, on est à R et RR pour une aiguille qui donne voie directe ?

Deux points ici:

• d'une part, il s'agit d'un reliquat d'un test précédent où je voulais valider que R et RR fonctionnaient bien dès le départ
• d'autre part, les moteurs ne sont pas encore câblés dans cette nouvelle version mais la logique persiste. Donc, je dois malgré tout actionner les aiguillages même si les rails ne bougent pas.

Voilà...
Patrick

4

Modélisation, Architectures logicielles et matérielles / Re : Les grandes lignes de mon projet d'automate DCC

« le: janvier 09, 2017, 12:16:21 am »

Vous vouliez un tour complet? Et bien maintenant vous l'avez...

http://jurasecondairen.blogspot.ca/2017/01/signalisation-automatique-un-tour.html

5

Modélisation, Architectures logicielles et matérielles / Re : Re : Les grandes lignes de mon projet d'automate DCC

« le: janvier 08, 2017, 08:58:14 pm »

Déjà, ça marche ! Un bon point (on se croirait à l'école  )

Je le prends

Évidemment, on attend que tous les cantons soient équipés !! 

J'y travaille... mais c'est assez long d'installer tout le câblage!

Patrick

6

Modélisation, Architectures logicielles et matérielles / Re : Les grandes lignes de mon projet d'automate DCC

« le: janvier 08, 2017, 05:11:54 am »

Bonjour,

La première vidéo avec la signalisation fonctionnelle est arrivée. Encore une fois, la qualité laisse à désirer, mais vous comprendrez facilement de quoi il s'agit... http://jurasecondairen.blogspot.ca/2017/01/signalisation-automatique-la-premiere.html

Au plaisir,
Patrick

7

Modélisation, Architectures logicielles et matérielles / Re : Les grandes lignes de mon projet d'automate DCC

« le: décembre 28, 2016, 03:40:48 pm »

Disons que cela fait un certain temps que je m'amuse avec des Arduino, mais cela fait un peu plus d'un an que je travaille sur mon projet... Je ne me souviens plus trop du point de départ... 😊

8

Modélisation, Architectures logicielles et matérielles / Re : Re : Les grandes lignes de mon projet d'automate DCC

« le: décembre 27, 2016, 08:57:54 pm »

Autre idée, très importante pour moi : je propage le n° DCC de canton en canton, avec un canton d'avance.
Dit autrement, un canton peut être occupé "par une source", sans train dedans. Pour être précis "pas encore dedans".
Et, si tu gères comme ça, tu peux anticiper le cas de deux trains allant en sens contraire, y compris la gestion des signaux.

C'est ce que je fais dans le module central: un canton peut être libre, occupé ou réservé. A y réfléchir, c'est vrai que je pourrais pousser cette logique dans le canton et ne rien laisser dans le module central. Il faudrait que j'approfondisse l'idée.

Autre chose :
Pourquoi veux-tu savoir où est la loco ayant le code DCC n°3 ?
Pas pour la signalisation, pas pour l'occupation des voies, pas pour gérer les itinéraires. Toutes ces questions sont globales :
Ex : Sémaphore si le canton suivant est occupé, ... par n'importe quel train.

Hmmm... c'est surtout pour gérer les conflits. Mais en développant un peu plus loin l'idée précédente, il est probable de pouvoir supprimer cette info. Par élimination, elle ne doit plus être utile... Encore une fois, à approfondir...

Patrick

9

Modélisation, Architectures logicielles et matérielles / Re : Les grandes lignes de mon projet d'automate DCC

« le: décembre 27, 2016, 07:33:54 pm »

Ah, je viens de te relire... Tu dis "centrale"... mais j'ai compris "noeud central"... Ok, tu as raison, la centrale pourrait être supprimée comme mentionné à la fin de mon précédent message...

10

Modélisation, Architectures logicielles et matérielles / Re : Les grandes lignes de mon projet d'automate DCC

« le: décembre 27, 2016, 07:32:00 pm »

Il faut préciser que j'ai rassemblé le noeud DCC et la centrale DCC dans le même module. Mais on pourrait totalement mettre de côté la messagerie DCC/booster et utiliser une centrale comme le Zephyr que je possède. Ainsi, le module "central" serait un pont vers Loconet.

En fait, la centrale DCC n'a aucune raison de savoir où est le train.

Hmmm... Pas tout à fait. Il te faut un point central pour résoudre les conflits et gérer les trajets (aiguillages)... Par exemple, deux locos demandent l'accès au même canton. Il faut pouvoir gérer les réservations sans propager de nouveaux messages CAN et que la commande reste "atomique". Si tu propages une nouvelle série de messages pour résoudre le conflit (demander où se trouve telle loco sur le réseau) tu risques de laisser passer l'évènement et de te retrouver dans une situation "en retard", les deux locos se retrouvant sur le même canton! etc... Ce n'est peut-être pas très clair, mais si tu essaies de faire le design de cette situation sur le papier, tu arriveras probablement à la même conclusion. En tout cas, tu as raison, cela mérite une petite réflexion...

Aussi, ça peut paraître étonnant, mais on pourrait supprimer totalement le booster central DCC, et mettre un mini booster sur chaque canton (transistor plus petit puisque seul une loco est alimentée). Et là, le seul équipement se résume aux modules cantons pour gérer les messages DCC! On diminue ainsi le trafic Can. C'est la suite de mon projet... Mais je veux d'abord finir et valider la première phase courante. Cela ne supprime pas non plus les noeuds Loco et potentiellement le noeud de résolution de conflits.

J'ai encore pas mal d'idées dans ma boite
Patrick

11

Modélisation, Architectures logicielles et matérielles / Re : Re : Les grandes lignes de mon projet d'automate DCC

« le: décembre 27, 2016, 05:31:04 pm »

Si le canton gère la signalisation, mais pas la traction DCC, comment peux-tu imposer à une loco de respecter un R60 ou un RR30, ou un arrêt devant un sémaphore ?
Il faudrait que le canton puisse envoyer un message à la traction mais s'il ne connait pas le N° DCC de la loco, ce sera difficile !
Ou bien je n'ai pas assez de détails, car je pense que tu as dû le prévoir.

Je me rends compte que si je veux tout expliquer, il faudrait que j'écrive un diagramme d'états complet avec plus de 80 à 100 messages différents... Cela me prendrait un temps certain  Je vais donc répondre aux questions au coup par coup... Désolé... Mais ce n'est pas perdu. J'ai le projet de rédiger un petit site web pour décrire complètement mon projet, mais cela reste encore une idée en l'air... En fait, tout le temps que je mets dans la rédaction ne va pas sur le projet. Des fois, je n'ai pas le courage de le faire et je préfère travailler sur mes Arduino 

Ceci étant dit, je retourne à ta question. Une idée du fil de messages (va-et-vient). N'oublie pas que je passe des paramètres dans les messages (par exemple, le loco id ou le zone id...):
- (canton) détection zone & mise à jour de la signalisation & envoi du message au dcc
- (dcc) gestion des positions des locos & envoi d'une requête de vitesse au canton
- (canton) envoi de la directive de vitesse à la loco
- (loco) en fonction de son script et de la signalisation, déduit la vitesse voulue & envoi de la directive au dcc
- (dcc) message DCC

Dans cet exemple, on peut voir que de nombreux messages sont impliqués dans cette résolution (le double en réalité). Et cela se multiplie très rapidement, d'où la grandeur du diagramme d'états... Chaque module a un diagramme d'environ une douzaine d'états, avec plusieurs états ré-entrant... Pour chaque message, il faut aussi considérer sa réponse (ou ACK) ce qui double quasiment le nombre. Etc...

J'espère que cela t'éclairera un peu plus.
Patrick

12

Modélisation, Architectures logicielles et matérielles / Re : Re : Les grandes lignes de mon projet d'automate DCC

« le: décembre 27, 2016, 04:54:54 pm »

Une question :
Tu gères avec le DCC. OK. Normal.
Mais serait-il envisageable de gérer avec une alimentation analogique quelconque ?

L'avantage du DCC dans ce cas-là est de centraliser la gestion des messages DCC dans un seul module. Je m'explique: avec l'analogique, il faut alimenter chaque canton au travers de chaque module canton... Du coup, on augmente le trafic de messages et la logique de communication. Cela s'éloigne du modèle que j'ai développé... Gérer la signalisation est faisable mais la traction, je ne suis pas sûr dans l'état. Bref, il faudrait y réfléchir sérieusement...

13

Le logiciel DCC++ / Re : JRMI avec un booster BaseStation DCC++

« le: décembre 27, 2016, 01:06:51 am »

"Lire le type depuis le décodeur" mais aucune réaction.

J'ai une expérience limitée avec JMRI.

Lorsque tu ecris: aucune réaction, est-ce que tu obtiens un message d'erreur ou quelque chose?

En règle générale, lorsqu'on a du mal à communiquer avec un décodeur au moment de la programmation, on ajoute une résistance en série avec la loco/décodeur (120Ohm 2W). Peux-tu essayer cela?

Sinon, je ne peux pas trop parler pour JMRI. Je n'ai jamais eu de problème avec le DecoderPRO.

Patrick

14

Modélisation, Architectures logicielles et matérielles / Re : Les grandes lignes de mon projet d'automate DCC

« le: décembre 26, 2016, 09:22:20 pm »

Salut,

En fait, oui et non... Le système global n'est pas vraiment centralisé, mais il reste que le module DCC est un peu le point central du système. Beaucoup de messages passent par ce module avant d'être re-dispatcher aux autres modules mais sans sauvegarder d'états particuliers... Aussi, il a la connaissance de toute la topologie du réseau. Il permet quasi-exclusivement de sauvegarder la position des locos ou manager les priorités entre les trains... Dans un sens, c'est un point central, mais il ne connait rien de la signalisation.

Les cantons, quant à eux, sont totalement autonomes. Dès qu'un évènement de zone est détecté, il est "broadcasté" à tous les autres modules cantons afin de mettre à jour la signalisation et au module DCC pour le suivi des trains. Bien évidemment, comme tu le mentionnes, chaque canton a connaissance de ses voisins. Cela évite une fois de plus de passer par le module DCC pour gérer la signalisation.

Pour résumer, je dirais qu'un point important est d'éviter de sauvegarder trop d'états, mais au contraire, d'envoyer des requêtes d'infos auprès des autres modules lorsque nécessaire. Cela augmente le trafic CanBus, mais l'ensemble du système est plus autonome et plus robuste face aux bugs (décalage entre réalité du réseau et états des sauvegardes dans les différents modules). Par exemple, un module Canton A sauvegarde les signaux dont il a le contrôle. Si un voisin B veut mettre à jour ses propres signaux, il lance une requête vers A pour lui demander la position d'un signal et récupère la réponse. DCC n'a aucune connaissance de cet échange.

Voilà, j'espère que cela vous éclaire un peu plus ;-)
Au plaisir, et bonnes fêtes!
Patrick

15

Vos projets / Re : Re : Automate DCC

« le: décembre 23, 2016, 03:31:46 am »

J'avais vu ton site depuis longtemps et je trouve toujours que c'est du travail d'artiste !

Merci beaucoup.

Moi aussi (et d'autres évidemment, mais pas forcément très nombreux) j'ambitionne de réaliser l'automate DCC et plus généralement le gestionnaire complet de mon réseau sur une base Arduino (plusieurs en réseau CAN).

Tu as une avance considérable sur moi !

... mais cela fait un bout de temps que j'y travaille, entre le codage et le design des modules... Beaucoup d'essais/erreurs.

Peux-tu nous donner les grandes lignes de l'architecture et le fonctionnement de ton automate ?

J'ai démarré un autre sujet...

En tout cas passes de bonnes fêtes

Merci et bonnes fêtes à tous.

Patrick