hexagon logo

Running Collection of Useful Tips

This is a dual purpose topic, proposed to contain a collection of Useful Tips & Tricks some of us use on a daily basis; both to share with the community and to have a copy on the cloud when I forget!
First and foremost, the "0+0" rule.
For whatever reason, PC-DMIS loves to change nominals!
In order to fix this completely, any number that you'd like to not change needs to be set to an equation*
*I'm sure there are numbers that probably won't change very much...
I personally don't like to write out 0+0 every time I have the need for a 0.
I can't remember who told this to me (it was 100% from this forum, someone will probably own up to it) but I like to assign a variable instead.
ASSIGN/ZERO=ABS(0)
ASSIGN/ONE=ABS(1)

Now, whenever I need to have a 0 or 1, I just type zero or one.

This brings up a lot of points.
First and foremost, it is extremely important to be able to understand what you're programming. If you start making variables willy-nilly, and don't have a way to differentiate V1 from V187 without going through the variables and finding out what you had assigned them 2 years ago, you're gonna have a bad time.
However, if you set a variable called NOTCH_1_L_180, you know that that variable should be the nominal location of Notch 1 at 180° (part-dependant obviously).
Let's say you have two parts that are almost identical. You take the time to create a variable for every single aspect of every feature you're going to measure (it doesn't take as much time as it sounds).
Now all you have to do is File>Save as the new part number, change some variables and shell the program. Everythings all set up and ready to go, the new variables are initialized and the features reset once it's shelled.
---
Personally I prefer to program using this method. Creating a variable for everything makes the program less likely to change, but makes it easier to change at the same time.
I personally do a lot of work with parts that come from a blank, say 15 different parts with the same notches at different locations, diameters, and depths.
I can program 1 part in a day or 6, and the other 14 the next day (exaggerated).
I'll always know what the variables mean, because I understand my own naming convention.
Mine, personally (as listed above) is the type of feature, the order of the feature (I go from datum to non datum, where applicable), what aspect of the feature (L for lcoation, D for Depth, R for Radius, etc) and the degree of rotation the feature is at (I work with round parts, if you haven't heard).

The variables themselves are nothing special, just the absolute value of whatever the blueprint says (I rarely get lucky with CAD models).
So instead of having to remember ever single number and dimension on the print, I just have to know that the Y-Axis is this variable, X is that, etc.
Makes it easier for me to program, anyhow.
---
Hopefully I'll add more to this eventually
  • I also thought this was useful:
    When using the Auto Line Feature, Surface Vector is the Workplane, the Edge Vector is the vector of the actual hits, and the Line Vector is the actual vector of the line
  • I'd really like to include something about alignments. I go for the Level-Rotate-Origin alignment process for our cylindrical parts; Leveling to the OD (cylinder), Rotating to a notch (plane or line, depending), and origining to the OD and a point.
    It would be cool to explain more of the process of why that's the way to go; I understand it simply locks down all 6 (DOF's? D'sOF? DOF?) degrees of freedom, and it lets me run my parts. However, I see a lot of times where there's not enough attention paid to the alignments.
    I can't imagine any good data being retrieved from a program with a bad alignment. Data can be retrieved, and the numbers could very well be in tolerance, but I couldn't trust a program that's not aligned properly. It's like trusting your CMM measures fine when it's out of calibration; sure, it could be fine, but do I need to go into detail as to why it could not?
    At any rate; if someone could help me explain alignments better, I'm sure we could all benefit.

  • Next; instructions.
    I see pretty good instructions on this forum, both from individuals answering questions and from those asking.
    However, I see more often than not a question that is explained incoherently or inadequately, or is missing that *one* sliver of information that either solves the issue, or makes it unsolveable.
    The point is, I personally, and I'm sure many others on the forum, would appreciate if you could put some time into your questions. Plan them out, go through them to make sure that if an individual has no idea who you are, or anything about the nuance of metrology you happen to come from, but they know a bit about PC-DMIS, they can still answer your question to the T.
    It helps me out a lot when I see a post and I can actually understand the question!
    I understand this is not always easy; being a world-wide software, there are plenty of opportunities for communication problems! However, if the question is posed as something along the lines of:
    Help! I'm trying to make a line and it won't work!
    


    Then nobody will be able to help, just based on that information.
    Instead, we are going to have to go through the painstaking process of asking you the simple questions.
    Such as "well how are you doing it"?

    It would be nice if, when I went on the forum to try to answer a question or 6, I got greatly worded questions. They're all great questions, don't get me wrong, but too many times I've seen 3 pages of people asking 6-word questions to the OP, and then 1 post that has either a quick answer that can't be understood unless you go through every page of posts, comments and all, or 5 different answers and the OP just replies "That worked, thanks", if they reply at all!
    This is sort of defeating the purpose of the forum; you might as well google it (which brings up a whole different thread entirely...)

    So, in short, if you want a quick and concise answer, you have to provide a full explanation of what you're working with.
    What did you do, post the ***king code, what have you tried, etc, not just one question that has to force us to ask questions to understand what's up!

    I just wanna help you guys; I would really appreciate if you'd make it easy for me!

    Sheesh, this sounds way more negative than I had originally intended..
  • For whatever reason, PC-DMIS loves to change nominals!


    Actually it doesn't *love* it, many users almost never experience it, but if you give PC-DMIS the preconditions for changing nominals, it has to obey, however unwillingly. The fact that we don't realize we've given PC-DMIS those contradicting facts/datas doesn't mean anything to PC-DMIS, it's just a computer program without feelings.

    Among these preconditions are

    - not locking all 6DOF of the final alignment
    - long chains of alignments depending on each other instead of referring back to START every time we lock all 6 DOF
    - variables in alignment commands
    - other ways? Fill in...


  • So how do I remove the permission i didn't know i gave to PC-DMIS to change nominals?

    PC-DMIS modifies nominals slightly even if i don't use variables in alignment commands, don't use long chains of alignments and do lock down all 6DOF in the final alignment
  • The last two certainly apply to me!
    I try to create a course alignment, a progressive alignment, and then a final locked-in alignment.

    When I say progressive alignment, I create a cylinder by measuring 4 or 5 circles, aligning to each circle/creating a cylinder & aligning to that (when more than 1 circle has been measured)
    It is these circles that cause me the nominals-changing issues I've got!
    (Which would make sense consider what you just told me! Lol)

    So, what would be a good workaround to this? I could rework the alignments to recall startup for that section, but I'd like to keep the variables in place if I can.

    +1!
  • Per , explaining how workplanes affect lines
    If you are in a workplane perpendicular to your line (workplanes normal/vector is parallel with the line direction) you will get a zero length line result.

  • ...it's just a computer program without feelings.

    The program doesn't love it; it just hates me! :P