Posts by panic mode

    open #machine.dat and search for $WARMUP_RED_VEL (there are few more variables that follow, such as $WARMUP_TIME=30.0). if you plan to use robot at such low temperatures, you should consider Arctic version, it is made for low temperatures.


    Does anybody know where the various manufacturers have set cut-off points for support in their country?
    Do they still stock/make spare parts?

    i think i heard that Kuka is stocking parts 10 years after product was discontinued.

    questions specific to KUKA should be posted in KUKA forum, not General section.

    without whole program it is not clear how it works. you also do not specify what is it you changed and how.
    if the program uses PRVI_KOS as a direct point, all you need to do is:
    - select program
    - select line containing inline-form motion instruction with PRVI_KOS point
    - move robot to a correct position,
    - press Teach/Touchup

    if the point is computed, you need to find where. The simplest workaround is to add extra line before motion instruction and modify the point, for example:

    XPRVI_KOS.Z=XPRVI_KOS.Z+25 ; add 25mm to Z
    PTP PRVI_KOS CONT Vel= 100% PDAT25 Tool[1]:grp1 Base[0]

    Warning, this will add offset every time...

    to check full program you may need to have everything in place and ready (using all I/O), but before you get to that, check your program in stages (modules) and for that you only need few signals. and that you can have either by setting variables manually (variable monitor or dialog) or writing some code that will produce the signals automatically.

    to manually control bunch of flags, I just use spare outputs (already there, very easy to access and easy to label using longtexts).
    to produce timed signals you can use SPS.

    just inside SPS loop place call to simulator:

    if use_simulation then


    forgot to mention, this assumes that you use signals (should be obvious, why wouldn't you?).
    in simulation, you would declare I/O as variables in the $config.dat:

    decl bool conveyor_on
    decl bool sensor_part_present
    decl bool storage full

    when done with simulation, you would replace that with signals:

    SIGNAL conveyor_on $in[1]
    SIGNAL sensor_part_present $in[2]
    SIGNAL storage_full $in[3]

    ProfiBUS or Ethernet KRL, XML allow you to pass data (position, handshake signals....) to/from robot, for example "conveyor running" is true/false, or "pick position" is 2499.75.

    robot takes those signals and then does something (move there etc.). this motion is something that happens after receiving information about pick position. you may alter that value while robot is moving towards that position (perhaps you specify 2473.18), but the change will be ignored - robot will still go to position it knew when motion started. also communicating such signals to robot does not need specific timing, al it is needed that data arrives, even if robot has to wait for data arrival. in other words, you don't have a real time control.

    for real time control you need RSI. RSI uses tight timing and for example allows external system to act as motion controller.

    you did not say anything about the robot, controller, configuration, installed software or versions, location (country):

    - X11 connectors and wiring are different on different robots (KRC2/KRC4, Standard/Compact, X11/X13/X16 etc).
    - some robots may have SafeMonitoringRange or SafeOperation are installed. depending on version you get more or less features.
    - kuka robots do not include SafetyPLC, there is no place in robot where user may write own safety logic. you may configure existing features or interface to external SafetyPLC.
    - safety standards to be met are not exactly the same everywhere in the world. just because you put cage around robot and wire gate and lightcurtain to X11 (even if correct), it still does not mean that the safety requirements are met.

    What is motor safety input? are you using SBM2?

    it is triggered when DSE does not get reply from power module within 125ms. standard remedy according to manual is to "check DSE and power module. acknowledge message...".

    recovery stick is a kuka usb thumb drive that is bootable. it includes utilities to make an image of the partitions of the robot's hdd. also it can be used to restore hdd partitions from those images. like with any other form of backup, the idea is to create images BEFORE something bad happens.

    sick comes with the manual.
    basically there are two modes of operation: GUI and Silent.

    GUI (graphical user interface) is just menu driven application similar like Ghost, allowing you to choose action after boot (interactive).
    Silent mode requires that action is specified in advance, then when you boot from the recovery stick, it will be executed automatically (not interactive).

    to make configuration run executable that is on stick.

    not sure what do you mean by first. only one sub is executed and that is dependent on bag value

    suppose the value assigned to bag was #orange. then when following code is reached, only sub orange() will be executed others will be skipped: apple(), grape() and asdf() and program continues after endswitch. actually all statements between "case #orange" and next "case" statement will be executed (in this case that is only one line calling sub orange())

    switch bag
    case #apple
    apple() : a subprogram
    case #orange
    orange() : a subprogram
    case #grape
    grape() : a subprogram