Usage particulier du bus CAN

[Tony04]

Bonjour à tous,

comme je le précise dans le titre, j'aimerais utiliser le bus CAN dans une configuration un peu particulière.

Je voudrais envoyer la même trame à tous mes satellites en une seule fois sans devoir répéter x fois l'opération avec des adresses différentes et du coup je configure le filtre de réception de tous mes satellites avec la même valeur,  0x103 dans mon exemple.
J'ai fait l'essai et cela fonctionne, mais est-ce que techniquement cette configuration tient la route car, si j'ai bien compris, le bus CAN dans son protocole d'échange, renvoie des informations en cas de mauvaise transmission par exemple. Or dans ce cas ma centrale ne peut pas différencier les retours de ces informations entre les différents satellites.

Je joins un petit croquis du montage en précisant que je ne fais qu'envoyer vers les satellites et ne demande aucune information en retour.

Merci par avance pour vos commentaires.
Cordialement
Antoine

[Dominique]

Bonjour Antoine,

Normalement c’est possible de recevoir un même message par tous les satellites, si ceux-ci ont un filtre prévu pour cela. Même sans filtre, d’ailleurs, tous les nœuds reçoivent tous les messages et les acquittent.

Mais si un noeud constate une erreur de transmission, il peut provoquer des répétitions et bloquer le bus. Dans ce cas il peut / doit se déconnecter du bus par un system décrit ici :
https://www.kvaser.com/about-can/the-can-protocol/can-error-handling/

Traduction : « Un nœud démarre en mode Erreur active. Lorsque l'un des deux compteurs d'erreur augmente au-dessus de 127, le nœud entre dans un état connu sous le nom d'erreur passif et lorsque le compteur d'erreur de transmission augmente au-dessus de 255, le nœud entre dans l'état Bus désactivé.

Un nœud d'erreur actif transmettra des indicateurs d'erreur actifs lorsqu'il détecte des erreurs.
Un nœud passif d'erreur transmettra des indicateurs d'erreur passifs lorsqu'il détecte des erreurs.
Un nœud qui est Bus Off ne transmettra rien du tout sur le bus »

Donc ton « broadcast à la Tony04 » peut ne plus marcher certains mauvais jours et tu perds des nœuds.

Je ne comprends pas bien en quoi c’est gênant de répéter des envois de messages, d’autant que c’est le programme qui le fait avec une boucle « for » et tu as juste 2 lignes de code et un tableau d’identifiants à ajouter pour atteindre la sérénités sur ton réseau 

[Tony04]

Merci Dominique pour ces précieux renseignements et je vais suivre tes conseils en séparant les adresses.
Je me doutais un peu de la mauvaise utilisation du CAN avec cette méthode, c'était juste une question de facilité.

Bon dimanche à toi.

Cordialement
Antoine

[Dominique]

Antoine et tout le monde,

Je vous conseille de gérer des compteurs d'erreurs à remonter au gestionnaire de temps en temps pour vous assurer de la bonne santé du bus Can.

Personnellement je n'ai pas du tout de problème sur le bus Can de mon réseau.. jusqu'à maintenant !

[Tony04]

Je veux bien mettre ce genre de compteur d'erreurs, mais je ne sais pas comment procéder.

Est-ce par un accusé de réception programmé en dur que tu constates des erreurs ou existe-t-il un autre moyen (interroger le composant CAN par exemple) ?

[Dominique]

voir l'article La bibliothèque ACAN (2)

Il y a un code erreur à récupérer à chaque emission :
const bool ok = controleurCAN.tryToSend(messageCANLEDs)

si ok est false, on incrémente un compteur. Les erreurs ne se voient pas en réception, mais seulement en émission.

Le principe est le même sur l'ancienne bibliothèque CAN BUS Shield

[Tony04]

Bonjour Dominique,

je viens de faire des essais avec l'ancienne bibliothèque CAN BUS Shield avec le code suivant:

Code: [Sélectionner]

boolean ok = CAN.sendMsgBuf(ad_emission_TCO, 0, 5, data_send);
Serial.println(ok);

et dans tous les cas je récupère 'true' même si le bus CAN n'est pas relié, est-ce normal ? Et si oui ce test ne me servira à rien.

Dans ton message tu proposes

Code: [Sélectionner]

const bool ok = controleurCAN.tryToSend(messageCANLEDs)   'const' n'est-ce pas une erreur ?

Merci d'éclairer ma lanterne qui ne brille pas trop en ce moment.

Cordialement
Antoine

[Dominique]

Bonjour Antoine,

La syntaxe exacte (c'est pas la même fonction, mais le principe est le même) est :

Code: [Sélectionner]

byte MCP_CAN::sendMsgBuf(byte status, unsigned long id, byte ext, byte rtrBit, byte len, volatile const byte *buf)
{
  byte txbuf_n=statusToTxSidh(status);

  if ( txbuf_n==0 ) return CAN_FAILTX; // Invalid status

  mcp2515_modifyRegister(MCP_CANINTF, status, 0);  // Clear interrupt flag
  mcp2515_write_canMsg(txbuf_n, id, ext, rtrBit, len, buf);

  return CAN_OK;
}
donc un boolean à la place d'un Byte va donner le contraire de ce que tu attends, car CAN_FAILTX = 2 donc true 

Code: [Sélectionner]

#define CAN_OK              (0)
#define CAN_FAILINIT        (1)
#define CAN_FAILTX          (2)

Comme cette ancienne bibliothèque est très utilement remplacée par la bibliothèque ACAN décrite par Jean-Luc récemment, je pense que tu aurais intérêt à changer de bibliothèque et réécrire les bouts de code correspondants dans ton programme : je sais c'est du boulot et moi je l'ai fait presque partout dans mes programmes (au fur et à mesure des mises à jour).

Là je peux te garantir que ça simplifie la vie et les exemples donnés dans les articles de Jean-Luc sont les plus utiles, en compléments de ceux qui sont dans la bibliothèque (qui étendent son usage à d'autres microcontrôleurs).

Bon courage

[Coyotte]

Hello à toutes et tous,

Je suis un peu surpris que l'utilisation prévue par Antoine puisse poser problème.
Il me semblait justement que l'intérêt du bus CAN était de pouvoir envoyer une information sur le bus sans connaître le nombre de destinataires.

Dans mon cas, par exemple, je compte envoyer "l'heure du réseau" sur le bus via un module (appelons-le "Clock"). Tous les périphériques éventuellement intéressé par celle-ci pourraient alors récupérer l'info.
S'il faut utiliser des "adresses" différentes cela revient à dire que lorsque j'ajouterais un périphérique utilisant cette info, je devrais modifier le module "clock" pour prendre en compte le nouveau destinataire ? Cela me semble aller à l'encontre du principe de ce bus, non ? (ou alors, je n'ai rien compris,ce qui est encore possible  )

Coyotte

[Tony04]

Tu m'as convaincu Dominique, je vais de ce pas changer de librairie et te tiendrai au courant.

Un grand merci à toi et bonne journée.
Antoine

[Dominique]

Je suis un peu surpris que l'utilisation prévue par Antoine puisse poser problème.
Il me semblait justement que l'intérêt du bus CAN était de pouvoir envoyer une information sur le bus sans connaître le nombre de destinataires.

Je suis d’accord que rien n’interdit de permettre a plusieurs nœuds de recevoir un message. Moi-même je m’en sers pour installer un superviseur-debuggeur-configurateur, comme la valise de test-configuration des garagistes.

J’ai seulement expliqué qu’un noeud peut arriver à disparaître en cas d’erreurs (255 ça peut arriver vite). Un cas fréquent est quand il n’est pas branché.

Effectivement pour mettre à jour une heure commune c’est suffisant. Mais tu ne sais pas si le message est reçu par tous les noeuds.
Dans le cas d’Antoine, je ne sais pas donc j’informe du risque, ce qui peut servir à tout le monde.
Mais si on veut vraiment garder le contrôle de tous les noeuds il faut éviter de les perdre.

[Dominique]

A titre d’information voici un exemple (commercial) de broadcasting sur bus Can :
https://copperhilltech.com/blog/tag/Message+Broadcasting

Moi aussi mon gestionnaire est sur un Due et j’utilise les 2 bus, l’un pour le réseau, l’autre pour le décor

Et ce site qui rappelle que le bus Can est fait pour du broadcast:
https://www.kvaser.com/about-can/the-can-protocol/the-can-bus/

[Coyotte]

Je m'en vais lire tout cela... 
Merci Dominique,

Michel

[Tony04]

A Dominique,

je viens de tester le sketch 3 nœuds de Jean-Luc (avec ACAN)  pour voir comment installer un compteur d'erreur comme tu me l'as suggéré.

L'objectif de ce compteur est normalement de s'assurer du bon déroulement d'un échange ce qui, dans mon cas ne fonctionne pas.

Je m'explique:
Le montage est celui de l'exemple de Jean-Luc avec 3 cartes. Tout se passe bien sur les 2 récepteurs.

Maintenant j'enlève la carte CAN du récepteur servo pour simuler une panne de cette carte et j'envoie une commande vers cette carte: Surprise! Aucune erreur détectée alors que logiquement plus aucun récepteur CAN n'a reçu la commande grâce aux filtres.
Bien sûr quand j'enlève aussi la carte CAN du récepteur leds l'erreur est signalée.

J'en déduit que sur tout un réseau CAN s'il y a au moins 2 cartes CAN en état aucune erreur ne pourra être détectée.

Suis-je dans le vrai ou m'échappe-t-il quelque chose ?

[Dominique]

OUi c'est vrai,

Il suffit qu'il y ait au moins un récepteur pour que l'émission soit OK. Sinon le tampon d'émission se remplit et cela monte une erreur.

D'ailleurs quand tu branches un récepteur à chaud, l'erreur disparait aussitôt.

Si tu veux t'assurer que le récepteur a bien reçu et exécuté la commande (les 2 à la fois), il faut que celui-ci envoie un message ad hoc.
Ca oblige à créer autant d'identifiants qu'il le faut car un même identifiant ne doit pas pouvoir être utilisé par 2 émetteurs différents.

Du coup, je reviens sur ta question initiale : oui tu peux utiliser un seul message d'un émetteur pour arroser plusieurs récepteurs à la fois.
Mais la seule garantie que tu as pour savoir si c'est exécuté par tous les récepteurs, ce sont les message de compte-rendu en réponse (tous individuels).
Chez moi j'en suis à 35 identifiants différents ! C'est encore peu.

Dans l'exemple de Michel, pour une synchro des horloges (date/heure où on n'est pas forcément à une seconde près), une répétition du message date/heure peut suffire à ce qu'il soit bien pris en compte.
Et un compte-rendu de ce type de commande ne serait pas nécessaire, si les satellites ont un autre moyen de faire savoir au central qu'il sont bien là et en service.