Editing Actuals

[[Lu...]]

I have a part that we want to skim a few thousandths off the primary datum but I want to make sure that won't cause any issues. We have measured the part and have the measured points saved. Basically, I want to alter the actual Z value of that plane by a few thousandths and then run subsequent evaluation. I don't want my nominals to change. How can I edit the actuals?

If I offset the plane, then my Z nominals will change for each dimension, and the results would be the same. I would have to change the nominals manually for each dimension, so this doesn't seem like a good option.

Thanks!

Edited Tuesday at 04:23 PM

[[Ma...]]

If you are measuring distance from two features, then you won't succeed.

You would need to measure from theoretical feature. Which could be from altered alignment / bestfit.

But i've not tested this.

[[Lu...]]

We just want to test if cutting an additional .003 off the primary datum will cause any associated true positions to fall out of tolerance. Any ideas? Maybe there's no easy way of doing this in Calypso?

[[Ma...]]

Do you have PCM?It would be verily easy with PCM

[[Ma...]]

This should be doable. If you copy your primary datum feature ( i hope it's a plane ) modify it's nominals and recall meas. points from that feature, then making alignment should do that. Next you can make theoretical feature from that altered plane to be used as in caliper distance or as datum.

[[Lu...]]

Yes but I already have a long program with many characteristics. When I switch over to this new datum alignment for each characteristic, the nominals will change. Lets say a hole is 1 inch in Z from my datum plane. If I create a new plane, recall measured points, and change the Z value by lets say -.003. Then I change my alignment in my hole position to my new alignment. When I change the alignment, the true position nominals will update from 1 inch to .997. So my result will be the same unless I manually edit .997 and make it 1 inch again. Is there any way to turn off this automatic updating?

Edited Tuesday at 08:40 PM

[[Ma...]]

if you have PCM capture the actual values of the required features. Query the operator to enter the offset value for this run 9in your example it was 0.003). Then through result element take the actual variables subtracting the offset variable.

[[Dr...]]

Based on my understanding of the situation, this is how I’d tackle it:

- Back up the original program (always smart).

- Copy the feature in question. I’m assuming it’s a plane; adapt as needed. I’ll refer to the original plane as “DATUM” and the copied feature as “SHIFTEDDATUM”.

- Under the Options dropdown in SHIFTEDDATUM, set it to be a Theoretical Feature. This allows for manual editing of the Actuals, though note that if we try to do so directly in the input field, it’ll revert back to matching the Nominal. The key is to change the value via a formula, even if that formula is nothing more than a number.

- Optional: If we want to be exact about shifting along DATUM’s actual normal vector, we could calculate the exact XYZ position of SHIFTEDDATUM with an Offset Plane construction. If the datum is at least approximately aligned with an axis though, that’s probably overkill.

If skipping the optional part above, simply do something like “getActual(“DATUM”).z - 0.003” in SHIFTEDDATUM’s Z Actual field. The remainder of the Actuals pull data directly from DATUM, e.g., the X Actual has the formula “getActual(“DATUM”).x”.

- Swap DATUM for SHIFTEDDATUM in any instance where it appears in the program, particularly on the characteristics side. It sounds like you’re working with a long program, so here’s a useful trick: Delete DATUM, clicking “Yes” when it asks you whether you want to delete the feature and sever the dependencies of all the characteristics relying on it. Immediately thereafter, rename “SHIFTEDDATUM” to “DATUM”, then immediately back to “SHIFTEDDATUM”. In the time that SHIFTEDDATUM had taken on the DATUM moniker, it picked up all of the broken dependencies, so now those characteristics are pointing back to SHIFTEDDATUM, even after the second name change. Crucially, things like hole position nominals should remain unchanged. You can now pull DATUM out of the wastebasket, meaning that if you have to run multiple subsequent evals, the data will flow properly from the ZMP to DATUM to SHIFTEDDATUM.