Bonsoir,
Merci à fdufnews et Christian_R pour vos réponses.
Je vais les prendre dans l'ordre.
En principe tous les blocs ont le même comportement mais effectivement il peut y avoir des exceptions. On peut dire qu'il y a trois types de blocs ceux qui n'ont pas d'aiguillage et ceux qui ont des aiguillages mais là, je pense que par programmation ou par la mise à un certain niveau de certaines entrées cela peut se régler.
Puis il y a les faisceaux d'aiguillages et là le code est sûrement différent. Cela demande en effet une maintenance plus importantes car deux programmes. Je me dis que peut-être par programmation, je pourrai par la suite faire des classes différentes et par des directives de programmation, chaque carte pourra utiliser la bonne classe.
fdufnews:
Lorsque plusieurs intervenant sont susceptibles de parler sur un même bus il peut y avoir des carambolages. Il faut utiliser/développer un protocole de communication qui soit insensible aux carambolages et qui garantisse l'intégrité des échanges.
Le protocole de communication peut être très simple.
Chaque carte est identifiée par un numéro. La carte avec le numéro le plus bas commence à questionner ses voisines. Lorsqu'elle a fini elle passe la main au numéro suivant et ainsi de suite jusqu'à la dernière.
Ou bien la carte avec le numéro le plus bas commence a publier sont état sur le bus (celle qui sont intéressées le capture au passage). Lorsqu'elle a fini la suivante prend le relais et ainsi de suite jusqu'à la dernière.
Il faut bien sur prévoir des sécurités, si une carte ne parle pas dans un temps imparti, on la déclare en panne et la suivante prend son tour.
Ou alors il faut un maître qui synchronise tout le monde.
Pour toute cette partie, je comprends le raisonnement et le principe mais alors la mise en application, je ne vois pas du tout, utiliser ou créer un protocole, donner un ID à une carte, écouter ce qu'il y a sur le bus puis prendre ou pas l'info, ça je ne vois pas comment !!!
fdufnews:
C'était juste un exemple d'architecture de communication. Mais comme je l'ai dit elle n'est pas très efficace.
Il vaut mieux privilégier les architectures qui permettent à une carte d'interroger ces voisines ou alors une architecture centralisée avec une carte maître qui interroge tout le monde et qui ensuite distribue un état du système à toutes les cartes.
Ma préférence allant plutôt vers un système distribué (c'est à dire sans maître) car c'est généralement plus robuste aux pannes matérielles. Si une carte tombe en panne le reste du système peut rester fonctionnel pour autant que cela ait été pris en compte à la conception.
Donc si je comprends bien ce que tu me dis c'est que l'exemple que je joins, qui est l'architecture que je pensais mettre en place, est possible mais pas efficace, ai-je bien compris ?
Ce que tu préconises c'est de développer/utiliser un protocole d'échange et que les cartes communiquent entre elles sans maître. Si c'est bien ça, il s'agit de mettre en place l'architecture matériel comme dans mon document joins mais les liaisons entre les cartes (blocs) seraient différentes ? Est-ce que je suis juste avec mon schéma joins ? Ta solution me plaît bien.
Concernant les réponses de
Christian_R:
je verrai plutôt un système centralisé avec une seule carte de commande et des aller/retours d'informations par un simple protocole 2 fils (type i2c, SPI, ou un truc fait maison...)
Mais comment gérer 150 entrées et 50 sorties sans multiplexage avec une seule carte ? car l'idée de supprimer le multiplexage me plaît bien... je pense plus simple à gérer...
- Par quoi (composants) les aller/retour se font-ils ?
Christian_R:
Donc des connexions asynchrones intelligentes entre plusieurs composants.
C'est quoi les "entres plusieurs composants" ?
Christian_R:
On envoie et reçoit les données (ouverture ou fermeture d'un aiguillage par exemple) sous la forme "adresse+donnée" avec un maître et plusieurs esclaves.
Je ne suis pas sûr de bien suivre, au-dessus tu dis que tu verrais mieux un système centralisé avec une seule carte, pourrais-tu stp m'expliquer ce que tu entends !!
Christian_R:
Ca utilise seulement 2 broches (DATA + CLOCK) et c'est évolutif à l'infini.
Ca serait génial si évolutif à l'infini, mais j'ai besoin de plus d'explications ou d'un schéma car je ne comprends pas, désolé !!! Je pense que tu veux dire que les esclaves peuvent être mis à l'infini et il suffit de mettre à jour le programme (ou peut-être même pas) ?
Christian_R:
Des DIP switches peuvent servir à coder des adresses sur les actionneurs,
C'est quoi ces actionneurs ?
J'avoue que tes propositions m'intriguent et m'intéressent mais j'ai de la peine à matérialiser tout ça... et le code là derrière, est-il compliqué ?
Merci à vous et je me réjouis déjà de lire vos réponses. J'aimerais vraiment trouver une solution pas trop complexe pour un premier projet.
Bonne soirée
Bien cordialement
Dbe8f
**PS: Pour le document joins, les alimentations ne sont pas là, les E/S sont prises au hasard, c'est juste pour le principe !**Est-ce que les documents joints ne sont visibles que lorsque l'on se logue ? Voyez-vous le document joint ?
