I am trying to measure Position (TP) of several holes/slots that are on a part with no Perpendicular Datum Scheme. With the compound angles of the surfaces and rotations, I am not getting accurate results. I can see that when I measure individual points around a slot for example and they are good. Would it be best to create another alignment, rotated (all 3 axis) so that I would have a parallel/perpendicular feature to Datums? If so, how do you know what angles to rotate to?
Possiblity 1: I'm making an assumption here that you are using XActMeasure and getting wild results because the datums are not perpindicular to each other. I don't know if GeoTol handles this better, coding this would be a miserable endeavor for the dev team, so I'm not throwing stones here.
I align and measure everything in that alignment, I do no output.
I then make all my alignments I might need for output to the print requirements.
Then I do all my output.
If Possibility 1 is what you are fighting, I would manually follow the standard. Align whatever datum scheme is in the feature control frame. Rotate and translate all basics in the order required to meet the print definition, which will mean your measured feature should be at X0, Y0, Z0 and in line with one of those axes (either I, J or K is 1 while the other two are 0 for the theoreticals).
Then I would output Legacy.
All deviations will be to zeroes, so this does NOT help the machinist in any way shape or form, but it does tell you if the part in in print accurately. Provided you understand GD&T enough to do the FCF alignment and make the translations and rotations in the correct order to get the feature in line at 0,0,0.
Possibility 2: The datum structure is ok (square or very close to it), but the features are at compound angles. Xact and Geo really should work for this.
You can do the manual thing as a double check.
Either case, you want your diameter measurements to be as close to 180° coverage as possible. The more you get a smaller arc than 180°, the increase to the error you will have.
Compound angle, sliding a probe into a hole some distance, this can get dicey as your head probably doesn't have a PERFECT match to the compound angle of the actual hole. This will drive you smaller than 180°.
Three rows of hits in any cylinder, minimum. I was programming this morning, and it defaulted (off line) to two rows on me, I didn't play with it as I wanted to change my head angle, and it solved the cylinder sideways.
Switch to three rows, cylinder solved correct orientation.
This is off-line, so no actual hits and part error, just the math converged faster sideways solving the cylinder. Always three rows, minimum.
If you are short the 180°, you can check your results by fixturing/jigging the part so the feature is straight up and down for A0 B0 on the head (sideways would work two, but is visually harder to tram in), measure your datums, then drop the probe at A0 B0 down the hole and get a solid 180°+ of hit coverage.
If those readings match what you are getting under normal conditions, your results are likely correct.
Different, you are getting some shanking or the short arc coverage is hurting you. There may be no recovering this, and you may need the second set up.
Another thing I'm going to say is, when I measure a cylinder and have 180° cirlce at the mount, 160° circle in the middle and 140° circle at the bottom, even though all are an equal number of hits, I tend to get weird results for size and location. Switch all three circles to the 140° and suddenly I get results that I expect and can confirm on a surface plate.
Is that just me?
Am I doing something else wrong and thinking the angle is the software, when really I was doing something that got fixed by reducing coverage? I don't know. This is just something I have fought with on compound angle connecting holes in the past with PcDmis.
If you have a model, and you align the datums, then rotate and translate the model, and your feature is NOT square to one axis and 0-0 on the other two axes, either you did something wrong, or the model is wrong.
This great to do off-line with perfect "hits" so there is nothing about the imperfect part affecting you.
If you are screwing up, you will know it.
If the model is wrong, the program used by production is wrong, and they really are drilling in the wrong place, you'll know it.
I've beat my head on the wall because they machine is rotating right, look I indicate the hole, it is perfect, only to find out the model was off an hour later.
Of course, I've also read a rotation wrong (maybe one time lol) and this check points that out so I can correct myelf.
Hope something I said helps.
Edit: You can also ask for a profile of a surface and get a cad-graph, this lets you see if maybe one hit is bad, which can screw up the math solving cylinders and planes and such. you can't give it to a customer, but it is good to help diagnose where your problem may lie, as it does a point to surface comparison without and math solving a feature.
Possiblity 1: I'm making an assumption here that you are using XActMeasure and getting wild results because the datums are not perpindicular to each other. I don't know if GeoTol handles this better, coding this would be a miserable endeavor for the dev team, so I'm not throwing stones here.
Prior to PC-DMIS 2020 R2, with the XactMeasure command, datum reference frames were handled rather like a PC-DMIS alignment, with a level feature, a rotate feature, and one or more origin features. All of these features you selected from the datum features. Starting with version 2020 R2, the geometric tolerance command does not use any alignment concepts for datum reference frames. Instead, it uses gage concepts for the datum reference frames. This enables support for more unusual datum reference frames that cannot be represented by the level-rotate-origin framework.
Comparison to Past Practice
Starting in PC-DMIS 2020 R2, the geometric tolerance command analyzes the datum reference frame in terms of invariance classes. This enables correct handling of unusual datum reference frames where the vectors are not square to each other. For example, a primary datum plane with a secondary datum plane at a 30 degree angle to the primary has a prismatic invariance class. Prior to this version, PC-DMIS did not fully support these unusual datum reference frames.
