post processor kuka krc1

    A photo of a program gives us no information to work with. Post the actual program code. Also, we need to know exactly what the error is, and which line(s) of the program are generating the error(s).

    Hi Guys,
    We are addressing that specific problem on our own forum.

    We simply didn't have a post processor for the KRC1 as we never had any user using that specific controller.

    They just sent us an "Example program", we should be able to create the KRC1 post pro starting from there.

    Thanks.

    RoboDK - Simulation and Offline programming software for industrial and collaborative robots.

    Visit us at RoboDK.com
    Take a look at our tutorial videos on our YouTube channel.

    Hello, thanks for share it.

    Depend of the version of KSS is how to change the postprocessor.

    Will be better if you can shared pictures about the errors showed in the kcp. i can imagine errors about the base frame and about the

    initial conditions

    best regards

    in KRL arrays start with index 1. therefore this makes no sense:

    BASE_DATA[0] = {FRAME: X 0.000,Y 0.000,Z 0.000,A 0.000,B 0.000,C 0.000}

    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

    Well, this is a really really bare-bones example, from a KRC1 circa 1999-2000.


    Really, though, a KRC1 program should look almost exactly like a KRC2 program, except that some of the more modern elements of KRL are missing.


    Also, instead of posting photos of the pendant, why not actually post the .ERROR files? That would be far, far more helpful.

    Can't remember if that's relevant on KRC1:

    - The filename is move2 in the source the name is move1

    - emtpy line between first line "&ACCESS RVO" and declaration "def move1()"


    Don't post Word Documents, post the real source, without any conversion.

    In any version of KRL that I'm aware of, the DEF or DEFFCT name of the subroutine/function must match the filename. And in KRC1-era KSS versions, that is the only "sub"routine allowed inside the .SRC file.


    So, if the Module name is MyModule, this creates (normally) two files: MyModule.SRC and MyModule.DAT. In the .SRC file, the first 1-3 lines are usually "properties" that start with the "&" symbol -- these are not usually visible on the pendant, but are visible when the file is opened in a regular text editor. I don't think there's any issue with deleting/omitting these lines, but I don't think I ever experimented with that on a KRC1.


    After the & lines, the first line is the DEF line. And the DEF line must match the module name, as follows:

    Code
    &ACCESS  RVP
&COMMENT
DEF  MyModule ( )
.
.
.
END

    Everything between DEF and END is part of the executable. Nothing is allowed past END (at this KSS version).


    The parentheses after MyModule can be filled with various arguments for passing from a higher-level program. But generally, any "top level" program will not have any arguments.


    DEF/END can be replaced with DEFFCT/ENDFCT, but DEFFCT must be declared as a function/variable type:

    Code
    DEFFCT BOOL MyModule()
  RETURN TRUE
ENDFCT

    Unlike a regular DEF/END routine, if the program pointer hits an ENDFCT, the program will crash. The last executable step of a function should always be RETURN "something", where "something" is a value or variable that fits into the DEFFCT "type" of the function.


    Based on my backups from KRC1s of that era, the MyModule.DAT file should be fairly simple: It has the same & properties as the .SRC file, then it starts with a DEFDAT MyModule, has various variables, and ends with an ENDDAT:

    Code
    &ACCESS  RVP
&COMMENT
DEFDAT MyModule
DECL BOOL MyBool = FALSE
ENDDAT

    At KRC1-era KSS versions, I believe it was not possible to call other modules without adding an "EXT" linkage to the .DAT file, like so:

    EXT BAS (BAS_COMMAND :IN,REAL :IN )


    In more modern KSS versions, the "top" routine of any module is inherently global and can be called without an EXT linkage. KSS 2.x did not support "implicit" linking, all links had to be explicit.

    I attached an improved version of KUKA KRC1 DAT post processor for RoboDK.


    The sample files provided by SkyeFire are very helpful. I believe there needs to be 2 spaces between EXT and BAS in the declaration section. I also removed additional data that I believe it was provoking errors (POINT2[] " ",TQ_STATE FALSE).


    Also, as panic mode suggested, I made the default BASE_DATA index 1 instead of 0.


    bastien diligent , I would recommend the following:

    Test a program with joint moves only (MoveJ)

    Test a program mixing joint and linear moves, also changing the TOOL and/or reference frames.


    If you see any issues, please post the original program files (SRC and DAT files and error messages). It would also help if you can provide the modifications you had to do to make it load on the controller.


    Please let me know if it works and we'll make it an official post processor in RoboDK with our next release.

    Hello,


    I have one KC1 cabinet with a KR150, and krc1 panel.


    Can you send me or do a video YouTube, for i can see how you do one program, post processor and the simulation on the robot ?


    Thanks

    I try RobotDK today, on a Kuka KR150/2 with KRC1.


    The service.dat service.src files's skyfire transfer by floppy disk work fine.


    now i transfer a dxf after i had install dxf2gcode in the good repertory of RoboDK, the transfer is ok.


    When i simule the program all work fine but when i generate the program with the krc1 post pro send by nubi i have error of compilation.


    Like the soft is blocked on another files .. ?


    Have you try this post pro ?


    Thanks


    Jeremy DM

Advertising from our partners