Comprendre le génération des gammes-requêtes RGG
Introduction
Au cours du traitement DT-IN-PL, dans la phase IN, on va venir activer les étapes de la gamme à utiliser: en effet, on peut par exemple enlever une étape qui n’aura pas lieu…
Les étapes de gammes sont toutes définies au même endroit dans DIAPASON: dans le dictionnaire des étapes.
Pour chaque étape du dictionnaire des étapes, on a associé un certain nombre d’informations comme par exemple la durée de l'étape, le temps de préparation.. ces données peuvent être surchargées dans les RGG si on le souhaite !
Si on ne gère pas d'étapes de production…comme c’est le cas pour des DIAPASON START installés dans des petites structures, on a forcément une étape de fin ( étape Fin de fabrication) qui est livrée avec DIAPASON. On peut mettre des informations dessus comme la durée ou l’unité de mesure de charge. On a pas besoin de mettre la gamme dans les Informations techniques de la nomenclature !
Comment fonctionne la génération de la gamme ?
Une fois que la gamme a été choisie dans la RVG, on va venir voir quelles étapes sont à activer ou non. Pour cela, c’est dans la nomenclature que ça se passe !
Voici la gamme PVC qui a été choisie dans la RVG:
Or, dans la nomenclature, on a associés des étapes de gammes aux différents articles dans les informations techniques !
On va donc venir parcourir la nomenclature, lister les étapes de gammes que l’on trouve, soit: A, C et D, et ainsi venir activer ou non les étapes de la gamme choisie dans la RVG:
Le principe de génération des gammes génériques tient compte des relations multiples pouvant exister entre étapes.
Précisément, c’est l’utilisation des valeurs des variables Existence Etape et Existence Liens qui pilotent son comportement. Ces 2 informations sont initialisables également dans la requête de génération de la gamme générique (Requête RGG).
![](../__attachments/115157916/att_7_for_293012150.png?inst-v=2e0628d9-a170-4eb1-b774-b0d7a84fa1a1)
Le principe est le suivant :
Si une étape n’existe pas, tous les enfants qui lui sont rattachés héritent des relations qu’elle a avec sa ou ses étapes pères.
Si les liens d’une étape n’existent pas, tous les liens effectifs sont supprimés, et les étapes antérieures qui n’ont qu’un lien unique avec cette étape sont récursivement supprimées également.
Comportement sur les cas d’arborescences simples n’a pas évolué : si la gamme générique est la suivante (A ➡️ B ➡️ C), le comportement
Si l’étape B n’existe pas, la gamme générée devient A ➡️ C.
Si les liens de l’étape B n’existent pas, la gamme générée est composée de l’étape C.
Quelle est la logique des requêtes RGG ?
Principe: Ces requêtes permettent de générer les étapes de la gamme avec toutes les infos associées (durée, temps de préparation..)
Il y a plusieurs requêtes RGG qui sont exécutées:
Une requête RGG liées à la gamme
La requête FabGamITs ( ou une requête similaire nommée autrement)
Une requête RGG par étape de la gamme
Toutes ces requêtes n’ont pas à être créées ! Elles le sont automatiquement quand on crée la gamme et les étapes de gamme.
La RGG de la gamme
Cette RGG sert juste à lancer la requête FabGamITs.
Elle porte le nom de 1_[Nom de la Gamme], par exemple 1_PVC.
La RGG FabGamITs
La RGG FabGamITs est une procédure qui n’est exécutée dans la RGG principale que si on l’appelle. Elle n’est pas exécutée par défaut. L’appel se fait en mettant “EXE-ETAPE RGG FabGamITs”. Elle parcourt les IT de la nomenclature et crée les étapes de la gamme qui existent. C’est dans cette requête qu’on peut surcharger des informations sur chaque étape de la gamme et qu’on peut définir quelles étapes existent ou non:
Nom_Etape Existe =0 : l'étape existe !
Nom_Etape Existe =1 : l'étape n’existe pas !
Attention à ne pas s’embrouiller, c’est bien “0”: l'étape existe et “1”: l'étape n’existe pas.
![]() | Cette fonction permet de mettre a jour de façon générique la valeur d’une variable d’une étape de la gamme |
Les RGG des étapes de la gamme
Les RGG des étapes de la gamme ne sont en général plus utilisées…au profit de la requête FabGamITs.
Comment paramétrer les RGG ?
Il y a une particularité dans les RGG: les variables qui y sont proposées dépendent de la gamme ! Par exemple, dans une RGG pour la gamme PRDSPE, qui comprends l'étape ASSPE on va pouvoir gérer les informations suivantes:
On peut ainsi réécrire les différentes données relatives à la gamme:
![](../__attachments/115157916/image-20230105-094513.png?inst-v=2e0628d9-a170-4eb1-b774-b0d7a84fa1a1)
On peut aussi alimenter les valeurs d’unité de mesure de charge
➡️ Première solution pour alimenter les valeurs d’unité de mesure de charge: on les alimente en dur dans la RGG
Dans notre exemple, imaginons que la configuration n’est pas faite dans DIAPASON. La seule information que l’on reçoit du configurateur, c’est le temps de fabrication en heures de la menuiserie, qui est envoyée dans une variable de la ligne de commande. Si la menuiserie est fabriquée en 4h, le configurateur transmet l’information sur la ligne de commande où on retrouve le champs Temps de fabrication =4h.
Or, on sait que le temps total de fabrication en heures de la menuiserie est partagée de la manière suivante:
25% sur le premier atelier, Débit
50% sur le second atelier, Assemblage
25% sur le 3eme atelier, Emballage
On écrira donc dans la requête RGG de la gamme:
![](../__attachments/115157916/image-20221205-150005.png?inst-v=2e0628d9-a170-4eb1-b774-b0d7a84fa1a1)
Le code suivant:
![]() | Ici, on définit:
|
Dans les RGG on a accès des variables qui sont crées spécialement pour les étapes de notre gamme !
➡️ Seconde solution pour alimenter les valeurs d’unité de mesure de charge: on les alimente via les Informations Techniques
Dans notre exemple la gamme sert à produire des menuiseries. On peut définir que chaque vantail de la menuiserie va passer:
1h à l'étape Débit
2h à l'étape Assemblage
1h à l'étape Emballage
Nous allons donc rajouter ces durées pour chaque étape dans la nomenclature générique du vari-article de la menuiserie ISTMenuiserie ! ➡️ C’est dans la partie Configuration Technique !
Pour y accéder, on vient sélectionner le vari-article et clic droit “ Actions”, “Maintenance Règle Nomenclature Générique”
![](../__attachments/115157916/image-20221213-145421.png?inst-v=2e0628d9-a170-4eb1-b774-b0d7a84fa1a1)
Puis, on ouvre les Informations Techniques du lien sur lequel on veut stocker les durées de chaque étape: ici, on veut rentrer le temps que passe le vantail sur chaque atelier, on va donc se placer sur le lien Vantail et clic droit , “ → Informations Techniques”:
![](../__attachments/115157916/image-20221213-145631.png?inst-v=2e0628d9-a170-4eb1-b774-b0d7a84fa1a1)
On va ensuite remplir les Informations Techniques selon la syntaxe qui est interprétée par les requêtes RGG de génération de la gamme.
![](../__attachments/115157916/image-20221213-150822.png?inst-v=2e0628d9-a170-4eb1-b774-b0d7a84fa1a1)
C'est quoi la syntaxe qui est interprétée par les requêtes de génération de la gamme générée ?
Dans le cas d’un DIAPASON START, c’est la requête RGG FabGamITs qui génère la gamme. Or dans cette requête, on vient chercher des Informations Techniques de cette forme pour générer la charge sur chaque étape de la gamme:
Une fois que la nomenclature de pointeur est générée (événement “DT”), on doit donc voir apparaitre dans les Informations Techniques de la menuiserie, sur le vantail:
![](../__attachments/115157916/image-20221213-153505.png?inst-v=2e0628d9-a170-4eb1-b774-b0d7a84fa1a1)
Dans la RGG, la valeur de l’unité de mesure de charge est à l’unité: si on passe 1h pour réaliser 1 vantail, et que sur la ligne de commande on a 3 fenêtres de 2 vantaux, on mets une valeur d’unité de mesure de charge de 2h. En effet la charge sur la gamme générée est pour une unité de la ligne de commande (soit ici pour une fenêtre de 2 vantaux).
Et comme on a 3 fenêtres, sur la ligne de commande, DIAPASON calculera automatiquement qu’il y a 6h !