Forum automatisme

itasoft a écrit : ↑22 févr. 2024, 19:25 Ep58 2040, jamais entendu parler ?

Il ne reste plus que la solution de faire une section VANNE en SFC avec un BIT de déclenchement mis à 1 dans le Grafcet Général

YassineSH a écrit : ↑22 févr. 2024, 09:42 Dans les programmes d'origines, la gestion de la vanne est faite totalement en SFC, le client souhaite garder la même logique.

YassineSH a écrit : ↑22 févr. 2024, 09:42

itasoft a écrit : ↑21 févr. 2024, 17:47 un DFB pour chaque équipement (par exemple, une vanne)
-----------
Si ça veut dire que une vanne est un équipement alors c'est pas possible, ceci dit, pour moi une vanne c'est pas un équipement mais un actionneur
Par contre, La commande et le contrôle d'une vanne peut bien être encapsulé dans un DFB et appelée par le Grafcet

Ce que je veux dire par équipement, c'est un objet (c'est corrigé)
Dans les programmes d'origines, la gestion de la vanne est faite totalement en SFC, le client souhaite garder la même logique.

JC87 a écrit : ↑23 févr. 2024, 09:36

YassineSH a écrit : ↑22 févr. 2024, 09:42 Dans les programmes d'origines, la gestion de la vanne est faite totalement en SFC, le client souhaite garder la même logique.

Hello,

Vu que le client est roi il faut faire ce qu'il veut et puisque c'était fait comme ça avant et bien il faut faire la même chose même si ça parait inadéquat.

Cela dit j'ai un peu de mal à voir comment est fait le programme d'origine parce que un programme entièrement en SFC ça n'existe pas.

JC

Laurent a écrit : ↑23 févr. 2024, 09:49

YassineSH a écrit : ↑22 févr. 2024, 09:42

itasoft a écrit : ↑21 févr. 2024, 17:47 un DFB pour chaque équipement (par exemple, une vanne)
-----------
Si ça veut dire que une vanne est un équipement alors c'est pas possible, ceci dit, pour moi une vanne c'est pas un équipement mais un actionneur
Par contre, La commande et le contrôle d'une vanne peut bien être encapsulé dans un DFB et appelée par le Grafcet

Ce que je veux dire par équipement, c'est un objet (c'est corrigé)
Dans les programmes d'origines, la gestion de la vanne est faite totalement en SFC, le client souhaite garder la même logique.

Au temps pour moi, en lisant "SFC", mon cerveau a traduit automatiquement "FBD"...

Je pense que ton client n'est peut-être pas clair sur les langages dispos et leur finalité : le SFC, c'est du grafcet, et c'est fait pour implémenter des traitements séquentiels.

Pour la gestion d'un équipement comme une vanne, la logique de fonctionnement se fait en logique combinatoire, qu'on peut implémenter dans n'importe quel autre langage (ladder, FBD, ST, voire IL...), qu'on peut écrire dans une section de la tâche MAST, ou dans un SR, ou dans un DFB (et quand on a plein d'équipements similaires, le DFB est une excellente approche, comme tu voulais le faire !).

Il faudrait faire comprendre à ton client que :
- le traitement séquentiel de l'application reste bien défini dans une section SFC,
- les traitements propres à chaque équipement peuvent se faire dans un DFB (gestion des commandes, calcul des défauts, etc.),
- les DFB de chaque vanne sont appelés dans des sections dédiées, dans le langage qu'on veut, et s'interfacent avec le séquentiel en pilotant les vannes selon les étapes actives du gracfet.

La volonté de ton client de gérer les vannes dans le SFC peut être emmerdant, dans le sens où ça oblige à _TOUT_ mettre dans le grafcet ; ça risque de faire un grafcet "usine à gaz".

En espérant que ça t'aide...

YassineSH a écrit : ↑23 févr. 2024, 14:42

Laurent a écrit : ↑23 févr. 2024, 09:49

YassineSH a écrit : ↑22 févr. 2024, 09:42

Ce que je veux dire par équipement, c'est un objet (c'est corrigé)
Dans les programmes d'origines, la gestion de la vanne est faite totalement en SFC, le client souhaite garder la même logique.

Au temps pour moi, en lisant "SFC", mon cerveau a traduit automatiquement "FBD"...

Je pense que ton client n'est peut-être pas clair sur les langages dispos et leur finalité : le SFC, c'est du grafcet, et c'est fait pour implémenter des traitements séquentiels.

Pour la gestion d'un équipement comme une vanne, la logique de fonctionnement se fait en logique combinatoire, qu'on peut implémenter dans n'importe quel autre langage (ladder, FBD, ST, voire IL...), qu'on peut écrire dans une section de la tâche MAST, ou dans un SR, ou dans un DFB (et quand on a plein d'équipements similaires, le DFB est une excellente approche, comme tu voulais le faire !).

Il faudrait faire comprendre à ton client que :
- le traitement séquentiel de l'application reste bien défini dans une section SFC,
- les traitements propres à chaque équipement peuvent se faire dans un DFB (gestion des commandes, calcul des défauts, etc.),
- les DFB de chaque vanne sont appelés dans des sections dédiées, dans le langage qu'on veut, et s'interfacent avec le séquentiel en pilotant les vannes selon les étapes actives du gracfet.

La volonté de ton client de gérer les vannes dans le SFC peut être emmerdant, dans le sens où ça oblige à _TOUT_ mettre dans le grafcet ; ça risque de faire un grafcet "usine à gaz".

En espérant que ça t'aide...

Pour notre chef de projet, qui s'est battu pour convaincre le client avec notre proposition, mais le client reste ferme sur sa position, et on pense avoir compris pourquoi, c'est parce qu'ils ont des techniciens qui se sont permis de bricoler dans les programmes. Lors de notre analyse et étude des programmes, nous avons constaté que même les SFC sont mal faits, et qu'il y a pas mal de bricoles qui ont été faites sur le programme, mais bon ça marche...
Donc le client a un peu peur que le fait de passer dans un autre langage et de passer par des DFB, ses techniciens ne seront plus capables de le modifier.

Après, nous ne sommes pas vraiment contre l'utilisation du SFC, mais malheureusement ce langage ne peut pas être utilisé dans les DFB, et donc nous ne pouvons pas instancier.