Allow spec limit settings to be equal (USL = LSL)

[nikles]

Hi.  I would like to have the ability to set the USL equal to the LSL.  I'm currently using JMP Pro 17.2.0.  If I try to set the limits equal to each other in the Column Properties window, I get an error "USL must be greater than LSL and the target".  Similar error if I try it using the Manage Limits platform.

Please see this thread for original discussion:

https://community.jmp.com/t5/Discussions/Setting-Spec-Limits-with-USL-LSL/m-p/717822#M89952 

What inspired this wish list request? 

If I try to set limits equal to each other in the Column Properties window or Manage Limits platform, I get an error.  I can programmatically set the limits to be equal using the << Set Property message, but I cannot read them back using Manage Limits.  This script helps to illustrate:

Names Default to Here(1);
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
//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;						

Sometimes I also see a small window popup saying something to the effect of "Inconsistent Limits" with all the offending columns listed, but I haven't figured out yet how to reproduce this.  

What is the improvement you would like to see? 

I would like the ability to set limits equal to each other in the Column Properties and Manage Limits windows.  I want to continue preventing USL < LSL though.

Why is this idea important? 

Our data contains 1000s of columns.  Some (but not all) columns represent codes (integers), where only one value means "ok" and all others indicate a different type of failure.  For example, a "1" is passing, a "0" = did not test, and values 2 or greater indicate some other error.  We wish to compute yields and other analyses on these data using scripts.  But we're finding that these columns where USL=LSL are not getting checked because when the script reads back the limits using Manage Limits, they're missing.  

Things we've considered: 

1. Set the limits to (x-0.1, x+0.1) instead of (x,x).  Cannot do bc that would require modifying hundreds of limits multiplied by several manufacturing steps multiplied by several programs, and would affect many other orgs in our company.

2. Set just the LSL for these columns, leaving the USL missing.  Then, in our yield analysis script, add a clause that checks the column name against a list of columns whose values are "coded", and if matching, just check if the value matches the LSL instead of checking if the value lies between LSL-USL.  Problematic bc it would require us to hardcode which columns need to be checked one way vs another within the script, constantly updating scripts as the list of names changes throughout development.  Plus, there would have to be separate lists maintained for each manufacturing step and each program, as they don't share the same tests.  Also problematic bc others are using different analysis scripts on the data, that may not be aware if we have deleted the USL and kept only the LSL.

3. Set the limits programmatically as in the script above.  Then when we wish to read them back from the data table at a later date, use the << Get Property message instead of the Manage Limits.  I'm still working on a script to try this, but I already have misgivings about this tact.  First, it would need a For loop to read and parse each column's specs, which might take awhile for 10k+ columns.  Second, I'm having difficulty parsing out the limits from the << Get Property("Spec Limits") message.  (1) It just returns USL(1) (no quotes) and it's unclear to me how to extract the number from this.  (2) it does not seem to return the LSL, even though I confirmed in the Column Properties window that it was also set to 1.  The script below illustrates:

Names Default to Here(1);
dt = Open("$SAMPLE_DATA/Big Class.jmp");
dt:Height << Set Property("Spec Limits", USL(1), LSL(1));  //confirm limits set in col props window.
specs = dt:Height << Get Property( "Spec Limits" );        //returns USL(1) only
lsl = specs["LSL"];    //returns .
usl = specs["USL"];    //returns .

Apologies in advance if there are other obvious solutions I haven't thought of (or forgot to mention).  Also apologies if I've glossed over some crucial detail.  I've been working on this for awhile now, so I'm pretty deep in the weeds.  

Thanks for considering.

[nikles]

Important correction.  The second lines in both of the scripts shown above should be:

dt:Height << Set Property("Spec Limits", {USL(1), LSL(1)});  //forgot to add {}

Apologies for the oversight.  This would explain why I was having difficulty using the << Set Properties and << Get Properties messages.  I now see that I *can* read the limits back using the Manage Limits window.  However, I do still get the following pop-up when Manage Limits is opened:

Moreover, if I try to "Save to Tall Limits Table", I get this error:

Lastly, in my original post under "Things we've considered", item 3 (Read limits back from the data table using the << Get Property message instead of the Manage Limits), this method now works for me.  I'd still prefer to use the Manage Limits platform to read my limits instead since it automatically creates a table, but this is a viable workaround at least.

[SamGardner]

Hi @nikles I read the related community discussion thread and this request.  It seems to me what you really need is a way to define and store a "categorical specification".  For example, if the test of the product simply produces a Pass/Fail result, and "Pass" is the specification, you want to be able to store that as the specification in a column property.  I could see also other types of categorical specifications, such as the test result is Excellent, Good, Poor, Fail, and "Excellent" or "Good" is the passing specification.  

Currently the USL and LSL for the Specification Limits column property is intended to be for continuous responses and because of that it doesn't make sense for LSL>=LSL.   The Manage Limits platform under Analyze > Quality and Process is intended to manage limits used in JMP analyses.  I'm not aware of any JMP platforms that utilize a categorical limit like this.  

For your immediate need, you could create a custom column property (Choose "Other" under column properties) to store the categorical specification.  Or you could use << Set Property( ) message in JSL on the data table.    Then you could utilize that property in your scripts.

[SamGardner]

@nikles we are planning on making an update to the data table in JMP v18.1 that would allow LSL=USL.  Note however that columns that have that property setting would not work in capability reports.  

[nikles]

@SamGardner Thanks for the help!  I'm glad they decided to allow LSL=USL.  I'd not considered your other solution about defining a categorical specification property, so thanks as well for that.  However, I would say that a problem with that solution would be similar to my other solution of only defining the LSL for these columns.  That is, I would need my scripts to treat those columns differently when computing yields, which requires my scripts knowing which columns to do this for.  Allowing LSL=USL lets me treat all columns the same.