Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - bobyAndCo

Pages: [1] 2 3 ... 54
1
Je reviens sur l'usage de l'ACS712 et des ses "limites".

Laurent,

Pour moi la question de l'ACS712 ne se pose plus dans le cadre du sujet qui nous intéresse ici. Je n'ai jamais caché mes limites en électronique, mais il me semble que Etienne démontre bien du le zmct103c fait le job, tant pour les courants faibles que pour des courants dépassant 1 ou quelques ampères ce qui permet aussi de traiter les courts-circuits.

Le montage d'Etienne me semble être celui de Cédric avec quelques différences de composants. Or connaissant Cédric, il n'y a pas de doute à avoir quand il dit que ça fonctionne.

Je suis 100% d'accord avec toi sur les limites de l'ADC de l'ESP32, d'où l'intérêt, dans un montage un peu conséquent comme les satellites autonomes, de dédier un composant à cette tâche exclusivement.

Perso, je vais essayer avec un ATTiny car j'avoue que je ne trouve pas très simple le codage et le fonctionnement pour les composants (MEGATinny) que tu préconises. Mais bon, au stade des tests ça n'a pas grande importance.

Christophe

2
La question était en fait, si toutes les leds sont allumées en même temps, cela représente quelle valeur de courant "tiré" sur le MEGA en même temps ?

3
Voilà qui me semble une optimisation optimale de ce que l'on peut faire pour un TCO avec un MEGA.

@Dominique, je ne comprends pas 5 x 74HC595 chainés = 3 pattes ? Je pensais que l'on ne pouvait enchainer que deux 74HC595.

Combien de leds peuvent-être allumée en même temps ? Ou, ce qui est la question exacte, quel est le courant maxi nécessaire pour les leds ?

Christophe

4
Aide / Re : Dcc++base station + DCC controler
« le: février 26, 2024, 04:53:05 pm »
Mario,

Tout d’abord et nous le répétons régulièrement, il n’y a pas (ou peu) de questions stupides, surtout quand elles émanent de débutants qui ont envie de progresser et qui s’en donnent les moyens. Par contre, il est arrivé que nous en ayons vu persister dans l'erreur, s'enfoncer dans les ténèbres et finalement sombrer dans le chao malgré les conseils que nous avons pu leur apporter. Ce dernier cas de figure existe en effet.

Ceci dit, je vois à quelle station tu fais référence, c’est un article que j’ai rédigé. Il est estampillé avec deux étoiles (sur trois) ce qui veut dire qu’il s’adresse à des « niveaux » confirmés en Arduino, électronique et accessoirement en programmation Arduino.

Cet article date de 2016, et bien que tout soit encore d’actualité, des possibilités plus faciles (moins DIY) sont accessibles aux débutants.

Dans ton cas, puisque tu possèdes le Mega, la carte moteur et le shield Ethernet, je te conseille de construire une centrale avec le logiciel DCC-Ex (évolution de DCC++) aujourd’hui adopté par Locoduino et qui sera rapidement opérationnelle. Tu trouveras facilement sur Locoduino des utilisateurs pour t’aider au besoin.

Il est vrai que la solution que je proposais dans l’article offre une interface de conduite de locomotives. Cela sera toujours possible avec la centrale DCC-EX, on en reparlera d’autant que j’avais justement pour projets dans les semaines qui viennent de reconstruire exactement ce que je viens de te décrire (Mega + Ethernet + DCC-Ex) Seule la carte moteur sera différente, LMD18200 dans mon cas.

Donc regarde d’abord ici : https://dcc-ex.com/ex-commandstation/get-started/index.html#gsc.tab=0

Réalise une station pilotée par le port USB (sans Ethernet pour l’instant), fais bouger des locomotives et reviens vers nous.

Intéresse-toi aussi à JMRI qui est une bonne solution pour le pilotage simple et pour la programmation des CVs. Tu pourras débuter avec JMRI.

Enfin, regarde avant de te lancer les différents articles rédigés par msport, ils sont très didactiques et abordables avec peu de connaissances. En voici un avec JMRI justement : https://www.locoduino.org/spip.php?article305

En espérant avoir pu t'aider.

Christophe



5
Aide / Re : Dcc++base station + DCC controler
« le: février 26, 2024, 01:59:07 pm »
Bonjour Mario,

Peux tu préciser certaines choses ?

Quelle carte moteur exactement ? Quel shield Ethernet exactement ? Avec quel système envisages-tu de piloter la centrale ? Logiciel, JMRI, Rocrail ? ou manette physique comme a pu en présenter par exemple Michel ? Quelle échelle (ça peut aider).

Le choix de l'Ethernet, pas du tout critiquable loin de là, répond-il à une raison précise ou non ?

Il existe plein de solutions sur Locoduino, dont celles de Michel (msport) qui a du proposer 5 ou 6 montages, il faut juste nous orienter.

Christophe

6
Aide / DÉPLACÉ: Carte ESP32 universelle + CAN
« le: février 26, 2024, 04:31:01 am »

7
Vos projets / Re : Carte ESP32 universelle + CAN
« le: février 26, 2024, 04:30:18 am »
Bonjour,

Pour le lien sur le PCB de la carte ESP32 universelle, il est ici : https://forum.locoduino.org/index.php?topic=1648.msg17802#msg17802

ou plus directement ici : https://www.locoduino.org/IMG/zip/esp32_can_v6_38_pins_gerber-2.zip

Tu notes bien que tous ls composants ne sont pas obligatoirement à commander.

Le fil pour la centrale DCC Railcom est ici : https://forum.locoduino.org/index.php?topic=1352

Le programme de la centrale est téléchargeable ici : https://github.com/BOBILLEChristophe/DCCxx-ESP32-Railcom

Bien lire le readme sur la première page du Github qui donne les pins à raccorder. En particulier pour le CAN qui utilise le broches 22 et 23 au lieu de 4 et 5 habituellement.

#define CAN_RX GPIO_NUM_22
#define CAN_TX GPIO_NUM_23

Pour les autres broches :

#define PIN_PWM GPIO_NUM_12 // ENABLE (PWM)
#define PIN_DIR GPIO_NUM_13 // SIGNAL (DIR)
#define PIN_BRAKE GPIO_NUM_14 // CUTOUT (BRAKE)
#define CURRENT_MONITOR_PIN_MAIN GPIO_NUM_36 // Mesure de courant

Pour les composants, s'il t'en manque ou si parfois il faut commander de trop grosses quantités, tu me fais signe car j'ai pas mal de réserve.

Attention aussi à commander les bons ESP32 (wroom, 2cœurs, 240Mhz, 38 pins) En cas de doute, ne pas hésiter à m'envoyer le lien.

Je vais aussi relancer une commande de PCB pour les satellites (mais ce n'est pas ce qui coute le plus cher).

Et n'hésite surtout pas à partager si tu as des questions, des problèmes ou si tout fonctionne bien pour en faire profiter tout le monde.

Christophe

8
A mes heures perdues (trop peu nombreuses...) je tente de controler Labox via le CAN,

C'est mieux que d'aller au bistrot !

- Je pense qu'il est nécessaire d'établir un protocole CAN défini, même si il l'est uniquement à l'échelle de locoduino. Cela permet à chacun de pouvoir apporter sa petite pierre à l'édifice à coté des développeurs chevronnés qui sévissent ici et de s'assurer de la compatibilité du code dans le temps.  (une petite manette CAN, un TCO, un accessoire,....)

C'est ce que nous sommes en train de réaliser. Cela fait un petit moment que nous échangeons après avoir étudier de nombreux autres protocoles dont celui de Marklin qui m'a le plus inspiré. En fait, l'implantation du CAN dans la Box avec la structure de messages que je propose doit valider (ou non) cette proposition, ce pourquoi j'ai profité de la perche tendue par Thierry pour relancer le sujet.

- Le protocole doit rester abordable: le gros avantage de DCCex était quand même d'être controlé par des instructions simplissimes <1 xx xxx ....> Un débutant sait très vite envoyer une instruction sur un port série. Son principal inconvénient était de ne communiquer que dans un sens.
La nécessité initiale du CAN était d'apporter cette communication bidirectionnelle au gestionaire.

Non le protocole sous forme <1 xx xxx ....> ne communique pas que dans un sens. Pour les commandes CAN de la Box, j'ai également programmé les confirmations de réception de commandes avec le CAN mais je me suis limité à celle qui sont d'origine dans DCC++ /DCC Ex ! On pourra élargir si le besoin est exprimé.

J'ai étudié les liens que Christophe m'a indiqué sur le CAN avec les possibilités de filtre. Rien n'est insurmontable ..... mais a t'on besoin d'apporter de la complexité supplémentaire?
(Concernant les satellites autonomes, c'est un concept tellement différent que les besoins en communication peuvent être différents également.)

Je ne crois pas apporter de la complexité, même en CAN, tu pourrais toujours communiquer "à l'ancienne <1 xx xxx ....>". Le propre d'un protocole c'est justement de pouvoir répondre à TOUS les besoins avec la même structure. La structure pour les satellites est la même. Comme le petit programme pour le TCO que j'ai mis en ligne ce matin. C'est le propre d'un protocole, sa raison d'être que ce soit la même chose pour tout le monde.

Je ne veux surtout pas froisser les développeurs qui font un travail monstre, qui ont conçu Labox plein d'autres choses, mais en tant qu'amateur, on se sens vite largué quand on voit l'évolution impressionnante des projets, et de ce fait on se dit qu'on ne peut pas apporter grand chose... Je pense qu'il ne faut pas perdre l'aspect pédagogique et abordable pour l'amateur.
En tous cas, encore félicitations pour tout le travail accompli et aussi pour votre réactivité sur les forums quand on pose des questions. On ne reste jamais bloqué très longtemps.

Merci pour les appréciations.

Malheureusement, nous sommes actuellement essentiellement sur des projets complexes. Il n'existe pas vraiment de programmes simples pour les projets complexes. Par contre, nous faisons en sorte, Thierry en particulier, moi aussi, de faire que cela soit très simple côté utilisateur.

Pour finir, je prendrais le cas des commandes pour la Box. Les seules commandes que l'utilisateur ait besoin de connaitre sont dans le fichier à partir de la ligne 54, tu avoueras que ce n'est tout de même pas très compliqué : https://github.com/BOBILLEChristophe/Test_CommCan_LaBox/blob/main/src/Test_CommCan_LaBox.cpp

Et en plus j'ai mis des commentaires explicites.

Quand nous serons d'accord sur la structure des identifiants CAN et accessoirement des datas il faudra rédiger effectivement toute la correspondance des fonction, ce ne sera pas de la tarte.

Pour vous donner une idée, je vous joins la doc du protocole CAN de Marklin, ça va vous donner une idée du boulot à venir. Et encore, je n'ai traduit que la moitié environ ! Le lien vers le document original est au début de la traduction, il comporte 68 pages.

Christophe

PS : Peut être les responsables de ce fil préfèreront-ils ouvir un nouveau sujet pour le CAN qui n'est d'ailleurs pas spécifique à la Box ?

9
Pour ma part, je préférerais la solution d'une carte à laquelle je pourrais envoyer un signal via un TCO physique (bouton poussoir) et qui serait capable de transmettre mes ordres aux aiguilles concernées...
Cette solution existe-t-elle ?

Pour répondre au souhait de LocoFred de réaliser un TCO « physique », avec des boutons poussoirs pour changer la position des aiguilles sur les satellites autonomes, j’ai écrit ce petit programme qui fait le job.

Je suis parti d'un postulat qui est que nous avions 10 aiguilles (donc 10 boutons)
const uint8_t nb_btn = 10;           // Nombre de boutons
Que la première broche utilisée (sur un Mega) est la broche 20.
const byte firstBtnPin = 20;         // Première broche de connexion des boutons
Que les boutons actionnent dans l'ordre les aiguilles des satellites comme suit :
  btn[0].sat = 11; btn[0].aig = 0;
  btn[1].sat = 11; btn[1].aig = 1;
  btn[2].sat = 12; btn[2].aig = 0;
  btn[3].sat = 12; btn[3].aig = 1;
  btn[4].sat = 12; btn[4].aig = 2;
  btn[5].sat = 13; btn[5].aig = 0;
  btn[6].sat = 14; btn[6].aig = 0;
  btn[7].sat = 14; btn[7].aig = 1;
  btn[8].sat = 15; btn[8].aig = 0;
  btn[9].sat = 16; btn[9].aig = 0;

La bibliothèque CAN utilisée est acan2515 de Pierre Molinaro : https://github.com/pierremolinaro/acan2515/tree/master

Le shield CAN recommandé est celui de SEED Studio : https://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/
qui autorise 1Mbps de débit.

Sur un Mega, il sera nécessaire de respecter le brochage suivant :



Voici le code que vous pouvez aussi télécharger :



/*
    Etude du programme pour des commandes d'aiguilles à partir de boutons poussoirs sur un TCO (physique)
    à destination des satellites autonomes
    Ce programme est destiné à fonctionner sur Arduino Uno ou Mega.

    Les broches sont commutées sur HIGH à l'état repos de boutons poussoirs par activation des résistances PULLUP internes
    Elles sont commutées sur LOW par l'appui sur le bouton poussoir lorsqu'elles reçoivent un signal à la masse (GND)
    Cet état LOW correspond au bouton appuyé.
   
    v 0.0.1 - 21/02/2024

    copyright (c) 2024 christophe.bobille - LOCODUINO - www.locoduino.org
*/

const byte thisNodeId = 252;         // N° de nœud CAN du TCO sur le bus

const uint8_t nb_btn = 10;           // Nombre de boutons
const byte firstBtnPin = 20;         // Première broche de connexion des boutons
const uint32_t delayDebonce = 100;   // Delay du debonce (en millisecondes)
const uint32_t delaySendMsg = 2000;  // Delay entre l'envoi de messages CAN (en millisecondes)


class Button
{
private:

public:
  byte ID;
  byte pin;
  bool pressed;
  uint32_t lastDebounceTime;
  uint32_t lastTimeSendMsg;
  byte sat;
  byte aig;
  Button();
};

Button::Button()  // Constructeur
  : ID(0),
    pin(255),
    pressed(false),
    lastDebounceTime(0),
    lastTimeSendMsg(0) {}

Button btn[nb_btn];  // Instances de Button

/************************ ACAN *****************************/
// If you use CAN-BUS shield (http://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/) with Arduino Uno,
// use B connections for MISO, MOSI, SCK, #9 or #10 for CS (as you want),
// #2 or #3 for INT (as you want).
#include <ACAN2515.h>
static const byte MCP2515_CS = 53;  // CS input of MCP2515 (Arduino Mega)
static const byte MCP2515_INT = 2;  // INT output of MCP2515 (Arduino Mega)
ACAN2515 can(MCP2515_CS, SPI, MCP2515_INT);
static const uint32_t QUARTZ_FREQUENCY = 16UL * 1000UL * 1000UL;  // 16 MHz

CANMessage frame;  // Instance de CANMessage
/**********************************************************/

void setup() {
  Serial.begin(115200);

  /************************ ACAN *****************************/
  //--- Begin SPI
  SPI.begin();
  //--- Configure ACAN2515
  Serial.println("Configure ACAN2515");
  ACAN2515Settings settings(QUARTZ_FREQUENCY, 1000UL * 1000UL);  // CAN bit rate 1000 kb/s
  const uint16_t errorCode = can.begin(settings, [] {
    can.isr();
  });
  if (errorCode != 0)
  {
    Serial.print("Configuration error 0x");
    Serial.println(errorCode, HEX);
  }
  /************************ ACAN : paramètres du messages *******************/
  // Structure de l'identifiant des messages CAN : https://www.locoduino.org/IMG/png/satautonomes_messageriecan_v1.png
  const byte prio = 0x03;     // Priorité la moins élévée
  const byte commande = 0xE1; // Identifiant des commandes d'aiguilles pour les satellites autonomes
  const byte resp = 0x00;     // Ceci n'est pas une réponse


  frame.id |= prio << 27;        // Priorite 0, 1 ou 2
  frame.id |= commande << 19;    // commande appelée
  frame.id |= thisNodeId << 11;  // ID expediteur
  frame.id |= resp << 2;         // Response
  frame.ext = true;                 // Identifiant long (29 bits) = true
  frame.len = 2;                     // Nombre d'octets de données du message
  /**********************************************************/


  for (byte i = 0; i < nb_btn; i++)
  {
    btn[i].ID = i;
    btn[i].pin = firstBtnPin + i;
    pinMode(btn[i].pin, INPUT_PULLUP);
    Serial.print("setup btn : ");
    Serial.println(i);
  }

  // Exemple d'aiguilles à commander
  // sat désigne sur quel satellite s'applique la commande
  // aig désigne sur quelle aiguille de ce satellite s'applique la commande
  btn[0].sat = 11; btn[0].aig = 0;
  btn[1].sat = 11; btn[1].aig = 1;
  btn[2].sat = 12; btn[2].aig = 0;
  btn[3].sat = 12; btn[3].aig = 1;
  btn[4].sat = 12; btn[4].aig = 2;
  btn[5].sat = 13; btn[5].aig = 0;
  btn[6].sat = 14; btn[6].aig = 0;
  btn[7].sat = 14; btn[7].aig = 1;
  btn[8].sat = 15; btn[8].aig = 0;
  btn[9].sat = 16; btn[9].aig = 0;
}

void loop()
{
  for (byte i = 0; i < nb_btn; i++)
  {
    // Le bouton est détecté comme appuyé
    if (LOW == digitalRead(btn[i].pin))
    {
      // L'état pressed est vrai et le delay de debonce est dépassé
      if (btn[i].pressed && millis() > btn[i].lastDebounceTime + delayDebonce)
      {
        // Le delai par rapport au dernier envoi est dépassé
        if (millis() > btn[i].lastTimeSendMsg + delaySendMsg)
        {
          // Envoi du message CAN de commande
          frame.data[0] = btn[i].sat;  // ID satellite destinataire
          frame.data[1] = btn[i].aig;  // Aiguille à commuter
          const bool ok = can.tryToSend(frame);
          if (ok)
            btn[i].lastTimeSendMsg = millis();
          else
            Serial.println("Send failure");         
        }
        btn[i].lastDebounceTime = millis();
      }
      btn[i].pressed = true;
    }
    else
      btn[i].pressed = false;
  }
}


10

Lorsque l'on associe une paire de satellites le fait de presser 1 bouton sur le premier va faire clignoter la led de celui ci.

OUI


Cet état de clignotement reste présent sur chaque satellite dont 1 bouton est pressé tant que le processus d association n'est pas achevé.

OUI


Le processus d'association bascule la led en allumage FIXE une fois le processus d'appairage achevé ET que 1 bouton sur chaque satellite reste pressé.


OUI

Elle est OFF ensuite en fois les boutons relâchés.


OUI

C est bien cela? ( elle est OFF en utilisation normale)

OUI

Si par "accident" un bouton d'appairage est pressé sans autre binôme dans le processus de découverte il n'y a pas de modification des attributions existantes?

NON

Que se passe t il si un satellite n'a pas de voisin? (soit horaire soit antihoraire) C'est le cas d'une voie en impasse par exemple.( tiroir ou gare terminus)
J'imagine que le soft gèrera le ralentissent dans la zone traitée par ce satellite et arrêtera le train une fois le capteur ponctuel horaire atteint. C'est bien cela?


OUI, s'il n'y a aucun satellite identifié à la sortie d'un canton (en fonction de la position des aiguilles éventuellement) on est dans le même cas que pour un canton occupé, le signal se met au rouge, le train frein puis s'arrête !


Pour un mouvement dans le sens de circulation opposé, y a t il des critères à avoir?


Pas comprendre la question

Tout mouvement des lors que les sécurités de "bloc automatique" sont respectées sont autorisées dans une zone d'un satellite donné?

Les commandes des trains ne suivent pas la signalisation qui n'est la que pour la décoration. Le satellite déduit des possibilités en fonctions de son environnement (position des aiguilles, occupation ou non de cantons voisins (jusqu'à +2). Ce sont ces états qui conditionnent si l'on peut appliquer tel ou tel ordre à une locomotive et qui déduisent la signalisation adéquate.

11
Tu as tout à fait raison. La prochaine version sera donc une 2.5.0 eu égard à l'importance stratégique de l'ajout !

Je suppose que ce message m'était destiné vu qu'il venait chronologiquement après mon message. Il faudrait tout de même que l'on en discute pour définir certaines choses (filtre CAN ou pas), les fonctions (DCC) sont elles suffisantes, en ai-je oublié ? La structure des messages CAN que j'ai retenue vous convient-elle ? (29 bits etc...) ?

Il faut aussi que je mette à jour le Github de Locoduino (ce que je peux faire d'ici 3 ou 4 jours) et que je teste à nouveau ce que je ne peux pas faire avant mon retour le 6 mars.

Christophe

12
A noter qu'aujourd'hui je suis le seul à proposer des améliorations sur le code. Il est pourtant gratuitement et entièrement disponible sur Github, et n'importe qui peut le prendre, le modifier, l'améliorer. Donc si toi au d'autres veulent aider, c'est tout à fait possible !

Bonjour Thierry,

Je profite de ce que tu abordes le sujet pour rappeler que j'avais proposé il y a quelque temps du code pour l'intégration du CAN dans la box. Je pense que toutes les commandes y étaient, commande de traction, de fonction, de power on/off et même le e-stop. La dernière version de ce travail date du 11/12/23 mais depuis je n'ai pas eu de nouvelles !!!

Visible sur lune branche créée ad hoc sur le GitHub de Locoduino : https://github.com/Locoduino/CommandStation-EX-LaBox/blob/CAN-messaging/CanMsg.cpp

J'avais aussi réalisé un fichier de test qui permettait de tester toutes ces fonctions et je l'avais fait sur mon réseau avec succès : https://github.com/Locoduino/Test_CommCan_LaBox

Sans réponse, je n'ai pas continué les mises à jour ce qu'il faudrait faire aujourd'hui.

Bien amicalement

Christophe

13
Bonjour et merci à tous,
je me lancerais bien dans la fabrication de quelques modules (3 ou 5) pour commencer et tester, mais il me manque encore quelques infos...
Peut-être ont-elles déjà fait l'objet de réponses, mais ou je ne les ai pas trouvées, ou je ne les ai pas comprises...

Bonjour Frédéric,

Tu trouveras ci-dessous les réponses à tes questions toujours très pertinentes.

Il y aurait dans les tuyaux ou dans les tiroirs une "V2" des satellites autonomes, mais encore en développement ?..
Et si j'ai bien compris, celle-ci, la "V1" est opérationnelle et l'on peut se lancer dans sa fabrication ?..

C’est vrai que cette « évolution » que Laurent a lancée aurait mérité un peu plus d’explications sur son positionnement et sa raison d’être. Je ne doute pas qu’il le fera sur le fil de son projet. C’est vrai que la dénomination V2 n’est pas appropriée et je ne sais d’ailleurs pas comment elle est apparue.

De ce que moi j’en comprends, il s’agit d’une version « plus musclée » qui correspondrait mieux à de plus grands réseaux (on parle de cantons de 3 mètres !!!), qui prendrait en charge plus d’équipements (plus d’aiguilles par exemple) et chercherait à améliorer ce qui pourrait éventuellement l’être dans mon projet.

Mais comme je l’ai dit, Laurent t’apportera mieux que moi ces réponses.

Pour ce qui est des satellites autonomes (pas v1), oui elle est opérationnelle, cela fait maintenant six mois environ que je la teste sur mon propre réseau.

2°/  Pour ce qui est de la commande des aiguilles adressée au satellite par le bus can, j'en ignore tout de la mise en œuvre :
J'imagine (mais j'ai peut être trop d'imagination), qu'il doit falloir insérer un nouveau nœud dans le bus qui relie déjà les satellites et les deux cartes Main et watchdog,
mais alors, si c'est bien le cas, à quoi est relié ce nœud ?..
Une carte capable de générer le message de changement de direction et de l'envoyer à la bonne adresse, ou une "manette" de pilotage reliée à la centrale qui serait capable de faire la même chose en plus des commandes destinées aux locos ?
Pour ma part, je préférerais la solution d'une carte à laquelle je pourrais envoyer un signal via un TCO physique (bouton poussoir) et qui serait capable de transmettre mes ordres aux aiguilles concernées...
Cette solution existe-t-elle ? (Au regard de toutes vos inventions, j'ai du mal à imaginer le contraire)...
Où puis-je la trouver avec ses explications, schémas, Gerber, codes, etc ?..
Locoduino est un grand bazar (au bon sens du terme), super bien achalandé, mais dans lequel j'ai encore un peu de mal à m'y retrouver...

Ce qu’il faut essentiellement avoir présent à l’esprit, c’est que les satellites autonomes privilégient la communication par le bus CAN à toutes autres forme de communication quand cela est possible. Le TCO n’échappe pas à la règle.

Donc je te redis clairement ce que j’ai dis déjà la dernière fois, les satellites reçoivent en effet les ordres de commande des aiguilles sous forme de messages CAN.

Il y a plusieurs façons d’envisager un TCO, il peut être virtuel, sur tablette ou écran ou bien physique avec de vrais boutons, de vraies leds etc… Le fait de communiquer en CAN permet au satellite autonome de répondre à toutes les formes choisies.

Puisque tu penses TCO physique, voici comment je procéderais. Les boutons de commande des aiguilles étant des boutons poussoirs répartis sur le tableau avec une lisibilité et une ergonomie maximale. Mais en tant que graphiste, tu dois savoir faire. Pour le micro contrôleur, je choisirais un Mega pour avoir d’emblée beaucoup d’entrées (boutons…) et de sorties (leds…).

Je choisirais un shield CAN (plutôt un Seeed Studio) qui fonctionne à 1Mbs : https://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/

Ce Mega avec son shield s’insèrent dans le bus CAN très simplement en reliant les fils du précédent et du suivant. Il devient de cette façon un nouveau nœud du bus CAN mais sans rien de plus.

Selon que l’on appuie sur tel ou tel bouton, le programme du Mega détecte que la commande est adressée à tel ou tel satellite et que cela concerne le servo 0, 1, 2 ou 3 du satellite. Et il allume alors la led correspondante.

Voilà, je ne veux pas faire trop long mais tu as ici le principe général pour un TCO physique. Il y en a eu un article, il y a longtemps mais c’était en xpressnet : https://www.locoduino.org/spip.php?article42

Ca peut te donner une idée.

Je suis très partant pour réaliser le programme pour un bus CAN si tu réalises la partie « physique ». Ce sera un bon sujet à partager.


3°/ Pour ce qui est de l'utilisation d'une centrale compatible RailCom®, peut-on se lancer dans la fabrication de "La Box" comme ça semblerait être proposé dans le post
"Détection RailCom© avec ESP32 (ou Arduino)" (https://www.locoduino.org/spip.php?article334) ou vaut-il mieux faire confiance au projet de Christophe,
"Une station DCC compatible RailCom" (https://forum.locoduino.org/index.php?topic=1352.0) ?..
Quelqu'un pourrait-il également m'indiquer le lien à suivre pour envisager la fabrication de la centrale idoine ?..
Une fois encore, je présume qu'il y aura un nouveau "nœud" reliant la centrale à notre bus ?..

Décidément, tu sais aborder les bons sujets !

Oui les satellites autonomes ont besoin sur le réseau d’une centrale DCC qui puisse générer un cutout. A l’heure actuelle, la Box ne dispose pas de cette faculté.

Alors, je ne parlerai pas de « confiance » pour la station que j’ai réalisée mais simplement d’option à ce stade. Oui cette station, couplée à une carte LMD18200 est la seule qui puisse être aujourd'hui utilisée avec les satellites autonomes. Mais cette station, qui fonctionne, était au départ un sujet de recherche et d’expérimentation en attendant Railcom sur la Box. Je ne souhaite pas en assurer le support ni les évolutions. Elle peut cependant être adopté en sachant qu’il faudra un jour basculer et que cela n’induit aucun cout qui ne soit réutilisable comme le LMD18200.

Dans un second temps, comme la version Railcom de DCC Ex sera disponible sur Mega (l’est peut-être déjà en Beta), je pense que ce sera une bonne évolution. Toujours avec un LMD18200

L’insertion de cette station dans le bus CAN se fera aussi simplement que montré plus haut et deviendra alors un nœud CAN également.

Et pour terminer,

4°/ Pour faire circuler les informations du can et le 12/24v, de quels câbles avons-nous besoin ?
     - RJ45 (4 paires) ou RJ12 (3 paires) ?
     - Câbles droits ou croisés ?
     - Blindés ou non ? (J'ai bien vu toutes les interventions et croisements de fers, mais je n'ai pas réussi à me faire une opinion...
     - Quelles sont les identifications de chaque fil ?

Pour tous ceux qui le souhaiteraient, je suis prêt à m'associer à une commande de PCB, avec ou sans les fournitures concernées,
pour la fabrication de 3 ou 5 cartes satellites,
la même quantité pour les cartes de détection du signal Railcom©
et 2 pcb pour la Main et la Watchdog... Et plus si affinités...

Il s’agit de câbles RJ45 de catégorie 5 ou 6. Pas de câble croisé (mais cela existe-t-il encore ?). En catégorie 5 ou 6 je crois qu’ils sont d’office blindés. C’est du basique, ce qu’il y a de plus courant et de moins cher (moins d’un €).

En utilisant ces câbles tu n’as pas de soucis d’identification des fils, sauf option particulière que je ne recommande pas mais je te donnerai alors l’identification si tu procèdes ainsi.

Comme tu es le premier à te lancer, je te propose de t’accompagner pas à pas et effectivement de faire des commandes groupées. J’allais justement envoyer une commande de PCB, je peux en mettre 5 de plus.

Par ailleurs, j’ai tous les composants en quantité et je dois envoyer une nouvelle commande (pour ce projet et d’autres).

Ce que je te propose pour tout ce qui est de nature perso, c’est d’échanger en MP.

Christophe

14
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 20, 2024, 03:03:43 pm »
Bonjour Laurent,

Comme je te l’ai déjà dit plusieurs fois j’ai vraiment du mal à te suivre. Tu nous présente des cartes mais dont on ne sait pas exactement ce qu’elles font et comment elles fonctionnent. Je ne sais pas faire de schémas électroniques mais je sais les comprendre.

Tu nous dit : Il sera plus simple d'en équiper les extrémités de canton plutôt que de tirer du fil d'un bout à l autre pour les sonde PT19 ou PT204.

Je ne sais pas ce qu’est un PT19 ni même un PT24.

Alors si tu ne tires pas de fils, comment exploite t’on le signal ?

Et puis tu nous dit que tout de même il faut tirer des fils, alimentation, certes mais tout de même.

Comme suggérer par Dominique, je crois qu’il faut isoler ce qui est de la recherche pure du fil du forum. Et il faut poser un peu plus les choses. Comme cette carte par exemple, je ne doute pas qu’elle soit intéressante mais elle arrive comme cela, sans prévenir. Je ne savais pas qu’il y avait un problème avec les capteurs ?

Quant à la question sur les leds ? Que puis-je te répondre si ce n’est que OUI cette led est importante. Je pense que cela se comprend à la lecture de l’article sur le processus de découverte.

Christophe

15
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 20, 2024, 01:44:18 am »
Laurent,

Je poursuit sur ton fil pour ne pas polluer celui de la Box. Donc je pense que tu comprends bien que le problème est côté génération du cutout, espace de quelques centaines de µs inséré dans la trame DCC.

Extrait de l'article sur Railcom : Railcom© nécessite que les trames DCC envoyées sur le réseau contiennent un « cutout », c’est-à-dire une suspension de l’alimentation d’environ 460 µs pendant laquelle le décodeur transmet un court message (généralement deux ou quatre octets) incluant son adresse. Ce cutout est réalisable assez simplement avec une centrale DCC en DIY.

Par ailleurs, il faut une carte moteur qui dispose d'une entrée break, il n'y en a pas tant que cela mais le LMD18200 en fait partie. Carte dont il faut dire au passage que les gens de DCC-Ex la trouve ringarde et obsolète. Mais je crois qu'ils n'aiment pas grand choses en dehors de ce qui sort de chez eux.

Pour les satellites, pas de problème, on changera de centrale au besoin, probablement Mega + (pour moi) shield Ethernet + LMD18200.

Pour l'instant, ma centrale fait le job, mais je ne souhaite pas faire le support, donc pour de multiples raisons, il était préférable que Railcom fonctionne avec la Box.

Ai-je bien répondu à ta préoccupation ?

Christophe

Pages: [1] 2 3 ... 54