Well, if you are using a variable to define a nominal, I have read (and use) the 0+V1 option. Instead of just using the variable, you make a math operation out of it. Use ZERO+VARIABLE.
2nd..tech has just suggested the +0 "trick", and after trying this, still not quite right. The nominals in the program are no longer changing (YEA!!!), BUT in the results report, the nominals are still changing...I don't understand this.
The syntax may be wrong, but my net goes down @ high noon...
you can stabilize your nominals by reporting out a generic feature that traps your nominals and measured values.... just a thought
now your taking me to places I've never been...lol
I have only 4-5 months under my belt with PC-DMIS....I realize there is alot more for me to learn, but my gut feeling tells me that having to use math functions or other trickery, is not the right way. the nominals are "hard" numbers applied by "me" taken directly from the "print". the actuals or hits should "only affect" the "measured values", PERIOD
I was initially impressed by PC-DMIS, I am still impressed by what it can do, I am not thrilled by how intensive programming can be, never had to deal with vectors in Apogee, I am becoming dissatisfied by what it does on its own... I am still impressed by what it CAN DO.
and I am extremely impressed by the help on this forum
Sorry to dig up an old thread, but this is my exact problem, only I don't know enough about playing with PCDMIS to know how to make use of the tips here? I've tried using variables, but then my circle command goes wrong (seems to make the machine try and use the variables like a new alignment, so tries to measure points at 5,0,0 as opposed to 40,0,0).
I'm VERY new to doing anything other than simple teaching of the machine, but very keen to learn!
There are several recent threads about this that you should search out. I believe the general concensus is that the most common cause of nominals changing is an alignment that does not constrain all 6 degrees of freedom. If you leave some freedom available you are just inviting the PC-DMIS background editor to jump in and start making changes, and it does.
Sometimes you might not need to constrain all freedom (on round parts where angular orientation of features does not matter, for example) but you still need to do it to keep Pc-DMIS happy. Sometimes you might need to create a few generic features to make this possible if you don't have physical features to use in the alignment. For example, I always create an XY plane, an X-axis line, and an origin point at the beginning of the program.
If I want to create an alignment that simply levels to a measured plane and I do not care what the rotation angle or the origin are, I level to my measured feature and then use my X-axis line and origin point to complete the alignment. It doesn't matter to me one way or another that I am oriented perfectly along the x-axis but Pc-DMIS cares and this should stop most incidents of automatically changing nominals.
There is a setting in the settings editor that also might have an affect on this. You will find reference to that in other posts. There is also a file that, when corrupted, can cause odd behavior with best-fit alignments and result in changing nominals. I doubt that this later one is your issue but it has been mentioned as one possible cause in some situations.
I have held myself to a rigid discipline of full alignment everytime, no matter what, and have not had any further trouble with this issue.
I have unchecked "Ignore CAD<->Part" under the F5-settings and set the registry flag "UseTHEOsForCADToPartLevelAlignment" to "1" (true). This setting is versionspecific so your mileage may vary.
This has done wonders for my wandering nominals. But as DaSalo says, this is surely mentioned in other posts handling the topic.
Thanks guys, my problem is always picking the right search terms, but I'll have a crack with the tips youv'e given me and at least I know the answers are out there with better search terms for later!
