Discussion:Grafcet

message: 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)
replies: text:  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)
thread_title:  Images absentes 

message: 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)
replies: text: 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)
thread_title:  type d'actions 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Macro 

message: 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)
replies: text: 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)

text: ... 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)
thread_title:  Norme 

message: 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)
thread_title:  Traduction de l'acronyme GRAFCET erronée 

message: 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)
thread_title:  modification du 29 aout 2009

message: 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)
thread_title:  Réceptivité 

message: 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)
thread_title:  Y'a des boulets qui écrivent ca Graphcet 

message: 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  : 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)
thread_title:  Remplacement d'une macro par son expansion...