hexagon logo
Register Sign in
  • Replies 37 replies
  • Subscribers 225 subscribers
  • Views 862 views
  • Users 0 members are here
Options
Related

Nominals in DIMENSIONS keep changing!

seppley
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
  • I wonder what it will do to vpt’s original program when AdjustLevelCommandRotation is set to False

    Ah... another "hidden" setting from the Wilcox guys, I guess. Just like the "UseISOCalculations" making an entire ISO userbase doing it wrong for years.

    I'm traveling so can't check this myself in pc-DMIS but there is another check box in the f5 setup window called "allow fine tuning of alignments". I have never really understood what this does. It kind of sounds like it is allowing pc-DMIS to make alignment modifications but I'm not sure this is actually what it is referring to.

    Has anyone verified the idea that if you use a recalled external alignment at the beginning of the program it will lock down the nominals? I have almost never had a problem with nominals changing and I almost always start programs with external alignments. The one time that I did not do this recently I had all of the nominals change. This same program also started with a level and origin to a plane with no rotation before going to DCC. I'm curious if the same program would have changed nominals if I had recalled a complete external alignment and then used this as the recall alignment for my level/origin alignment. Perhaps pc-DMIS has trouble referencing the machine csys but does not have trouble if you give it an explicit external alignment to reference.

    Anyhow, I can't test any of this right now. It would be very nice to lock down exactly what causes this behavior, exactly how to avoid it, and put that in a sticky so everyone who comes to this site can learn how to avoid this.

    "AllowFineTuningOfAlignment" did not help, either on or off.
  • DungT's suggestion looks very good, it could be the solution to all the nominals changing conundrum.

    Whilst walking in PC-DMIS settings darkest corridors, I also found another setting - UseTheosForCADToPartLevelAlignment which also might have an impact on this.

    Thanks again, DungT!
  • Quoting some findings from the Wilcox Support Database:

    AdjustLevelCommandRotation (added around version 3.25)

    It has no affect on the PC-DMIS dialogs. It changes the behavior of the level command slightly so that when we do a level, it keeps the other two axes as close to what they were as possible. This was a change from prior versions of PC_DMIS so that in case there were problems, we could turn this new behavior off by setting the option to zero. Normally unless there is a problem with the alignments, this option should be one.



    UseTheosForCADToPartLevelAlignment

    There is a bug report describing almost exactly the current problem, I quote from the resolution ("I" below is some Wilcox developer):

    I did some testing today with 2012 RC. I tested this issue of 2D feature theoretical values changing after a Level alignment prior to the Rotate command.

    It is certainly repeatable and doesn't matter if CAD is imported or not.

    The UseTheosForCADToPartLevelAlignment setting seems to take care of this problem for the tests I ran today. It looked good.


    Also found another report with the resolution:

    << Xxxxxx Yyyyy (Development Notes) -- 05/13/11 14:26:33>>
    Code appears to be working correctly; the main issue is the user has used an alignment that hasn't had it's ROTATE set, so the theo values of the measured circles will drift some based on the measured values. However, internally, the CAD to PART transform really is not changing.

    There are two reasonable ways to eliminate the drifting theo values:
    - lock down the final rotation of the alignment before using it to measure the circles (the program will need to be run again in order to clean up the theos, but after that they will be stable)

    - set the PC-DMIS setting UseTheosForCADToPartLevelAlignment to TRUE using the Settings editor. Refer to the help manual, Home > PC-DMIS Settings Editor > Option> UseTheosForCADToPartLevelAlignment. The program will need to be run again in order to clean up the theos, but after that they will be stable. (as a side note, I had to search on 'Alignment' or 'CAD' in order to find this setting in the help manual; 'Use' and 'Theos' didn't work...)
    <<END>>

    And quoting the Help:

    Use Theos for CAD to Part Level Alignment
    Introduced in v2010 MR2, this entry only does something in those cases where a level alignment exists without a successive rotation constraint. In this case PC-DMIS needs to decide the rotation direction of the secondary axis about the primary axis (the level axis). It will affect feature theoretical values following this type of alignment.

    Entry Name: UseTheosForCADToPartLevelAlignment

    Entry Type: Boolean value. The default value is False. False is the legacy value. Part programs prior to the creation of this registry setting behaved as if this setting were set to False.

    When set to False, the rotation about the primary axis is determined by the measured values of the input features and the change in rotation of the CAD to PART transform about the level axis is approximately the same as the change in MACHINE to PART.

    When set to True, the rotation of the CAD to PART transform is not dependent on the measured values of its input features; instead, it is based on the current CAD to PART transform.

  • Looks like we have a winner here!

    Question is why this is a setting and not default?
  • Somehow, this seem to happen to me everytime I import a CAD, clicking away on the model to create my features and then running the program...

    I made a program like this today and after measuring a plane I did a level and origin and then measured a circle and a slot (the THEO's taken from points clicked on the model).
    I ran it and noticed a small deviation in the theo's. I polished these up and moved my part slightly.
    Ran it again and noticed larger deviations in the theo's. Moved the part slightly more.
    Rinse, repeat - still getting theo's that deviated. Polished them again.

    Closed PC-DMIS, fired up the settings editor and looked up the UseTheosForCADToPartLevelAlignment. I changed the setting to TRUE (1), saved and closed the settings editor.
    Ran the program again and still got theo's that deviated. At this time, I almost blew a gasket, thinking that it didn't work.
    Anyway, I polished the theo's once more, saved and closed the program.
    Opened it up again and ran it. No deviating theo's!
    Moved the part slightly, ran it - no deviating theo's!
    I repeated this at least three more times, all resulted in the theo's staying the same.

    Heureka! Finally! (time for a happy dance!)

    So, all in all, it seems that the registry setting did the trick! Too early to tell if the setting affects something else though... (knock on wood)
  • Unrelated topic;

    Can anyone tell me how I can change a report read out on a dimension? I ran a part that stated that my hole dia was off by .0002 and so I measured it with a hole mic and found it to be just slightly over nominal which is fine considering we are measuring this feature with +/- .010 I want to just go in and change the dimension manually but it won't let me? Any advice would be appreciated.

    CMMGUY13

    That is called fraud. The honest thing to do would be to add a report comment stating you checked it with a hole mic, the result of that check, and you opinion that it's good 'nuff.


    HTH

© 2024 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement