Transformation of existing programs, inline forms correction

    Hello everyone!


    KR 8 R1420 arc HW
    KRC4 compact

    Firmware version 8.3.35

    [TechPacks]

    TechPacks=ArcTechBasic|BoardPackage|Profinet KRC-Nexxt|

    ArcTechBasic=1.5.6

    BoardPackage=1.4.0

    Profinet KRC-Nexxt=3.2.4

    So, I've been asked to move the existing welding program to another welding table. The issues with previous commissioning are:

    1) All the movements are PTP, with exception of welding commands

    2) Everything is done with inline forms

    3) The only base used is nullframe, base 0

    Small code sample before my works:

    Code
    ;FOLD PTP P315 Vel=100 % PDAT212 Tool[1]:ABIROB_W300_45 Base[0];%{PE}%R 8.3.44,%MKUKATPBASIS,%CMOVE,%VPTP,%P 1:PTP, 2:P315, 3:, 5:100, 7:PDAT212
$BWDSTART=FALSE
PDAT_ACT=PPDAT212
FDAT_ACT=FP315
BAS(#PTP_PARAMS,100)
PTP XP315 
;ENDFOLD

    What I've done to fix the problem:

    1) Defined new base #1 - Table and used Orange edit option - Position transformation. It seems like the values have been changed properly.

    2) Used Orange edit Block Edit option to change all inline movement commands to base #1 (this didn't work on Welding folds ARCON/ARCOFF.

    3. Cleaned up the .dat file of unnecessary data.


    What my questions are:

    1) I am not able to change ARCON/ARCOFF inline commands to use base #1 using the OrangeEdit Block Edit. If they reference FDAT_ACT = FP1105 in fold structure is it enough to change DECL FDAT FP1105 BASE_NO to 1?

    Code
     DECL FDAT FP1105={TOOL_NO 1,BASE_NO 0,IPO_FRAME #BASE,POINT2[] " ",TQ_STATE FALSE} =>  DECL FDAT FP1105={TOOL_NO 1,BASE_NO 1,IPO_FRAME #BASE,POINT2[] " ",TQ_STATE FALSE}

    2) Is typing over inline form enough? Example:

    Code
    ARCON WDAT771 (1) PTP P1105 Vel=100 % PDAT737 Tool[1]:ABIROB_W300_45 Base[0] => ARCON WDAT771 (1) PTP P1105 Vel=100 % PDAT737 Tool[1]:ABIROB_W300_45 Base[1]

    I remember the first time i worked with KUKA i had some issues with it.

    3) After the changes the points should be defined in base #1, instead of #0 and the inline commands should go straight to the same positions. After that i could use the prepared program to use base #2 which would be another table after definition. Is my thought process correct?


    Everything would be easy without Inline forms. Please excuse me if some of my questions are stupid, I'm fairly new to KUKA - worked with FANUC and ABB mostly. FANUC utilities would do wonders here :smiling_face:

    • Best Answer

    well... it is always a challenge to work efficiently on a new platform. put someone who worked with KUKA in front of ABB or FANUC and it will be no different.

    but anyone should still know how to measure tool and base, enter load etc before writing program. anything less is inadequate.

    about manipulating ILFs by hand:

    anything after semicolon is ignored by robot. it means soemthing to editor but in operation it means nothing. this applies to FOLD/ENFOLD lines as well.

    when i do conversions (any kind, not just KRL), i modify small part using target system, then compare modified file to original then make a script to modify all such instances. then repeat for other ILFs for example.

    if there is a problem, script can be adjusted and just re-run.

    yes this takes time to get working but once the script is complete, it can be saved and used any time and to process many files very quickly and when needed.

    an example of tool for such modification is FnR which is free (http://findandreplace.io/?z=codeplex).

    it has GUI for easy testing and tweaking of each script line. and you can assemble the collection of such lines into a BAT file for example.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    1 and 2) Changing the base index on dat file and inline form manually can produce undesired results. If possible, the best option is drive the robot to ARCON/ARCOOF locations, change the base through Inline forms, and when it ask you about something like "leave the point in the same position", You select "Yes". This way You are informing the system that You want change only the base index, not the physical position itself.

    3) Yes, I agree with You and think this is the best course to do a task like this.

    Thank you for the answers.


    panic mode I completely agree - programs were not done by me, presumably someone without any robot experience. It gives me a headache just thinking how much time they have spent on working with teachpendant. I'm still deciding if i want to fix their mess. I am pretty sure i will need to use your method with the script usage.


    massula The problem is that the person who programmed the robot initially used a couple hundred movements in one routine. Changing it by hand is completely pointless. I guess I will try Panic's method. I kind of find KUKA's target system a little bit fuzzy, however i've heard once you get the hang of it you're set.

    Crmo , I was referring to make this procedure only on ARCON/ARCOFF points, not the complete path, that You changed with OrangeEdit. But now I have a doubt about my own advice. I think this option to maintain the position after change the base through inline forms is available only on VKRCs. No sure if this is available on regular KRCs.

    Quote

    anything after semicolon is ignored by robot. it means soemthing to editor but in operation it means nothing. this applies to FOLD/ENFOLD lines as well.

    does this mean that in the code below only $BWDSTRT=FAlSE to PTP XP510 are valid so i can just skip Base[0] change and tinker with .dat file?

    Code
    ;FOLD PTP P510 Vel=100 % PDAT360 Tool[1]:ABIROB_W300_45 Base[0];%{PE}%R 8.3.44,%MKUKATPBASIS,%CMOVE,%VPTP,%P 1:PTP, 2:P510, 3:, 5:100, 7:PDAT360
$BWDSTART=FALSE
PDAT_ACT=PPDAT360
FDAT_ACT=FP510
BAS(#PTP_PARAMS,100)
PTP XP510 
;ENDFOLD

    Also, there has to be a way to fix this. If it won't be possible then i will just save the points in an array and maybe transfer it to external offline software and just generate the code back again without ILF's.

    yes... but... that means next time someone edits that instruction, OLD values will return as defaults since they are still embeded into comment.


    black is part that is normally always hidden, green is shown.

    note that things after {PE} are default parameter entries for this form. order and number of them depend on instruction.

    in this case:

    1. PTP (motion type)

    2. Point name

    3. not approximated ("CONT" would indicate approximated)

    4. Point name i think (second point if using CIRC)

    5. 100 velocity

    6. don't recall

    7. DAT variable name

    Note, when ILF motion is added to a program, several variables are declared.

    also since values may be spread over more than one structure so there are prefixes to observe:

    xP1 = positional data for point P1

    fP1 = frame data for point P1

    pPDAT1 = parameter data (index does not need to match that of point)

    LCPDAT1 = same as pPDATx but for CP motions (LIN,CIRC) each ILF will use either PDAT or CPDAT is used

    when using approximated motion, coliison detection, additional variables get declared too

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Quote from massula

    Crmo , I was referring to make this procedure only on ARCON/ARCOFF points, not the complete path, that You changed with OrangeEdit. But now I have a doubt about my own advice. I think this option to maintain the position after change the base through inline forms is available only on VKRCs. No sure if this is available on regular KRCs.

    I was talking about this. But it is really VW only.

    So, I managed to get the orange bugger to work like i want it to. I'd like to share with my solution for anyone having similar problems:

    It actually is possible to work only with text and fix the inline forms correctly, preventing them from messing up the file if an operator wants to touch up your point. I wasn't quite sure if it would be a sustainable solution, since Kuka's file format still seems a little bit weird to me.

    1. Taught base #1 and base#2 (welding tables)
    1. Used the old program taught in #nullframe - transfered to base#1.

    2. Transfered the programs to base#2 and translated among the base#2 -tables were not completely aligned.

    3. Deleted the S&T Values, which prevented robot from executing the program in base#2.

    4. Fixed welding process points to match the application.

    Tools used: Winmerge, Find and Replace, Orangeedit. The welding process still needs a few fixes, but that is mostly due to mechanical work. Thank you guys for helping!

Advertising from our partners