Reporting without any datum shift, reporting based on the alignment/workplane you are in, easier to access the dimensions with vba or like programming, work arounds for poor drafting, new fangled reporting strategies don't interrupt previously setup reporting strategies. Probably a fair amount of alternative reasons that are escaping me at this moment.
Reporting without any datum shift, reporting based on the alignment/workplane you are in, easier to access the dimensions with vba or like programming, work arounds for poor drafting, new fangled reporting strategies don't interrupt previously setup reporting strategies. Probably a fair amount of alternative reasons that are escaping me at this moment.
Good answer. Especially the "work arounds for poor drafting." Comes up more often than I'd like. It can also be useful for when you need to report to an old GD&T standard. Or a custom GD&T standard - some companies make their own rules.
Legacy mode is also less resource intensive than the more modern reporting commands. On large parts with thousands of features the software can slow to a crawl if you don't stick to legacy reporting.
Thank you all for your replies. Here's my problem.... without being able to post a pic due to strict ITAR rules I will try to explain as best I can.
Imagine a cube. Top plane being Dat A, +X plane being Dat B and +Y plane being Dat C. There are four holes on each of the 4 X (+/-) X and Y planes. DRF for the +X and -X are BAC. DRF for the +Y and -Y are CAB. Being in the correct alignment prior to measuring holes I am finding everything in on say Datum C but OOT of the plane opposite (-Y plane). Same for Datum B and its opposite (-X). Now I am using Geo Tol to report my finings. Another company machines this part and I am checking their work. I ran through their report and for the most part they are using Geo Tol to report as well until I get to the holes in question. They then switch to Legacy which shows the holes in tol. Now because the report doesn't show the DRF there is no way to tell what alignment they are in when checking said holes (ie ABC, BAC, CAB, ACB etc..).
Side note... I come into PC-DMIS world this year with 20+ years experience, most of which using Calypso and last 6 years using Modus + others LK camio etc..
Why not simply ask them for their code? It's a pain diving into someone else's code but it's doable.
I agree. That's the surest way to replicate their measurements.
Something to keep in mind is that GeoTol uses math that is quite different from legacy dimensions when positioning the DRF origin.
Legacy just uses the current alignment as the origin. If you align to the datums to report in legacy, it is using the math fit type that the features were measured with (typically a Least Squares Best fit).
GeoTol uses the datum features more like datum simulators, positioning the DRF origin at the high spots of the datums. Here is a link to a help file article that better explains this:
How PC-DMIS Solves and Uses Datums (hexagonmi.com)
So, you can use the exact same datums to report in GeoTol and Legacy and get different results. It is possible that your supplier used the same datums as the drawing calls out but chose to report in legacy because the different math gave them more favorable results. Not necessarily correct results.
When you struggle to correlate legacy sometimes fixes (over looks) some of the BS that Xact or GeoTol puts into the reporting.
Double check your results (coord location of the cast feature) vs. Xact or GeoTol reporting. I do not like it that Xact will apply datum shift when it is not needed (and you have to play with the reporting options to get the answer you want which can freaking take too much time when all of your programming is done offline). I've had that happen more than once and it burned my back side. I've had the GeoTol training but have not used it here because we are still on 2019R2.
