Offset Plane Issues

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Offset Plane Issues

    I am revising an old program written sometime before 2012 and it's brought up some questions. First, why would one ever measure a plane and then construct an offset plane with an offset of zero? Second, if one did this, shouldn't dimensions referencing those planes give the same results? that is, the planes should be interchangeable? Instead this is what I'm seeing. I'm currently using version 2022.2 but this is translated from something earlier, probably last saved in 2017R1 in case that could possibly matter. The routine is saved as 2022.2 now though.

    image.png

  • #2
    Normally when you execute the routine it will revert to be the same. I see no reason to offset a plane with 0 offset, maybe the programmer was testing and is left over code that has been forgotten there?

    Comment


    • #3
      the offset value might have changed to zero by mistake
      is the output as required?

      Comment


      • #4
        ^ I've had offset values reset to 0 when I F9 them in a later version than what the program was saved as.

        Comment


        • #5
          I believe there's another problem, because the actual centroid of FRAK doesn't match with hits measured values, but dim D45 is right...

          Comment


          • #6
            Thanks for the thoughts, all.
            jigars, constadin and Sora5, the offset plane is used just as I would have used the measured plane if it were me, that is it is dimensioned as if it were. Thanks Sora5 for the tip that it could revert but I don't think that was what happened here. Don't worry too much about that part of it, I would still like to find out the purpose but I'm not going to worry too much about it I guess.

            JEFMAN, yes this is my big concern. It seems to actually BE offset by 0 according to the coordinates and vectors (and graphically) but the dimensions say otherwise. I have executed the dimensions and created new identical dimensions and get the same result.

            Also I just noticed the word "cartesian" in the offset plane is a different color. Does anyone know why this is? I'm not sure if that's from pasting here or if it is in the actual measurement routine, and I'm just leaving for the day so that mystery will have to wait...

            Comment


            • #7
              In theory, you could use an offset of 0, or a generic plane to "flatten" any flatness variation for the measured plane... but FRAK is only 3 hits (a 3pt plane will not capture any flatness, ever), so it makes absolutely zero sense.

              So I too am confused as to the following:
              1 Why the two dims would produce different X axis values and
              2 Why someone would do this intentionally in the routine
              Last edited by louisd; 12-01-2022, 04:52 PM.

              Comment


              • #8
                Originally posted by louisd View Post
                In theory, you could use an offset of 0, or a generic plane to "flatten" any flatness variation for the measured plane... but FRAK is only 3 hits (a 3pt plane will not capture any flatness, ever), so it makes absolutely zero sense.

                So I too am confused as to the following:
                1 Why the two dims would produce different X axis values and
                2 Why someone would do this intentionally in the routine
                D45 x was from 3 hit points X value: average of 0.264 0.239 and 0.269
                D46 x from the plane

                Comment


                • louisd
                  louisd commented
                  Editing a comment
                  Yes.
                  If offset plane OUTPLN is an offset of zero, and references FRAK, it should in theory have the same resultant dimensional value.
                  For D45 and D46 to have differing results, is alarming.

                  --You are 100% confident that you have executed this routine in its entirety to produce the results pictured (not CTL+e or CTL+u partial executions)?

              • #9
                louisd, no I am not certain this was executed from the start, in fact the screenshot I posted is from the program as last saved, theoretically in 2017. But I did ctrl-e the constructed plane, ctl-l the constructed plane and dimensions (those dimensions were inserted by me anyway, originally the dim for OUTPLN appears later) and even created another offset 0 plane and dimensioned it, all with the same results shown.

                I am interested in how running in its entirety can affect these results though, if you can explain. I would think once the first plane is measured then running the constructed plane onward should be sufficient. Apparently not though, or at least maybe not, because when I ran the program (which admittedly had changes but not to these features) the results made sense:

                image.png

                Also for anyone wondering I think the text color change must've been a result of the screenshot process, the text color is all the same within the progra (plus it didn't happen this time.)

                TO BE CLEAR, THIS IS NOT A RESOLUTION. I am still very curious about this result and how it may be related to a full vs. partial execution, or any other possible reason. And thank you everyone for the help!​

                Comment


                • louisd
                  louisd commented
                  Editing a comment
                  If you execute a routine partially, the resultant values of that execution are stored in the ACTL and MEAS results... which are then fed into dimensional outcomes.
                  Every time you execute a routine entirely, all of the ACTL and MEAS results will change based on the ACTUAL and MEASURED values of that component you just measured.

                  If you don't like your ACT and MEAS values varying on a routine you set as read-only, i suggest you open & execute the routine offline (you can do this generally by opening another routine first, then opening the routine you want to simulate executing second). doing an offline execution will make the ACTUAL and MEASURED values identically match all the theoretical values. It makes the routine look very "clean" as the 3 rows of coordinate values being displayed for each feature will be identical.

              • #10
                That, to me, is very clearly a resolution.
                First, why would one ever measure a plane and then construct an offset plane with an offset of zero?
                --We don't know for sure, but it's standard practice if one wants to OMIT form/flatness variation from the judged feature. It's also (apparently) a glitch in revisions that offset values shift to zero.

                Second, if one did this, shouldn't dimensions referencing those planes give the same results? that is, the planes should be interchangeable?
                FRAK and OUTPLN measured resultant values now match, as they should after executing the routine entirely. The delta between values was clearly a result of the last execution being a partial, omitting the updating of (last) MEASured ACTUAL values for one of the two planes.

                pleas elaborate on why you'd think it isn't resolved?

                Comment


                • #11
                  Perhaps it's poor phrasing to say it's not resolved, what I mean to say is I still don't understand it.

                  I mean, whenever the measured plane was measured, shouldn't creating a plane offset 0 have the same result? The key thing to notice is that in the first shared screenshot the x, y, z, i, j, and k measured values of each plane match, it is the dimensions (which again were inserted later, and therefore don't need updating) that don't match.

                  also I don't know how to insert a quote, hope this is understood even if it doesn't work. Here goes:

                  Originally posted by louisd
                  If you execute a routine partially, the resultant values of that execution are stored in the ACTL and MEAS results... which are then fed into dimensional outcomes.
                  Every time you execute a routine entirely, all of the ACTL and MEAS results will change based on the ACTUAL and MEASURED values of that component you just measured.​
                  But if I partially execute a routine, the same thing occurs, right? For the features I execute. All I executed in the first screenshot was the offset plane. I also created new zero offset planes and got the same dimension result for those as for OUTPLN. Which was the same result as the original routine had. Well, I mean there was no result for FRAK in the original, just for OUTPLN. I created a dim for FRAK and was concerned that it wasn't the same.

                  Incidentally the reason I created the dim for FRAK in the first place was that I didn't know why a zero offset plane would be created. I was thinking, "they're the same right?" so I did the dim and got concerned, especially when seeing the ACTL's in the feature.

                  Comment


                  • louisd
                    louisd commented
                    Editing a comment
                    This is really fundamental.
                    PCDMIS records the last measured values in the ACTL and MEAS lines of code. Done. End of story.


                    --But to be more clear... Any partial execution of a measurement routine will produce & record updated ACTL and MEAS values.
                    IE: When you --partially execute-- a feature that is dependent on a feature that --wasn't partially executed--, you get weird deltas, like you snipped in your first post.
                    This occurs because the newly executed feature is relying on data that was recorded from a previous instance.... or it produces a null (THEO) reference output because that partial execution has no idea what the dependent feature is pointing to... that feature wasn't executed in that instance.

                    Resolution? There's a few.
                    1: execute routines offline before saving and setting to read only. All ACTL and MEAS values will match THEO.
                    2: DON'T partially execute code unless you are aware of what is stated above.
                    3: If you have a business need to partially execute routines on the regular, implement FLOW controls to automate the process (Input comments, Labels, IF/ END_IF, IF_GOTO, DO/WHILE, DO/UNTIL) etc.
                    Last edited by louisd; 12-05-2022, 05:03 PM.

                • #12
                  Thank you all for taking an interest.
                  It remains my belief though that I can open a program saved an arbitrary length of time ago and construct a feature based on one or more of those previously measured features and the constructed feature will be as expected based on the saved ACTL and MEAS values previously saved in the measured feature(s).

                  Comment

                  Related Topics

                  Collapse

                  Working...
                  X