Voir les contributions
1
Bus CAN / Re : Bus CAN DIY compatible JMRI
« le: octobre 05, 2024, 10:31:59 am »
Bonjour Eric,
Je trouve très intéressant que tu relates tes expériences du CAN qui je pense rassureront ceux qui hésitent ou qui rencontrent des difficultés.
Tout d'abord, il est vrai qu'il faut commencer à chercher les causes de non fonctionnement dans les équipements "pas chers". Ils sont parfois défectueux ! Parfois c'est même la série entière. J'ai acheté une fois un lot de 10, aucun ne fonctionnait et je me suis aperçu que c'était le PCB lui-même qui comportait une erreur ( le H à la place du L) !!!
Le grand classique dans le non fonctionnement est souvent aussi l'erreur sur le débit. Ne pas chercher à faire du 1 Mbps avec les modules Niren 8 Mhz qui ne pourront jamais fonctionner à plus de 500 Kbps. De la même manière, dans un programme, l'un des modules est paramètré sur un débit donné et l'autre module sur un autre débit !!!
Tu as raison d'aborder l'utilisation de l'option loopback mode, c'est bien sûr par là qu'il faut commencer.
Et pour être absolument certain que la partie hard est correcte, c'est surtout d'avoir réussi à faire fonctionner deux modules entre eux, l'un en réception, l'autre en émission. A partir de là on dispose d'une base certaine pour ajouter et tester d'autres modules. Perso, j'ai deux UNO avec shield SEEED que je réserve à cela. Ils ne servent à rien d'autre, je ne change jamais le programme. Et quand je rencontre un problème, je ressort ces deux modules pour les insérer dans l'ensemble et m'aider à trouver où est le problème.
Un autre intérêt de cette façon de faire : Si un module CAN fonctionne en émission mais aucun sur le bus en réception, avec la biblio de Pierre Molinaro, l'émetteur va se mettre en carafe après avoir envoyé 17 message infructueux. Et donc, si l'on n'y prend pas garde, la source que l'on croyait bonne ne l'est plus et l'on a beau chercher côté réception, on n'aura jamais rien ! Par contre, si deux modules échangent normalement, il y aura toujours des trames à circuler sur le bus pendant que l'on recherche le problème.
Je recommande surtout d'être très organisé pour les diagnostics. Il faut par exemple toujours partir des programmes d'exemple de Pierre Molinaro, éventuellement modifier le programme pour en reserver un à l'émission et l'autre à la réception. (réserver deux modules comme je le disais ci-dessus). Parfois on cherche un problème de hard alors que c'est notre programme qui est faux. Cette manière de faire nous aide à déceler le problème.
Enfin, concernant le 2518 dont tu parles, il me semble que c'est un CAN FD donc non compatible avec la CAN 2.0 que l'on utilise généralement car il est aussi très avantageux économiquement.
Il serait très intéressant que d'autres puisse faire part de leurs pratiques, astuces et façon de faire pour aider et rassurer tout ceux qui souhaite avancer dans cette voie.
Merci encore.
Christophe
Je trouve très intéressant que tu relates tes expériences du CAN qui je pense rassureront ceux qui hésitent ou qui rencontrent des difficultés.
Tout d'abord, il est vrai qu'il faut commencer à chercher les causes de non fonctionnement dans les équipements "pas chers". Ils sont parfois défectueux ! Parfois c'est même la série entière. J'ai acheté une fois un lot de 10, aucun ne fonctionnait et je me suis aperçu que c'était le PCB lui-même qui comportait une erreur ( le H à la place du L) !!!
Le grand classique dans le non fonctionnement est souvent aussi l'erreur sur le débit. Ne pas chercher à faire du 1 Mbps avec les modules Niren 8 Mhz qui ne pourront jamais fonctionner à plus de 500 Kbps. De la même manière, dans un programme, l'un des modules est paramètré sur un débit donné et l'autre module sur un autre débit !!!
Tu as raison d'aborder l'utilisation de l'option loopback mode, c'est bien sûr par là qu'il faut commencer.
Code: [Sélectionner]
settings.mRequestedMode = ACAN2515Settings::LoopBackMode ; // Select loopback modeEt pour être absolument certain que la partie hard est correcte, c'est surtout d'avoir réussi à faire fonctionner deux modules entre eux, l'un en réception, l'autre en émission. A partir de là on dispose d'une base certaine pour ajouter et tester d'autres modules. Perso, j'ai deux UNO avec shield SEEED que je réserve à cela. Ils ne servent à rien d'autre, je ne change jamais le programme. Et quand je rencontre un problème, je ressort ces deux modules pour les insérer dans l'ensemble et m'aider à trouver où est le problème.
Un autre intérêt de cette façon de faire : Si un module CAN fonctionne en émission mais aucun sur le bus en réception, avec la biblio de Pierre Molinaro, l'émetteur va se mettre en carafe après avoir envoyé 17 message infructueux. Et donc, si l'on n'y prend pas garde, la source que l'on croyait bonne ne l'est plus et l'on a beau chercher côté réception, on n'aura jamais rien ! Par contre, si deux modules échangent normalement, il y aura toujours des trames à circuler sur le bus pendant que l'on recherche le problème.
Je recommande surtout d'être très organisé pour les diagnostics. Il faut par exemple toujours partir des programmes d'exemple de Pierre Molinaro, éventuellement modifier le programme pour en reserver un à l'émission et l'autre à la réception. (réserver deux modules comme je le disais ci-dessus). Parfois on cherche un problème de hard alors que c'est notre programme qui est faux. Cette manière de faire nous aide à déceler le problème.
Enfin, concernant le 2518 dont tu parles, il me semble que c'est un CAN FD donc non compatible avec la CAN 2.0 que l'on utilise généralement car il est aussi très avantageux économiquement.
Il serait très intéressant que d'autres puisse faire part de leurs pratiques, astuces et façon de faire pour aider et rassurer tout ceux qui souhaite avancer dans cette voie.
Merci encore.
Christophe