hexagon logo
Register Sign in
  • Replies 42 replies
  • Subscribers 23 subscribers
  • Views 1209 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.
  • I'd like to have a way to save/use/recall the transformed alignment from an XactMeasure datum shift.

    Like the "FCFLOC1" alignment was selectable from the available alignments list...
  •               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


    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?
  • 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?

    Hmmm, a little more in depth than what I run into, but I do have to rotate_offset every so often. I've always done it:
    Level
    Rotate
    Set axis origins
    Rotate_Offest
    then Axis offsets. 

    LIGN01    =ALIGNMENT/START,RECALL:ALIGN00, LIST= YES
            ALIGNMENT/LEVEL,ZPLUS,PLN3
            ALIGNMENT/ROTATE,XPLUS,TO,LIN1,ABOUT,ZPLUS
            ALIGNMENT/TRANS,XAXIS,LHA1
            ALIGNMENT/TRANS,YAXIS,LHA1
            ALIGNMENT/TRANS,ZAXIS,LHA1
            ALIGNMENT/ROTATE_OFFSET,45,ABOUT,YPLUS
            ALIGNMENT/TRANS_OFFSET,XAXIS,-2455.516
            ALIGNMENT/TRANS_OFFSET,YAXIS,825.838
            ALIGNMENT/TRANS_OFFSET,ZAXIS,-676.361
            ALIGNMENT/END


    Is that sort of what you are wondering about?
  • 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.
  • In this case the (reverse) rotations need to come first in the order given, then the translations can be applied in any order. I initially tried it the traditional way one would normally do a part alignment (right you are Matt). This didn't yield the results I was after (duplicating the reported measured coordinates). It took a little trial and error running through the possible combinations.

    VPT - this is the wall I'm up against. The FCF reports measured results from one alignment (datum shift) against the pre-existing alignment NOM coordinates. Any alignment will transform an entire feature (noms, targs, acts). The FCF breaks this up and by doing so kinda compares apples against oranges. I can't think of a way to accomplish this solely using alignments. What I'm leaning towards is creating some generic features that when used as datum(s) in an FCF would induce the same datum shift. Performing this inside the dimension would be the safest way to go and leave the integrity of the measured/nominal pairs intact. I think the ideal way would be to use built-in commands if possible. It would most likely result in a cleaner, more repeatable solution. At this point I'm all ears.
  • I first worked on this several months ago and drew a blank but kept coming back. Tried radians - no luck. Tried using the "set" coordinates in different ways - no luck. Tried anchoring to different features - no luck. I know the developers aren't knuckleheads and there had to be some method to the madness. I can't explain why the datum shift values aren't presented in the order used (by me). But it seems to work at least for measured values. The part I had in mind for this came and left long ago. All of what I work on these days are tied to datum structures which don't give me any leeway for shifting things around. Can't say what kept drawing me back. Stubbornness, I would guess.
  • Can't say what kept drawing me back. Stubbornness, I would guess.

    Hehe, been there! Or knowing the usefulness of the function if you would succeed...

    Why I climbed the mountain? Because it's there. Sunglasses


    Tried your luck adressing the devs directly, Gomo?
  • I've though about this a little and I don't think you can apply the rotations as they are reported in a any sequential order - the minute you do one rotation, the figures for the next go out the window (as they all relate back to the original coordinate system)

    I'll speculate that it's simply because they're tiny values in this instance that it's close - which may account for the rounding errors.


    I don't have time to try figure it out right now, but I think this is what you need to be getting your head around.

    https://en.wikipedia.org/wiki/Davenport_chained_rotations
  • If there is a way to get the actual <xyz,ijk> of the fitted DRF, it should be possible to write this to a binary file in the same format as ordinary .ALN-files are saved, and then activate that as an external alignment.

    Caveats: I don't know if those values are accessible and I don't know the format of the .ALN file even though it looks like <some header data><alignment matrix in IEEE double format><another alignment matrix in IEEE double format>


    Edit: Should the datum shift just be added to the current alignment, component by component?
  • I don't know - I may well be wrong with my assumptions!



    I reckon JEFFMAN would be able to figure it out - he's the matrix king!
© 2024 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement