@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?
