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

Pages: [1] 2 3
1
Composants / Re : PCB la Box
« 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

2
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« 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.




 

3
Pour ma part, je répond juste pour manifester mon intérêt mais je crains ne pas pouvoir apporter grand chose au niveau technique...

Railcom me semble être une évolution majeure dans la gestion d'un réseau. Je pense que toutes les solutions actuelles avec les suivis de trains sur les logiciels n'auraient pas été conçues de la sorte si  Railcom avait été présent dès le début.

Dans l'optique d'un réseau modulaire qui se construit par étape et non pas par conception complète dès le départ, la notion de gestion décentralisée est primordiale. Je pense bien sur aux satellites autonomes même si je trouve un peu compliqué d'avoir une carte par canton. 

L'exemple qui me vient à l'esprit est le controle aérien (ca doit exister pour les trains... ) quand un avion est sur une zone, il est géré par un contrôle puis lorsqu'il la quitte, c'est un autre qui prend le relais.
Il est bien sur possible de tracer le train de zone en zone en communiquant son CV, mais c'est aussi possible de détecter n'importe quel train qui se présente à l'entrée d'une zone et de gérer son comportement sur cette zone. De cette façon, une seule carte gestionnaire par zone peut gérer quelques cantons. On pourrait même envisager de changer de réseau avec des bascule de cantons comme les boucles de retournement, Ou travailler à plusieurs, chacun sur des modules indépendants qui se relieraient pour une expo...

Pour cela 2 pré-requis:
- une zone doit avoir des entrées et sorties à sens unique ( possible en voie unique mais il faut alors un minimum de communication entre les zones.)
- un train qui n'est pas au feu rouge doit avancer.

On peut ensuite "jouer" ou programmer des scenarios et gérer la sécurité dans chaque zone.

Tout comme les satellites autonomes, ce mode de gestion n'est pas applicable à tout réseau et ne conviendrait pas à tout le monde.
J'aurais vraiment envie d'expérimenter dans cette voie mais je suis pour l'instant bloqué par mes centrales DIY : un Mega avec shield moteur puis maintenant Labox, qui ne gèrent pas le Cutout nécessaire au railcom.
Vu l'activité impressionnante de création sur ce site, je suis sur qu'une solution diy, finira par se présenter...

4
Bus CAN / Re : Mes débuts en CAN, entre déboires et réussite...
« le: février 11, 2024, 10:39:07 pm »
Merci beaucoup, je regarder ce qui me va le mieux


5
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: février 11, 2024, 12:36:01 am »
J'ai enfin reçu mes 6203, je suis parvenu à ressouder le condensateur CMS C9 qui n'avait pas été correctement soudé par JLCPCB. 1er test ce soir, tout fonctionne à merveille, Je continue maintenant avec la partie CAN mais merci de tous vos précieux articles et conseils!!

6
Bus CAN / Re : Mes débuts en CAN, entre déboires et réussite...
« le: février 11, 2024, 12:27:48 am »
Oui, Pour la philosophie du DIY, je suis d'accord avec toi, au final, c'est l'envie d'apprendre et d'y arriver qui prend le pas sur le projet final...

j'avais vu tes cartes rouges avec les pads à souder, c'est vrai que c'est fiable, rapide et économique,
Est il possible d'avoir le fichier Gerber?
C'est vrai que je me suis vraiment araché les cheveux pour arriver à faire fonctionner cette liaison et je me dit que je ne continuerai pas sans me faire des modules fiables au niveau materiel.

Mes shields, c'est des anciens modeles: V1.2  il y'a un interrupteur On/Off dessus, je n'ai pas trouvé à quoi il servait, ça marche dans les 2 cas, peut-être la 120Ohms, car elle est nulle part ailleurs.
UNO +Shield, c'était pratique pour faire des essais mais c'est assez encombrant et il faut remettre des duponts pour cabler.

J'ai quand même encore un probleme: je n'ai au final réussi à initialiser qu'un seul nano avec un module MCP2515. le nano et le module ne sont pas en cause ( je les ai fait marcher sur l'autre) ce doit être ma platine de NANO, pas grave, je vais finir par trouver
Le probleme est que quand je branche celui qui s'initialise sur mon bus avec des 2 UNO+SHIELD, le CAN se coupe, et plus rien ne passe... Le fichier exactement le même, donc pas de probleme de fréquence de bus. J'en suis la pour le moment, je vais continuer mes essais en essayant notamment avec la box (que j'ai fini aujourd'hui! :) )

A suivre donc....



7
Bus CAN / Mes débuts en CAN, entre déboires et réussite...
« le: février 09, 2024, 10:42:32 am »
Bonjour,

Je me suis décidé à écrire ce fil après avoir vraiment rencontré pas mal de difficulté à mettre en place un réseau CAN qui fonctionne. (et ce n'est pas encore tout à fait le cas...)
Le but premier pour moi était de faire tourner sur arduino même si je m'aperçois que la solution avec un ESP 32 peut apporter pas mal de choses.

Le premier point de difficulté est le peu d'informations disponibles sur le Net, le CAN n'est pas si souvent employé dans les projets DIY autres que ferroviaire. La bibliotheque ACAN fonctionne trés bien mais elle est trés pauvre en exemple et ils ne sont trés parlants.

L'une des meilleures sources d'informations est sur ce site et c'est l'article de Jean-Luc : https://www.locoduino.org/spip.php?article268
C'est en reprenant l'article ligne par ligne que j'ai réussi à bien tout faire fonctionner.
juste une petite critique: dans les exemples, il y' a des lignes qui ne servent pas ( des include Canbuffer, ACANsettings, ...) On se pose beaucoup de questions à propos de ces lignes quand ça ne marche chez nous.

Au final, l'origine principal de mes déboires est la sensibilité de la liaison SPI: j'ai au départ utilisé 2 UNO avec 2 Shield Can. j'avais toujours des erreurs "problemes de connexion", j'ai trituré le code dans tout les sens pour finir par m'apercevoir qu'il fallait appuyer un peu sur le shield pour que ça marche (pourtant enfoncé à fond), de même, j'ai ensuite voulu utilser des Nano avec des modules MCP2515, je m'en suis sorti après avoir changé des cables dupont, et même la platine d'essai avec bornier qui reçoit le nano, la continuité au testeur était bonne entre les bornes du nano et les bornes du module. Ca parait trés bête, c'est du niveau débutant++ mais c'est des heures de passée et de la perseverance pour au final arriver à faire marcher. Je pense qu'on a moins de soucis en partant sur un CI et c'est en tous cas important de chercher de ce coté quand on expérimente et que ça ne marche pas.

Je me permet donc de mettre un bout de code pour UNO ou NANO qui ne contient qu'une seule chose et rien d'autre: l'initiation du CAN. Si vous avez "connexion OK", c'est déja une belle etape de franchie et qu'on commencer à s'amuser avec les messages. Juste vérifier que la broche int est raccordé à la broche D2 et que le CS à la broche D10.


#include <ACAN2515.h> // c'est quand même le minimum

//Broches pour le chip select et l'interruption du MCP2515
static const uint8_t MCP2515_CS  = 10;
static const uint8_t MCP2515_INT = 2;

/*
 * L'objet pour piloter le MCP2515. SPI designe l'objet
 * utilise pour la connexion SPI car sur certaines cartes
 * notamment les Teensy, il peut y avoir plusieurs SPI.
 */
ACAN2515 controleurCAN(MCP2515_CS, SPI, MCP2515_INT);

/*
 * La frequence du quartz du MCP2515 en hertz.
 * Sur les cartes CAN que l'on peut trouvez chez les revendeurs
 * chinois, il s'agit generalement d'un quartz 8MHz
 */
static const uint32_t FREQUENCE_DU_QUARTZ = 8ul * 1000ul * 1000ul;

//La fréquence du bus CAN
static const uint32_t FREQUENCE_DU_BUS_CAN = 125ul * 1000ul;

CANMessage canSend;  // ces 2 lignes sont inutiles pour initialiser le CAN
CANMessage canRec;   // on crée juste 2 objets messages can: un pour envoyer, un pour recevoir

void setup()
{
  /* Demarre la ligne serie */
  Serial.begin(115200);
  /* Demarre le SPI */
  SPI.begin();
  /* Configure le MCP2515 */
  Serial.println("Configuration du MCP2515 ");
  /* Fixe la vitesse du bus a 125 kbits/s */
  ACAN2515Settings reglages(FREQUENCE_DU_QUARTZ, FREQUENCE_DU_BUS_CAN);
  /* Demarre le CAN */
  const uint16_t codeErreur = controleurCAN.begin(reglages, [] { controleurCAN.isr(); } );
  /* Verifie que tout est ok */
  if (codeErreur == 0) {
    Serial.println("Configuration ok");
  }
  else {
    Serial.println("Probleme de connexion");
    while (1);
  }

void loop()
{
//Rien pour l'instant
}


Au final, cette partie est la plus pénible quand ca ne marche pas. La partie échange de message est beaucoup plus intéressante et facile à manipuler . La liaison CAN est en effet trés fiable et je n'ai constaté aucune perte ou erreur d'infos dans mes essais

8
Bus CAN / Re : Question mise en place CAN dans la centrale DCC
« le: février 05, 2024, 06:01:01 pm »
Merci de tous ces éléments, c'est déja plus clair au niveau de la structure du message. je ne savais pas que c'etait en mode étendu. il y'a au final beaucoup d'informations dans l'identifiant.
La longueur du message est donc fixé selon les besoins (pas toujours 8 octets de 8 bits)

Excusez moi, je reformule:
Cette partie est la constitution de mon identifiant, je peux quasi l'utiliser tel quelle:


uint16_t hash = 0x1801;   //identifiant choisi pour mon noeud

  frame.id |= prio << 25;  // Priorite         Je dois declarer une priorité =0000 pour le plus prioritaire
  frame.id |= cmde << 17;  // Commande sur 8 bits à renseigner selon un "catalogue" à recuperer dans les switch/case coté reception
  frame.id |= resp << 16;  // Reponse : Commande = 0 / Reponse = 1   
  frame.id |= hash;        // Hash  = N° de mon noeud
  frame.ext = true;                          // Je declare le message en mode etendu

//selon le type de message défini par cmde je défini le nbe d'octets necessaire et je le renseigne par

 frame.len = //entre 0 et 7 octets


Reste à récupérer les différents "cmde" à envoyer


je vais pouvoir expérimenter tout ça...

9
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: février 05, 2024, 12:22:04 pm »
Oui malheureusement, après vérification, les 5 sont pareils....
Je vais quand même faire la réclamation, je vais essayer de corriger mais je n'ai jamais soudé de CMS à part les résistances de 500Ohms

10
Bus CAN / Re : Re : Question mise en place CAN dans la centrale DCC
« le: février 05, 2024, 12:10:55 pm »
N'hésite surtout pas à revenir vers moi pour plus d'explications comme par exemple la mise en œuvre concrète. Par ailleurs pour la gestion du petit réseau que tu envisages, je t'invite à suivre ce que je publie sur les satellites autonomes sur le forum et sans doute bientôt sous forme d'articles.

Bon courage

Christophe

Bonjour,
Je me permet donc de revenir vers toi, Je réitère d'ailleurs mon admiration devant tout le travail effectué quand je parcours le code....
Pour la partie message CAN, j'ai bien parcouru les fichiers .cpp et .h , assez compliqué de s'y retrouver.
Un peu plus abordable en regardant le code qui envoie automatiquement des ordres à la centrale mais je ne comprend pas tout quand même:
Par contre, jai passé un peu de temps avec la bibliotheque ACAN et je visualise assez bien la structure d'un message.
Pourrais tu m'indiquer quelle structure de données a tu choisis pour commander Labox?

Par exemple, pour controler une loco,  tu ecris

CanMsg::sendMsg(0, cmde, resp, loco->address & 0xFF00, loco->address & 0x00FF, loco->speed, loco->direction);

Pourrais tu expliquer un peu en détail?
-0

-cmde : adresse d'envoi qui défini le type de message et sa priorité? ( controle loco, fonction loco, arret d'urgence,....) 

-resp : reponse mais pas bien compris

- je n'ai pas compris les adresse locos et pourquoi 2 datas

-speed/direction OK

Ou tout simplement si je veux controler la loco 5 à vitesse 25 en avant sans passer par la programmation objet comme dans la box: que dois-je ecrire :

ACANSettings settings (125 * 1000) ; // 125 kbit/s
CANMessage message ;
message.id = 0x...    correspond à cmde?
message.data[?] ???

Merci beaucoup de votre aide.
J'admire le travail logiciel dans la box mais je n'ai pas le niveau pour l'assimiler. j'aimerai juste pouvoir programmer mes "satellites" à mon niveau et controler la box.
L'une de mes premieres idées était de placer un arduino à coté de Labox, qui reçoit des messages CAN et qui les aurait traduit en commande série. mais c'est un peu dommage alors que le CAN est intégré à Labox

11
Bonjour,
une remarque : C9 semble avoir été dessoudé par inadvertance. : Il est debout si je ne me trompe.

Oui, en effet, je n'avais pas remarqué, pour ce coup, je n'y ai pas touché, c'est bien une erreur de JLCPCB
Sinon, tout à l'air de fonctionner, j'ai bien chargé le programme, l'ecran et les menus fonctionnent bien. je suis malheureusement bloqué car j'ai égaré les 2 L6203 que j'avais reçu. je les ai pourtant bien eu dans les mains.... Bref, après avoir passé la semaine à chercher, j'ai fini par recommander.
Je vais en profiter pour regarder en attendant le controle de Labox par messages CAN.

12
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: janvier 30, 2024, 09:34:57 pm »
Bien vu en effet!! :)
Merci beaucoup
Donc tout est rentré dans l'ordre, j'ai ressoudé la diode Inv. J'ai retourné le régulateur (Erreur de débutant!!, c'était pourtant bien marqué dessus) j'ai maintenant bien 5V au régulateur, je vais pouvoir continuer.

Concernant les valeurs à controler au début, elles restent fausses pour moi mais je pense que ça dépend du multimetre. j'en ai un autre qu'il faut que je retrouve, je referai une mesure sur mes cartes restantes

Allez, je passe à la suite...

13
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: janvier 29, 2024, 10:13:29 pm »
Voici le fichier de placement.
Au final et si je place mon multimetre en mode testeur de diodes, il semblerait que les diodes soient placées dans le bon sens. (0,2 dans le sens passant, 3,2 en inverse)

Par contre, je n'ai pas du tout les valeurs annoncées:
Aux bornes de la diode, en Ohmmetre, j'ai 8K dans le sens passant et 56K dans le sens inverse, il est possible que le courant fourni par mon multimetre pour mesurer la resistance soit inferieure à la tension de seuil de la diode. Cela dit, je ne trouve pas mes 12V aux bornes du régulateur.

Quel était l'origine des 678Ohms à rechercher?

J'ai fini par dessouder un pole de la diode, reverrifier mon alim 12v et sa polarité, dés que je branche (même sans la diode) la tension tombe à 0,6v, il doit y avoir un court circuit quelque part....

14
Si vous avez 0.6 V sur le régulateur step down, c'est que la diode D_INV est dans le mauvais sens. Vous pouvez l'enlever si vous êtes sur de la polarité de votre alimentation. Elle court-circuite l'alimentation si il y a inversion.


OK, Je n'avais pas compris son fonctionnement avec le + branché sur la masse, c'est plus clair avec cette explication.

Cela dit, j'ai vérifié ma commande JLCPCB, et j'avais correctement commandé. je vais vérifier tout de suite les autres diodes.
J'ai vu qu'il y'avait un bouton "Quality complain" à coté de ma commande dans mon historique de commande. Je verrai si je fais une réclamation...
Quand j'ai commandé les cartes, JLCPCB ne m'a pas proposé la livraison simple comme pour les PCB normaux, j'ai du prendre une livraison à plus de 20€, j'en ai eu pour 55€ au total.

Bon, j'essaie d'avancer!!

15
Vos projets / Re : projet centrale &quot;LaBox&quot; wifi DCC++ Can
« le: janvier 28, 2024, 10:53:52 pm »
Bonjour,

Je me suis décidé à me lancer dans la fabrication de Labox suite à l'article de décembre. Félicitations d'ailleurs pour tout le travail accompli.
J'ai bien suivi la procédure de commande avec la ré-orientation des composants, Je n'ai par contre pas vérifié les valeurs, ayant transmis directement le fichier.
A reception, il semblerait qu'il yait un probleme car le premier test sur la carte avant de souder les composants ne me donne pas la bonne valeur. (8K à la place de "678"Ohms, la mesure en sens inverse me donne 33K), j'ai tout de même continué, je ne mesure logiquement que 0,6v à l'entrée du régulateur.
J'ai controlé la polarité des diodes au multimetre, tout à l'air OK.


J'ai regardé le schema mais j'avoue avoir du mal à comprendre, le jack 12v semble aller directement dans le régulateur sans passer dans aucun composant.
Je pense que la diode D-inv ne figure pas et qu'elle est la pour proteger contre les inversions de polarités. Si j'ai bien compris, ce serait elle qui est censée opposer une resistance de 678 Ohms dans le bon sens. La diode mise par JLCPCB est une SS14.

Autre question: le PCB est gravé LaBox 0.2, hors il semblerait que ce soit la dernière version, l'article étant de décembre 2023 et c'est la version avec CMS.
Vous parlez pourtant de la version 0.4 plus ancienne avec composants traversants. Ai-je bien le bon PCB?

Enfin, ce n'est qu'un détail mais concernant les leds rouges qui sont facultatives, vous indiquez de les monter tête bêche comme ceci : "+Led2- -Led4+",
N'est ce pas plutôt l'inverse?

Merci de votre aide!!
Julien





Pages: [1] 2 3