hexagon logo

Nominals in DIMENSIONS keep changing!

I have read most of the posts on this site, and they mainly seem to point to the nomials for the actual feature changing... and like most of you say " I have never had DMIS change a nominal ... ever! And if it is changing it on you , you have done somthing wrong!"

I am not talking about it changing a nominal for a feature! I am saying that when i create a dimension, without CAD, I have to tell it what nominal i want for the dimension, bedcause it always picks the wrong one! Then I print a report and all is fine... UNTIL I RUN THE PROGRAM AGAIN! Then, the next time i print the report, all the nominals are different and I have to update them again!

Also tolerances that i put in the angle dimension edit box won't transfer to the report at all.

Thoughts??

Sam
  • ignore cad part is unchecked, I will try the +0 method and see if that helps.

    sam
  • ...you could try moving the "gbarstate.dat"-file out of the user directory (this will reset your window settings though) and run the program again to see if it still changes the nominals. If it doesn't, put the file back again.
  • Is this the problem where when you dimension something between 2 constructed features, the nominals will change in the dimensions? If so, I believe it is a known issue. I have always had to assign a variable the nominal & use the variable in the dimension for it to work.

    That said, I cant understand why this has not been fixed. I mean, having your nominals change on you should be a major concern, right?
  • I mean, having your nominals change on you should be a major concern, right?


    Amen!
  • is it possible your program file is a read only file? Just wondering.
  • Yes.. this should be fixed by Hexagon. I had the tech people on the phone once and they acted like they had never heard of the problem before! They also didn't have any suggestions on how to fix it either.

    So far the +0 has worked on this particular issue.

    Still don't know why when I create an angle dimension it will not take the value from the edit box that i type in though.. i have to fix iti in the code instead.

    Sam
  • I've seen a case of nominals changing today (in a vpt part program Stuck out tongue closed eyes ). At least for this one case, it seems the cause was an incomplete alignment. The program only did level on a plane, set Z-zero on the plane, nothing more. I could reliably see the nominals change when testing offline.

    Then I added two 'fake' features, a line from an MCS axis, and the MCS origin, and used them in the alignment to make it complete (level, rotate, zero), and suddenly the nominals stopped changing.

    We'll have to wait for the final verdict when vpt has tried this online, in a CMM...
  • I've seen a case of nominals changing today (in a vpt part program Stuck out tongue closed eyes ). At least for this one case, it seems the cause was an incomplete alignment. The program only did level on a plane, set Z-zero on the plane, nothing more. I could reliably see the nominals change when testing offline.

    Then I added two 'fake' features, a line from an MCS axis, and the MCS origin, and used them in the alignment to make it complete (level, rotate, zero), and suddenly the nominals stopped changing.

    We'll have to wait for the final verdict when vpt has tried this online, in a CMM...


    Perhaps this should be taught as a caveat in the training lessons. If you want to lock in your nominals, start the program with a constructed alignment from generic features. We used to do this with our PMM w/QUINDOS (UNIX) and never had an issue. I believe that we were instructed to build features and place them in one of the db's , EDB, GDB, I don't remember. This way we could access the feature for an initial alignment for any program we built.
  • That, or just do a complete alignment, like they USED to teach in the starting classes, not the level only, then measure more, then level and rotate then measure more, then level rotate and origin. I always do complete alignments, never partials, never.