Voir les contributions
1861
Discussions ouvertes / Re : Train miniature du futur
« le: décembre 20, 2017, 11:12:52 pm »
Tu as certainement lu mon article « Mise en œuvre du bus CAN » http://www.locoduino.org/spip.php?article148 dans lequel je décris comment réaliser une mémoire tampon circulaire pour ne perdre aucun message. Elle tient évidemment dans le même Arduino qui est connecté au 2515.
J’ai fait pas mal de tests pour verifier qu’aucun message n’est perdu de cette façon, y compris en observant le trafic en parallèle avec un autre Arduino. Il y a beaucoup de chose à dire sur la robustesse du protocole CAN, mais ce serait plutôt à faire sur le fil consacré au bus CAN http://forum.locoduino.org/index.php?topic=51.0 que sur sur le présent fil.
J’ai cru aussi au début qu’il fallait être capable de tenir des débits importants, mais ce n’est pas si vrai que ça et ça se calcule bien. Je pense que dans notre cas, on est loin des limites si on est en DCC (les commandes des locos passent par les rails, le reste par le CAN). C’est peut-être plus dense en traction PWM, avec la synchronisation expliquée par Jean-Luc puisque tout passe par le CAN.
Ta remarque concernant un contrôle de flux au niveau application (utiliser des accusés de réception) est tout à fait pertinente et je le pratique mais pas systématiquement. Par contre, pour commander des aiguilles j’evite que toutes les aiguilles changent en même temps et je fais respecter des délais pour éviter les pointes de courant trop importantes. Dans notre cas il y aura très peu d’aiguilles par canton (0 à 3 par exemple) et ce sera la commande des aiguilles par l’Arduino qui temporisera plutôt que le bus CAN.
En passant, j’ai déjà réalisé une console de surveillance du bus CAN, avec un écran LCD 4x20 et je te garantis que l’ecran est trop petit pour afficher tous les messages. Tu peux tout juste compter les principaux types de messages. Faire un data-logger sur carte SD avec lecture différée est possible.
Mais continuons cette discussion sur le fil du Can et revenons sur ce fil pour confirmer que le choix du CAN est valide.
J’ai fait pas mal de tests pour verifier qu’aucun message n’est perdu de cette façon, y compris en observant le trafic en parallèle avec un autre Arduino. Il y a beaucoup de chose à dire sur la robustesse du protocole CAN, mais ce serait plutôt à faire sur le fil consacré au bus CAN http://forum.locoduino.org/index.php?topic=51.0 que sur sur le présent fil.
J’ai cru aussi au début qu’il fallait être capable de tenir des débits importants, mais ce n’est pas si vrai que ça et ça se calcule bien. Je pense que dans notre cas, on est loin des limites si on est en DCC (les commandes des locos passent par les rails, le reste par le CAN). C’est peut-être plus dense en traction PWM, avec la synchronisation expliquée par Jean-Luc puisque tout passe par le CAN.
Ta remarque concernant un contrôle de flux au niveau application (utiliser des accusés de réception) est tout à fait pertinente et je le pratique mais pas systématiquement. Par contre, pour commander des aiguilles j’evite que toutes les aiguilles changent en même temps et je fais respecter des délais pour éviter les pointes de courant trop importantes. Dans notre cas il y aura très peu d’aiguilles par canton (0 à 3 par exemple) et ce sera la commande des aiguilles par l’Arduino qui temporisera plutôt que le bus CAN.
En passant, j’ai déjà réalisé une console de surveillance du bus CAN, avec un écran LCD 4x20 et je te garantis que l’ecran est trop petit pour afficher tous les messages. Tu peux tout juste compter les principaux types de messages. Faire un data-logger sur carte SD avec lecture différée est possible.
Mais continuons cette discussion sur le fil du Can et revenons sur ce fil pour confirmer que le choix du CAN est valide.
