Measuring back to datums

[dcoss]

Ok, this is probably a no-brainer question for some of you, but I really don't know the answer. So, let's say that I have a diameter that I measured while aligned with datum B as the primary datum and I output true runout (or whatever) of that diameter back to datum B. Then an engineer comes in and says that he also wants me to output the true position of that same diameter, this time using datum A as primary datum and B as secondary datum. My question is this: Do I need to measure datums A and B first, align to them, then measure the diameter and then output the true position? Or does it matter if I just write some code in the program after the diameter is measured and THEN measure datum A, align to datums A and B, then output the diameter's true position?

[Jakep379]

It doesn't matter. Measure Dat A and Align to A/B output the true position. When programming sometimes it's even necessary to make your alignments "not datum's" to gather what you need. Example if you had an A datum that was extremely small/ awkward you would align to something else to make sure your program runs correctly and align to the datum's at the end for your measurements

[Schlag]

I am going to have to agree to disagree with this. Would you do the same thing with multiple features ?? You have 6 holes and you check them under 6 different alignments, then report the positions to your actual A-B-C datums. I think best practice is to inspect the features in the same alignment that you plan on reporting them. Maybe this is just an OCD thing but I do remember Rob Jensen discussing this multiple times during training.

[Jakep379]

If that were the case then wouldn't recalling another alignment for any purpose have the same negative affects? Regardless of how your alignments are to gather the data. You can align correctly later to get your measurement. Xactmeasure does this automatically. It will move your tryhedron to the correct location for the datum scheme without you physically being in the correct alignment. To your point your saying doing this causes negative effects on the features themselves by changing alignments?

[dcoss]

That makes total sense. Thank you for the example.

[dcoss]

I guess the main reason I asked the question as well was that if I changed the alignment that was already in the program and added another datum, I don't want to mess up any of the code that comes after by doing so.

[Jakep379]

I guess the main reason I asked the question as well was that if I changed the alignment that was already in the program and added another datum, I don't want to mess up any of the code that comes after by doing so.

If you want to edit an existing alignment. Yes you can mess up the code after depending on how you answer the question that proceeds. When you edit an alignment its going to ask a yes/no question if you want to convert the dependent commands "rest of code" to the new alignment or leave them unchanged. You would choose yes.

Example if you were aligned to just B and all your proceeding features was .100 away from B and now you wanted to add A. When you add A your alignment now moves the Tryhedron to the new location and all your proceeding features are now .200 away. If you choose "yes" this updates your features to say yes you are .200 away. However if you say "no" it does not update your features and stays .100 away so all your features move with the Tryhedron and can cause a mess.

There is a few instances where you would say "no" but that's mainly when you deliberately want to move your features to the new location.

[Jim Poehler]

A little caveat here. Most everyone who has extensive experience with PC-DMIS will agree that when you say "no do not update", the software will at some point in time decide that is what it wants to do and you can watch all the nominals change right before your very eyes. That's why we always save, save, save and never use anything other than a copy to make these kind of changes. Just an FYI here, don't get burned.

[Jakep379]

True this goes for anything in general going back to edit. Weird things do happen.

[CodeWarrior]

One thing to add, save a backup before messing around with the code just in case