Script JMP requis - Matrice GRRSalut à tous. C'est la première fois que je poste ici, alors n'hésitez pas à envoyer des pointeurs sur le protocole du forum et autres.
Je fais beaucoup d'études de jauge pour le travail et je recherche un script (ou une aide pour en construire un) qui exécutera automatiquement toutes les combinaisons d'opérateurs (ou d'outils dans mon cas). J'essaie de contourner le fait d'avoir à inclure/exclure des outils, à définir une tolérance (que je n'utilise pas), etc. pour chaque exécution GRR à 2 outils. Donc, si j'avais 5 outils, le script exécuterait les 10 combinaisons d'outils et cracherait 10 ensembles de nombres GRR.
J'apprécie toute aide que vous pouvez apporter. Je ne suis pas un codeur mais je peux apprendre et définitivement appliquer un code fini à JMP s'il est fourni. Merci!
Ingénierie Qualité et ProcédésRe: Script JMP nécessaire - Matrice GRRVotre deuxième cas d'utilisation semble juste. Le point crucial pourrait être de créer un modèle capable de gérer une taille de flotte variable avec différents noms et recettes exécutant un nombre différent de sites par tranche. C'est pourtant la bonne piste.Re: Script JMP nécessaire - Matrice GRRMerci. Oui, cela aide. Ne serait-ce que pour mieux comprendre comment poser les questions et les limites du programme.
Je pense que je pourrai peut-être développer un peu plus les détails. J'essaie d'utiliser un jargon général tel que « opérateur » et « partie ». Les opérateurs que j'essaie de comparer sont les outils ou appareils de mesure. Les pièces sont différents sites de mesure sur une plaquette de silicium. La configuration ressemble donc à ceci :
...Je suppose que je ne peux pas coller une photo ici.
J'ai 4 colonnes :
ID de l'outil
ID du site
Mesure_X
Mesure_Y
O, Réponse :
Mesure_X
Mesure_Y
X, Regroupement :
ID de l'outil
ID du site
Cela doit être un outil puis un site, sinon cela ne fonctionne pas.
Type de graphique : Variabilité
Type de modèle: croisé
Je ne veux pas changer de méthode ; il est établi et fonctionne assez bien pour les pouvoirs en place. J'ai juste besoin que le programme fasse toutes les combinaisons de 2 outils en une seule fois. À l'heure actuelle, j'utilise la fonction Exclure, j'exécute un GRR à 2 outils, je reviens en arrière et sélectionne la combinaison d'outils suivante, j'exécute un GRR à 2 outils, et ainsi de suite jusqu'à ce que tout soit terminé. Ainsi, la partie technique consistant à faire en sorte que le programme exécute toutes les paires sans intervention semble assez simple.
Re: Script JMP nécessaire - Matrice GRR@Metro-Sam Merci pour l'information supplémentaire. Pour ma propre édification, « l'outil » est alors l'appareil de mesure ? Et vous cherchez à comparer les « outils » les uns aux autres pour diverses caractéristiques du GRR telles que la répétabilité, la reproductibilité, la discrimination et autres ? Vous dites que vous avez des pièces qui sont mesurées à plusieurs reprises... et que les interactions sont importantes. Interactions entre quels facteurs ? Vous ne faites aucune mention des opérateurs ? J’ai toujours trouvé utile de dresser un diagramme arborescent de l’expérience réelle. Donc, à des fins purement illustratives, « Outils » serait en haut de l'arborescence, avec peut-être les opérateurs un niveau en dessous, les pièces un niveau en dessous des opérateurs, les mesures répétées étant le niveau le plus bas ? Il faudrait alors réfléchir à l'imbrication et au croisement qui pourraient se produire... qui doivent se produire à un moment donné pour évaluer les interactions que vous recherchez. Mais l’articulation de ces interactions spécifiques déterminera le croisement requis de facteurs. Comme @statman et je dis qu'il y a beaucoup de choses à considérer.
Fondamentalement, ce que je décris ci-dessus est facile à générer dans JMP ainsi que l'analyse permettant de comparer les différents outils. Je suggère une approche graphique telle que décrite dans l'approche Wheeler EMP.
Et il semble que vous soyez un peu novice en JSL ? JSL a tendance à être utilisé par la plupart pour l'un des deux scénarios suivants :
1. JMP ne peut pas faire quelque chose de manière native et prête à l'emploi... donc avec suffisamment de compétences en codage, les gens créent souvent des solutions JSL pour ce scénario. En fait, de nombreux compléments JMP de la bibliothèque d'échange de fichiers de la communauté d'utilisateurs ont commencé de cette façon... et le créateur du complément a choisi de partager sa solution avec la communauté d'utilisateurs. Ce n'est pas vraiment votre candidature. D'après ce que j'ai vu et interprété à partir de vos commentaires jusqu'à présent... Je ne pense pas que vous ayez besoin d'une fonctionnalité d'analyse ou de flux de travail que JMP ne peut pas gérer de manière native.
2. Un utilisateur a un problème et le flux de travail JMP associé est répété encore et encore. Et plutôt que de lancer ce flux de travail à partir de zéro à chaque itération, ils écrivent un script JMP qui est conservé pour une utilisation répétée. Ensuite, en un seul clic de souris, l'utilisateur exécute le script et ce flux de travail est exécuté. Cela ressemble à votre cas d'utilisation ? La façon dont de nombreux utilisateurs de JMP créent le script consiste à créer l'intégralité de leur flux de travail dans ce que j'appellerai un scénario de test. Le scénario de test contient tous les clics de souris et sélections de menu que l'utilisateur exécuterait. Chaque fois que vous faites quelque chose dans JMP, en arrière-plan, JMP écrit le code JSL correspondant aux étapes du flux. Ensuite, lorsque vous avez terminé, enregistrez simplement le script pour une utilisation ultérieure. Bien sûr, vous pouvez modifier le script selon vos besoins. Cette technique peut vous rapprocher de l'intégralité du script final dont vous avez besoin... il vous suffit ensuite de remplir les blancs ou de supprimer les étapes inutiles. Cette approche peut vous faire gagner beaucoup de temps et d'efforts de codage, car JMP écrira le code correct pour vous... et vous n'aurez pas besoin de rechercher des éléments tels que des parenthèses incompatibles ou de vous demander quel est réellement le code JSL spécifique pour une action spécifique. En fin de compte, vous souhaiterez peut-être convertir le script en complément JMP, qui deviendra alors une partie spécifique de votre application de déploiement JMP personnelle.
J'espère que ça aide?
Re: Script JMP nécessaire - Matrice GRRUn peu plus d'informations sur les données :
Je mesure habituellement l'ensemble des "pièces" 3 fois
Chaque pièce (300 à 800) peut avoir une valeur différente
Donc pour une pièce donnée nous aurions 6 mesures par jeu (10 jeux pour l'exemple de 5 outils ci-dessus)
Les interactions sont importantes pour cette application car chaque ensemble de pièces est lié (mais non dépendant)
C'est en fait assez difficile à décrire sans vous dire exactement ce que je fais. Je dois garder cela assez général pour les problèmes de propriété intellectuelle.Re: Script JMP nécessaire - Matrice GRRC'est probablement dans la façon dont je le décris. Je fais cela si souvent que j'oublie tous les détails importants que vous devez traiter pour avoir une vue d'ensemble 
Donc si j'avais 5 outils, ce serait la Matrice :
Outil_1 à Outil_2
Outil_1 à Outil_3
Outil_1 à Outil_4
Outil_1 à Outil_5
Outil_2 à Outil_3
Outil_2 à Outil_4
Outil_2 à Outil_5
Outil_3 à Outil_4
Outil_3 à Outil_4
Outil_4 à Outil_5
Si je peux demander à JMP de faire tout cela en même temps sans exclure manuellement les autres outils pour chaque exécution, ce serait un script réussi.
Re: Script JMP nécessaire - Matrice GRRMerci! On dirait que je dois me familiariser avec JSL.
Habituellement, le type et le paramètre de modèle restent les mêmes pour une matrice GRR donnée ; ma seule contribution est de choisir les outils. Cela semble donc assez faisable.
Ce que je fais, c'est obtenir une population de numéros correspondants dans l'ensemble du parc d'outils pour déterminer où devraient se trouver les nouveaux outils. En fonction de la partie que je mesure, les outils auront des distributions différentes quant à leur correspondance. La métrologie dans ma région est assez unique.
Re: Script JMP nécessaire - Matrice GRR@Metro-Sam , Bienvenue dans la communauté. Pete soulève quelques bons points. Voici mes pensées, je m'excuse si je suis un peu en deuxième année :
1. Je ne comprends pas ce que vous voulez dire lorsque vous dites que vous avez 5 outils et 10 combinaisons d'outils ?
2. Lisez Wheeler & Lyday « Évaluer le processus de mesure »
3. En accord avec Pete, je pense qu’il s’agit souvent de situations uniques. L’évaluation des systèmes de mesure n’est pas une aventure ponctuelle. Lorsque vous évaluez des systèmes de mesure, à quelles questions essayez-vous de répondre ? Le système de mesure peut-il différencier de manière adéquate ce qu’il est censé mesurer (l’échantillon) ? A-t-il une résolution suffisamment efficace (discrimination) ? Est-ce stable/cohérent ? Dans quelle mesure la variation est-elle due à l'équipement (généralement appelée répétabilité de précision) ? Dans quelle mesure est-ce dû à l'interface utilisateur (généralement appelée reproductibilité de précision) ? Dans quelle mesure la variation de l’étude est-elle attribuable à la composante de mesure ? Il est possible de répondre à ces questions, mais elles dépendent fortement de ce que vous mesurez et de l'espace d'inférence dicté par la manière dont les « échantillons » ont été obtenus.
4. Les évaluations du système de mesure peuvent être supérieures à celles du Gage R&R. Consultez le livre blanc JMP :
https://www.jmp.com/en_us/whitepapers/jmp/emp-management-systems-analysis.html
Re: Script JMP nécessaire - Matrice GRREn général, JSL est utile dans le cas où vous avez un flux de travail répétitif et que vous souhaitez ne pas avoir à répéter manuellement la même séquence de clics de souris et de sélections d'options pour chaque itération du flux de travail. Alors, si tel est votre cas, pourquoi ne pas simplement laisser JMP faire le gros du travail de composition des scripts à votre place ? Configurez un flux de travail d'expérimentation et d'analyse et suivez vos étapes... JMP enregistrera les étapes dans un script, et vous pourrez ensuite simplement enregistrer le script pour les itérations futures. Le seul problème est que vous devrez saisir vos valeurs de réponse à chaque fois.
Mais avez-vous vraiment un flux de travail complètement répétitif, tant pour la conception que pour l’analyse ? Mon expérience avec les études GRR est qu'il existe toutes sortes de problèmes comme l'imbrication, le croisement, le croisement/imbrication, le nombre de niveaux pour chaque facteur, etc. qui varient d'une étude à l'autre. Configurer du code JSL pour gérer cette multitude de problèmes serait possible, mais les concepteurs de JMP ne l'ont-ils pas déjà fait pour configurer les menus, les options, etc. Ensuite, du côté de l'analyse... je ne peux pas imaginer votre flux de travail d'analyse est également identique à chaque fois ? Peut etre c'est? Mais mon expérience n’a pas été la même. Il y avait souvent des choses que je trouvais intéressantes ou que je devais examiner... des valeurs aberrantes, des observations intéressantes, des observations manquantes, donc je m'écartais de l'analyse standard dans mon flux de travail... c'est l'une des caractéristiques élégantes de JMP... vous pouvez parcourir votre analyse de manière séquentielle en explorant tout au long du processus.
