Touchsense correction problem

    Hi all


    I have a problem with touchsense for a KRC2. I want to make a subprogram where I do my laser measurement with 6 points.
    This works fine, but when I want to put the correction on (CD1,CD2...) in another program it says correction data not found.
    I saw in the manual that the precondition is that the search points have to be programmed. Is it really necessary that the search points are programmed in the same program where
    I want to use the correction? If I program some points after my measurements they shift fine with the correction.


    Any help is very welcome!


    Thx

    Hm... I'm not personally familiar with how TouchSense performs its corrections, but I'm assuming that it performs a Base shift. It may be that the TouchSense subroutine deliberately restores all Base data to the pre-measurement conditions as "cleanup" at the end of the module, in order to be ready for the next measurement. If you can identify which Base data is being altered by the CORR ON inline form, you could create a static Frame variable (in $CONFIG or declared Globally in your module's .DAT file), and copy the shifted Base data into that variable, and then use it anywhere.


    I would suggest opening the CORR folder and chasing the raw KRL code from there. It should be possible to reverse engineer how the correction is being made.

    Thank you SkyeFire


    Here is an example of the correction from my test program that worked.


    source file :


    ;FOLD CORR CD { 1 , 2 , 3 }{ 4 , 5 }{ 6 } CONT;%{PE}%R 1.1.9,%MKUKATPTOUCHSENSE,%CCORR,%VUNI,%P 2:1, 4:2, 6:3, 8:4, 10:5, 12:6, 14:1
    H70(10,VCD1,POS_DUMMY,PA0,VCD2,VCD3,VCD4,VCD5,VCD6,1)
    ;ENDFOLD


    dat file :


    DECL SRCH_TYP_2 VCD1={OPT 1,CAL_MODE FALSE,SRCH_OK TRUE,CAL_VAL 29.0644093,MES_VAL 36.7787666,OFFSET 7.71435738,TCH_RESULT_A 0.0,TCH_RESULT_B 0.0,TCH_RESULT_C 0.0,TCH_RESULT_D 0.0,TCH_RESULT_E 0.0,TCH_RESULT_F 0.0,B_X -0.001953125,B_Y -0.00787353516,B_Z -53.3848877,W_X -0.001953125,W_Y -0.00787353516,W_Z -53.3848877,REF_X 1479.35632,REF_Y 570.715637,REF_Z -842.073181,MES_X 1479.35095,MES_Y 570.709167,MES_Z -849.787537}


    I'm think I have to do something with the vcd value or the offset value from the .dat file.
    I dont have a robot to test now but I find out something I will post it.

    Well, the H70 call is the key. H70 is being sent VCD1 and several other variables, what looks like the search points.


    Okay, pulled up an old copy of H70 I had lying around. H70 calls CORR, and passes it all 6 VCD variables. CORR does... whoo boy, a huge whackload of math. But in the end, when CORR finishes, it stores the base correct in the global variable BASE_CORR. So I would concentrate my efforts there.

    I think so. You'll need to do some careful testing, obviously. But from what I could see of the code in the H70 module, it looks like BASE_CORR is where all the mathematics of the correction function converge.

    I would suggest to make copy of base_corr in search sub program. Because you can obtain a small problem with it if apr catch other base than you were using while searching. But I can be wrong, and it is not necessary.

    There are no impossibles, there are only possibles waiting to be found.

Advertising from our partners