Discussion:Grafcet

Images absentes

La plus part des images de la fin de cet article sont manquants. peuvent-elles être renvoyées ?

Les images ont été effacée faute de copyrigth clairement défini. Je n'ai pas eu le temps de les sauver. J'ai refait les premières facile à reconstituer, mais je cherche qqu'un pour m'épauler pour les restituer à partir du texte (qui n'est pas toujours très limpide à mes yeux) ou pour en faire des originales, quitte à adapter le texte (ce que je me proposais de faire, mais mes journées n'ont que 24 H ;-). J'ai mis un message à ce propos dans Wikipédia:Articles à approfondir. Si tu es partant....--Ssire 14 mars 2006 à 21:42 (CET)

Je vais essayer de faire ça un de ces jours. J'ai fait un cours sur le Gracet il y a un moment, je vais le ressortir et voir si je peux récuperer des images et du texte qui va avec. --Grouk 4 avril 2006 à 16:09 (CEST)

type d'actions

Je suis intrigé par les 3 derniers types d'action décrites.

• l'Action de comptage d'un temps n'est pas identique à la précedente? à moins que ce soit l'action limité dans le temps (qui est absente)
• l'Action fugitive correspond à un action sur frond montant d'activation de l'étape? quel en est sa représentation?
• l'Action maintenue pendant l'activation de plusieurs étapes est plus simplement un "action mémorisé", avec un set-reset (indiqué dans la norme)

Si quelqu'un a des idées de ce que voulais dire l'auteur... si non, je le referais à ma sauce.--Grouk 6 avril 2006 à 23:42 (CEST)

c'est bien là que je coinçais. Il me semble qu'il vaut mieux refaire à ta sauce, même le début, pour un ensemble homogène (ça ne me gène pas du tout si tu remplaces mes dessins par les tiens pour la même raison)--Ssire 7 avril 2006 à 00:42 (CEST)

Macro

Je n'avais jamais fait attention à cette règle de l'utilisation unique d'une macro. (Différent de sous-programme). Je suppose qu'il y a une raison objective à cela ? Laquelle ? Si connue, peut être que ça vaudrait le coup de l'indiquer dans l'article ?--Ssire 8 avril 2006 à 07:36 (CEST)

Cela vient du fait que si elle est utilisée plusieurs endroits dans le Grafcet, il se pose un problème si elle est appelée en même temps de ces différent endroits : l'activité des étapes est alors être mélangé entre les appels. Si l'on veux utiliser une même macro, il faut la dupliquer. Cela revient en fait à faire un instance de Macro par appel, à l'instar des appels de fonctions dans la norme IEC 61131-3.--Grouk 8 avril 2006 à 10:28 (CEST)

Ama , il vaudrait mieux la supprimer ici et, à la limite n'en parler que dans la section du langage 'SFC'. La notion de Macro est surtout une invention du constructeur Schneider pour faciliter la mise en page dans ses ateliers de programmation. Il n'y a en fait aucune autre raison logiquement valable à la création de "macro" dans la norme ;) . On ne gagne que de la lisibilité. Et au passage, ce constructeur admet dans son langage la notion de jetons multiples : c'est à dire qu'il permet l'activation de plusieurs étapes simultanément lors de transition "OU" non complémentaires dans une même branche (soit un "ET" caché incongru et dangereux).--Rodan (d) 17 mai 2008 à 08:23 (CEST)

Norme

En fait, il faut commencer par préciser que "GRAFCET" est une norme (ce que je viens de faire). Il y a donc des documents officiels qui normalisent ça. Il faut les relire , les digérer et en faire un aperçut encyclopédique ici.

Mais surtout : les exemples ne sont pas "normés". Actions sur les étapes initiales (l'étape initiale est l'état inactif du grafcet et ne doit donc rien faire)
Branches à deux étapes : ça revient à un état inactif et un état actif.... ça s'appelle un "bit" ;)
Etape unique dans une branche entre 2 transitions en ET... sont interdites , et pour de bonnes raisons de sécurité et de logique simple.
Et accessoirement, les flèches ne font pas partie de la norme : ce n'est pas du logigramme , il suffit de respecter le fait que la transition doit toujours être au-dessous de l'étape, et il n'y a aucune confusion possible. Si le trait remonte, il commence toujours par descendre avant ;)

je ne suis pas d'accord sur le fait qu'une étape initiale n'effectue aucune action. Elle peut en faire Crochet.david 15 mars 2007 à 20:49 (CET)

David Crochet, garde à l'esprit que tu es un enseignant (on s'est croisé déjà ici et là). Tu n'enseignes que ce que tu observes dans l'interprétation des normes faites par certains constructeurs d'automates programmables industriels. Le résultat est que nous devons corriger dans l'industrie (le vrai monde ou les machines bougent...) ce genre d'interprétation fausse et dangereuse. GRAFCET a été pensé au départ pour éviter certains aléas de fonctionnement observés dans la nature et assurer un fonctionnement synchrone et réactif d'un système séquentiel. Le fait que les implémentations aient dérapé et changé cette norme en langage ne devrait pas le faire oublier. Pour revenir à l'étape initiale (juste pour exemple), considère-la comme équivalente au "zéro" en algèbre et, même si le langage utilisé permet d'y associer une action, s'interdire cette possibilité n'est absolument pas une mauvaise idée.... au moins pour les actions qui "font bouger des trucs" ;). On me dit souvent "mais je veux allumer un voyant qui dit que le cycle est inactif". Je répond "c'est que tu réfléchis à l'envers". Tu devrait avoir (à un niveau supérieur combinatoire ou même... gemma -une horreur-) des modes de marches, des permissions de cycle, des signaux de départ cycle et tout ce qui commande le cycle. Le graphe doit être esclave de ces commandes et considéré dans son ensemble comme un actionneur. Le souci que l'on observe c'est que certains langages d'automatisme veulent tout permettre dans un seul langage (une seule interface d'édition) dans le seul but de simplifier l'enseignement des programmeurs. Dans ton enseignement ne te limite surtout pas à un seul langage, ce n'est pas un service à rendre à un étudiant. En bref, tout ce que je dit c'est simplement qu'il ne faut pas confondre langage informatique et norme. On peut implémenter (écrire, coder) du grafcet en C ansi et faire une addition en langage sfc sur un automate schneider à jetons multiples.--Rodan (d) 17 mai 2008 à 08:23 (CEST)

... ce que Grouk a très bien précisé dernièrement (je viens de voir le détail de l'évolution de l'article avant d'écrire ce petit chapitre qui n'a plus trop lieu d'être), mais je laisse, ça peut servir.--Rodan (d) 17 mai 2008 à 08:23 (CEST)

exclusivité du OU

Si j'ai compris quelque chose, soit on enlève ta phrase sur le "grafcet fautif" qui dit que dans une divergence en OU à deux receptivités vraies, l'état est indéfini, soit on enlève la règle 4.

Pour moi, la règle 4 devrait se dire : si deux évènements, survenant avec un écart inférieur au temps de réaction de la PC, rendent deux transitions simultanément franchissables, elles sont alors obligatoirement franchies (peut être pas exactement simultanément, mais au moins dans un délai inférieur au temps de réponse de la PC).

Donc les OU sont inclusifs dans le Grafcet. Il est évident que la force du Grafcet est qu'à chaque fois que je vois un OU, je me pose la question "et si les deux étaient vraies ?" alors qu'avec tous les autres langages on ne distingue pas ces cas qui font tout planter uniquement une fois tous les 6 mois quand tout le monde est à la bourre.

Pourquoi le grafcet m'interdirait-il de dire : certaines pièces doivent êtres peintes à droite, d'autres à gauche, et certaines des deux côtés, si je possède un poste de peinture de chaque côté ?

Par contre, on est d'accord, les implantations réelles du Grafcet sur API, et surtout le SFC fonctionnent différemment (mais là ce n'est pas non plus indéfini, je crois qu'on va à gauche)

Patrick TRAU pat(à)trau.fr

Traduction de l'acronyme GRAFCET erronée

GRAFCET ne signifie pas « GRAphe Fonctionnel de Commande Etapes/Transitions ». GR signifie bien "graphe" mais "AFCET" est en réalité le nom de l'organisme (loi 1901) qui a soutenu cette modélisation des automates séquentiels. Elle a été créée en 1968 sous la dénomination Association Française de Cybernétique Economique et Technique, puis devenue ASTI (Association des Sciences et Techniques de l'Information ) en 1998 ...

Cela siginie en fait les deux. Voici un extrait tiré du Groupe GRAFCET: "[...] L’analyse des avantages et inconvénients de ces outils mena, en 1977, à la définition du GRAFCET, ainsi nommé pour, à la fois marquer l’origine de ce nouvel outil de modélisation (grAFCET) et son identité (GRAphe Fonctionnel de Commande Etapes-Transitions)." Grouk 30 août 2007 à 15:49 (CEST)

Vieux Liens

Le premier lien sur le GrafCet n'est plus conforme ; sa dernière mise à jour date de 1998...

Règle n°5

Y a-t-il un exemple pour illustrer cette règle?

Dans l'état, elle semble antagonitse avec les autres: en effet en reprenant l'illustration juste en dessous, si la réceptivité en aval de l'étape 5 "(a.b)+c=1" vaut 1 avant l'activation de l'étape, lorsque l'étape 5 est activée, la transition en aval étant validée (et donc automatiquement franchie), elle provoque la désactivation de l'étape 5: en résumé et en théorie, 5 est simultanément activée et désactivée, et pourtant... dans la pratique, les automates considèrent l'étape comme désactivée.

modification du 29 aout 2009

Les version précédentes ne sont ni correctes ni lisibles. certains liens ne sont pas pertinents (notamment celui qui dirige vers "le grafcet langage de programmation" puisque le grafcet n'est pas, ne peut pas et ne sera jamais un langage de programmation). Jean-bernard DELUCHE (d) 29 août 2009 à 09:45 (CEST)

Réceptivité

Le terme "condition de transition" est préférable à réceptivité.

"réceptivité" est bien le terme officiel. La réflexion est à soumettre aux organismes de normalisation, mais pas ici... --Rodan (d) 24 février 2011 à 14:54 (CET)

Du grafcet aux réseaux de Petri

Auteur(s) : René David, Hassane Alla

Editeur(s) : Hermès - Lavoisier

EAN13 : 9782866013257

Résumé

Les connaissances nécessaires à la compréhension et à l'utilisation du Grafcet et des réseaux de Pétri sont réunies dans cet ouvrage. Le Grafcet est un outil de spécification des automatismes logiques. Créé en 1977, il est maintenant largement enseigné et utilisé en France et il est devenu une norme internationale en 1987. Une présentation formelle et cohérente y est faite ici. Les réseaux de Pétri permettent la description de systèmes dynamiques à événements discrets de toute nature. Ils possèdent de nombreuses propriétés qui sont présentées ici de façon simple et claire. Les principales extensions et abréviations utiles pour la modélisation et l'analyse des systèmes à événements discrets sont présentées. Outre les réseaux de Pétri synchronisés, temporises, stochastiques, continus et colorés, cette deuxième édition définit et étudie les réseaux de Pétri hybrides qui contiennent une partie discrète et une partie continue. Cette édition introduit également les réseaux de Pétri synchronisés étendus, et apporte des compléments et améliorations. Du Grafcet aux réseaux de Pétri , qui s'adresse en priorité aux enseignants, constitue un support de cours indispensable pour les écoles d'ingénieurs et les universités. Sa conception didactique originale le rend accessible à de nombreux lecteurs. En effet, une centaine d'exercices dont certains très élémentaires sont proposés au fur et à mesure de l'avancement de la lecture, et une solution est donnée pour chacun de ces exercices.

Les réseaux de pétri sont un "design pattern" des GRAFCET qui leur sont antérieur.

Y'a des boulets qui écrivent ca Graphcet

Pourrait on insister sur l'orthographe, il y a des ingénieurs de 3ème zone qui trop content d'avoir appris ca, n'ont rien retenu et écrivent Graphcet, voire pire Graphset :) 77.159.196.124 (discuter) 11 juin 2019 à 12:42 (CEST)

Remplacement d'une macro par son expansion...

Dans le texte il est indiqué : "Une macro-étape Mi peut être complètement remplacée par son expansion qui contient une étape d'entrée Ei et une de sortie Si." Donc n'y a-t-il pas une erreur dans le graphique : pourquoi les étapes d'entrée et de sortie, qui feraient bien partie de l'expansion, n'ont-elles pas été reprises dans le grafcet équivalent, figurant tout à droite ? Cela serait pourtant cohérent avec le texte qu'elles le soient. Et sinon comment procéder si la transition issue de l'étape d'entrée de l'expansion de la macro n'a pas une réceptivité toujours vraie, et/ou si la macro elle-même n'a pas en sortie une transition dont la réceptivité est toujours vraie ?

Sinon il me semble bien que cette notion de "macroétape" a été introduite à l'instigation de Télémécanique (actuellement Schneider Electric), comme le dit Rodan.

Pour info j'avais programmé un exécuteur de Grafcet dans le temps (ça fait plus de 35 ans), faisant partie d'un simulateur d'automatisme incluant une modélisation de la PO. Je m'étais un peu cassé la tête sur ces macros, finalement j'avais laissé tomber pour le produit final. Produit qui est encore utilisé, la boîte qui le commercialise et vend des prestations dessus, issue du labo d'automatique de l'université de Valenciennes, a été rachetée par IGE-XAO, après avoir été un temps une "division" de Schneider.

J'ai noté qu'il n'est pas question dans l'article des forçages. Sujet délicat, j'ai d'ailleurs constaté que ce qui est dit dans le David/Halla ne semble pas conforme à la norme. Mais par contre correspond en gros à ce que j'avais programmé (mais utilisé par seulement quelques initiés). Bdel63 (discuter) 7 mai 2023 à 22:25 (CEST)