hexagon logo
Register Sign in
  • Replies 42 replies
  • Subscribers 23 subscribers
  • Views 1216 views
  • Users 0 members are here
Options
Related

Alignment from FCF Datum Shift

GomoFazter


I think what vpt (and me) were hoping for was a way to create an alignment that uses the Xact fit shift. There are all sorts of applications for this. Using the available options in best-fit alignment is not the same, because they do not attempt to fit within a tolerance zone.
A few years old but I haven't found anything using search. 

SPH1       =GENERIC/SPHERE,DEPENDENT,CARTESIAN,OUT,$
            NOM/XYZ,<0,0,0>,$
            MEAS/XYZ,<0,0,0>,$
            NOM/IJK,<0,0,1>,$
            MEAS/IJK,<0,0,1>,$
            DIAMETER/1,1.1
DIM LOC1= LOCATION OF SPHERE SPH1
AX    NOMINAL       +TOL       -TOL       MEAS        DEV     OUTTOL
D       1.0000     0.2500    -0.2500     1.1000     0.1000     0.0000 ------#--
END OF DIMENSION LOC1
            DATDEF/FEATURE=SPH1,A
            DISPLAYPRECISION/6
FCFLOC1 =POSITION : CIR152_1,CIR152_2,CIR152_3,...
            FEATCTRLFRAME/SHOWNOMS=NO,SHOWPARAMS=NO,SHOWEXPANDED=NO
              SIZE TOLERANCES/33,DIAMETER,0.375,0.005,-0.005
              PRIMARY DIMENSION/POSITION,DIAMETER,0.01,MMC,A,MMC,,
              NOTE/FCFLOC1
            FEATURES/CIR152_1,CIR152_2,CIR152_3,CIR152_4,CIR152_5,
                                CIR152_6,CIR152_7,CIR152_8,CIR152_9,CIR152_10,
                                CIR152_11,CIR152_12,CIR152_13,CIR152_14,
                                CIR152_15,CIR152_16,CIR152_17,CIR152_18,
                                CIR152_19,CIR152_20,CIR152_21,CIR152_22,
                                CIR152_23,CIR152_24,CIR152_25,CIR152_26,
                                CIR152_27,CIR152_28,CIR152_29,CIR152_30,
                                CIR152_31,CIR152_32,CIR152_33,,
            ASSIGN/V1=GETTEXT("DRF_SHIFTX",1,{FCFLOC1})
            ASSIGN/V2=GETTEXT("DRF_SHIFTY",1,{FCFLOC1})
            ASSIGN/V3=GETTEXT("DRF_SHIFTZ",1,{FCFLOC1})
            ASSIGN/V4=GETTEXT("DRF_ROTATIONX",1,{FCFLOC1})*-1
            ASSIGN/V5=GETTEXT("DRF_ROTATIONY",1,{FCFLOC1})*-1
            ASSIGN/V6=GETTEXT("DRF_ROTATIONZ",1,{FCFLOC1})*-1
            FORMAT/TEXT, , ,HEADINGS, , ;NOM,MEAS, , , , , 
DIM BEFORE= LOCATION OF CIRCLE CIR152_1
AX     NOMINAL        MEAS
X     10.153721   10.154507
Y    -27.402826  -27.405035
Z     -8.032519   -8.025360
END OF DIMENSION BEFORE
ALIGN1     =ALIGNMENT/START,RECALL:PREVIOUS,LIST=YES
              ALIGNMENT/ROTATE_OFFSET,V4,ABOUT,XPLUS
              ALIGNMENT/ROTATE_OFFSET,V5,ABOUT,YPLUS
              ALIGNMENT/ROTATE_OFFSET,V6,ABOUT,ZPLUS
              ALIGNMENT/TRANS_OFFSET,XAXIS,V1
              ALIGNMENT/TRANS_OFFSET,YAXIS,V2
              ALIGNMENT/TRANS_OFFSET,ZAXIS,V3
            ALIGNMENT/END
DIM AFTER= LOCATION OF CIRCLE CIR152_1
AX     NOMINAL        MEAS
X     10.151373   10.152161
Y    -27.394485  -27.396694
Z     -8.041472   -8.034312
D      0.376500    0.377383
END OF DIMENSION AFTER
            COMMENT/REPT,
            "Xshift:  "+V1
            "Yshift:  "+V2
            "Zshift:  "+V3
            "Rotation X:  "+V4*-1
            "Rotation Y:  "+V5*-1
            "Rotation Z:  "+V6*-1

The FCF output with datum shift is:


Using a sphere as the only datum seems to allow all 6 degrees to float. There is some small round-off error due to the numbers being used limited to the current DISPLAYPRECISION (not much).

Now what? Trying to actually use this has me baffled. I'd like to simulate the FCF output having the transformed measured coordinates evaluated against the model nominal values. The BEFORE dim has the nominals I want but the AFTER dim has the measured I want (like the FCF output). Inserting & Recalling alignments, Updating Dependent Commands (answering both yes and no) leaves me feeling like I've found my way into a rabbit hole. Maybe Profile dims behave differently?

I'm aware that some settings may influence the results: Update Dependent Commands (warning), UpdateBelowChangedAlignmentDuringExecution (registry), Ignore CAD to part (F5 settings), Allow Fine Tuning of Alignment (F5 settings). I'd really like to get this working inline without resorting to any type of external automation if possible. Can someone throw me a bone here? There's gotta be a way to get some mileage out of this.
  • GomoFazter,

    I made a test with your code above, doing position of a group of four circles with known errors in location, using only the plane as datum. This means that I got translation in X and Y and rotation around Z.

    Changing your alignment code to the following 

    A2         =UPPRIKTNING/START,ÅTERKALLA:A1,LISTA=JA
              UPPRIKTNING/FLYTTA_OFFSET,X-AXEL,V1
              UPPRIKTNING/FLYTTA_OFFSET,Y-AXEL,V2
              UPPRIKTNING/FLYTTA_OFFSET,Z-AXEL,V3
              UPPRIKTNING/VRID_OFFSET,-V4,OMKRING,XPLUS
              UPPRIKTNING/VRID_OFFSET,-V5,OMKRING,YPLUS
              UPPRIKTNING/VRID_OFFSET,-V6,OMKRING,ZPLUS
            UPPRIKTNING/****


    I got exactly the same values down to the 5:th decimal (showing 6) comparing the FCF coordinate table to XYZ-values of four circles in the new coordinate system.

    If I do ROTATE before TRANSLATE, the error is much larger.

    Note the changed order of TRANSLATE and ROTATE, and the changed sign of ROTATE!

    I still don't know if this approach will be correct when we have more rotations, but it's a lot closer than any previous example in this thread!

    (the Swedish word for END, ****, is replaced with stars by the 'bad word filter')
  • OK, yeah, I don't use Xact measure, so I don't know if this will work or not, BUT, it might be worth a try....

    You want to come up with a usable alignment that matches the datum shift & rotations when you do an Xact dimension of a circle.

    Can you do multiple features for the same Xact dimension callout? IF SO, give this a try:

    You measure the circle, then after you measure the circle, make generic features, using CIR1.HIT[1].X,CIR1.HIT[1].Y,CIR1.HIT[1].Z and repeat for all the hits. Then when you to the Xact dimension, dimension the circle & the hits at the same time.

    This will give you the XYZ shifted locations for all the hits of the circle. Using the THEO & MEAS values of the points, make another set of generic features, then use those for an iterative alignment....

    As I said, not sure if this will work, but hey, it might!
  • vpt - haven't had a chance to do much more with this. Clearly some more poking around will be needed.

    Ninja - I tried different rotational sequences and the X-Y-Z order was the only one that panned out for me. That's not to say other methods wouldn't work (aka AndersI approach). Your link does a great job of explaining why the order is important.

    AndersI - The vectors can be viewed by opening (F9'ing) the alignment. Click the BestFit button then go to the Transforms Tab. Even though the alignment created from the datum shift values is incremental it is based on the recalled datum and initially inherits that transform then builds upon it. So the values on the Transform Tab are absolute in the machine system. I wouldn't think it would matter if the components are done seperately in individual alignments or all together at once in a single alignment. As long as the sequence remains the same so should be the end result.

    I was getting the same accuracy as you are seeing (±20% for the last digit). The example I was working with had a number of 5th axis holes basically all radiating outward from the Z axis. I don't know if the number of free degrees has any bearing on the method used (I wouldn't think so). Kind of hoping all that will come out in the wash and some guidelines could be established. Glad to see you kicking the tires. All I really wanted to do was get the ball rolling.

    I thought of the *.aln file and a disconnect being incorporated between part & cad to reflect the FCF fit. A slippery slope and would only apply from that point onward in the program. I don't think I'd want to go there but you never know...

    Matt - I'll have to give it a try. A goal would be for this to work untouched in a production program. If it would need any 'hands-on' attention for each run the chances of something falling through the cracks increases along with the risk of misreporting part conformance.

    (I wish some of you guys would change your time zone!)

  • Like the "FCFLOC1" alignment was selectable from the available alignments list...

    This is exactly what I'd like to see.

    Sent from my SM-G900P using Tapatalk
  • This is exactly what I'd like to see.

    The FCFLOC1 dimension uses 2 "alignments". The first one (for the nominals) is available before the dimension is created, or can be constructed by the datums used in the FCF itself. The 2nd "alignment" used for the transformed measured coordinates can be assembled from the datum shift values. As far as I know an alignment can't move nominals in one direction or measured values in a different direction for the same feature (noms/targs/acts go along for the same ride). Did you mean to apply the datum shift to only the measured values of all previous features and leave the nominal values as they were? Would subsequent features inherit the same shift for measured values only? I'm trying to get a better understanding of how this might be implemented. It sounds like it could become fairly involved.
  • Shouldn't you do trans_offset before rotate_offset?

    Thinking about it, we don't know the order it was done in the FCF, and if it's done in the order the standard dictates, we have to decode the datums to know it...

    Or am I completely out on a limb here?
    I agree with you anders.

    The xyz ijk offsets aren't a sequence as such they're a final result - I think you'd have to do xyz first then ijk.
    Both of you are right. The translation should come first (per AndersI example) then the rotations. I was hasty in attributing the small "round off" error of millionths I saw to the precision being worked to. Following AndersI's sequence left me with absolutely no difference at all. Thanks to both of you for clearing that up!
  • I think the problem is worse...

    I believe that if we have more than one rotation the order is essential. To know that order, you have to analyse the DRF to see what's locked, in what order. In a complex DRF, the translations may come intermixed with rotations, I don't know - haven't had any time to concoct a complicated test case.
  • I don't think there is a problem. There could well be a learning curve though. I doubt anyone could exhaust all the possible scenarios a FCF could be put through. My original post was nothing more than a technique others could build on. It was never meant as a "plug & play" solution. The whole thing is undocumented (down to the enums used to obtain the datum shift values). I would hope that anyone using the technique has enough sense to look at the results before blindly passing them along. But once a successful implementation is made I would expect it to hold up in subsequent part runs. Like PcDmis itself, the user needs to determine if it is suitable for their application.

    You are right about the sequencing of rotations - it's critical and not commutative.

    I don't mind going out on a limb at times. If taking one step forward means taking two steps back then count me in!
  • AndersI - I did come up with a completely different method to accomplish the same thing without using the datum shift values. It's cleaner and removes any confusion regarding the order of applying (or not) the transformations. Let me get it presentable and I'll have it in the (West Coast) morning. I think you'll find it amusing.
  • The whole thing is undocumented (down to the enums used to obtain the datum shift values).

    Not completely undocumented, as they are defined in the PCDLRN type library, and have rather descriptive names Slight smile

    AndersI - I did come up with a completely different method to accomplish the same thing without using the datum shift values. It's cleaner and removes any confusion regarding the order of applying (or not) the transformations. Let me get it presentable and I'll have it in the (West Coast) morning. I think you'll find it amusing.

    Sounds intriguing! Eagerly awaiting the presentation (although I'll have to wait a day - it's already midday here...)!
© 2024 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement