[Ecostruxure Control Expert] DFB et SFC

[YassineSH]

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

Au temps pour moi, je voulais dire M580

Merci pour ta proposition, mais on peut pas instancier les vannes comme ça, si j'ai plusieurs vannes, je serai obligé d'appeler le grafcet.

[JC87]

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]

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]

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

Salut,

Non pas entièrement en SFC, mais les parties qui gèrent les vannes..

[YassineSH]

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...

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.

[sinced]

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.

Ton client est automaticien ?
la migration demande d'utiliser les methodes standards (analyses fonctionnelles, codage etc.)
De toute ma petite experience personnelle, je n'ai jamais programme un objet standard avec du SFC. En general LADDER ou FBD fait le job. Si j'ai peut etre des boucles etc je vais prendre le ST. Le SFC j'ai utilise pour justement gerer les sequences d'activation des equipements etc.

Tu dis que le programme initial est entierement en SFC sur le M580 ca veut dire que tu ne pourras pas utiliser de sous programme. Il va te falloir saisir a la main le SFC de chaque vanne apres avoir pris le soin de faire valider le fonctionement par le meme client. Le jour ou il faut faire evoluer l'application si tu as 30 SFC tu vas devoir modifier a la main les 30 SFC. Je suppose que ton client sera content de cette approche.