Nominals changing.

[cmmspm]

Good morning, world-

OK, I wrote a program last night and put all the dimensioning in. This morning I ran it and there was a dimesion 13.758, that I'm positive that I typed in correctly in the nominal when dimensioning, but now it reads 13.75649 after I checked the part.

Does anyone have any idea why this nominal would be changing on it's own? I'm wondering if I clicked something that I should not have?

Thanks,
John

[dwade]

Welcome to the wonderful world of PC-DMIS. It happens all time. Usually when program offline and run a part for the first I have to go and "clean up" the program to get all of the noms correct. Sometimes it happens, and sometimes it doesn't.

[Matthew D. Hoedeman]

I have seen this issue myself, but ONLY when using an iterative alignment. To get around it, I do the iterative alignment as a seperate program, then save it to an exteranl file, then recall that alignment in the check program. I do this with ALL my regular 3-2-1 alignments and only started doing it with the iterative when I saw this happen. So, it MAY have been waiting to happen to me when using the regualr 3-2-1 alignment, but with my method of keeping the alignment seperate, it may have protected my rump all along.


ADDITIONAL INFO:

I think this issue came into being when Wilcox changed the way that features are 'stored' in the program. They used to be tied directly to the alignment features THROUGH the alignment, but now they are tied all the way back to machine position, through the alignment, through the alignment features and to the machine position. Then, a new alignment after a re-home fudges your values.

[jmgreen]

I've complained about this too, to tech support. I have even seen them change slightly after I've put them in and tabbed over. The solution I was told is to put "+0" after the number. It works but I find this to be a pi$$ poor fix.

[cmmguy]

Seems really bad in v3.7

[PCDMISRON]

I am expericing the same issues with some DMIS imports which were constructed from a trnaslation of UMESS-UX programs. In my case, I have observed chnage in the actula measurment points as well as the nominals. In some instnaces the target values which are the second set of XYZ's in the 'hit/basic' lines remain as translated.

I am trying to find some repeatablity in the issue so that I can report it to Hexagon.

Ron

[Cumofo]

I think you may be missing a value in your alignment block.

[gcunniff]

I used to run a dual arm machine and we were getting some strange things with noms changing. Sometimes we had sub assembly checks that would use the same points on those parts after they were welded into further assembly operations. We were getting some noms changing when we cut and pasted points from one program to the next. What we found out is that the programs had different alignments based on where the fixtures were setup on the plate. We correlated fixture locations and set up alignment programs that would work for both assembly and sub assembly fixtures. Once we had a common alignment file, we could cut and paste to our hearts desire.

[Matthew D. Hoedeman]

I used to run a dual arm machine and we were getting some strange things with noms changing. Sometimes we had sub assembly checks that would use the same points on those parts after they were welded into further assembly operations. We were getting some noms changing when we cut and pasted points from one program to the next. What we found out is that the programs had different alignments based on where the fixtures were setup on the plate. We correlated fixture locations and set up alignment programs that would work for both assembly and sub assembly fixtures. Once we had a common alignment file, we could cut and paste to our hearts desire.

I use external alignments 100% (well, 99+% anyway!) of the time with no alignments in the check program and I have never had a nominal change. Not saying that is a 'fix' for it, just saying I never had that problem.

[tlnzz]

I've complained about this too, to tech support. I have even seen them change slightly after I've put them in and tabbed over. The solution I was told is to put "+0" after the number. It works but I find this to be a pi$$ poor fix.

This is the only ,"fix", that has worked for me. tlnzz.

[Tested]

I use external alignments 100% (well, 99+% anyway!) of the time with no alignments in the check program and I have never had a nominal change. Not saying that is a 'fix' for it, just saying I never had that problem.

Do all of your externial alignments show up in your drop down window?

[Matthew D. Hoedeman]

Do all of your externial alignments show up in your drop down window?

YES and NO.

For each job (none lasting longer than a year, max) I have a subdirectory. All the programs for that job go in that subdirectory. The external alignment gets saved in that subdirectory. So, only the alignment files for that job will show up (usually 2 at max, for RH / LH parts). But, when I work in a different sub-dir, then those alignment files show up, etc., etc., etc.

[Tested]

Cool, thanks

[Eric Hollenbeck]

I do this

ASSIGN/V1 = .1
DIM D15_6= 2D DISTANCE FROM CIRCLE CIR_D15_6 TO POINT PNT_D15_6 PAR TO POINT PNT_D15_6, SUB_RADIUS UNITS=IN ,$
GRAPH=OFF TEXT=OFF MULT=10.00 OUTPUT=BOTH
AX NOMINAL MEAS +TOL -TOL DEV OUTTOL
M V1 0.1000 0.0004 0.0004 0.0000 0.0000 0.0000

Works every time

Eric

[rangerboat72]

Get used to using work-arounds in PC-DMIS. You will find that you need to do several of them...