Posts by panic mode

  • KUKA: Effect of Ethernet IP tag link communication on CIP communication

    do the math... or check it with Wireshark


    the amount of traffic due to EIP is low. and CIP safety packets are also small and far apart - RPI is some 25ms or so. for Ethernet port those 25ms is an eternity... it can send and receive many messages every millisecond so utilization due to EIP is low.


    in fact so low that same KLI port is used for many things including EKI, RSO, FastSendDriver etc.

  • GripperCheck on KRC5

    the equal sign is not used correctly....

    single equal sign is used for assignment, for example:

    Code
    nGripper_Act = 666


    double equal sign is used for comparison, for example

    Code
    IF nGripper_Act==666 THEN
    ;...
ENDIF

    sometimes both are used in same line of code:


    Code
    $OUT[666] = nGripper_ACT==666


    which is just a short form of


    Code
    IF nGripper_Act==666 THEN
  $OUT[666] = TRUE
ELSE
  $OUT[666] = FALSE
ENDIF


    GRPg_SetStateAndCheck is a subprogram and normally it should be in some SRC file that is part of your version of GripperTech


    GRPg_Check is a function and also should be part of that SRC.



    When calling subroutines (subprograms or functions) one may need to pass parameters. those are the values that you see between brackets after subroutine name. Depending on declaration of the parameters, this may or may not be omitted, may or may not be a literal and may or may not work with your variable (Depends on scope of your variable).

    order of parameters must be followed and if one does not want to specify value for one of them, then leave it empty but keep commas since they are used to determine order and place of parameters.



    Example:


    MsgNotify("Hello") ; one parameter

    MsgNotify("Hello",) ; two parameters but only first one is given value, the second one is empty

    MsgNotify("Hello", "MyProgram",,,12345); parameters 3 and 4 are empty, all others are initialized by a literal


    literal is just a hardcoded value.

  • Torque mode Kuka

    SET_TORQUE_LIMITS is what you need. just set it before issuing motion command to move to a transfer position where it is waiting. what is the message that you get and what are the values for MAX_VEL and MAX_LAG? are you sure you are not exceeding them?


    KRC may apply brakes after couple of seconds of idling. if needed you can change that in WoV project so that brakes will remain open even if robot is waiting (as long as drives are on).

  • KUKA KRC4 AB PLC COMMUNICATION

    the message suggests that KRC is setup as scanner (master) and expects PLC to be the adapter (slave).

    then it tries to talk to the slave (PLC) and finds that PLC is made by KUKA(121) instead of AB (1) which does not make sense... so it aborts.



    creating connection starts by determining role of each node.

    one node must be a master, the other node(s) must be slave(s).

    usually robot is the slave and PLC is the master (when CIP safety is involved, it must be like that).


    master configuration required EDS for each of connected slaves. \so your PLC project will need EDS for KRC (and not the other way around).



    if you do want PLC to be the slave and KRC to act as a master, no problem.

    in that case KRC configuration must use EDS for the PLC (not a KRC) and PLC will have no idea about KRC (PLC project will NOT have EDS for KRC).

  • KUKA Robot for Welding

    that makes no sense - is way too broad... you did not even mention type of weld process: arc weld, spot weld, friction, steer friction, ultrasonic, laser, soft weld (solder), cold weld.... they use different hardware, software, robot types, options etc.


    next, it is also unclear what type of help you need. just selecting something or also configuring (tool changers, positioners, linear rails, turn tables...)

  • Kuka KRC4 Unable to connect with CompactLogix PLC

    what are the used network settings? can you ping all nodes? if i understand correctly you did some setup on the PLC side but did you do the same on the robot side? does your robot have EIP option? which version? what KSS? what is the exact controller type and which physical port you are connecting to? KRCs use managed switch and it is important to connect to correct port. also beware of changing KRC network settings (see pinned topic READ FIRST) - make sure to use IP address that is not in reserved range and before making any changes, it is a really good idea to collect full backup image of the controller.


    on the robot side you would want to:

    1. make sure EIP option is available

    2. KLI interface is configured correctly

    3. WorkVisual is configured correctly (including integration of KOP files and any device description files that project uses)

    4. active project is transferred from KRC to WorkVisual

    5. save copy of the project then also save it under new name (this will be one to modify and send back to KRC)

    6. if EIP bus is not part of the project add one

    7. enable first of five EIP slaves and configure it.

    8. map IO

    9. compile project and deploy it, then activate it


    additional steps may be needed if using CIP safety.

  • Sensors for Detecting Contact with Product

    Quote from pdl

    Collision guard is never quick enough. If your payload can play inside the limits, I've had good success with these.

    I like them too. different versions exist (spring, magnet, air). The ones i used are all working with air.

    Just keep in mind that result is different:


    Using these devices is simple. Collisions are not avoided although contact damage is dramatically reduced. The downside is that abnormal cases end up in the collision, production is stopped and human intervention is needed..


    Using sensors one can avoid contact at all and use predefined behavior. When implemented correctly, this can continue to operate completely on its own, without need for human intervention. Creating robust solution using only sensors and software can be challenging.


    The most flexible setup would use both...

  • KUKA HMI ERROR

    sounds like intermittent connection...

    and you already replaced smartPad and KPC.

    but did you check if KPC is operational during outage?

    you can check this by using external monitor or trying to read project using WorkVisual etc.

    if KPC is operational, you can rule out power problem (X961).

    next thing to try is replacing CCU and/or X19 interface.

  • Tracc TCP

    that is good.

    can you please state software versions?

    is this a new installation or it is something that was working before?

    if it is new, i would say to follow the manual to ensure correct setup.

    if it is something that used to work, maybe sensor location or tool data was changed.

  • Tracc TCP

    which is supposed to mean what exactly?


    i am no welding expert but pretty sure that Fronius CMT is also available for twin.

    so why not simply answer the asked question - is your tool shape really cylindrical or not.

    if i recall Tracc does not work with tools that are not round

  • Kuka Downloads (software, cad...)

    of course not...


    as mentioned before this is not matter of creating link, it is a matter of finding host, creating account, transferring large files, then creating links etc.

    that is a burden that i do not have time for or money to have files hosted permanently (all free accounts expire).


    if you need help with getting one specific file, you need to be specific. maybe someone can find the time to do this for one file.

  • Interrupt not working when program is stopped

    the operating systems changed several times and so did resource management. just the Windows grew from Win95 to Win10 and that was not a single step. KSS went through many more releases (KSS 3.x 4.x 5.x 8.2.x 8.3.x 8.5.x etc ) and each of those major versions had many versions (about 50 or so in KSS8.3.x alone).

    of course many things will be compatible but - there will be some changes as things evolve. using reference document for KRC1 to form expectations for KRC4 or KRC5 is a bit of a stretch. modern KSS versions have very different allocation of resources. for example now there is a multisubmit and CPU quotas, a clear sign of things done differently.


    but regardless of KSS version, the way like to think of programs is simple:


    any instruction in a program is ONLY exectuded when that program is processed by an interpreter. and interpreter can ONLY process instructions while it is enabled. for robot program interpreter that means (among other things) that RUN button is held pressed while in T1 mode.


    anything else is a fringe factor and therefore may not be guaranteed. therefore i would not like to do it the way you want even if was working on KRC1. if you expect controller to react to some events when robot interpreter is not running, do not put that code into robot program - put it in a program that runs continously (Submit). Then you can be sure that events are captured no matter what. Then your robot program can process them as needed, whenever robot program gets to run.

  • Incrementing value in signal declaration

    that is not enough, for 10 positions you need to declare and copy another 54 signals....

    but that would eat a lot of IO. for 10 positions, each with 6x 32bit that is nearly 2000 I/Os...


    but if using index, there should be a way to handshake which position is being transferred right now. for example PLC can present XYZABC values and also tell you position number that is value represents (1-10 or whatever) and it can wait until robot replies. for example robot can echo back to PLC that index value which could be interpreted as "this position is received, send another one", then PLC can change position values and index until all are transferred. then keep index at zero to indicate it is done (nothing to transfer at this time) .


    Code
    SIGNAL fPLC_pathPlan_x_1 $IN[225]  TO $IN[256]
SIGNAL fPLC_pathPlan_y_1 $IN[257]  TO $IN[288]
SIGNAL fPLC_pathPlan_z_1 $IN[289]  TO $IN[320]
SIGNAL fPLC_pathPlan_a_1 $IN[321]  TO $IN[352]
SIGNAL fPLC_pathPlan_b_1 $IN[353]  TO $IN[384]
SIGNAL fPLC_pathPlan_c_1 $IN[385]  TO $IN[416]


SIGNAL IndexFromPLC $IN[416] TO $IN[419] ; 4 bit is enough for positions 1-15
SIGNAL EchoIndexToPLC $OUT[416] TO $OUT[419]; 4 bit is enough for positions 1-15


    and


    or


    Note this assumes that PLC keeps track of which positions need to be transferred and if the transfer of all relevant points is complete - They do not need to be transferred in certain order, it is possible to skip some range or only transfer specific few.

  • Sensors for Detecting Contact with Product

    such applications are usually running at top speeds so i would look for a way to detect the product before making contact. this way it is possible to make a decision and react early, long before before product is reached.


    various sensor technologies exist and some may not apply. for example:

    contact sensing is possible with LVDT etc but this adds cycle time.

    inductive is short range and may not work on plastic or cardboard containers.

    capacitive is also short range but can work on non-metal targets.

    optical is longer range but one need to be careful in selection to avoid issues with clear plastic of reflective materials.

    ultrasound should work well, it is also longer range. the only thing to keep in mind is that when more than one sensor is used they need to be synchronized to avoid interference/false signals.


    if you really want contact sensing, maybe add an air cylinder and pressure regulator to adjust contact force. robot can extend the cylinder during approach to feel for obstacles. once it is clear that there is no obstacle, it can be retracted. sensing could be done by a reed switch attached to the side of the cylinder (extended position) or also by a pressure sensor.