nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JMP Script Needed - GRR Matrix

Metro-Sam

Hey all. This is my first time posting in here so feel free to send pointers on forum protocol and such.

I do a lot of gauge studies for work and am looking for a script (or help to build one) that will automatically run all combinations of operators (or tools in my case). I'm trying to get around having to include/exclude tools, set tolerance (which I don't use), etc. for every 2-tool GRR run. So if I had 5 tools, the script would run all 10 tool combinations and spit out 10 sets of GRR numbers.

I appreciate any help you can give. I'm not a coder but can learn and definitely apply a finished code to JMP if provided. Thanks!

Accepted answers

All comments

P_Bartell

In general JSL is useful for the scenario when you have a workflow which is repetitive and you'd like to not have to repeat the same sequence of mouse clicks and option selections by hand for each iteration of the workflow. So if that is your case, why not just let JMP do the heavy lifting of script composition for you? Set up an experiment and analysis workflow and go through your steps...JMP will record the steps in a script, and then you can just save the script for future iterations. The only issue is you'll have to enter your response values each time.

But do you really have a completely repetitive workflow for both design and analysis? My experience with GRR studies is there are all sorts of issues like nesting, crossing, crossing/nesting, number of levels for each factor, etc. that vary from one study to the next. Setting up JSL code to handle this multitude of issues would be possible, but didn't the JMP designers kind of do this already wrt to setting up the menus, options, etc. Then on the analysis side...I can't imagine your analysis workflow is identical each and every time as well? Maybe it is? But my experience was not like that. There was often times things I found interesting or needed to look at...outliers, interesting observations, missing observations, so I would deviate from the standard analysis in my workflow...that's one of the elegant characteristics of JMP...you can move through your analysis in a sequential fashion exploring along the way.

statman

@Metro-Sam , Welcome to the community. Pete raises some good points. Here are my thoughts, I apologize if I am a bit sophomoric:

1. I don't understand what you mean when you say you have 5 tools and 10 tool combinations?

2. Read Wheeler & Lyday "Evaluating the Measurement Process"

3. In agreement with Pete, I believe these often are unique situations. Evaluating measurement systems is not a one-shot adventure. When evaluating measurement systems what questions are you trying to answer? Can the measurement system adequately differentiate that which it is intended to measure (the sample)? Does it have enough effective resolution (discrimination)? Is it stable/consistent? How much variation is due to equipment (typically called precision repeatability)? How much is due to the user interface (typically called precision reproducibility)? How much of the variation in the study is assignable to the measurement component? These questions can be answered, but are very dependent on what you are measuring and the inference space dictated by how the "samples" were gotten.

4. Measurement system evaluations may be superior to Gage R&R. See the JMP white paper:

https://www.jmp.com/en_us/whitepapers/jmp/emp-management-systems-analysis.html

Metro-Sam

Thank you! Sounds like I need to get familiar with JSL.

Usually the Model type and setting stay the same for a given GRR matrix; my only input is choosing the tools. So it sounds pretty doable.

What I'm doing is getting a population of matching numbers across the tool fleet to determine where new tools should be. Depending on what part I'm measuring, the tools will have different distributions of how well they match. Metrology in my area is quite unique.

Metro-Sam

It's probably in the way I'm describing it. I do these so often, I forget about all the important details you need to process to see the big picture

So if I had 5 tools this would be the Matrix:

Tool_1 to Tool_2

Tool_1 to Tool_3

Tool_1 to Tool_4

Tool_1 to Tool_5

Tool_2 to Tool_3

Tool_2 to Tool_4

Tool_2 to Tool_5

Tool_3 to Tool_4

Tool_4 to Tool_5

If I can get JMP to do all of these at once w/o manually excluding the other tools for each run, it would be a successful script.

Metro-Sam

A bit more information on the data:
I usually measure the set of "parts" 3 times
Each part (300 to 800 of them) can have a different value
So for a given part we would have 6 measurements per set (10 sets for the 5-tool example above)
Interactions are important for this application because each part set are related (but not dependent)
It's actually pretty difficult to describe w/o telling you exactly what I'm doing. I've got to keep this pretty general for IP concerns.

P_Bartell

@Metro-Sam Thanks for the additional information. For my own edification, the 'tool' is the measurement device then? And you are looking to compare the 'tools' to each other for various GRR characteristics such as repeatability, reproducibility, discrimination, and others? You say you have parts that are measured repeatedly...and interactions are important. Interactions between which factors? You make no mention of operators? I always found it helpful to put together a tree diagram of the actual experiment. So for purely illustrative purposes, 'Tools' would be at the top of the tree, with maybe operators a level below, with parts a level below the operators, with the repeat measurements the lowest level? Then you'd have to think about the nesting and crossing that could occur...which must occur at some point to evaluate the interactions you seek. But articulating those specific interactions will determine the required crossing of factors. As @statman and I are saying, there is lots to consider.

Fundamentally what I describe above is easy to generate in JMP as well as the analysis to compare the various tools. I suggest a graphical approach as described in the Wheeler EMP approach.

And it sounds like you are a bit of a novice to JSL? JSL tends to be utilized by most for one of two scenarios:

1. JMP can't do something natively out of the box...so with enough coding skill, people often create JSL solutions for this scenario. In fact, many of the JMP Add Ins in the User Community File Exchange Library started out this way...and the Add In creator has chosen to share their solution with the User Community. This isn't really your application. Based on what I seen and interpreted from your input so far...I don't see you needing any analytics or workflow capability that JMP can't handle natively.

2. A user has a problem and associated JMP workflow they repeat over and over and over. And rather than initiating that workflow from scratch each iteration, they write a JMP script which is retained for repeated use. Then with literally one mouse click, the user runs the script and that workflow is executed. This sounds like your use case? The way many JMP users create the script is to create their entire workflow in what I'll call a test case. The test case contains all the mouse clicks and menu selections the user would execute. Whenever you do just about anything in JMP, in the background, JMP is writing the corresponding JSL code for the steps in the flow. Then when you are done, just save the script for future use. Of course you can edit the script as needed. This technique might get you very close to the entire final script you need...then you just fill in the blanks or delete steps not needed. This approach can save alot of coding time and effort since JMP will write correct code for you...and you don't have to go searching for things like mismatched parenthesis or wondering what the specific JSL code actually is for some specific action. Then ultimately you might want to convert the script to a JMP Add In and then it becomes a specific part of your personal JMP deployment application.

I hope this helps?