Structure programme : Multi-instance

[Ronan]

Salut !

J'ai une machine comme ça :

- Les produits passent sur deux voies, qui effectuent chacune 3 opérations. La logique de chaque process est la même, seul les E/S changent en fonction de la voie.
- Les 3 process échangent des informations entre eux (synchro de cycle, état...)
- Les 3 process ont souvent besoin des mêmes entrées (état de la voie, mode manu/auto de la voie...)

Ma structure programme :

- L'OB1 crée deux instances du FB_VOIE et lui passe tous les paramètres d'E/S nécessaires.
- Le FB_VOIE fait le traitement et crée également 3 instances des FB_PROCESS1, FB_PROCESS2, FB_PROCESS3.
- Toutes les données d'E/S pour les FB process sont des données locales (stockée dans le DB du FB_VOIE).
- Chaque instance de FB "process" est locale (stockée dans le DB du FB_VOIE).

Le but :
- Avoir un traitement identique entre toutes les voies.
- Se tapper le "mapping" des entrée qu'une seule fois (au moment du paramétrage du FB_VOIE).

Je souhaitais simplement votre avis, vous faites comment dans ces cas là ?

Ronan

[GG10]

bonjour

pas facile comme question.
sache que en siemens on peut faire un programme l'exporter en source puis ensuite dans le source remplacer voie 1 par voie 2
réimporter le programme et voila ton deuxième programme est fait.
sinon j ai l habitude d'utiliser des fb d'instance exemple un fb moteur un fb vanne etc... que tu instancie avec un db a chaque utilisation.
tu peux forcement faire la même chose avec ton process mais faudrait avoir plus d 'élément et faire des essais avant de trouver la bonne solution.

[josé]

bonjour
Les FB sont la pour ça. Le programme de ton FB ne doit utilisé que les variables du DB d'instance. et la différence se fera sur les entrées sorties de ton FB .
Ou alors, j'ai pas compris la question.

Personnellement, je créer 1 bloc FB que je met au point et je fait sa copie avec rechercher/remplacer pour lui attribuer une autre zone de variables.
Des programmes identiques a la mise en service deviennent différent ( usures matériel, réglages tempos différentes ) remplacement par un matériel compatible mais avec des réglages différents, pièce cassé et se retrouvé devant une boite vide ou le stock mini est de 2 pièces

[R26R]

Pour moi ta structure prévue est la mieux adaptée, la plus propre.

Effectivement, des fois entre 2 trucs identiques en théorie, tu peux avoir des différence. Donc je suis parfois réticent aux FB.

Mais sinon je met à mon bloc FB un ID (integer), en entrée. Sur le premier FB je lui affecte la constante 1, sur le suivant 2, etc... Comme ça si j'ai une spécificité sur le 2e FB de part le systeme physique, je peux me dépatouiller en faisant une exception en faisant un compare id = 2...

Et bien laisser de la réserve dans les stats, si il manque une info en entrée et que tu peux pas en rajouter par exemple ta supervision tape direct dans le FB d'instance, ça te permet d'avoir de l'espace et de pouvoir affecter "hors bloc".

[Ronan]

Merci pour vos retours ! Vos retours vont dans le même sens que ce que j'ai fait, c'est une bonne nouvelle

bonjour

pas facile comme question.
sache que en siemens on peut faire un programme l'exporter en source puis ensuite dans le source remplacer voie 1 par voie 2
réimporter le programme et voila ton deuxième programme est fait.
sinon j ai l habitude d'utiliser des fb d'instance exemple un fb moteur un fb vanne etc... que tu instancie avec un db a chaque utilisation.
tu peux forcement faire la même chose avec ton process mais faudrait avoir plus d 'élément et faire des essais avant de trouver la bonne solution.

Les premiers essais sont concluants. Pour moi les "points noirs" sont pour la maintenance :
- Tout est dans un gros DB d'instance (pas hyper accessible pour des gens débutants)

- On peut se mélanger dans les environnements d'appels. Je m'explique : En tant que technicien de maintenance, je veux me mettre en ligne sur le bloc du process1 / voie 1
1- Ouvrir OB1
2- Sur l'appel du bloc FB_VOIE de la voie 1 : "Ouvrir et visualiser"
3- On obtient bien le FB_VOIE en visu dyn. avec l'environnement d'appel lié à la voie 1
4- Dans cette même fenêtre, sur l'appel du bloc FB_PROCESS1 : "Ouvrir et visualiser"
5- On obtient bien le FB_PROCESS1 en visu dyn. mais avec tous les appels du programme. On est obligé de changer manuellement l'environnement d'appel pour sélectionner la voie souhaitée.

Les FB sont la pour ça. Le programme de ton FB ne doit utilisé que les variables du DB d'instance. et la différence se fera sur les entrées sorties de ton FB .
Ou alors, j'ai pas compris la question.

C'est bien ça, le FB n'utilise que ses variables locales et la différence voie1/voie2/voieX se fait sur les entrées du FB_VOIE.

Pour moi ta structure prévue est la mieux adaptée, la plus propre.

Effectivement, des fois entre 2 trucs identiques en théorie, tu peux avoir des différence. Donc je suis parfois réticent aux FB.

Mais sinon je met à mon bloc FB un ID (integer), en entrée. Sur le premier FB je lui affecte la constante 1, sur le suivant 2, etc... Comme ça si j'ai une spécificité sur le 2e FB de part le systeme physique, je peux me dépatouiller en faisant une exception en faisant un compare id = 2...

Et bien laisser de la réserve dans les stats, si il manque une info en entrée et que tu peux pas en rajouter par exemple ta supervision tape direct dans le FB d'instance, ça te permet d'avoir de l'espace et de pouvoir affecter "hors bloc".

Pas trop de différences entres process, mais c'est effectivement la solution si un jour la logique doit varier entre les deux voies.

Merci encore

Ronan