j'ai une incompréhension portant sur la programmation et représentation d'automate programmable. J'étudie actuellement les automates dans l'optique d'en implémenter un par la suite.
En faisant des recherches portant sur la programmation d'automate, le cours mentionne différente manière de représenter le programme dont un certain nombre prenant l'appellation de "conception parallèle".
Mais si j'ai bien compris, un automate fonctionne selon un cycle de scrutation, incluant la phase de scrutation entrée et sortie et la phase d'exécution, et il procède de manière séquentielle.
Est-il malgré tout possible de programmer un automate avec des méthodes parallèles? Ou s'agit-il simplement d'une représentation pour le cahier des charges et in fine, le programme devra être écrit et interprété de manière séquentielle?
Merci de votre réponse et bonne fêtes de fin d'année.
Je n'ai pas suivi ce cours. Un automate peut avoir plusieurs senseurs ou déttecteurs. Il est parfois plus efficace de séparer les processus d'analyse en processus paralllèles. Ils sont plus simples à coder, et si le processeur est assez puissant, cela pourra augmenter la réactivité de l'automate.
Le Tout est souvent plus grand que la somme de ses parties.
Je comprends totalement l'intérêt d'avoir un processus parallèle d'un point de vue efficacité voir même d'architecture. Mais ma question c'est est-ce que un automate programmable industriel peut faire fonctionner des processus parallèle?
A la lecture du cours que j'ai pu trouver j'ai cru comprendre qu'il fonctionnait uniquement d'une manière séquentiel, en répétant le cycle. Peut-être ai-je mal compris et c'est totalement possible.
En grafcet par exemple, après une divergence en OU, tu vas te retrouver avec autant de processus s'exécutant en parallèle que de branches, donc oui, un API peut exécuter des tâches en parallèle.
Je ne répondrai pas pour zoup, mais ça dépend vraiment de l'automate. Y a-t-il plusieurs moteurs ou circuits à contrôler? Est-ce qu'il y a un sélecteur de ligne (ou données) qui permet d'accéder à diverses fonctions de l'automate? Si ces fonctionalités sont indépendantes et que le contrôleur y a accès, on peut le faire en "parallèle".
Le Tout est souvent plus grand que la somme de ses parties.
En réalité je suis en train de choisir un automate pour répondre à mes besoins, je me renseignais sur cette possibilité pour faire un choix le plus éclairé possible. Mon système devra présenter un sélecteur de données et un seul circuit de contrôle.
Si tu es capable d'envoyer les informations appropriées à chaque composante à travers ce circuit, tu fais des actions parallèles. Parce que l'ordi est beaucoup plus rapide que la mécanique. Le sélecteur active l'entrée de la composante désirée et c'est seulement celle-ci qqui accepte l'information.
- Edité par PierrotLeFou 3 janvier 2022 à 15:00:11
Le Tout est souvent plus grand que la somme de ses parties.
Merci de ta réponse. Est-ce que tout les automates peuvent effectuer des traitements parallèles ou certains en sont incapables?
Je ne suis pas spécialiste en API, mais comment pourrait-il en être autrement? Si tu ne peux pas surveiller 2 entrées indépendantes (ou plus) simultanément et réagir en fonction de leur état, l'intérêt d'un API risque d'être très limité.
Apparemment les automates ont un cycle que l'on peut diviser en deux parties:
- La scrutation E/S
- La scrutation programme
Lors de la scrutation entrée/sortie, l'automate lit les entrées et envoie des signaux de part ses sorties. Lors de la scrutation du programme il va exécuter les instructions du programme au regard de l'état des appareils.
L'automate gère donc les entrées/sorties à un moment de son cycle et exécute les instruction à un autre moment.
Admettons que l'entrée E1 doit activer l'état 1 et que l'entrée E2 active l'état 2.
Si E1 et E2 sont activées simultanément, tu penses qu'il faudra systématiquement attendre la fin d'un des états pour activer l'autre, ou bien que les 2 états pourront être activés en même temps?
Encore llà, ça dépend si les entrées / sorties créent une interuption ou si on doit faire du polling. Pourquoi devrait-on le faire en même temps pour chaque entrée / sortie ?
Le Tout est souvent plus grand que la somme de ses parties.
Les entrées s'activeront l'une après l'autre avec certainement un léger écart de temps de quelques micro secondes lors de la scrutation E/S. D'un point de vue programmation ca peut très bien se gérer sans avoir du parallèle.
Le déclenchement des actions et récupération des observations se font de façon séquencielle, mais avec des décalages de l'ordre du nanoseconde. Mais l'exécution prendra plusieurs millisecondes, voire secondes si on parle de composantes mécaniques. Donc ces actions se feront en parallèle.
Le Tout est souvent plus grand que la somme de ses parties.
Encore llà, ça dépend si les entrées / sorties créent une interuption ou si on doit faire du polling. Pourquoi devrait-on le faire en même temps pour chaque entrée / sortie ?
La programmation d'un API ne peut être comparée à celle d'un microprocesseur et la méthode de scrutation des entrées est transparente. Venant du monde du microprocesseur, j'ai eu du mal à raisonner dans la logique API.
Je vais parler de ce que je connais un peu, en l'occurrence la programmation d'un API en Grafcet qui est une implémentation de machines d'état.
Dans cet exemple, si "condition1" est vraie, les états 21 et 30 seront actifs, ce qui veut dire que la branche de droite et celle de gauche seront parcourues SIMULTANEMENT, donc en parallèle.
Je me posais sans doute les mauvaises questions. Je regardais d'un côté la possibilité hardware de réaliser un automate, et comment le faire. Et de l'autre côté, comment écrire le programme. Le programme est forcément séquentiel, mais il contient des variables d'état qui simulent le parallélisme.
Bien que l'utilisation de thread dans des langages évolués fonc que les processus sont "concurrenciels", donc apparemment parallèles.
- Edité par PierrotLeFou 5 janvier 2022 à 2:52:28
Le Tout est souvent plus grand que la somme de ses parties.
Merci PierrotLeFou et zoup pour tout ces éléments de réponse.
J'aurai une dernière question, comme il y a possibilité de traitement parallèle, l'API traite cela par des registres et différents unités fonctionnelles c'est bien cela?
Ça peut être cela, mais pas forcément. Si ton automate n'était pas trop compliqué et ne nécessitait pas une grande réactivité, on pourrait le faire sur une machine n'ayant qu'un seul coeur (comme un Z80, pourquoi pas ... ) Mais si tu as accès à une machine multi-coeurs, tu pourras vraiment le faire. L'idée que je vois est qu'il y a plusieurs ordres de grandeur entre la vitesse de l'ordi et celle de l'automate. L'ordi peut déclencher en quelques micro-secondes plusieurs processus qui vont durer plusieurs millisecondes, voire secondes si c'est mécanique.
Le Tout est souvent plus grand que la somme de ses parties.
Ok très bien. Ca signifie que si dans mon programme j'ai plusieurs branches et que j'ai un API "simple", finira la première branche avant de débuter la seconde branche. Dans le cas où l'API est composé d'un système plus complexe (multi-coeur, plusieurs unités fonctionnelles...), il pourra parcourir les deux branches de manière simultanée. C'est bien cela?
Si ton automate était un ordinateur ... On peut faire une requête pour accéder au disque dur. Ça prend combien de temps pour émettre la requête? Moins d'une micro-seconde. Mais ça prend combien de temps pour faire bouger les bras des têtes de lecture? Quelques millisecondes. Ça veut dire que je pourrais contrôler disons 100 disques "en même temps". Mais toutes mes actions auraient été séquencielles. Si j'ai un processeur multi-coeurs, les requêttes pourraient être lancées "simultanément" (en parallèle) Mais si tu as un seul bus de transfert (pour les fonctions et pour le data), pourras-tu faire 1000 actions en même temps?
Le Tout est souvent plus grand que la somme de ses parties.
Avec un seul bus je pourrais potentiellement organiser ma séquence de tel sorte que les actions se déroulent en même temps. Mais dans ce cas on traitera une seule opération à la fois, mais on pourra travailler sur plusieurs actions.
On se méprend sur la notion de "parallèle". Tu ne peux pas "déclencher" les actions en parallèle. Mais une fois déclenchées, elles "s'exécutent" en parallèle.
Le Tout est souvent plus grand que la somme de ses parties.
Merci du temps que vous avez passé à m'expliquer. Je clos le sujet.
Merci encore
Interrogation sur la programmation d'automate
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.