Messages récents

Pages: [1] 2 3 ... 10
1
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« Dernier message par Dominique le Aujourd'hui à 09:45:16 am »
Je donne deux exemples :

1) Activer les fonctions d’une locomotive d’adresse DCC donnée à partir d’un message Can  :
- marche avant, arrière, stop, vitesse, direction
- et fonctions du décodeur, etc..
C’est simple ici le décodage du message Can s’interface avec les fonctions prévues dans Dcc-ex.

Mais il y d’autres façons de commander cette machine avec LaBox (port serie-usb, wifi, tcp…HMI) et j’ai besoin pour mon gestionnaire de recevoir un message qui décrit le changement de régime de cette machine (mais pas les fonctions lumière-sons) a chaque changement.
Est-ce qu’on dispose des interfaces pour faire cela ?

Peut-être faudra-t-il aussi envoyer un message à la lecture de l’adresse d’une machine.

2) les fonctions Can dans LaBox vont occuper du temps CPU (setup et loop) qui ne doit être activé que si on s’en sert. Heureusement un « USECAN » peut être utilisé si besoin.

Donc il faudra permettre des mises en œuvre conditionnelles selon les besoins de chacun .

Je n’ai pas eu le temps de regarder le protocole Can des tableaux de bord des voitures, sans doute intéressant pour une approche TCO, mais regardons d’abord nos propres besoins.

Comme je l’ai dit précédemment je ne suis pas totalement dispo pour proposer des éléments de protocole qui ne remettent pas en cause ceux proposés par Christophe (sauf identifiants et filtres à simplifier et compléter) et il faudra trouver une manière souple de coder ce protocole pour l’adapter à ses besoins.

A suivre
Dominique
2
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« Dernier message par Dominique le Aujourd'hui à 08:55:39 am »
Bonjour à tous,

Je savais que ça allait arriver: nous y sommes maintenant !

Définir un protocole Can est nécessaire. Qu’il serve à tout le monde est aussi nécessaire. Mais la, ce n’est déjà plus tout à fait possible.

As-t-on besoin de tout le protocole de Marklin ?
Sûrement pas.

Le protocole proposé par Christophe est adapté à ses satellites autonomes qui nécessitent une centrale Railcom ! Ce n’est le cas actuellement.

Nous devrions commencer par un protocole simple et didactique, utile surtout.
Peut-on définir d’abord les messages et les fonctions de base qui pourront s’étendre plus tard.
Je n’ai pas encore tout le temps souhaitable pour apporter mon expérience. Ce week-end sera le mieux.
3
Vos projets / Re : Re : LaBox" : Une Centrale DCC polyvalente et abordable
« Dernier message par bobyAndCo le Aujourd'hui à 01:35:07 am »
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 .ino à partir de la ligne 110, tu avoueras que ce n'est tout de même pas très compliqué : https://github.com/BOBILLEChristophe/Test_CommCan_LaBox_2/blob/main/Test_CommCan_LaBox_2.ino

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 ?
4
Composants / Re : PCB la Box
« Dernier message par becbunsen le février 21, 2024, 11:02:48 pm »
Un peu tard peut-être mais je vais revendre 2 PCB, avec eventuellement des composants, j'avais presque tout acheté pour les 5 exemplaires)
N'hésite pas à me contacter
5
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« Dernier message par becbunsen le février 21, 2024, 08:05:57 pm »
Bonjour à tous,

A mes heures perdues (trop peu nombreuses...) je tente de controler Labox via le CAN, J'avais dans un premier temps élaboré un protocole de messagerie. J'ai ensuite déchiffré le tien avec les commandes dans l'ID sur 29 bits. j'ai d'ailleurs fait un beau tableau Excell. Mes messages semblent avoir le bon format sur mon sniffer CAN mais je n'ai pas encore testé sur Labox (je ne peux y consacrer beaucoup de temps et j'ai plusieurs petits projets en même temps...)

Je me pemet de donner mon avis sur 2-3 points :
- 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,....)

- 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.
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 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.




 
6
Vos projets / Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Dernier message par bobyAndCo le février 21, 2024, 05:30:04 pm »
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) 2022 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;
  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;
  }
}

7
Vos projets / Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Dernier message par bobyAndCo le février 21, 2024, 03:54:43 pm »

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.
8
Vos projets / Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Dernier message par laurentr le février 21, 2024, 03:37:14 pm »
Bonjour Christophe

J'ai une question à propos du mode DISCOVERY et de l'état de la LED.

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.

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é.
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é.

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

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


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?

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?
Pour un mouvement dans le sens de circulation opposé, y a t il des critères à avoir?

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é?

Ltr



9
Vos projets / Re : Re : LaBox" : Une Centrale DCC polyvalente et abordable
« Dernier message par bobyAndCo le février 21, 2024, 02:58:43 pm »
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
10
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« Dernier message par Thierry le février 21, 2024, 01:19:21 pm »
Tu as tout à fait raison. La prochaine version sera donc une 2.5.0 eu égard à l'importance stratégique de l'ajout !
Pages: [1] 2 3 ... 10