Posts by cnccreations

  • KRC2 Ed05 USB Thumb Drive No Longer Showing Up

    We have a KRC2 Ed05, KSS 5.6.9

    Today the USB drive no longer shows up when I plug it in to the robot controller.

    • The thumb drive lights up but doesn't show up in in the drive list.
    • If I hit Ctrl Esc (with a ps2 keyboard plugged in) and open My Computer in windows, it isn't visible there either (Win XP on the robot controller).
    • I have tried logging in as exper/admin too with no effect (although the USB drive normally shows up under default user anyway).
    • I have tried all 4 accessible USB ports and multiple thumb drives.
    • I have also tried pluggin in a USB keyboard and mouse, no sign of life from either
    • If I go to the windows device manager, under Universal Serial Bus Controllers there are 3 Universal Host Controllers and 3 USB Root Hubs, all of which show up as working correctly and enabled.

    When I powered the robot up today, the bios came up with a Checksum error / date and time not set warning. I turned it off and on again and it booted up and that was when I noticed the USB wasn't showing up. I powered down and changed the motherboard battery, and that seems to have fixed the bios error, but suspecting this may be related?

    Any help on how to fix, or another way to copy files onto the controller would be appreciated.

  • Load data accuracy?

    Quote from Alfredo Iglesias

    According to what I have learned in Dynamic and Kinematic Robotics (theoretical) and I think it is mentioned by the engineer in the video. The internal models do compensate for the "spring" deformations that occur in each link. That's why I think the engineer says at the end of the video that if you have a robot with a capacity of 120kg and no load or a load of less than 30% is placed on it. Some accuracy will be lost. That's why he then explains that Kuka should be sent to "recalibrate", because they have access to change the Internal Models of the robot.

    Also something interesting that he hints at, which is calibration with a laser tracker, he hints that if you calibrate the robot you can improve it a lot, but you will not be able to access the data from the Internal Model of the robot, in order to leave it even better calibrated.

    That is why I asked you my question, based on your experiences, that you have lost so much accuracy when using large robots with loads of less than 30%.

    Thank you for sharing your experiences!

    Hi Alfredo Iglesias, I think most of what is discussed in the video is relating to "absolute accuracy" optioned robots, which have been factory measured under certain load conditions in a wide range of poses to determine the difference between the commanded position and the actual position of the robot rollface, and have internal compensation for these differences which can then be activated (effectively accounting for spring deflection in the arm sponge/backlash in the gearboxes etc.) and improving the accuracy when carrying a similar load. But the majority of KUKA robots sold do not have this AA option and so don't have this internal compensation.

    Load mastering (adjusting the zero position for each axis depending on the tool load) as SkyeFire mentioned can also be helpful and is something I should revisit since we've added some new tools. The SARCA product sounds interesting too!

  • Load data accuracy?

    Quote from Alfredo Iglesias

    Continuing with this thread.

    Here is a public link to a presentation by a KUKA engineer. It is about absolute accuracy robots.

    https://www.youtube.com/watch?v=dNBQme…ts%26Automation

    I have a question at minute 55:44. According to your experience or knowledge, in robots that do not have absolute accuracy AA.
    Is it correct to assume that working with a tool that weighs less than 30% of the nominal load will bring significant accuracy problems?
    Or is this only considered for AA robots?

    I am not referring to the accuracy error when loading the weight values!

    I have a 240kg payload robot (not AA). With axis 2 tilted forward around 30deg from vertical, and axis 3 approximately horizontal (so robot reaching forward but not fully outstretched) adding 60kg (around 25% of the robots max payload) to the rollface will result in the rollface moving down approximately 1mm (a combination of sponge in the gearbox and flex in the arm). On a non-AA robot, I believe this will be the same regardless of what you set the load data to, as I don't think the controller compensates static positions based on the load. The load ID is important for dynamic movement though.

    And in relation to your original question, on a 90kg payload robot, with a 20kg gripper and upto 20kg part, you could probably program your pick positions/frame with the gripper holding a 10kg part (middle of the range giving a combined mass of 30kg) and not run into any major accuracy issues over the +- 10kg range. Having something to approximate the load parameters based on the estimated part weight would be nice if possible but if your movements aren't too fast and your gripper keeps the part close to the rollface basing it on a 30kg weight may be adequate.

  • KR 210 L150-2 cad model

    Hi DeanG, the KR 210 L150-2 is basically just the KR 210-2 with a 400mm extension in the upper arm (arm length is 1500mm instead of 1100mm) so if you can get a hold of one of the standard reach (2700) models you could easily modify. Also I believe the KR150/KR180/KR210/KR240-2 are dimensionally identical (KUKA used to provide one CAD model to cover all of these) so keep an eye out for any of those (and if you can find the 3.5m reach variant of any of those you should be able to use without modification).

  • KRC2Ed05 to Omron Safety PLC Serial Connection, Submit Interpreter stopping when transferring files

    Thanks hermann that's a good point, I could probably wait for $DATA_SER3==197 instead as the response from the PLC should always be the same length and this would avoid any cases where characters are missing, although the checksum should pick this up. My only thought is this may slow the submit loop slightly, as it is waiting until all the data has been received before it starts processing it, although I suspect the difference is negligible.

  • KRC2Ed05 to Omron Safety PLC Serial Connection, Submit Interpreter stopping when transferring files

    Thankyou panic mode that's a big help.

    I hadn't come across the TIMER_LIMIT function before (but have now found reference to it here on the forum in the hidden functions thread).

    I've added that in and made a few other adjustments, and appears to be working well now. Have gone through several large file copies/moves without any issue. I'll include the updated code below in case it is of use to anyone looking to implement a serial connection.

    Declarations:

    Code
    ;**************Serial Module Declarations*******************
DECL INT CharValue, Handle, Offset, CheckSumCalc, CheckSumRet, SerialFail, I, J, K
DECL CHAR Comma, CheckSum[2], SendString[19], Response[200]
DECL REAL Timeout
DECL STATE_T TX_State, RX_State, CH_State
DECL MODUS_T Modey
;************End Serial Module Declarations*****************

    Initializations:

    Main Code:

  • moveable Bases with a linear axis.

    Hi Henry100

    One other option (using some parts from above too), once you have setup the base frame for the magazing (say setup at position E1=0 and stored as Base3), you could have a separate program similar to the below to store the axis positions for the first point in your pick routines.

    Code
    $ACT_BASE = 3
$BASE=BASE_DATA[3]
PTP  {X0,Y0,Z200,A 90,B 0,C 180,E1 0,E2 0,E3 0,E4 0,E5 0,E6 0,S 6,T 51}
MagPickPosAxis=$AXIS_ACT

    Where MagPickPosAxis is a E6AXIS position declared in the config.dat

    Then for your pick program update the E1 position based on your current positon and do the subsequent moves as LIN_REL. That way your moves are linear, and you avoid having to update every position based on your current track location. And if ever you need to re-teach the magazine base frame you can do so and just run the above code to re-calculate the axis position for your first point.

    Code
    $ACT_BASE = 3
$BASE=BASE_DATA[3]
MagPickPosAxis.E1=$AXIS_ACT.E1
PTP MagPickPosAxis
LIN_REL {x100,y-100}
LIN_REL {z-200}
Gripper_Close()
LIN_REL{z200}
etc.

    Hope this is of some help. Please excuse any typos/omissions.

  • KRC2Ed05 to Omron Safety PLC Serial Connection, Submit Interpreter stopping when transferring files

    I setup a serial link a few years ago (with much research on this forum) between my KUKA krc2 ed05 (KSS 5.6.need to check the rest) and an Omron G9SP safety plc which handles the robot cell safety, some critical functions (not ejecting the tool while the spindle is running, not releasing the ATC when the tool is not in the nest etc) and gives some additional IO. The serial communications is handled through the submit interpreter in the sps.sub file.

    It has been running well EXCEPT sometimes when I'm copying or moving large files between the usb thumb drive and the robot controller it hangs. After this I have to change to T2 (or T1), cancel the submit interpreter then start it again.

    I've included a copy of the relavent sections of the sps.sub file below (declarations and the actual code which runs within the main loop of the sps file). Some of the variables not defined here are defined globally in the config.dat file.

    I added the integer SerialDebug to find where it was hanging, and it's value is 14 so it's on the following line:

    Code
    WAIT FOR ($DATA_SER3 <> 0) ; wait for data in COM3 buffer

    I think basically the copying of large files messes up the timing of the serial port sending data to the Omron PLC. As such, the PLC doesn't respond. As such I'd like to add some sort of a timeout, so if nothing has been received in the COM3 buffer after say 500ms, it skips the receive data section and tries sending again. My first thought is to use a WHILE loop that also includes a small delay and counter to keep checking the buffer, and abort if it takes to long, but would like to know what best practice is given it's in the submit interpreter in terms of keeping loop time down etc. Would welcome any thoughts on optimising other sections of the code too (my background definitely isn't in programming...) or if there is a completely different way I should be doing this. Hopefully the code may be of help to others looking to implement serial comms too.

Advertising from our partners