Hallo. Ich hätte gerne die Möglichkeit, die USL gleich der LSL zu setzen. Ich verwende derzeit JMP Pro 17.2.0. Wenn ich versuche, die Grenzwerte im Fenster „Spalteneigenschaften“ gleich festzulegen, erhalte ich die Fehlermeldung „USL muss größer als LSL und das Ziel sein“. Ähnlicher Fehler, wenn ich es mit der Manage Limits-Plattform versuche.
Die Originaldiskussion finden Sie in diesem Thread:
https://community.jmp.com/t5/Discussions/Setting-Spec-Limits-with-USL-LSL/mp/717822#M89952
Was hat diese Wunschlistenanfrage inspiriert?
Wenn ich versuche, im Fenster „Spalteneigenschaften“ oder auf der Plattform „Grenzwerte verwalten“ einander gleiche Grenzwerte festzulegen, erhalte ich eine Fehlermeldung. Ich kann die Grenzwerte mithilfe der Nachricht „<< Set Property“ programmgesteuert auf Gleichheit festlegen, kann sie jedoch mit „Limits verwalten“ nicht zurücklesen. Dieses Skript hilft zur Veranschaulichung:
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;
Manchmal sehe ich auch ein kleines Popup-Fenster mit der Meldung „Inkonsistente Grenzwerte“, in dem alle fehlerhaften Spalten aufgelistet sind, aber ich habe noch nicht herausgefunden, wie ich das reproduzieren kann.
Welche Verbesserung würden Sie sich wünschen?
Ich möchte die Möglichkeit haben, in den Fenstern „Spalteneigenschaften“ und „Grenzwerte verwalten“ die gleichen Grenzwerte festzulegen. Ich möchte jedoch weiterhin USL < LSL verhindern.
Warum ist diese Idee wichtig?
Unsere Daten enthalten Tausende von Spalten. Einige (aber nicht alle) Spalten stellen Codes (Ganzzahlen) dar, wobei nur ein Wert „ok“ bedeutet und alle anderen auf eine andere Art von Fehler hinweisen. Beispielsweise gilt eine „1“ als bestanden, eine „0“ = nicht getestet und Werte von 2 oder höher weisen auf einen anderen Fehler hin. Wir möchten Erträge und andere Analysen dieser Daten mithilfe von Skripten berechnen. Wir stellen jedoch fest, dass diese Spalten mit USL=LSL nicht überprüft werden, da sie fehlen, wenn das Skript die Grenzwerte mithilfe von „Grenzwerte verwalten“ zurückliest.
Dinge, die wir berücksichtigt haben:
1. Setzen Sie die Grenzwerte auf (x-0,1, x+0,1) statt auf (x,x). Dies ist nicht möglich, da dies die Änderung von Hunderten von Grenzwerten multipliziert mit mehreren Herstellungsschritten multipliziert mit mehreren Programmen erfordern würde und sich auf viele andere Organisationen in unserem Unternehmen auswirken würde.
2. Legen Sie für diese Spalten nur die LSL fest und lassen Sie die USL weg. Fügen Sie dann in unserem Ertragsanalyseskript eine Klausel hinzu, die den Spaltennamen mit einer Liste von Spalten vergleicht, deren Werte „codiert“ sind. Bei Übereinstimmung prüfen Sie einfach, ob der Wert mit der LSL übereinstimmt, anstatt zu prüfen, ob der Wert zwischen LSL und LSL liegt. USL. Das ist problematisch, da wir dazu gezwungen wären, fest zu programmieren, welche Spalten innerhalb des Skripts auf die eine oder andere Weise überprüft werden müssen, und die Skripte ständig zu aktualisieren, wenn sich die Namensliste im Laufe der Entwicklung ändert. Außerdem müssten für jeden Herstellungsschritt und jedes Programm separate Listen geführt werden, da nicht dieselben Tests durchgeführt werden. Problematisch ist auch, dass andere andere Analyseskripte für die Daten verwenden, die möglicherweise nicht wissen, ob wir die USL gelöscht und nur die LSL beibehalten haben.
3. Legen Sie die Grenzwerte programmgesteuert wie im obigen Skript fest. Wenn wir sie dann zu einem späteren Zeitpunkt aus der Datentabelle zurücklesen möchten, verwenden Sie die Nachricht << Get Property anstelle der Manage Limits. Ich arbeite immer noch an einem Skript, um dies auszuprobieren, aber ich habe bereits Bedenken hinsichtlich dieser Taktik. Erstens wäre eine For-Schleife erforderlich, um die Spezifikationen jeder Spalte zu lesen und zu analysieren, was bei mehr als 10.000 Spalten eine Weile dauern kann. Zweitens habe ich Schwierigkeiten, die Grenzwerte aus der Nachricht << Get Property("Spec Limits") herauszufinden. (1) Es wird lediglich USL(1) (ohne Anführungszeichen) zurückgegeben und es ist mir unklar, wie ich die Zahl daraus extrahieren kann. (2) Es scheint, dass die LSL nicht zurückgegeben wird, obwohl ich im Fenster „Spalteneigenschaften“ bestätigt habe, dass sie ebenfalls auf 1 gesetzt ist. Das folgende Skript veranschaulicht:
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 .
Ich entschuldige mich im Voraus, falls es andere offensichtliche Lösungen gibt, an die ich nicht gedacht habe (oder die ich vergessen habe zu erwähnen). Ich entschuldige mich auch, wenn ich ein wichtiges Detail übersehen habe. Ich arbeite jetzt schon eine Weile daran, also stecke ich ziemlich tief in der Sache.
Vielen Dank für Ihre Überlegung.
@nikles, wir planen ein Update der Datentabelle in JMP v18.1, das LSL=USL ermöglichen würde. Beachten Sie jedoch, dass Spalten mit dieser Eigenschaftseinstellung in Fähigkeitsberichten nicht funktionieren würden.
Hallo @nikles, ich habe den entsprechenden Community-Diskussionsthread und diese Anfrage gelesen. Mir scheint, was Sie wirklich brauchen, ist eine Möglichkeit, eine „kategoriale Spezifikation“ zu definieren und zu speichern. Wenn der Test des Produkts beispielsweise einfach ein Pass/Fail-Ergebnis ergibt und „Pass“ die Spezifikation ist, möchten Sie dies als Spezifikation in einer Spalteneigenschaft speichern können. Ich konnte auch andere Arten von kategorialen Spezifikationen sehen, z. B. das Testergebnis ist „Ausgezeichnet“, „Gut“, „Schlecht“, „Nicht bestanden“ und „Ausgezeichnet“ oder „Gut“ ist die bestandene Spezifikation.
Derzeit sind USL und LSL für die Spalteneigenschaft „Spezifikationsgrenzen“ für kontinuierliche Antworten vorgesehen und daher für LSL>=LSL nicht sinnvoll. Die Plattform „Grenzwerte verwalten“ unter Analysieren > Qualität und Prozess dient der Verwaltung der in JMP-Analysen verwendeten Grenzwerte. Mir ist keine JMP-Plattform bekannt, die eine solche kategoriale Beschränkung verwendet.
Für Ihren unmittelbaren Bedarf können Sie eine benutzerdefinierte Spalteneigenschaft erstellen (wählen Sie unter „Spalteneigenschaften“ „Andere“), um die kategoriale Spezifikation zu speichern. Oder Sie können die Nachricht << Set Property( ) in JSL für die Datentabelle verwenden. Dann könnten Sie diese Eigenschaft in Ihren Skripten verwenden.
Wichtige Korrektur. Die zweiten Zeilen in beiden oben gezeigten Skripten sollten lauten:
dt:Height << Set Property("Spec Limits", {USL(1), LSL(1)}); //forgot to add {}Entschuldigung für das Versehen. Dies würde erklären, warum ich Schwierigkeiten hatte, die Nachrichten „<< Set Properties“ und „<< Get Properties“ zu verwenden. Ich sehe jetzt, dass ich die Grenzwerte mithilfe des Fensters „Grenzwerte verwalten“ *auslesen* kann. Allerdings erhalte ich immer noch das folgende Popup-Fenster, wenn „Limits verwalten“ geöffnet wird:
Wenn ich außerdem versuche, „In der Tabelle mit den Höchstgrenzen zu speichern“, erhalte ich die folgende Fehlermeldung:
Schließlich funktioniert diese Methode in meinem ursprünglichen Beitrag unter „Dinge, die wir in Betracht gezogen haben“, Punkt 3 (Limits aus der Datentabelle mit der Nachricht „<< Get Property“ anstelle der „Limits verwalten“-Nachricht zurücklesen) jetzt für mich. Ich würde immer noch lieber die Plattform „Limits verwalten“ zum Auslesen meiner Limits verwenden, da diese automatisch eine Tabelle erstellt, aber dies ist zumindest eine praktikable Lösung.
@SamGardner Danke für die Hilfe! Ich bin froh, dass sie beschlossen haben, LSL=USL zuzulassen. Ich hatte Ihre andere Lösung zum Definieren einer kategorialen Spezifikationseigenschaft nicht in Betracht gezogen, also vielen Dank auch dafür. Allerdings würde ich sagen, dass ein Problem mit dieser Lösung ähnlich wäre wie meine andere Lösung, bei der nur die LSL für diese Spalten definiert wird. Das heißt, meine Skripte müssten diese Spalten bei der Berechnung der Erträge unterschiedlich behandeln, was erfordert, dass meine Skripte wissen, für welche Spalten sie dies tun sollen. Wenn ich LSL=USL erlaube, kann ich alle Spalten gleich behandeln.
