*Need Help* Conditional characteristics based on actual values

[[Br...]]

I am trying to figure out how to utilize PCM to create conditional characteristics that can be run on the fly based on data gathered during the CMM run. For instance, if I scan the angle of a cone and it is out of spec, normally it would result in a out of tolerance flag and it would move on to the next characteristic. I would like to have a conditional characteristic which re-measures the feature in a different way (Line of the cone instead of scanning the entire cone), that ONLY occurs when the parent characteristic is out of spec. Meaning if the parent characteristic was in tolerance, the secondary characteristic would NOT be scanned, and not present on the final report.

How would I go about doing this? Would love assistance from any PCM gurus that could help me get this working!

[[Ch...]]

I think the easiest way might be with a "condition" in the characteristic rather than PCM, but I believe this is also very do-able with PCM. I think the simpler way would be to use a "condition" on the first characteristic (scans entire cone). The condition checks for a Boolean true or false and will skip this characteristic. The trouble is the condition referencing its own condition. You may have to make 2 of the same full scan charactersitics. The first can be "marked" so it does not appear on report.

Example:

1.) 'ConeAngleScan-REF' Characteristic ( marked on report )
2.) Copy same charactersitic but will be called : 'ConeAngleScan-REAL' ,etc
2.) For 'ConeAngleScan-REAL' - in presettings you could define a variable TOL=getActual("ConeAngleScan-REF").toleranceState
[Note : tolerance state should prodcue either : inTolerance or outOfTolerance exactly as typed here.
3.)Right click ConeAngleScan-REAL click condition and right click in yellow bar to enter formula to check for true/false yes/no. If TOL == "inTolerance" it will check this feature ConeAngleScan-REAL , if not it skips around it and goes to the line method characteristic.
4.) Make a 3rd characteristic 'ConeAngleLines' and use the condition to check if TOL variable is outOfTolerance - if so, it should skip the scan above and measure and evaluate the linear cone. NOTE: You should have 2 features one with default scan as mentioned and one with linear scan. Only one should get measured depending on in or out of tolerance.

There is a way to remeasure a feature using 2 different strategies with PCM, but it is more involved - and I havent fully tested it yet. Others can help I'm sure if this is the way you prefer to go.

Good luck.

[[Mi...]]

I can't say this is 100% and there's probably a better way but I've played with this idea - I haven't actually done it. Because honestly every time this came up, it was better to just improve the original measurement method. If measuring more thoroughly fixes the issue that means the first method sucks.

Since you're talking cones, I suggest trying some different evaluation settings and strategies. Especially in situations where the ratio of diameter to length is very high. I would be willing to bet most of your issue with measurement error would be fixed by going into the evaluation constraints and checking off Normal Vector. Changing to L1 feature might also be appropriate and help with reliable calculations. I also tend to measure cones with point strategies as opposed to scanning - but not always.

So I've done this only in simulation purely as a thought experiment for the reasons said above, but you can program a second strategy in the feature, then use PCM and a couple functions to run it when necessary. Doing this this way means you only have 1 characteristic, and it will make it check the feature immediately, if you base the acceptance on a characteristic it will only realize it needs to re-run the feature as it's calculating at the end. Unless you use PCM to pull a getActual() from the characteristic... which could work, but then you have multiple characteristics which leads to extra questions and work if you have to do SPC analysis on your data.

-I am not sure if it keeps the data from the first run or only from the second.
-The loop counter variable is there because I envisioned using this like my own version of scanning optimization but possibly having it recheck features multiple times if needed.
-The getActual().form < is set to something that makes no sense because I wanted this to run in simulation, obviously that would have to change in a real world application
-This might not work at all in the real world, but it works in simulation.
-you would use something other than .form, based on your description I would think ".apexAngleHalfDEG" or ".apexAngleDEG"

if (getActual("Cone Ped. Pinion Hole 1").form < 0.01) and (measurementLoopCounter < 1) then
	measurementLoopCounter = measurementLoopCounter+1
	setElementStrategy("Cone Ped. Pinion Hole 1", "Better")
	measure("Cone Ped. Pinion Hole 1")
endif

[[Ch...]]

thank you Michael, as always very helpful.

Just a thought to add to this, if he was interested in in/out of tolerance. adding on to your code we could check the angle as mentioned :

 getActual("Cone1").apexAngleHalf 

(note you would likely have to convert to degrees from radians)

 ANG = (getActual("Cone1").apexAngleHalf*(180/pi)) 

Then we could use PCM to check if ANG is < MAXTOL and > MINTOL etc. where each are your defined limits.

Cheers.

[[Mi...]]

Yes, I would use code that looks like this to check within a tolerance. I intentionally keep the tolerances separate from reported characteristic tolerances.

This code means "if the cone angle is more or less that 0.5° than the nominal"

(abs(getActual("Cone Ped. Pinion Hole 1").apexAngleDEG - getNominal("Cone Ped. Pinion Hole 1").apexAngleDEG) > 0.5)