プロセス変数ドリフトまたはクリープ検出やあ、
設定された期間にわたってプロセス変数の大規模なセットのドリフト/クリープ/勾配を検出するためにJMPで利用できる方法はありますか? 次に、ユーザーは、勾配が高すぎるか低すぎると見なし、フラグを立てる必要があるしきい値を設定します。
現在、プロセス スクリーニング ツールには、アップシフト、ダウンシフト、および絶対シフトの平均値を表示する、有効にできるドリフト サマリー オプションがあることを認識しています。 この場合、全体的なドリフト (正か負かに関係なく) を探していますが、(私が見たものからの) 絶対シフトは [Abs(Upshift) + Abs(Downshift)] として計算されます。 これは、全体的に上昇したか下降したかを教えてくれません。 技術的には、Abs(Upshift + Downshift [負の値]) を探しています。
私の現在の回避策は、プロセスのスクリーニング結果をデータ表に変換する画面を作成し、計算をやり直すことです。 ただし、これは、計算された値が、クイック グラフ/クイック管理図などの便利な機能を多数備えた処理スクリーニング プラットフォームから切り離されていることを意味します。また、ローカル データ フィルターではうまく機能しません。
他の誰かが私がこれにどのようにアプローチできるかについて何かアイデアを持っていれば、本当に感謝しています. ありがとう！分析Re: プロセス変数ドリフトまたはクリープ検出追加された列のソート順に関する問題については、この問題は、2022 年秋に利用可能になる JMP の次のメジャー リリースで対処されることを確認できます。 受け入れられた解決策は、今のところ良い回避策です。
Re: プロセス変数ドリフトまたはクリープ検出JMP サポートに、まだ根本的な問題が解決されていないことを確認しましたが、私の知る限り、受け入れられた解決策で回避策を講じれば問題は解決します。
Re: プロセス変数ドリフトまたはクリープ検出やあ、
この投稿を読んでいるときに、追加された列 (Combined Drift) の順序に対処する解決策が見つかったかどうか疑問に思っていましたか?
ありがとうございました。
Re: プロセス変数ドリフトまたはクリープ検出テーブルから読み取った値にテーブルの並べ替えが適用され、テーブルに書き込まれた値には適用されない理由を解明するために、私はまだ JMP サポートと協力しています。今のところ、大まかな回避策は次のとおりです。
names default to here(1);
dt = Open("$Sample_Data/iris.jmp");
//Open Process Screening with drift summaries
ps = dt << Process Screening(
Y( :Sepal length, :Sepal width, :Petal length, :Petal width ),
Control Chart Type( "Indiv and MR" ),
Drift Summaries( 1 )
);
//Add a dummy column and use set values to reset the table order
ncb = (ps << XPath( "//TableBox" )) << Append( newCol = NumberColBox("Delete Me", {}));
newCol << Set Values({});
newCol << Delete Box;
//calculate the combined drift
UpDrift = (ps << XPath( "//NumberColBox[NumberColBoxHeader[text()='Mean Up Drift']]" ))[1] << Get;
DownDrift = (ps << XPath( "//NumberColBox[NumberColBoxHeader[text()='Mean Down Drift']]" ))[1] << Get;
CombinedDrift = Abs( Matrix(UpDrift) + Matrix(DownDrift) );
ncb = (ps << XPath( "//TableBox" )) << Append( newCol = NumberColBox("Combined Drift", CombinedDrift));Re: プロセス変数ドリフトまたはクリープ検出おっしゃる通りです。以前に間違った注文を見つけられなかったことをお詫び申し上げます。私はこの方法を数回使用しましたが、まだその問題に遭遇していません (私は戻って、自分のスクリプトをいくつか再確認しました)。何らかの理由で、テーブルからデータを引き出すと、テーブルのソート順を使用しているように見えますが、データを書き込むと、行は別の順序で戻ります。私はそれを解決するために働きます。
Re: プロセス変数ドリフトまたはクリープ検出やあ、
不一致に関しては、例としてスクリーンショットを取り上げます。結合されたドリフト列の値を見ると、平均上昇ドリフトと平均下降ドリフトを合計すると、値が一致しないことがわかります。 2 つのマトリックス間で計算が正しく行われていると思いますが、値が追加されると、元のプロセス スクリーニング テーブルの列パラメーターの順序がずれている可能性があります。
これがそれを明確にすることを願っています。Re: プロセス変数ドリフトまたはクリープ検出計算値が一致しないという意味がわかりません。不一致の例を挙げていただけますか？
2 番目の段落の回避策に同意します。データ フィルターからの更新後に再計算するのが最も簡単な方法かもしれません。
Re: プロセス変数ドリフトまたはクリープ検出やあ！
このたびはご連絡いただきありがとうございます。 これでほぼ完全な解決策だと思いますが、元のプロセス スクリーニング テーブル ボックスに追加する計算値が、適切なパラメーター/列と実際には一致していないようです。 このスクリプトで生成されたマトリックスに列名を追加して、値を追加するときに一致させる方法があるかどうか疑問に思っています。
また、コラムを恒久的にすることは可能かどうか疑問に思っています. ローカル データ フィルターを適用して再計算を行うと、列が消えます。 おそらく簡単な回避策は、データ テーブルでデータ フィルターを実行し、このスクリプトを再実行することです。Re: プロセス変数ドリフトまたはクリープ検出Process Screening テーブルに列を追加できます。
names default to here(1);
dt = Open("$Sample_Data/iris.jmp");
//Open Process Screening with drift summaries
ps = dt << Process Screening(
Y( :Sepal length, :Sepal width, :Petal length, :Petal width ),
Control Chart Type( "Indiv and MR" ),
Drift Summaries( 1 )
);
//calculate the combined drift
UpDrift = (ps << XPath( "//NumberColBox[NumberColBoxHeader[text()='Mean Up Drift']]" ))[1] << Get;
DownDrift = (ps << XPath( "//NumberColBox[NumberColBoxHeader[text()='Mean Down Drift']]" ))[1] << Get;
CombinedDrift = Abs( Matrix(UpDrift) + Matrix(DownDrift) );
//Add column to table with Combined Drift
ncb = (ps << XPath( "//TableBox" )) << Append( NumberColBox("Combined Drift", CombinedDrift) );右側に新しい「Combined Drift」列が表示されます。
