Salut. J'aimerais avoir la possibilité de définir l'USL égale à la LSL. J'utilise actuellement JMP Pro 17.2.0. Si j'essaie de définir les limites égales les unes aux autres dans la fenêtre Propriétés de la colonne, j'obtiens une erreur "USL doit être supérieur à LSL et à la cible". Erreur similaire si je l'essaye en utilisant la plateforme Manage Limits.
Veuillez consulter ce fil pour une discussion originale :
https://community.jmp.com/t5/Discussions/Setting-Spec-Limits-with-USL-LSL/mp/717822#M89952
Qu'est-ce qui a inspiré cette demande de liste de souhaits ?
Si j'essaie de définir des limites égales les unes aux autres dans la fenêtre Propriétés des colonnes ou sur la plateforme Gérer les limites, j'obtiens une erreur. Je peux définir par programme les limites pour qu'elles soient égales à l'aide du message << Définir la propriété, mais je ne peux pas les relire à l'aide de Gérer les limites. Ce script permet d'illustrer :
Names Default to Here(1);<BR />dt = Open("$SAMPLE_DATA/Big Class.jmp");
dt:Height << Set Property("Spec Limits", USL(1), LSL(1)); //I can set USL=LSL in a script<BR />//I can confirm they've been set by manually opening the Column Properties window.
//At some later date I need to reopen the table and get the limits to evaluate yield:
msl = dt << Manage Limits(Process Variables(:Height)); //The limits are now missing.
dtlim = msl << Save to Tall Limits Table;
Parfois, je vois aussi une petite fenêtre contextuelle disant quelque chose du genre "Limites incohérentes" avec toutes les colonnes incriminées répertoriées, mais je n'ai pas encore compris comment reproduire cela.
Quelle est l’amélioration que vous souhaiteriez voir ?
J'aimerais pouvoir définir des limites égales les unes aux autres dans les fenêtres Propriétés de colonne et Gérer les limites. Je veux cependant continuer à empêcher USL
Pourquoi cette idée est-elle importante ?
Nos données contiennent des milliers de colonnes. Certaines colonnes (mais pas toutes) représentent des codes (entiers), où une seule valeur signifie « ok » et toutes les autres indiquent un type d'échec différent. Par exemple, un « 1 » est réussi, un « 0 » = n'a pas testé et les valeurs 2 ou plus indiquent une autre erreur. Nous souhaitons calculer les rendements et autres analyses sur ces données à l'aide de scripts. Mais nous constatons que ces colonnes où USL=LSL ne sont pas vérifiées car lorsque le script relit les limites à l'aide de Gérer les limites, elles sont manquantes.
Choses que nous avons prises en compte :
1. Définissez les limites sur (x-0,1, x+0,1) au lieu de (x,x). Impossible car cela nécessiterait de modifier des centaines de limites multipliées par plusieurs étapes de fabrication multipliées par plusieurs programmes, et affecterait de nombreuses autres organisations de notre entreprise.
2. Définissez uniquement le LSL pour ces colonnes, en laissant l'USL manquant. Ensuite, dans notre script d'analyse de rendement, ajoutez une clause qui vérifie le nom de la colonne par rapport à une liste de colonnes dont les valeurs sont "codées", et si elles correspondent, vérifiez simplement si la valeur correspond à la LSL au lieu de vérifier si la valeur se situe entre LSL et USL. Problématique car cela nous obligerait à coder en dur quelles colonnes doivent être vérifiées d'une manière ou d'une autre dans le script, en mettant constamment à jour les scripts à mesure que la liste des noms change tout au long du développement. De plus, il faudrait tenir des listes distinctes pour chaque étape de fabrication et chaque programme, car ils ne partagent pas les mêmes tests. Cela pose également problème car d'autres utilisent différents scripts d'analyse sur les données, qui peuvent ne pas savoir si nous avons supprimé l'USL et conservé uniquement le LSL.
3. Définissez les limites par programme comme dans le script ci-dessus. Ensuite, lorsque nous souhaitons les relire ultérieurement à partir de la table de données, utilisez le message << Get Property au lieu du message Manage Limits. Je travaille toujours sur un script pour essayer cela, mais j'ai déjà des doutes quant à ce tact. Premièrement, il faudrait une boucle For pour lire et analyser les spécifications de chaque colonne, ce qui peut prendre un certain temps pour plus de 10 000 colonnes. Deuxièmement, j'ai du mal à analyser les limites du message << Get Property("Spec Limits"). (1) Il renvoie simplement USL(1) (sans guillemets) et je ne sais pas comment en extraire le numéro. (2) il ne semble pas renvoyer le LSL, même si j'ai confirmé dans la fenêtre Propriétés de la colonne qu'il était également défini sur 1. Le script ci-dessous illustre :
Names Default to Here(1);<BR />dt = Open("$SAMPLE_DATA/Big Class.jmp");
dt:Height << Set Property("Spec Limits", USL(1), LSL(1)); //confirm limits set in col props window.<BR />specs = dt:Height << Get Property( "Spec Limits" ); //returns USL(1) only
lsl = specs["LSL"]; //returns .
usl = specs["USL"]; //returns .
Toutes mes excuses par avance s'il existe d'autres solutions évidentes auxquelles je n'ai pas pensé (ou oublié de mentionner). Je m'excuse également si j'ai passé sous silence certains détails cruciaux. Je travaille là-dessus depuis un moment maintenant, donc je suis assez plongé dans les mauvaises herbes.
Merci d'avoir réfléchi.
@nikles, nous prévoyons de mettre à jour la table de données dans JMP v18.1 qui permettrait LSL=USL. Notez toutefois que les colonnes dotées de ce paramètre de propriété ne fonctionneront pas dans les rapports de fonctionnalités.
Salut @nikles, j'ai lu le fil de discussion de la communauté associé et cette demande. Il me semble que ce dont vous avez vraiment besoin, c'est d'un moyen de définir et de stocker une "spécification catégorielle". Par exemple, si le test du produit produit simplement un résultat Réussite/Échec et que « Réussite » est la spécification, vous souhaitez pouvoir la stocker en tant que spécification dans une propriété de colonne. J'ai également pu voir d'autres types de spécifications catégorielles, telles que le résultat du test est Excellent, Bon, Mauvais, Échec, et « Excellent » ou « Bon » est la spécification de réussite.
Actuellement, les valeurs USL et LSL de la propriété de colonne Limites de spécification sont destinées aux réponses continues et, de ce fait, cela n'a pas de sens pour LSL>=LSL. La plateforme Gérer les limites sous Analyse > Qualité et processus est destinée à gérer les limites utilisées dans les analyses JMP. Je ne connais aucune plate-forme JMP qui utilise une limite catégorielle comme celle-ci.
Pour votre besoin immédiat, vous pouvez créer une propriété de colonne personnalisée (choisissez « Autre » sous les propriétés de la colonne) pour stocker la spécification catégorielle. Ou vous pouvez utiliser le message << Set Property() en JSL sur la table de données. Vous pourrez ensuite utiliser cette propriété dans vos scripts.
Correction importante. Les deuxièmes lignes des deux scripts présentés ci-dessus doivent être :
dt:Height << Set Property("Spec Limits", {USL(1), LSL(1)}); //forgot to add {}Toutes mes excuses pour l'oubli. Cela expliquerait pourquoi j'avais des difficultés à utiliser les messages << Définir les propriétés et << Obtenir les propriétés ». Je vois maintenant que je *peut* relire les limites à l'aide de la fenêtre Gérer les limites. Cependant, j'obtiens toujours la fenêtre contextuelle suivante lorsque Gérer les limites est ouvert :
De plus, si j'essaie de "Enregistrer dans le tableau des limites élevées", j'obtiens cette erreur :
Enfin, dans mon message d'origine sous " Choses que nous avons prises en compte ", point 3 ( lire les limites de la table de données en utilisant le message << Obtenir la propriété au lieu de Gérer les limites), cette méthode fonctionne maintenant pour moi. Je préférerais toujours utiliser la plate-forme Gérer les limites pour lire mes limites, car elle crée automatiquement un tableau, mais il s'agit au moins d'une solution de contournement viable.
@SamGardner Merci pour l'aide ! Je suis heureux qu'ils aient décidé d'autoriser LSL=USL. Je n'avais pas envisagé votre autre solution concernant la définition d'une propriété de spécification catégorielle, alors merci également pour cela. Cependant, je dirais qu'un problème avec cette solution serait similaire à mon autre solution consistant à définir uniquement le LSL pour ces colonnes. Autrement dit, j'aurais besoin que mes scripts traitent ces colonnes différemment lors du calcul des rendements, ce qui nécessite que mes scripts sachent pour quelles colonnes faire cela. Autoriser LSL=USL me permet de traiter toutes les colonnes de la même manière.
