Spezifikationsgrenzen für die Prozess-Screening-PlattformHallo zusammen,
Ich habe eine Frage zu Spezifikationsgrenzen bei Prozessscreening-Anwendungen. Ich habe beispielsweise eine Metrik für die Dicke eines Teils. Der Zielwert liegt bei 0,7 mit einer Untergrenze von 0,6 und einer Obergrenze von 0,8. Alles innerhalb dieser Grenzen gilt als bestanden. Wie aus der folgenden Grafik ersichtlich, werden jedoch Werte von 0,8 als nicht bestanden gewertet. Gleichzeitig gelten Werte von 0,6 als bestanden.
Gibt es eine Möglichkeit zu steuern, ob die Grenzwerte inklusiv oder exklusiv sind? Ist dies eine Einstellung auf der Registerkarte „Einstellungen“ oder kann dies von Fall zu Fall auf der Prozess-Screening-Plattform vorgenommen werden?
Ich verwende derzeit JMP 16, werde aber möglicherweise bald auf 18 umsteigen. Daher bin ich für alle Vorschläge für die einzelnen Versionen dankbar.
Grundlegende Datenanalyse und ModellierungQualitäts- und ProzesstechnikWindowsBetreff: Spezifikationsgrenzen für die Prozess-Screening-PlattformSind Sie sicher, dass die Werte genau 0,8 sind? In diesem einfachen Beispiel werden keine Werte als Fehlschläge gezählt (ich verwende allerdings JMP18, also hat sich das vielleicht geändert)
Betreff: Spezifikationsgrenzen für die Prozess-Screening-PlattformHallo @AdditiveRange10
Überprüfen Sie Ihre Daten auf eine verrückte kleine Dezimalstelle. Ich habe Datensätze mit seltsamen Importproblemen erhalten, die zu einer kleinen Dezimalstelle führten, die meine Fähigkeitsanalyse durcheinander brachte. Sie können Round(dt:col,2) versuchen, um es loszuwerden.
Betreff: Spezifikationsgrenzen für die Prozess-Screening-PlattformNein, die Werte wurden vorher definitiv gerundet, es gibt also keine kleinen Dezimalstellen.
Ich habe die Analyse mit der Prozess-Screening-Plattform in JMP 16 ausgeführt und es ist wie oben angegeben und die Werte, die 0,80000 betragen, werden als Fehler gezählt. In JMP 18 jedoch, wenn ich die Prozessfähigkeitsplattform verwende, bekomme ich dies. Wenn ich alle Punkte auswähle, die innerhalb von 0,6-0,8 liegen, erhalte ich 93/107 = 87 %, was der Erfolgsquote entspricht, wie in der Analyse gezeigt
Es bleibt jedoch die Frage, ob das Histogramm optisch irreführend aussieht, da der Bin [0,8-0,9) außerhalb der USL zu liegen scheint. Haben Sie Vorschläge, wie man das ändern kann? Ich weiß, dass das Hand-Tool nützlich sein könnte, aber es scheint keine gute Option zu sein, um eine Analyse für viele Metriken zu skripten.
Betreff: Spezifikationsgrenzen für die Prozess-Screening-PlattformMit dem Handwerkzeug können Sie den Bin Span ändern und Sie sollten in der Lage sein, ein Skript dafür zu erstellen, aber das erfordert möglicherweise etwas Einarbeitung.
Betreff: Spezifikationsgrenzen für die Prozess-Screening-PlattformHallo @AdditiveRange10
Vielleicht kannst du mit diesen beiden dorthin gelangen
Möglicherweise müssen Sie den XPath-Speicherort verwenden, um es dem richtigen Diagramm zuzuweisen.
Betreff: Spezifikationsgrenzen für die Prozess-Screening-PlattformEs ist nicht möglich, die Spezifikationen inklusive/exklusiv festzulegen. Ihre Messungen scheinen diskret zu sein, daher würde ich einen LSL etwas niedriger (z. B. 0,599) und einen USL etwas höher (z. B. 0,801) festlegen. Bei JMP 16 bin ich mir nicht sicher, aber in JMP 18 sehe ich, dass Messungen = Spezifikation in Spezifikation berücksichtigt werden, aber der Vergleich von Gleitkommawerten ist aufgrund der ungenauen Darstellung manchmal problematisch. Für Gleitkommawerte ist es immer besser, >- oder <-Vergleiche durchzuführen als ==.
Betreff: Spezifikationsgrenzen für die Prozess-Screening-PlattformHmm, ich habe gerade etwas anderes ausprobiert. Ich habe die Plattform für Prozessfähigkeit verwendet und 10 Datenpunkte mit denselben Spezifikationsgrenzen aufgezeichnet: LSL = 0,6, Ziel = 0,7 und USL = 0,8. Basierend auf den Daten gibt es 3 Punkte, die 0,9 oder 1 sind. Wenn ich die Spezifikationsgrenzen manuell eingebe, erhalte ich eine Nichtkonformitätsrate von 30 %, also 3/10.
Wenn ich jedoch die Importspezifikationsgrenzen mit einer Datentabelle verwende, erhalte ich eine Nichtübereinstimmungsrate von 60 %, also 6/10. Könnte dies an der Art der LSL-Spalteneigenschaften liegen oder? Es handelt sich um eine fortlaufende numerische Spalte mit dem Format „Beste“ und einer Breite von 12. Ich habe versucht, die Breite zu variieren und neu zu berechnen, aber es gab keinen Unterschied.
Der springende Punkt ist wiederum, dass ich LSL- und USL-Werte aus einer Tabelle verwende, da ich eine Analyse für viele Variablen durchführe und sie nicht einzeln eingeben kann.
Betreff: Spezifikationsgrenzen für die Prozess-Screening-PlattformJa, dies bestätigt, dass es sich um ein Präzisionsproblem beim Vergleich zweier Gleitkommawerte handelt. Dies lässt sich am besten mit der oben beschriebenen Methode vermeiden.
Betreff: Spezifikationsgrenzen für die Prozess-Screening-PlattformSie schlagen also vor, die Planformulare für Prozessfähigkeit oder Prozessscreening nicht zu verwenden? Die Spezifikationstabelle wird mithilfe eines Python-Skripts generiert, sodass ich dort etwas Spielraum bei der Formatierung habe? Schlagen Sie etwas Bestimmtes vor?
Betreff: Spezifikationsgrenzen für die Prozess-Screening-PlattformIch schlage vor, Ihre Spezifikationen mit Schutzbändern zu versehen, um die Ungenauigkeit beim Vergleich von Gleitkommawerten zu berücksichtigen. Ein Float64 (Gleitkommazahl mit doppelter Genauigkeit) kann reelle Zahlen mit einer Genauigkeit von ungefähr 15 bis 17 Dezimalstellen darstellen. Dies bedeutet, dass es zwar einen sehr breiten Zahlenbereich darstellen kann, aufgrund der Einschränkungen der binären Darstellung jedoch bei den letzten Dezimalstellen ein geringes Maß an Ungenauigkeit auftritt. Im Wesentlichen können die meisten reellen Zahlen mit einem Float64 nur angenähert und nicht exakt dargestellt werden.
Dies bedeutet, dass das Schutzband mindestens 1e-15 betragen muss.
Betreff: Spezifikationsgrenzen für die Prozess-Screening-PlattformIch bin zu meinem Python-Skript zurückgekehrt und habe alle Float-Werte für die Spezifikationsliste von Float64 in Float16 geändert. Unter Verwendung der Prozessbildschirmplattform und importierter Spezifikationsgrenzen aus der Spezifikationstabelle scheinen die Werte außerhalb der Spezifikation korrekt gezählt zu werden. Dies könnte die aktuelle Problemumgehung für dieses Problem sein.
