3.7 MR3 True Position issue

[Greg Haglin]

Has anyone seen this - I'm getting different "actual" results when dimensioning true position using 1 datum, no datum MMC, RFS, or simply location. How can the "actual" change?

[Matthew D. Hoedeman]

Well, the first thing I would try is turning ON the PERPEN CENTERLINE, as far as I am concerned, that should be on for default, it acts as a 'snap' point for TP, that way, if you are reporting 3 axis (XYZ) it will give a TP value of the actual measured to the nominal vector line of the hole (simulating the actual stud or bolt that goes through the hole, on the correct location), thus eliminating the surface error from the hole. As for the actual changing, it will change when you use a datum, since Pcdmis makes an alignment 'in the background' to dimension the hole with, so the actual will change. Also, the last 2 are back to datums. Now, this is a bone of contention between users and Wilcox, has been for quite a long time. Since you are using a datum in the last 2 TP dims, your actuals will change based on the datum feature. AND, since you are using both MMC and RFS, you will get different values either way, due to the way the Wilcox has it programmed to do the MMC/LMC/RFS when dimensioning TP with Datums in the TP dimension. So, my advice to you is create an alignment using the datum features you need for the dimension, then dimension to that, then there is no mystery about HOW the alignment is being created in the background by Pcdmis. You would think that if you are using MMC on both the datum and the feature that the bonus of the size of the datum would get added straight to the feature and the bonus for the feature would get added straight to the feature. That is NOT the way they do it. If you COULD also add the XYZ location of the datum feature for both of those, you would find that THEY are not the same either. THIS IS THE PROBLEM WITH THE WAY they have it programmed. Once you assign something as MASTER or DATUM, it should and MUST stay at nominal, it should NOT get slid or moved or adjusted and that is exactly what Pcdmis is doing (based on previous posts and comments I have seen on the boards). SO, make an alignment to the datum scheme you need for the dimension, then use that alignment, don't trust the Pcdmis background alignment.

[Wes Cisco]

Yes, the demon does that!

I have been 'round the Mullberry bush on this one several times with various persons from the forum, B&S, & Wilcox. This is my understanding of things, if anyone knows otherwise, PLEASE Chime In:

1) Your current alignement should be comprised of the datum structure specified in the feature control frame of your trueposition callout. For example: tp dia .005 / A / B / C Your alignment needs to be use datums A, B, & C. (this also means you need an alignment for each variation of feature control frame datums)

2) Unless you need a modifier on a datum (mmc, lmc, etc) then you do not want to use the "use datums" check box or select any datums in the trueposition window. Just select your feature from the list on the left, then MMC, RFS, etc for the feature.

3) If you do want a modifier on a datum and you check the "use datums" box and select one or more datums, then pc-dmis will conduct a "fitting" alignment behind the scenes in an attempt to replicate a hard gage.

I do not like the idea of the software creating alignments I can not see. If the features need a hard gage, I have a hard gage made. But that is just me. I have been told by people who ought to know that algorythims for this "fitting" work. I hope this is clear and helpful. Good luck.


P.S. The document you posted looks very much like one I sent to Wilcox about this very subject. The behind the scenes "fitting" alignment is the cause for the change in actuals, it moved your origins, amoung other things.

[Greg Haglin]

Thanks Matt, that helps alot, although the water is still a little muddy - turning on the perpen centerline got me the same results as the actual shows.

[Matthew D. Hoedeman]

Yep, in this case it did, since you are only reporting 2 axis and I would guess that the surface is flat to A-B-C (or close to it). It comes in REAL handy when you are checking a hole in a surface that is 45 degrees to A-B-C, but the hole is checked to A-B-C. If you report all 3 axis and there is any surface deviation, it really throws the TP for a loop into outerspace. Ya toggle that handy little thing and the surface deviation is eliminated, thus proving that the nominal bolt will pass through the hole.

[J Temmen]

I don't take anything for granted, so when I first saw the measured values changing when I added datums I tersted it for myself. When I created an alignment to [D] [E] and [F] and did a TP on hole 1 I got the same deviation as when I used [A][B][C] alignment and used "USE DATUMS" in the dialog box. It may be in the background but as far as i'm concerned it works.

[Matthew D. Hoedeman]

BUT, as with so many things Pcdmis does, does it work everytime? Can you PROVE that it worked right WITHOUT doing your own alignment? If YOU make the alignment you know exactly what it is doing, everytime, without re-work.

[J Temmen]

I've proven it to myself enough times that I rely on it to repeat. Unfortunately I don't have the luxury of time to do it every time. You have to trust something sometime.

[Greg Haglin]

Found this on the Wilcox site in the Download Instructional Files area:'Using Datums in True Position Dimensions' by Rob Jenson
It explains more about what's going on in the background but does not show the nominals changing like in my posted example.
Has a good 'General Rules for True Position' section also.

[JamesMannes]

http://pc-dmis.com/anyboard9/forum/posts/1817.html

[terry]

ugly head raised again

Hello all,
Below is an email I sent to tech support. I am not sure what answer I will get. This is causing major issues and I am not sure I trust tech support’s answers as much as I us to.

" Attached you will find both the pc-dmis part program and print. The issue I am having is the correct way to report true pos of features that relate to a different alignment than the original ABC. The way we have been doing this so far is to measure the feature in the current alignment and when we report position we choose use datums and select the restraining from the list. This seems to have worked until I came across this program. I am now some times getting two totally different true position errors by reporting the position in original alignment and restraining to the required datums, and creating a new alignment using the same datums I restrained to in the other alignment.
In example #1(located just before the middle of program) I first reported the true pos of the 72.25 bore to ABC restraining to the E H datums and got a TP error of .315. I then reported the TP of the same bore to the newly constructed alignment both re-leveling and origin to the correct datums and got a TP error of .031.
In example #2(located at end of program) I first reported the true pos of the datum H bore to ABC restraining to the EJK datums and got a TP error of .226 I then reported the TP of the datum H bore to the newly constructed alignment both re-leveling and origin to the correct datums and got the exact TP error (.226) I got from reporting it to the ABC restraining to EJK.
Why am I getting two different answers to the same question? I guess what I am asking why does it seem to work correctly in example #2 but not example #1?

Print locations…
1of 2 sec GG
2of 2 lower right hand bore."

[kbotta]

I usualy "recall" the alignment that is to be used in the FCF, then just report the normal positional. I do not use the 'use datums' selection, as BnS cannot validate the algorithm to be ASME compliant (sp).
KB

[Big John]

True position

I Know this one!!!
It is differcult to explain but I had a newsletter from Wilcox in November 2005.

Hope that it is usefull

John

[dccfreak]

I have seen this as a problem in all versions after 3.5 MR2. It doesn't seem to occur as often in 3.7 MR3 as others though. I still use 3.5 primarily, unless I want to get into some groovy scans, then I will use 3.7.

Getting ready to dive into 4.0 just to see what fun happens there.

[terry]

That’s all fine and good. I get the concept that using datums will induce pc-dmis to allow bonus toll to be applied to the datums thus creating a best fit. Ok don’t really like the way it reports it by not showing a deviation from nominal. But if it really works that way I will live with the short coming of a non customizable feature. But that is not my issue. My issue is why am I getting a much larger error when I true position the bore by choosing datum’s on? On all the posts and lit I have read I would think I would get a lesser error if best fitting is taken place because of bonus being added to the datum’s. I want to know why my error is lower by creating a alignment that matches my control frame. I believe this result is the most accurate because my XY location error read outs match my TP errors. I just don’t know why turning datum’s on occasionally seems to increase my true positional error.

Regards,
Terry