Posts by DannyDJ

    Hello, if in the sps is used $POS_ACT, $TOOL or $BASE they in some cases can stop sps from executing. For example when robot is turned on, those variables at boot have undefined values(you can see that by ? mark in tool and base window). Software limit switch you can also write at the start of the robot program, if you don't need to constantly overwriting the same value over and over again.

    If you have KRC4 you can also use files to read data into KRL program, for example also point data(check CREAD,CWRITE manual).

    There is a folder C:\KRC\ROBOTER\UserFiles but i think it is limited to 10MB.

    But one can use also "krl_mount" function to access network drive and read data from there.


    For example one can make E3POS MyPoint[20] point array in KRL and read all points data from 10MB file by using only 20 points for example.

    Usually value of inline points in .dat is stored with X prefix. So if you want to use values from inline form point P9, one should write XP9 in program.


    LIN XP9:ofset

    Konekotor is good. As i told, I have instal another PC, and PC is working fine.

    DC 24V supply is ok, a have measure its output.

    Your answers are really confusing, you said the other PC works on other controller, but not on broken controller(at least what i have understood), and there is no picture on pendant on the screen.


    For PC power is supplied from KPS600 on X7(pins 7,8) connector over fuse F15 that is why i asked according your problem description how did you confirmed DC supply is OK for PC.


    So if PC works on broken take also pendant from working controller. But how did you then confirmed that PC works if you still don't have picture on pendant :/. I'm out and hope you fix what ever problem you have.

    I will check connector. Yes, I swap PC. PC is definitly working on other robot. I have cheked fuses, they are OK. DC supplay is OK. I have asked before, could be problem with supply for drives?

    So have you measured the voltage on X961 connector when you say DC supply is OK? If there is voltage on X961 the other PC from working controller should start also here unless when you plug the X961 in the PC you somehow detach the pin out of connector or is oxided like Panic said. This controller was working OK before this problem?

    maybe KPC PSU is not on. if it is on, there will be 5V or red wires and about 12V on yellow wires on hdd/cd power connectors.

    I also was thinking that, and he said he tried other PC(hopefully tested), KPC PSU is inside the same housing, so if other PC is working on other controller, it should boot also here if there is 27V on X961 connector.

    i thought abut the same but discarded it. if CMOS settings were lost, there would still be some initial info on the screen along with errors. also TS stated that he swapped entire KPC. so i would suspect issue is elsewhere. probably power to KCP or KPC is not on (blown fuse, poor connection...) or KCP background light is gone.

    Yes i agree,i missed the part that PC was exchanged(hopefully with one which has been checked on working controller),but i had also many times issues where just PC wasn't turning on, even if there were power on the PC power supply connector. If BIOS setting are cleared, sometimes motherboard still wants to be turned on (there is no screen on pendant) with shorting PWR_ON jumper just like a regular PC with power ON/OFF button. If everything else is checked and turns ok, i would still try this. Of course if this other PC is working on other controller OK, then issue somewhere else... checking power supply for voltage etc...

    Hello, did you tried and short POWER_ON jumper on the motherboard? Sometimes BIOS on the motherboard is cleared and KUKA PC doesn't start by itself then. After that KUKA settings needs to be applied in the BIOS.

    1st,2nd. You should post the whole code from the sps. What doesn't work? The $OUT[2] doesn't get false when robot is not in home position?


    Or the sps is too slow overriding the signal?

    In my case usually workers are trained to work with GripperTech only for gripper actions. In that way the output is never set to TRUE directly. From the IO display they cannot set the ouputs to TRUE when they are logged by default as the operators and they can only work in that user group.


    For example if you don't have GripperTech you could use the variable overview windows or Variable single window, define new bool variable for locking and let the workers trigger the variable from that window instead of letting them directly switching the outputs on and off.


    Don't let them trigger the outputs directly, they can also trigger some other outputs which they shouldn't.


    Also keep in mind that $IN_HOME(1-5)signal has +-2 degrees tolerance range for each axis, this tolerance can also be adjusted if needed.

    Hello, one way to safeguard from accidentally releasing the gripper from falling down anywhere in the cell is to connect robot's unlock gripper position to the unlock signal.


    For example you can make some $IN_HOME(1-5) signal, and when the robot is not in that specific unlock gripper HOME position, you override the unlock signal, when the robot is in $T1 or $T2.


    Also with option above one can also rewrite a bit GripperTech code in the sps, so that operator gets Dialog message to choose from("Do you REAAALLY want to unlock the gripper?Yes/No") before actually triggering the unlock signal.


    And also if robot is connected to the PLC and all the signals are going through the PLC, there can be also a safeguard code made by using $IN_HOME(1-5) or any other position locked signal along with $T1 or $T2 mode.

    In my case we have centering pins in the grippers and in the base of the robots, so no reteaching of points was needed afterwards.

    As i can remember, even watching the increments and position values on the axes on actual display didn't show any robot movement, while trying to jog out of this position. :wallbash: But i agree with you, there should be some nicer way to fix this problem, rather then dismounting grippers and robots(maybe opening the motor brakes manually), just can't imagine dismounting and mouting the bigger and heavier robot. :hammer1: but there at least at the end you can use release device on motors on bigger robots, but even that i think it is not possible on a new robot like IONTEC.

    Okay, stupid question: I managed to jog my Agilus into a collision that I can't get clear of. Spending 10 minutes just jogging in the opposite direction produced no motion -- the torque fault trips before I can even get 0.01mm of motion to relieve the pressure.


    I've never had this problem with the Big Iron -- they would always jog clear... eventually. But this little bot is completely stuck. Any special tricks for resolving this on a Agilus?

    Hi, I had the same problem once with Agilus robot, somehow due to tight and small space in the cell i managed to jog the sharp corner of my gripper into robot's arm. :wallbash: At the end i had to detach the gripper :uglyhammer2: in order to jog out of this position :wallbash:

    Or try RDP like in this post:



    or open port 5900 and use VNC


    Keep in mind that jogging the robot like with Virtual Pendant is not possible with above options.