LOCODUINO
Discussions Générales => Bus CAN => Discussion démarrée par: becbunsen le décembre 06, 2023, 09:44:26 pm
-
Bonjour,
J'envisage de mettre en place un bus CAN dans mon reseau pour la retrosignalisation et les automatismes.
J'ai 2 questions de débutants:
- Comment implanter le CAN dans la centrale DCC ? j'ai un Mega avec un shield moteur, je le commande trés facilement en liaison serie. je peux contourner le probleme avec un arduino qui va transcrire mes ordres CAN en messages serie pour la centrale mais je pense qu'on peut brancher directement l'interface CAN sur le mega de la centrale. je ne sais pas alors comment gerer le code
- Existe t'il un protocole "tout fait" pour les messages CAN concernant le modelisme ferroviaire ou chacun crée le sien selon ses besoins?
Merci de vos retours
Julien
-
- Comment implanter le CAN dans la centrale DCC ? j'ai un Mega avec un shield moteur, je le commande trés facilement en liaison serie. je peux contourner le probleme avec un arduino qui va transcrire mes ordres CAN en messages serie pour la centrale mais je pense qu'on peut brancher directement l'interface CAN sur le mega de la centrale. je ne sais pas alors comment gerer le code
J'ai ma centrale qui comprend un Mega, une carte Can et le fameux LMD18200.
voir https://forum.locoduino.org/index.php?topic=290.30 (https://forum.locoduino.org/index.php?topic=290.30)
Avec DCCpp il existe des fonctions API pour piloter les machines, en plus des autres commandes possibles.
Il faut écrire du code pour traduire les messages Can en commandes DCC.
Il y a des explications sur mon fil du forum.
Si besoin, je peux te transmettre des bouts de code.
- Existe t'il un protocole "tout fait" pour les messages CAN concernant le modelisme ferroviaire ou chacun crée le sien selon ses besoins?
Non pour le moment mais on démarre une réflexion pour LaBox qui est pourvue du Can en standard. On publiera quand on aura quelque chose.
-
Bonjour,
utiliser le protocole CAN n'est pas immédiat et Dominique confirme que c'est une réflexion en cours pour LaBox.
Christophe a fait valoir que Marklin l'utilise et donc avait standardisé pour son usage.
La communication du satellite V1 (voir l'article) en a fixé quelques règles.
Mais avant de se poser la question de la communication, mieux vaut se poser celle de l'architecture.
LaBox ne se veut pas un gestionnaire.
-
Mon réseau est plutôt du type étagère organisé en module que j’ajoute successivement, je n’ai pas la place pour un grand réseau permanent et je préfère m’appliquer par petit bout avec un module pleinement opérationnel avant de passer au suivant.
Je voudrais donc que chaque module ait un maximum d’automatismes avec un gestionnaire propre et limiter au mieux le recours à un gestionnaire central. Je n’ai de toutes façons pas un grand nombre de voies.
J’ai Jmri, ça fonctionne mais je ne veux pas l’utiliser
Il faut donc que je relie chaque gestionnaire de module à la centrale pour agir sur le Controle des loco.
La plus grosse difficulté est le Controle de la loco. Pour les tests, je peux spécifier l’adresse de la loco dans le code mais ce n’est pas satisfaisant si on veux utiliser n’importe quelle loco.
ABC permet des freinages et redémarrage sans connaître l’adresse, c’est la solution sur laquelle j’etais parti, notamment pour la sécurité ( canton occupé, aiguille non positionnée) et les arrêts en gare.
L’ideal serait railcom et j’attend avec impatience la centrale compatible!!
Le principe: une loco rentre sur le module, elle est identifiée et peut donc être contrôlée sur le module en fonction des détecteurs de celui-ci. Une fois sortie, c’est le gestionnaire de l’autre module qui prend le relais.
-
Avez-vous un/des schémas. Plans et des photos ?
Si je comprends bien il s’agit de plusieurs réseaux indépendants reliés entre eux par un/des voies et un système de commande centralisé pour circuler d’un réseau a l’autre ?
-
Michel a raison de metre le doigt sur l’aspect technique qui n’est pas, et de loin, le principal problème.
Faire circuler des messages CAN sur un bus, on sait faire.
Mais pour faire quoi et comment le faire au mieux. Et il a donc raison s’insister, qu’ai-je envie de faire sur mon réseau ? Car même si nous cherchons à standardiser le plus possible, nous aurons du mal à tout appréhender.
C’est vrai que j’ai beaucoup étudier les commandes CAN de Marklin et il faut franchement reconnaitre qu’ils ont fait un super boulot dont je suis persuadé nous devons nous inspirer.
C’est la messagerie qui est le cœur de la solution, la vraie valeur ajoutée. Combien d’appareils à piloter, dans quelles catégories (Traction, rétro signalisation de capteurs tout-ou-rien), de détection plus élaborées (Railcom, RFID, MFX…). Comment élaborer des messages aussi simples que possibles et portant le plus efficace possible. Voilà un petit aperçu.
Ce serait effectivement intéressant que vous soumettiez vos souhaits car je cherche à faire actuellement un inventaire des besoins pour voir le champ global de la réflexion.
S’inspirer de Marklin a ses limites car ils n’utilisent le CAN que pour la seule traction (au sens large tout de même) mais pas à la rétro signalisation par exemple qui reste en S88, même techniquement un peu amélioré.
Michel a encore raison, j’ai mis les doigts dedans (le CAN) et je n’ai pas l’intention de m’arrêter avant tout de suite. On en reparlera donc volontiers.
Sur l’aspect automatismes dont vous parlez, je vais publier très prochainement le début d’une série d’articles sur ce que j’ai appelé « les satellites autonomes ». Je crois que ça répond bien à votre attente. Il est associé à Railcom effectivement, car si LaBox n’a pas encore Railcom, nous avons tout de même des centrales compatibles Railcom. Avez-vous lu l’article : https://www.locoduino.org/spip.php?article334
Et ils utilisent un bus CAN pour communiquer. La vidéo ici n’est pas forcement très explicite mais elle montre comment une locomotive est tout d’abord ralentie puis arrêtée sans aucune intervention humaine quand le canton précédent est occupé. https://youtu.be/qTaGxd1uDpA?si=h6VSbw2_M5puNT3i (https://youtu.be/qTaGxd1uDpA?si=h6VSbw2_M5puNT3i)
N'hésitez pas à revenir vers moi.
Bien amicalement
Christophe
-
Je profite de ce fil pour poser ma question qui est relative au CAN. Vous semble t'il possible d'associer un transceiver CAN à un ATTiny par exemple ? Je me dis qu'il peut être intéressant de mettre sur le bus CAN de petits appareils comme par exemple 4 boutons commutateurs d'aiguilles qui adresseraient leur commande à un satellite par exemple. Pour 4 boutons, je ne vois pas mettre un Nano ou un ESP par exemple.
Ou alors, quel est le plus simple et le moins couteux des microcontrôleurs susceptibles de faire le job ?
-
Bonjour Christophe,
c'est une question intéressante, comme l'application visée.
Un petit tour sur Internet ne m'a pas permis de trouver de bibliothèque CAN pour Attiny, apparemment il y a eu des tentatives ...
Cela dit, on est obligé de passer par un module driver CAN à MCP2565 (2,7€)
Un ATtiny en module passe par un Digispark avec une mise en œuvre un peu acrobatique. (1 à 3€)
Un ATtiny85 chez JLCPCB est à 2.25$
Un Arduino pro mini chez Aliexpress est à 2€
Et pour finir, comment intégrer tout ça : une mini carte mère ou un un pcb avec les composants bruts ?
-
Merci Michel pour la réponse. J’avais fait une rapide recherche et je n’avais rien trouvé de probant comme toi. Et effectivement, ce que je voyais c’était des économies compte tenu de la simplicité du montage, mais à moins de 3€ le pro mini, ça satisfait le cahier des charges.
Bien. A toi
Christophe
-
Christophe,
Ca me rappelle mes prototypes de Satellites V1 : Un Pro-mini et une carte Niren !
Il m'en reste dans les fonds de tiroir si tu en veux qq uns..
-
En terme de coût, je me demande si un ESP32 + un MCP2562 n'est pas l'optimum :
5€ + 1€ chez Aliexpress. Mais ça consomme plus ...
-
Michel a raison de metre le doigt sur l’aspect technique qui n’est pas, et de loin, le principal problème.
Faire circuler des messages CAN sur un bus, on sait faire.
Mais pour faire quoi et comment le faire au mieux. Et il a donc raison s’insister, qu’ai-je envie de faire sur mon réseau ? Car même si nous cherchons à standardiser le plus possible, nous aurons du mal à tout appréhender.
C’est vrai que j’ai beaucoup étudier les commandes CAN de Marklin et il faut franchement reconnaitre qu’ils ont fait un super boulot dont je suis persuadé nous devons nous inspirer.
C’est la messagerie qui est le cœur de la solution, la vraie valeur ajoutée. Combien d’appareils à piloter, dans quelles catégories (Traction, rétro signalisation de capteurs tout-ou-rien), de détection plus élaborées (Railcom, RFID, MFX…). Comment élaborer des messages aussi simples que possibles et portant le plus efficace possible. Voilà un petit aperçu.
Ce serait effectivement intéressant que vous soumettiez vos souhaits car je cherche à faire actuellement un inventaire des besoins pour voir le champ global de la réflexion.
S’inspirer de Marklin a ses limites car ils n’utilisent le CAN que pour la seule traction (au sens large tout de même) mais pas à la rétro signalisation par exemple qui reste en S88, même techniquement un peu amélioré.
Michel a encore raison, j’ai mis les doigts dedans (le CAN) et je n’ai pas l’intention de m’arrêter avant tout de suite. On en reparlera donc volontiers.
Sur l’aspect automatismes dont vous parlez, je vais publier très prochainement le début d’une série d’articles sur ce que j’ai appelé « les satellites autonomes ». Je crois que ça répond bien à votre attente. Il est associé à Railcom effectivement, car si LaBox n’a pas encore Railcom, nous avons tout de même des centrales compatibles Railcom. Avez-vous lu l’article : https://www.locoduino.org/spip.php?article334
Et ils utilisent un bus CAN pour communiquer. La vidéo ici n’est pas forcement très explicite mais elle montre comment une locomotive est tout d’abord ralentie puis arrêtée sans aucune intervention humaine quand le canton précédent est occupé. https://youtu.be/qTaGxd1uDpA?si=h6VSbw2_M5puNT3i (https://youtu.be/qTaGxd1uDpA?si=h6VSbw2_M5puNT3i)
N'hésitez pas à revenir vers moi.
Bien amicalement
Christophe
Merci de vos retours, Je reviens ici tardivement, j'avoue que je cherche encore le mode de fonctionnement de mon réseau. Ce qui est sur: c'est que mon reseau est de type étagere (etroit) par module et évolutif. je ne travaille que sur un module à la fois (1,20m de long sur 30 de large) et je ne connais pas à l'avance mes futurs modules, j'envisage quand même une boucle de retournement d'un coté.
Le "modele" de ce que j'aimerai réaliser, en terme de taille et d'aspect serait (en toute modestie...) quelque chose comme celui-ci
https://www.youtube.com/watch?v=BIyUnKoZxmQ&t=491s
Dans cet exemple, le fonctionnement des 2 gares pourrait être indépendant (il faut juste ne pas envoyer de trains de chaque coté comme c'est une voie unique)
Pour l'instant, J'attaque mon second module qui sera une simple gare à 2 voies + 1 voie de garage. J'ai conçu un connecteur en 3D pour bien aligner les modules et les extrémités des rails sont soudés sur une bande de PCB vissé dans le module. (il faut que je trouve comment mettre des photos.)
Concernant la connectique, j'ai envisagé une connection entre les modules par connecteurs Molex 6 poles : 2 pour le DCC, 2 pour un 12V et 2 pour le CAN.
La connection Can permet aux modules d'interagir avec la traction mais j'aimerai un maximum d'automatisation en local (feu et freinage en fonction des position d'aiguilles et des occupations de cantons.
Le but n'est pas forcement de planifier des itinéraires compliqués mais simplement d'éviter les collisions et provoquer des arrets en gare.
Bref je cherche encore
j'avais envisagé l'utilisation du freinage ABC avec une bonne configuration de chaque locomotive, mais le railcom simplifierait évidement la donne.
Pour l'instant, j'avoue être betement bloqué par l'impossibilité de controler mes aiguilles en DCC....impossible de decoder le signal, j'ai fait 3 montages, éssayé plusieurs valeurs..... j'ai commandé les composants de Labox pour voir si ca ne vient pas de ma centrale DCC.
-
Bonjour becbunsen,
Tu abordes plusieurs sujets en un.
Tout d’abord dans le titre du sujet où tu parles de mettre en place CAN dans la centrale DCC. Bon, plus exactement, je pense que tu veux dire, « comment piloter ma centrale DCC en utilisant un bus CAN ».
Tout dépend bien sur de ta centrale, mais si par exemple tu utilises LaBox de Locoduino, nous avons, mes camarades Dominique, Michel et moi-même développé et testé des commandes CAN qui permettent de piloter LaBox.
Tu trouveras sur ce lien le programme complet de LaBox auquel j’ai ajouté les fichiers « CanMsg .h» et « CanMsg.cpp »
https://github.com/BOBILLEChristophe/CommandStation-EX-LaBox2/blob/main/CanMsg.cpp
Dans le fichier « config.LaBox.h », nous avons ajouté ligne 181 #define CAN en plus des paramètres spécifiques à LaBox
#define USE_HMI
#define HMI_SHOW_CURRENT
#define CAN
Enfin, le fichier « CommandStation-EX-LaBox2.ino » pour inclure le CAN.
Dans le fichier CanMsg.cpp tu vas trouver un certain nombre de commande qui permettent de piloter les locomotives en CAN (à partir de la ligne 113) :
uint16_t loco = 0;
if (cmde < 0xFA)
loco = (frameIn.data[0] << 8) + frameIn.data[1];
switch (cmde) // Fonction appelée
{
case 0xF0:
DCC::setThrottle(loco, frameIn.data[2], frameIn.data[3]);
xQueueSendToBack(xQueue, &frameIn, 0);
break;
case 0xF1:
DCC::setFn(loco, frameIn.data[2], frameIn.data[3]); // frame.data[2] = fonction, frame.data[3] : 'on' ou 'off'
break;
case 0xF7:
// WRITE CV on MAIN <w CAB CV VALUE>
DCC::writeCVByteMain(loco, frameIn.data[2], frameIn.data[3]);
break;
case 0xFE:
TrackManager::setMainPower(frameIn.data[0] ? POWERMODE::ON : POWERMODE::OFF);
xQueueSendToBack(xQueue, &frameIn, 0);
break;
case 0xFF:
DCC::setThrottle(0, 1, 1); // emergency stop
xQueueSendToBack(xQueue, &frameIn, 0);
break;
Comme tu le vois, nous trouvons les commandes de traction, les commandes de fonction (jusqu’à 28 fonctions), la mise sous tension du réseau, l’emmergency stop et même la possibilité de modifier les CV qui sont modifiables sur la POM comme le son.
Sur cet autre lien, tu trouveras maintenant un programme conçu pour. Tester toutes ces commandes CAN : https://github.com/BOBILLEChristophe/Test_CommCan_LaBox_2
Ce programme doit être installé sur n'importe quel Arduino relié au bus CAN avec la centrale, il tourne en automatique pour voir s'executer une à une les principales commandes à destination de la centrale.
Voilà déjà pour commander une centrale DCC avec des commandes CAN.
Pour le pilotage en automatique de ce type de réseau, je t’en reparle dans la journée.
-
Merci, je vais etudier tout ça mais c'est en tous cas exactement l'information que je cherchais!
-
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
-
@ becbunsen, votre projet correspond bien à ce que peut apporter la solution de Christophe qui est très motivé et vous aidera.
Ce réseau étagère sera une belle réussite. ;D
-
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
-
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
Bonjour becbunsen,
Je te remercie de poser ces questions car je suis certain que d’autres sont comme toi mais n’osent pas poser ces questions. C’est dommage, le CAN n’est pas aussi compliqué qu’il n’y parait à condition de passer le temps nécessaire à le comprendre.
Le CAN, c’est une partie matérielle et surtout, ce qui va vous intéresser ici, une messagerie. Je vais me risquer à prendre l’analogie d’une phrase dans le langage courant. Phrase qui doit respecter une certaine structuration pour être comprise par celui ou ceux à qui elle est destinée.
La trame CAN est en quelque sorte à la communication CAN ce que la phrase est au langage avec un sujet, un verbe un complément d’objet direct…
Fondamentalement la trame CAN se divise en un identifiant (sur 11 ou 29 bits) et un champ de données dont la taille totale peut atteindre 64 bits (ou 8 octets) et que l’on divise souvent en 8 champs de 8 bits : data[0], data[1], data[n]
On est libre du nombre de champ data que l’on envoie selon nos besoins, dans certains cas on peut même n’envoyer aucune data ou jusqu’à 8 champs de 8 bits.
Le champ d’identification du message sur 11 ou 29 bits est totalement libre dans sa construction et c’est ce qui le rend parfois difficile à comprendre.
La principale règle est que, pour des questions de priorité de distribution sur le bus et de gestion des conflits entre messages qui arrivent en même temps sur le bus, ce sont les messages qui ont les identifiants les plus faibles qui sont prioritaire sur les autres.
Ainsi, le message qui aurait pour identifiant 1 est prioritaire sur l’identifiant 536 870 912 (29 bits à 1).
Si je reprends mon analogie avec le langage, il va falloir passer un peu de temps pour structurer intelligemment les informations que l’on va placer dans l’identifiant et l’ordre dans lequel on va placer ces informations.
Dans le code que j’ai proposé, on trouve cela illustré ici :
uint16_t hash = 0x1801;
frame.id |= prio << 25; // Priorite
frame.id |= cmde << 17; // Commande
frame.id |= resp << 16; // Reponse : Commande = 0 / Reponse = 1
frame.id |= hash; // Hash
frame.ext = true;
frame.id, dans la bibliothèque ACAN_ESP32 correspond à l’identifiant
J’ai choisi que la priorité des messages tiendrait sur 4 bits et aurait pour valeur 0 (car pour moi les messages à la centrale sont plus prioritaires que les autres sur le bus) et je place cette valeur à la position 25 sur les 29 bits de l’identifiant (que j’ai choisi long).
frame.id |= prio << 25; // Priorite
Position 25 plus longueur de priorité 4 bits remplissent bien les bits 25 à 29 de l’identifiant
J’ai ensuite décidé que les bits qui seront lu comme des bits pour identifier quelles commandes de locomotives allaient être exécutés viendraient se positionner à partir du bit 17 de l’identifiant et tiendraient sur 8 bits.
Concernant l’information de réponse dont tu parles, j’ai jugé que cette information était très intéressante pour savoir s’il s’agissait d’une commande envoyée bit 16 à 0) ou si c’était une réponse de la centrale qui confirme qu’elle a bien reçue la commande (bit 16 à 1). Dans ce cas, la centrale confirme la réception en revoyant un message en tout point identique à celui reçu mais en changeant seulement la valeur du bit 16. Une sorte d’accusé de réception.
Nous verrons cela en détail un peu plus loin.
Enfin, les 16 derniers bits de poids faible de l’identifiant, j’ai choisi de les remplir avec une valeur choisie arbitrairement mais qui souvent est l’ID du nœud CAN qui expédie le message. Ici, j’ai choisi uint16_t hash = 0x1801;
Enfin, deux derniers points, avec la bibliothèque ACAN_ESP32, c’est au programmeur d’indiquer si l’identifiant est sur 29 (frame.ext = true;) ou sur 11 bits (frame.ext = false;). Ext pour extended frame format.
Le programmeur doit aussi renseigner la longueur du champ de données frame.len (en octets).
Si l’on se place maintenant dans la position du récepteur du message, c’est ce que l’on trouve dans le fichier CommandStation-EX-LaBox2/CanMsg.cpp
On voit tout d’abord que l’on « décode » l’identifiant :
if (ACAN_ESP32::can.receive(frameIn))
{
const uint8_t cmde = (frameIn.id & 0x1FE0000) >> 17; // Commande
const uint8_t resp = (frameIn.id & 0x10000) >> 16; // Commande = 0 / Reponse = 1
const uint16_t hash = (frameIn.id & 0xFFFF); // Hash
ensuite, sans entrer dans les détails, on voit que selon la commande envoyée (switch(cmde)), on execute l’une ou l’autre des fonctions internes à la box :
switch (cmde) // Fonction appelée
{
case 0xF0:
DCC::setThrottle(loco, frameIn.data[2], frameIn.data[3]);
xQueueSendToBack(xQueue, &frameIn, 0);
break;
case 0xF1:
DCC::setFn(loco, frameIn.data[2], frameIn.data[3]); // frame.data[2] = fonction, frame.data[3] : 'on' ou 'off'
break;
case 0xF7:
// WRITE CV on MAIN <w CAB CV VALUE>
DCC::writeCVByteMain(loco, frameIn.data[2], frameIn.data[3]);
break;
case 0xFE:
TrackManager::setMainPower(frameIn.data[0] ? POWERMODE::ON : POWERMODE::OFF);
xQueueSendToBack(xQueue, &frameIn, 0);
break;
case 0xFF:
DCC::setThrottle(0, 1, 1); // emergency stop
xQueueSendToBack(xQueue, &frameIn, 0);
break;
}
setThrottle, commande de traction ou de e-stop dans le cas où les paramètres sont :
DCC::setThrottle(0, 1, 1); // emergency stop
Commande de mise sous tension ou d’extinction de la box :
case 0xFE:
TrackManager::setMainPower(frameIn.data[0] ? POWERMODE::ON : POWERMODE::OFF);
La fonction xQueueSendToBack(xQueue, &frameIn, 0); est la réponse que la commande à bien été reçue.
Voilà pour ne pas faire trop long.
Deux réponse complémentaire cependant, pourquoi ceci :
loco->address & 0xFF00, loco->address & 0x00FF, simplement pour diviser l’adresse qui peut être en 16 bits sous forme de de deux valeurs en 8 bits.
Je vois d’ailleurs qu’il y a une erreur ici puisque cela devrait être : (loco->address & 0xFF00) >> 8, loco->address & 0x00FF
Attention, ceci n'a rien à voir : 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 est la vitesse de transmission des messages sur le bus CAN.
Comme tu me sembles vouloir comprendre le CAN je te conseille de continuer à expérimenter et poser des questions et de bien lire les articles de base en particulier celui de Jean-Luc : https://www.locoduino.org/spip.php?article268
Je te conseille vraiment de réaliser (pas simplement lire) ce que présente Jean-Luc et tu auras acquis 80% de ce qu'il faut savoir.
Christophe
-
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...
-
Dans le fichier :
Test_CommCan_LaBox_2/Test_CommCan_LaBox_2.ino
tu as tous les exemples pour les envois de commande. Tu peux recopier tous les fichiers sur un ESP32 équipé du CAN pour envoyer ces messages et relier avec un autre ESP32 (en CAN) pour la Box:
Les principales fonctions pour commander des locomotives dans le loop :
void loop() {
/*------------------------------------------------------------------
Serie de commandes envoyées a LaBox pour tests
--------------------------------------------------------------------*/
// Power on
laBox.setPower(on);
delay(100);
// Test des differentes fonctions du decodeur
for (byte i = 0; i <= 28; i++) {
// Activation
loco->fn[i] = on;
laBox.setFunction(loco, i);
delay(1000);
// Desactivation
loco->fn[i] = off;
laBox.setFunction(loco, i);
delay(100);
}
// Active les feux et le bruit de la locomotive
laBox.toggleFunction(loco, 0);
laBox.toggleFunction(loco, 1);
delay(1000);
// Programmation de CV POM
// WRITE CV on MAIN <CAB CV VALUE>
laBox.writeCVByteMain(loco, 63, 75);
delay(100);
// Avant 25
loco->speed = 25;
loco->direction = 1;
laBox.setThrottle(loco);
delay(15000);
// Arret de la locomotive
loco->speed = 0;
laBox.setThrottle(loco);
delay(5000);
// Avant 50
loco->speed = 50;
laBox.setThrottle(loco);
delay(15000);
// Arriere 50
laBox.toggleThrottleDir(loco);
delay(15000);
// Arriere 75
loco->speed = 75;
laBox.setThrottle(loco);
delay(15000);
// emergency stop
laBox.emergency();
delay(1000);
// power off
laBox.setPower(off);
delay(5000);
}
Petit réglage auparavant dans le setup :
void setup() {
Serial.begin(115200);
CanMsg::setup();
loco->address = 65;
xTaskCreatePinnedToCore(&recepCan, "recepCan", 2 * 1024, NULL, 5, NULL, 0);
}
On dit ici que la loco a l'adresse 65, il faut mettre une adresse qui correspond à la loco testée
Christophe
-
@becbunsen
Attention, dans le fichier CommandStation-EX-LaBox2/CanMsg.cpp Michel (msport) à apriori rencontré un problème avec le filtre CAN (lignes 74 à 81). Il vaut mieux désactiver le filtre actuel, cela n'a pas d'importance pour les tests.
Il faut donc écrire ceci à la place :
// with filter
//const ACAN_ESP32_Filter filter = ACAN_ESP32_Filter::singleExtendedFilter(
// ACAN_ESP32_Filter::data, 0xF << 17, 0x1F87FFFF);
//errorCode = ACAN_ESP32::can.begin(settings, filter);
// without filter
errorCode = ACAN_ESP32::can.begin(settings);
Serial.printf("[CanConfig %d] : config without filter\n", __LINE__);
-
Bonjour
Je me plonge dans cette rubrique qui mériterait plus de visibilité pour ceux qui comme moi plongent dans le CAN de "0".
Une première question qui me vient est que l ensemble des messages transitant d une source vers une destination ( possiblement multiple) y aurait il un intérêt à définir un bus montant et un autre bus descendant pour favoriser l écoulement des flux?
Cela peut paraitre luxueux mais après tout cela spécialise chacun des bus à un usage déterminé: émission ou réception, ce qui peut dans certain cas en passant par un "centralisateur" décorréler les actions en favorisant les vitesses de transmission en regard des temps de traitement qui peuvent requérir plus de cycles surtout si les destinataires d un même message sont nombreux et doivent être différenciés.
Ltr
-
Mon cher Laurent,
ll est absolument contraire à l'esprit du CAN que l'on parle d'émetteur et de récepteur ! Ni d'ailleurs de maitre et d'esclaves. Le can est un bus "broadcast" et sans hiérarchie entre les nœuds.
Pourquoi veux-tu favoriser l'écoulement des flux alors même que sur un réseau de modélisme ferroviaire il est fort probable que tu n'arrives même pas à utiliser 20% du potentiel du bus ?
Pour différencier les messages à la réception, il y a plusieurs dispositifs mis à ta disposition, des filtres "hard" programmables, et des méthodes à la réception d'autant plus efficaces que la messagerie est bien conçue.
Christophe
-
Merci Christophe pour ces info.
Débutant avec ce hardware encore mal connu pour moi et ayant quelques idées de la façon de l'intégrer à différents montages, à la lecture également du modèle de messagerie que tu as récemment proposé, j essaye de voir comment articuler le tout pour par exemple disposer de décodeurs locaux sous le réseau avec une fonctionnalité propre ex un décodeur d aiguillage CAN intégrant le pilotage d un servo, la commande d un relais pour une polarisation de pointe de cœur et message d acquittement en retour.
Idem pour un décodeur de signal.
Je note bien que les filtres vont jouer un rôle majeur mais la notion de priorité me pose question car si il y a une pile de messages prioritaires qui ne désemplie pas ( ex le cas de tes satellites qui pilotent les info servant aux instructions les vitesses des trains) comment s assure t on de disposer d assez de bande passante pour les messages moins prioritaires? ( enfin qu'ils soient émis et reçus car si toujours relayes ils finissent par ne pas être transmis?)
Il doit bien y avoir des "trucs" pour tout cela... je dois encore les appréhender.
Ltr
-
Laurent,
Tout d'abord, je pense qu'il faut que tu crées un nouveau fil pour un sujet qui n'a pas à voir avec la mise en place CAN dans la centrale DCC. Car si je comprends bien, tu veux faire des mini satellites. Je pense que les versions v1 correspondent tout à fait à ce que tu souhaites faire.
Très franchement, tu es loin de la préoccupation de messages qui ne seraient pas émis faute de bande passante ou par saturation des buffers mais on en reparlera sur le nouveau fil.
Christophe