Parlons Arduino > Vos projets

projet de reseau etagere analogique

<< < (2/5) > >>

palou:
Bonjour

Je viens de faire un tableau avec un plan d'adressage des ID CAN des modules :
type de contrôleurMasqueFiltre miniFiltre maxiNombre idsNotesMASTER0x6fe0x6fe0x6fe1TCO0x6ff0x6ff0x6ff1spéciaux0x7f00x7f00x7ff16par exemple plaque tournanteaiguilles0x7c00x7c00x7df32commandes par relais (aiguilles et dételeurs)pwm0x7a00x7a00x7bf32Alimentation des sections de voiescapteursOx7800x7800x79f32Capteurs "courant" + barrières IRaccessoires0x7600x7600x77f32sorties diverses (leds, servos, ...)
Pour préciser, les contrôleurs aiguilles peuvent piloter 8 solénoïdes, les contrôleurs pwm pourront alimenter 1 ou 2 sections chacun (voir la faisabilité avec la bibliothèque syncPwm), les contrôleurs capteurs devraient pouvoir surveiller 8 capteurs chacun, et il se peut que certains capteurs soient pris en charge par les contrôleurs PWM (à étudier) et enfin les contrôleurs accessoires seront à la demande vu la diversité des accessoires possibles (passage à niveau, éclairage, portes de remise, ...)

Est ce que ce plan d'adressage vous parait cohérent ?

cdt
Pascal

Dominique:
Bonsoir,

Je ne suis pas à l'aise avec votre présentation par masque et filtre : ce qui compte c'est qu'il y ait un identifiant unique par émetteur (car il ne doit pas y avoir 2 messages émis avec le même identifiant par 2 émetteurs différents) et on ne voit pas qui est/sont les récepteurs et ce sont les récepteurs qui peuvent appliquer des masques et filtres pour ne voir que les messages qui les intéressent.
Evidemment je comprend que quand il y a un filtre min et max, cela veut dire qu'il y a une plage d'Id pour un ensemble de modules. Mais ce ne sont pas ces modules qui ont besoin de ces masques et filtres, ce sont les récepteurs qui sont d'autres modules (master, TCOs, etc..)
D'autre part, il faut faire jouer les priorités si nécessaire : les Id les plus petits seront prioritaires sur les plus grands. donc qui est prioritaire ?

Voici, comme exemple, les identifiants utilisés dans mon réseau :


J'ai listé tous les modules qui communiquent sur mon réseau et pour chacun, quel Id pour les messages émis, et quel(s) récepteur(s : souvent plusieurs) dont le gestionnaire de réseau qui reçoit tout en principe. Les masques et filtres c'est à voir après.
Pour les priorités :
- les détecteurs des zones d'arrêt (DP + feux) sont les plus prioritaires car les trains doivent stopper immédiatement.
- ensuite il y a les occupations de zones
- puis les demandes de commutation d'aiguilles
- puis les commandes de traction
- ...
- le RFID vient plus loin car c'est une confirmation de position, pas urgente
- puis viennent les commandes émises par le gestionnaire.

Je n'ai pas cherché de valeurs compliquées (il y aura plus tard des valeurs plus élevées pour les commandes du décor et des Id étendus pour les programmations)

Dominique:
Au passage, vous pouvez supprimer le buffer de réception (Can_recup()) car la bibliothèque ACAN contient une file d'attente qui fait la même chose.
Regardez les articles sur la bibliothèque ACAN et mon article sur les détecteurs RFID (https://www.locoduino.org/spip.php?article271)

palou:
Bonsoir Dominique

Si je comprends bien ce que vous me dites, il faudrait prévoir pour chaque controleur au moins 2 ID : 1 d'action et 1 d'interrogation.

Dans mon cas la chaine de commandement serait TCO => Master (pour les ordres), Master => controleurs (actions), Master => controleurs (interrogations).
Dans le sens retour on aurait controleurs => Master (alertes (par exemple occupation/libération/fin d'action)), controleurs => Master (réponses aux interrogations), et enfin Master => TCO (affichage du résultat)

Donc le TCO devrait avoir au moins 1 ID (pour l'affichage), le Master au moins 3 ID (ordres TCO, alertes controleurs, réponses controleurs) et les controleurs au moins 2 ID (actions et interrogation), sachant qu'un controleur pourrait avoir plusieurs ID pour les actions si certaines actions sont plus prioritaires que d'autre (par exemple pour la plaque tournante, l'alimentation de la voie est plus importante que la rotation. Il faut qu'on coupe le courant avant de commencer à tourner et  donc il y aurait 2 ID d'actions pour le controleur de plaque...)

Et ensuite définir un ordre de priorite : Par exemple par ordre d'importance, les alertes (C => M), les ordres (T => M), les actions (M => C), les réponses (C => M), les interrogations (M => C) et enfin l'affichage (M => T), sachant que certaines actions d'un controleur sont plus prioritaires que d'autres: Par exemple , le controleur de section (qui alimente la voie) devrait etre plus prioritaire qu'un controleur d'aiguille donc ses actions et alertes devraient avoir une valeur d'id plus faibles par rapport aux équivalents "aiguilles".

J'ai tout compris ? :)

Pascal

Dominique:

--- Citer --- J'ai tout compris ? :)
--- Fin de citation ---

Pas tout à fait : chaque module a un Id et un seul pour les messages émis. Mais ces messages peuvent avoir plusieurs significations en jouant sur les octets de données.
Moi je positionne des bits dans l’octet 0 (le premier) pour cela (voir mon exemple RFID).
Les autres octets dépendent de la signification.

La bibliothèque ACAN permet de manipuler facilement ces octets grâce aux multiples définitions du tableau de 8 octets (union de bytes ou Int ou long).

N’oubliez pas que les messages émis sont reçus par tout le monde (d’où les masques et filtres pour limiter le dérangement). Et il faut au moins un récepteur sinon l’émetteur se bloque.

Navigation

[0] Index des messages

[#] Page suivante

[*] Page précédente