PDAT, LDAT, and FDAT Parameter Definitions

    I can't figure out the shortened names for many of the parameters in these STRUCs. Can someone give a quick definition to each, or point out a reference document that describes them?

    STRUC PDAT REAL VEL,ACC,APO_DIST,APO_MODE_T APO_MODE,REAL GEAR_JERK

    STRUC LDAT REAL VEL,ACC,APO_DIST,APO_FAC,AXIS_VEL,AXIS_ACC,ORI_TYPE ORI_TYP,CIRC_TYPECIRC_TYP,REAL JERK_FAC,GEAR_JERK,INT EXAX_IGN,CIRC_MODE CB


    STRUC FDAT INT TOOL_NO,BASE_NO,IPO_MODE IPO_FRAME,CHAR POINT2[24],BOOL TQ_STATE

  • Go to Best Answer

    can you be specific?

    highlighted ones are basic data types

    REAL = 32-bit number, floating point

    INT = 32-bit number, signed, integer

    BOOL = boolean (TRUE/FALSE)

    CHAR = character (8-bit)

    PDAT and LDAT are PTP and CP motion parameters, store motion parameters for inline form motion instructions (PDAT for PTP motions, LDAT for LIN and CIRC motions, because units are different)

    FDAT is Frame info for some point (tool, base etc)

    VEL = velocity (first derivative, dx/dt)

    ACC = acceleration (second derivative)

    JERK = jerk (third derivative)

    APO = approximation

    ORI = orientation

    TQ = Torque

    EXAX = external axis

    IPO = interpolation, IPO_MODE tells what frame is the reference frame (usually 'stationary')

    suffix _T and _TYPE indicate that this is TYPE of some sort (ENUM or STRUC)

    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

    Opening up BAS.SRC will show you exactly what the system does with these variables. Particularly, which system variables they get passed into.

    Several of these variables either don't get used for anything, are only used for particular special motion modes, or are obsolete but kept in order to maintain backwards compatibility.

    CIRC_MODE is a variable type -- the actual variable is CB.

    POINT1 and POINT2 are not part of LDAT or PDAT -- they're part of BASIS_SUGG_T, which is only used by the user interface to suggest new point names as you create new ILF points.

    Yeah forgive me. I understand the value of investigating, but in most programming languages it's bad practice to have functions, structures, classes, etc without documentation that is completely exhaustive. The system variables document is pretty good but I saw that these structures didn't make the cut.

    There's a divide here -- system variables are an inherent part of KSS, and start with $. It's impossible to remove them from a KRC.

    But these variables are user-space variables that just happen to come by default with every robot -- they can actually be deleted entirely, without harming the operation of the robot. They are only used by the user interface, to support the Inline Forms. It's entirely possible to delete the entire contents of $CONFIG.DAT and still have an operable KRC, you'll just have to hand-program everything in KRL"raw".

    Documentation of these variables seems to fall into this divide -- the KSS engineers are pretty good about documenting the core system variables and functions (with a few, odd, glaring exceptions), but there seems to be an assumption that if you using Inline Form programming, you're working in "amateur mode" and don't need (or aren't interested in) any more detail. So the documentation seems to split into two categories: manuals for people who only use the menus and ILFs and never dig any deeper, and manuals for "real" programmers who do everything in raw KRL with a text editor.

    The good news here is that KUKA (unlike, say, Fanuc) exposes the entirety of $CONFIG.DAT, BAS.SRC, and the other "factory option" files (like IR_STOPM) to anyone willing to dig a bit, and the code is entirely open to being reverse-engineered and even modified.

Advertising from our partners