hexagon logo
Register Sign in
  • Replies 37 replies
  • Subscribers 225 subscribers
  • Views 854 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
  • 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.

    +1
  • 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.

    same here, since 1988 using GEOPAK 3.16 ......................
  • Are you saying you probe a plane, line, and point (for example) then go to the alignment menu and align using those probed features?
    I read somewhere... Level before rotating. I assumed that meant probe the plane, align that plane level, then probe the line... etc.
    So, that's what I do. Am I doing it wrong?

    IMO, yes, you are doing it wrong. When you open the alignment window, do the level, then rotate, then origins, then rotate about (if needed) then origin offsets, in that order, all in one go.

    The only time you could possibly need to do an alignment that just does a level (at the beginning of a program) is if your level feature is WAY out of level to the machine, and if you know what you are doing, you don't even need to do it then since they added the ability to use a FEATURE as the reference plane for manual features in V3.7 (or was it V3.5?). AND, even if it IS way out of level to the machine and you CAN'T use a feature as the reference plane, you still don't need to do the 'single-step' alignment, just measure the plane and the line and the point and do the manual alignment, WHICH YOU DO FOLLOW with a DCC alignment, right? If so, the DCC alignment will 'correct' for the small amount of cosine error from the MANUAL level plane not being close to the machine plane. I've proved this many times, much to the embarassment of many "so called experts" who claimed otherwise.
  • 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.

    Just to offer another point of view. If there is a level involved, I do a complete alignment. I've never had any problems with rotations or re-setting origins when starting from a fully defined alignment.
  • Ok, I see where you're going now.
    We do everything in DCC.
    Most of our parts have a general location they go on the CMM. Set it up and Ctrl+q.
    Otherwise, it's a read point or manual hit to show the CMM where to start.
    The programs have a DCC 3-2-1 alignment at the beginning, to 'find' the part. Then on to the alignment proper.

    In the grand scheme of things, does it really matter if the software is calculating and updating the Level plane before probing the Rotation?
    In the end, the results should be the same if it probes all the features first, then does the math vs. resolving each one independently.

    Yes, no, maybe......

    Let's look at a test case (and this is one I USED to run into a lot, but since has been eliminated from our process) and this might be a little long too!

    We have to do reverse engineering on details. Some of these details are VERY tall, they all have dowels in them. The relationship between the dowels is VERY important to make the detail right. So, since a tall detail is too tall to probe the dowels from the 'top', the detail has to be set on it's side (on risers). Unless you square that detail up to the machine axis, when you measure the plane on the bottom, then measure the lines on the side, the probe comp WILL be off for the manual alignment for those lines, IF you are just using the workplanes (which will be to machine axis). If you set the detail up so that the base is 30 degree out of sqaure to the machine axis, you will get 30 degrees of cosine error in the probe comp for those lines. However, if you probe the plane, THEN do just a level alignment to it, the workplanes will now be sqaure to the measured plane instead of to the machine and that cosine error will be gone. When they added the ability to use a feature for the workplane, this issue could be worked around. But, let's say you didn't know about the feature=workplane thing (or are using an old version that does not allow it). So, you probe the plane and 2 lines. The 2 lines have probe comp based upon maching work planes. The measured plane will have correct probe comp (it's a 3-D feature after all!), the lines will not (2-D features workplane dependant). BUT, following good programming, the DCC alignment will then correct for the cosine error from the manual alignment because you are now square to the plane as well as square to the lines (even if they are not correctly comped and thus off location by the cosine error). The DCC features correct for it. Do you follow what I am getting at? IF you follow correct manual-dcc alignment process, your manual errors will get corrected and it isn't an issue. BUT, some people think that you can't allow even the most minor error in the manual alignment, which, IMO, is not really required.
  • To my own defense, the primary alignment - the very first one, is the same as I do in every program. Measure a plane, level and set origin to the plane. Then I go about and measure features for locking rotation and setting origin.

    The program AndersI is referring to had the primary alignment - just as he describes, but the following alignment (rotation lock and origin) was a bestfit alignment, I am sure AndersI noted this, so there was
    a complete alignment in the program - not only a level and origin. This is not the first time this have happened to me and almost all times, there is a BFALN involved.

    This procedure should work nevertheless - the nominals (THEO's) should not be touched, unless you as a user allow or tell it to.
    The way I see it, this is a bug somewhere in the underlying PART/CAD/MACHINE transformation matrix that just does not work.
  • 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 is a good suggestion, but it should not be necessary to do this. You have a machine coordinatesystem already. If you only use a plane as level and zero, the transformation matrix calculation (for the other two axis') should be based on the machine coordinatesystem, like AndersI mentions.
  • To my own defense...

    You don't have to defend yourself. There must still be a bug (feature?) in PC-DMIS involved.

    I could repeat the problem in your original program. Then I stripped everything after the two circles, so all I had was the partial manual alignment + two circles in CNC, (no BFALN) and I could still generate the problem. Then I made the alignment complete (but still oriented exactly the same), and the problem was gone (after that I tested the same fix on the original program, and all was fine).

    So, to me, it seems PC-DMIS is doing something wrong when we go into CNC after only a partial alignment. Or I'm not understanding how it is expected to work (which wouldn't be a first...).
  • You don't have to defend yourself. There must still be a bug (feature?) in PC-DMIS involved.

    I could repeat the problem in your original program. Then I stripped everything after the two circles, so all I had was the partial manual alignment + two circles in CNC, (no BFALN) and I could still generate the problem. Then I made the alignment complete (but still oriented exactly the same), and the problem was gone (after that I tested the same fix on the original program, and all was fine).

    So, to me, it seems PC-DMIS is doing something wrong when we go into CNC after only a partial alignment. Or I'm not understanding how it is expected to work (which wouldn't be a first...).

    Verified - but with a totally different program.

    How would we go about to "explain" or "find" the culprit (the reason for this happening) here?
    Anders, got any ideas?

    I would say that when aligning on a plane and setting origin in it, PC-DMIS should retain the MCS, but sometimes it seems that PC-DMIS cannot do this, instead it moves/adjusts the nominals (although it should not!) by itself, just like if we have answered YES to a global "Do you want to update the nominals...".
  • 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.
© 2024 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement