Auteur Sujet: Protocole de pilotage  (Lu 1153 fois)

olc95

  • Newbie
  • *
  • Messages: 12
    • Voir le profil
Protocole de pilotage
« le: mai 30, 2019, 09:45:44 am »
Bonjour,

J'avance petit à petit sur mon projet de réseau, qui reposer notamment sur les cartes Satellite (V1) qui ont fait l'objet d'une excellente série d'articles sur locoduino.

Je souhaite piloter ces cartes à travers une interface SAM « maison ». Pour l'instant, côté informatique, je compte utiliser JMRI et m'appuyer sur un protocole de communication existant afin de ne pas réinventer la roue.

J'ai commencé à regarder OpenLCB, promu et supporté par le NMRA, et qui me semblait donc le candidat idéal de piloter les cartes. Sauf que je n'ai pas été capable de trouver une documentation simple sur le protocole. Est-ce que par hasard quelqu'un serait familier avec OpenLCB et/ou aurait un pointer vers une doc décrivant simplement le protocole avec quelques exemples ?

Dans l'immédiat, j'envisage du coup de plutôt partir sur C/MRI de Bruce Chubb. Le protocole est très bien décrit, et j'ai même trouvé une lib qui pourrait grandement faciliter l'interfaçage avec le bus CAN des satellites.

--
Olivier

nopxor

  • Jr. Member
  • **
  • Messages: 81
    • Voir le profil
Re : Protocole de pilotage
« Réponse #1 le: mai 30, 2019, 10:57:26 am »
Bonjour,

Pour C/MRI, il y a cette carte à base d'Arduino:
http://forum.locoduino.org/index.php?topic=507.0

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1438
    • Voir le profil
Re : Protocole de pilotage
« Réponse #2 le: mai 30, 2019, 03:40:27 pm »
Ca me semble à l’opposé du principe des satellites.

Tu peux utiliser un satellite V1 pour l’interface série - CAN tout simplement.
Cordialement

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1438
    • Voir le profil
Re : Protocole de pilotage
« Réponse #3 le: mai 30, 2019, 06:55:06 pm »
Je parlais de la réponse de noxpor. Olc95 déploie des satellites V1 avec une architecture repartie et donc la carte centralisée proposée par noxpor n'est pas la solution à son problème. Il veut juste une carte qui d'un côté discute avec JMRI sur la ligne série et de l'autre discute avec les satellites via le CAN.

D'ailleurs il parle de soft, pas de hard.

Enfin, ici, JMRI n'a pas à avoir connaissance de l'existence du CAN et je ne vois donc pas l'intérêt de C/MRI  :)
Cordialement

nopxor

  • Jr. Member
  • **
  • Messages: 81
    • Voir le profil
Re : Protocole de pilotage
« Réponse #4 le: mai 31, 2019, 12:04:57 pm »
Bonjour,

Le bus CAN de Locoduino n'est pas reconnu par JMRI.
Actuellement seul les bus CAN OpenLCB et CBUS MERG sont compatibles.
http://jmri.org/help/fr/html/hardware/can/index.shtml

D’où l’intérêt de C/MRI...

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1438
    • Voir le profil
Re : Re : Re : Protocole de pilotage
« Réponse #5 le: mai 31, 2019, 05:09:24 pm »
Enfin, ici, JMRI n'a pas à avoir connaissance de l'existence du CAN et je ne vois donc pas l'intérêt de C/MRI  :)

 :o :o :o :o CAN & C/MRI étant des bus respectifs, pourquoi le C/MRI n'a-t-il pas d'intérêt ? Chacun sa paroisse. De toutes manières les deux sont reconnus par JMRI.

Il me semblait avoir été clair par l'utilisation de ici. Il n'a pas d'intérêt ici car C/MRI marche avec un bus RS485 + un paquet de soft pour assurer tout ce qui est au dessus de la couche physique. Il n'a pas d'intérêt pour Olc95 qui est forcément en CAN.

Par ailleurs, ça pourrait être sympa de pouvoir discuter sans se voir accuser d'être de partie pris  ::)
« Modifié: mai 31, 2019, 05:17:06 pm par Jean-Luc »
Cordialement

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1438
    • Voir le profil
Re : Re : Re : Protocole de pilotage
« Réponse #6 le: mai 31, 2019, 05:16:24 pm »
Le bus CAN de Locoduino n'est pas reconnu par JMRI.
Actuellement seul les bus CAN OpenLCB et CBUS MERG sont compatibles.
http://jmri.org/help/fr/html/hardware/can/index.shtml
Wow dommage ! Ne serait-ce un peu se tirer une balle dans le pieds que de ne pas être compatible ? Ou quelles sont les contraintes imposant cette incompatibilité ?

Les contraintes sont de rajouter du logiciel dans JMRI. Si ça te tente, il suffit de faire un git clone https://github.com/JMRI/JMRI.git, je suis sûr que toute contribution sera favorablement accueillie  ;)

Je ne sais pas si c'est se tirer une balle dans le pied (comme précisé maintes fois, Locoduino n'a pas de but lucratif et donc pas de pied). De toutes façon une simple passerelle série/CAN fait l'affaire et est beaucoup moins complexe à implémenter.

Enfin, même remarque que ci-dessus : serait-il possible de discuter sereinement sans se faire attaquer avec des « Wow dommage », des histoires de « chapelle » et des « balles dans le pied » ?
« Modifié: mai 31, 2019, 05:27:34 pm par Jean-Luc »
Cordialement

msport

  • Hero Member
  • *****
  • Messages: 674
  • HO avec DCC++ en DIY Réseaux très éphémères
    • Voir le profil
Re : Protocole de pilotage
« Réponse #7 le: mai 31, 2019, 10:46:33 pm »
Bien d'accord que pour réaliser quelque chose qui marche, il faut déjà avoir les idées claires sur l'architecture qu'on veut mettre en œuvre en évitant de choisir des briques sympathiques au demeurant mais nécessitant des interfaces délicates à développer.

Peut-être (re)lire : Comment réussir son projet Arduino
http://locoduino.org/spip.php?article233
Cordialement

olc95

  • Newbie
  • *
  • Messages: 12
    • Voir le profil
Re : Protocole de pilotage
« Réponse #8 le: juin 01, 2019, 09:27:44 am »
Bonjour,

Je n'ai en effet pas retenu la piste consistant à implémenter le protocole du bus CAN des Satellites directement au niveau de JMRI. Je ne suis pas persuadé que le projet Satellite soit suffisamment populaire à ce jour pour que l'équipe de développement de JMRI accepte de merge-request un nouveau module. C'est pourquoi j'ai préféré rester dans l'idée d'un SAM qui s’interface au logiciel pour lui donner accès aux satellites de façon simple.

Bref, mon idée est plutôt de m'appuyer sur un protocole existant et supporté par JMRI. Faire ainsi présente l'énorme avantage de rendre le projet Satellite immédiatement utilisable avec tous les logiciels supportant le protocole retenu (très probablement C/MRI dans mon cas).

Peut-être que je fais fausse route et je veux bien en discuter. Je fais cela pour m'amuser, il n'y a pas d'enjeu derrière. Au pire j'aurai appris comment fonctionne un bus CAN et progressé dans la compréhension de JMRI ... ce qui sera déjà pas si mal ! :)

--
Olivier
« Modifié: juin 01, 2019, 12:59:31 pm par olc95 »

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1438
    • Voir le profil
Re : Protocole de pilotage
« Réponse #9 le: juin 02, 2019, 10:34:26 am »
En résumé si j'ai bien compris (j'ai survolé les docs) :

Le standard C/MRI couvre à la fois du matériel (transmission via RS485 le long d'une chaine de nœuds, chaque nœud assurant la transmission eu nœud suivant si le message n'est pas pour lui) et du logiciel : format de trame.

JMRI supporte un système de configuration des capteurs (et des actionneurs) pour un certains nombre de cartes compatibles C/MRI : USIC, SUSIC ou Smini. La SUSIC par exemple est une carte supportant jusqu'à 64 cartes filles, chacune avec 24 ou 32 lignes. Donc 64 x 32 = 2048 E/S

L'avantage est que JMRI permet de configurer ceci de manière plus conviviale via une interface graphique.

L'idée est donc de faire une carte qui, par exemple, se fait passer pour une SUSIC (enfin un peu moins, 2048 E/S c'est 158 Satellites mais on peut imaginer d'avoir des passerelles CAN-CAN de manière à monter au dessus de 100 nœuds). Elle reçoit des trames de JMRI via la ligne série. Ces trames sont telles que décrites dans un manuel payant mais que j'ai trouvé sur le NMRA : https://www.nmra.org/sites/default/files/standards/sandrp/pdf/S-9.10%20CMRInet%20DRAFT.pdf d'une part. D'autre part, elle transcode ces messages à destination de cartes Satellite V1 (ou V2). À l'inverse elle reçoit les messages des Satellites et les transcodes pour se faire passer pour une SUSIC.

C'est l'idée ?
Cordialement

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1720
  • 100% Arduino et N
    • Voir le profil
Re : Protocole de pilotage
« Réponse #10 le: juin 03, 2019, 10:47:02 pm »
Il y a pas mal de détails sur le site de JMRI :
http://jmri.org/help/fr/html/hardware/cmri/CMRI.shtml

avec une image qui en dit long :




Comme indiqué dans l'article http://www.locoduino.org/spip.php?article240, les satellites sont dans le collimateur : Dans un prochain article nous vous présenterons une manière de déporter les broches de lecture de détecteurs ou de sortie vers des actionneurs,
via un bus CAN, sans changer la configuration et les réglages de JMRI !

Mais ce sera dans un prochain article !
« Modifié: juin 03, 2019, 10:52:29 pm par Dominique »

olc95

  • Newbie
  • *
  • Messages: 12
    • Voir le profil
Re : Protocole de pilotage
« Réponse #11 le: juin 10, 2019, 11:32:36 pm »
Bonsoir,

Désolé pour le lag : pas mal de télescopage d'activités, je n'avance pas aussi vite que je souhaiterais ! :)

@Jean-Luc oui c'est l'idée. Peut-être plutôt émuler des smini (on peut en avoir jusqu'à 128), mais c'est précisément ça. Le projet ne coûte que le prix d'un mega 2560 et une carte CAN, donc le risque est maîtrisé ! :)

À bientôt,
--
Olivier

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1438
    • Voir le profil
Re : Protocole de pilotage
« Réponse #12 le: juillet 05, 2019, 09:32:49 am »
Bonjour,

Juste pour info, j'ai entrepris de coder un analyseur C/MRI et une émulation des SMINI dans le but de faire apparaître des satellites V1 comme des SMINI pout JMRI. C'est pas fini, ça ne fonctionne pas encore mais l'analyseur est implémenté (un automate pour le message et un pour le protocole) mais évidemment pas testé.

L'architecture objet permet d'ajouter l'émulation des autres cartes C/MRI par la suite. Ça sera étendu aux satellites V2 dans le futur.

Il y a encore de travail : un peu de code à écrire et beaucoup de test.

Le repository est ici : https://github.com/Locoduino/CMRIParser

PS : J'ai examiné la bibliothèque de madleech : https://github.com/madleech/ArduinoCMRI. Elle ne me satisfait pas.
Au moins deux bugs sont présents : lignes 115 et 130 les tests sont faux
La transmission fait une attente active (appel de delay) de 50ms, bloquant les autres opérations sur la carte
La transmission est monolithique et bloque potentiellement sur le buffer d'émission.
« Modifié: juillet 05, 2019, 12:32:29 pm par Jean-Luc »
Cordialement