Starting with data in one table, and specification limits in another used to be a tough way to start a large scale capability analysis. While it maybe a right of passage in some industry segments to script a JSL program that loads specifications from one table into the column properties of a data containing table, there are some better options. The Capability Analysis platform in JMP 12 makes working with data and a separate spec table a quick and easy task. In this article I'm going to walk discuss how to take advantage of the JMP capability platform to work out the problem of adding data from a spec table to the column properties of a data table. Stepping through process manually only requires a few clicks (Example of the Process Capability Platform) but is the end goal is to script the platform to automate both the analysis and update a data table's column properties with specification limits. As it turns out, its remarkably easy with a fairly compact script.
The script attached below is largely pulled from the scripting index with a couple very helpful tips from JMP developer, Dr. Lancaster.
The script begins by getting the columns from the data table that are continuous numeric.
Next an empty argument is created. The variable "y" refers to an empty "process variables()" argument. Then that expression is filled with the column names held in "dty".
Expressions are used at several points because they aren't evaluated until the variable referring to the expression is referenced.
The next expression is for generating the capability report, and the now filled process variables argument is inserted into obj which completes the function. Where is "process variables (names)" inserted? It doesn't really matter, because everything within "Process Capability()" is just another argument.
There are two important arguments in Process capability() to note. First is "Spec Limits(Import...", that tells the platform which table contains the specification limits. The second, "Spec Limits Dialog( "no(skip..." this argument causes the same platform behavior as letting the platform skip columns that don't have specs rather than prompting the user to supply them. (or, "No, don't prompt, just skip the columns with missing specs.")
The last parts of the script provide a reference to the report to make a data table out of the Overall Sigma Summary Report, and to save the specifications to a new data table and the original data table's column properties.
I hope you find this explanation useful. I've also attached the slides I used at a recent JMP day.
Names Default To Here( 1 );
dt = Open( "$SAMPLE_DATA/Cities.jmp" );
dty = dt << GetColumnNames( numeric, continuous );
y = Expr( process variables() ); //this constructs the "process variables" argument that is inside the process capability function.
n = N Items( dty );
For( i = 1, i <= n, i++,
Insert Into( y, dty[i] ) // the column names, not name strings, are inserted and comma delimited
obj = Expr( // this is an expression so that it won't be evaluated and we can do things to it later
Spec Limits( Import Spec Limits( "$SAMPLE_DATA/CitySpecLimits.jmp" ) ),// file path and file name of the specs table
Spec Limits Dialog( "No (skip columns with no spec limits)" ),// Handy thing to know, Thank you Dr. Lancaster!!
Overall Sigma Summary Report( 1 )
Insert Into( obj, Name Expr( y ) ); // this is later and we insert "y" which is "process variables( column names )" show( name expr(y)) to see it
pr = obj << report; // pr becomes a handle for the report, and obj gets evaluated
dt2 = pr[Table Box( 2 )]<< Make Into Data Table;// this is where the the summary report is in the capability report
dt3=obj<<save spec limits to new table; // saves the specs that were used in the analysis to a separate table.*
obj << Save spec limits as column properties; // saves the spec limits used in the report to the data table.
* The specifications used in the report are also included in the summary report.