Colour Plots by Pass and Fail

[#1]

I have a script that plots metrics by wafer number.  If the wafer falls below a threshold of passing die, it is designated a fail.  Is there a way to have the colours of the plots reflect pass and fail aside from creating a separate grading column for each parameter?

[#2]

maybe something like this?

Names Default To Here( 1 );
dt = current data table();
dt << Color by Column( column(1) );
dt << Color Rows by Row State;

where "column(1)" is the column with a indicator variable.

that last line isn't necessary, it colors all the cells in a row by the row state

[#3]

a universal plot where green is pass and red is fail - for the value that is used on the y axis at this moment?

[#4]

🙏 is in spec (value) is one of the ingredients to make this rock.
With 14 kudos (2025-06) there is a good chance that it will be available in a future version in a few years' time.
However, to be sure, please vote! every Kudo counts : )

Once this function is available, one an create a transform column in the report via

newCol = is in spec(:yCol)

and use this column as color.

In addition, one need this functionality:Column Switcher + Transform Columns 
At the moment there is close to 0 interest, so little chance that THIS feature will come : (
However, voting is still running ...

Independent of the future of this wish - the good thing is:
One can implement the functionality manually - by triggering an action every time the user changes the selection in the column switcher. Unfortunately, at the moment, there are several "bugs" with transform columns which have to be fixed to make this work (smoothly): improvements for Transform Column 

[#5]

In September, with the introduction of version 19, JMP will get a cool new feature: Scoping.
Transform Columns - as comfortable as Summary Statistics? (💚) 

With this functionality, Transform Columns will get the ability to know which rows are used for a subplot, not excluded, selected by the local data filter, ...

This topic here is kind of linked, but orthogonal.
What is needed here is the knowledge: which column is used at a specifix position in Graph Builder.
something like :@X1 - to access whatever column is used as first X in GraphBuilder , :@Y3 (used as 3rd Y in GraphBuilder), :@wrap (used as wrap), and so on ...

Maybe, we can convince @XanGregg of the superpower which is hidden behind this feature ....

[#6]

@hogi 

Right.  I can apply a universal colour scheme to all the graphs but I need pass/fail on a parameter basis.

[#7]

Currently I think this would require scripting with something like << Make Column Switch Handler

[#8]

Yes, I guess so.

unfortunately, updating the plot is not trivial: With current JMP, one doesn't get a handle to talk to the transform column.
A workaround: create a new transform column with each call of the Column Switch Handler, empty the plot and use the new column
... resulting in the loss of all the current plot settings.

more details can be found here: how to reference a Transform Column?  and here: improvements for Transform Column .

The second wish is similar to Make New Formula Column return references to the newly created columns , just for Transform Columns.

[#9]

Is there a specific reason to forcefully use Transform Columns? Current JMP version does offer plenty of other options which could be used (depending on the final goal). "Dynamic" formulas will make things like this easier but depending on their implementation they will have (plenty of?) limitations. 

Easiest option with something like this would be to stack the table, join spec limits to that table and use that for plotting. This won't always be possible, but it is simpler than using Column Switch Handler.

[#10]

---

@jthi wrote:

Is there a specific reason to forcefully use Transform Columns? 

---

I am happy with any solution.

I agree with @SpannerHead : no new columns should be added to the data table - just to calculate the color values.
So a Transform Column, dynamically generated in the report was a local step. And it's very convenient.

Stack table etc.: Definitely OK as a "workaround" as long as the functionality is missing.