Posts by panic mode

    if there is a difference, one can choose to overwrite one with values from another. so it is anyone's guess what happened there. this is why making backups etc is important before touching something. if you are not 300% sure you can restore everything back the way it was, do not make the change.

    going by the label ,this is a KR150 (not KR150-2 etc.) and it is supposed to have a spring type counterbalance. if you posted picture of the actual robot arm and the wrist label, we may offer a tip, otherwise contact KUKA, they can look it up in 2min and no guesswork is involved unless arm was modified after robot left the KUKA factory... such changes used to be somewhat common when changing reach (installing wrist extension) and increased reach normally means derating (lower payload). if such modification was done by 3rd party label would no longer match actual configuration.

    robots are machines and as such require maintenance as everything has wear and tear.

    if you did nothing for a long time, that could explain the problems. for example dead batteries could cause improper shutdown and therefore corruption of any open file(s). so the next boot could be a coin toss...

    teach pendant is a device that serves as point of control but it is not a controller, it is just access point for humans. real robot controller is KRC. teach pendant communicates with KRC (normally) but if there is a problem, teach pendant will only show some very basic info as in your case. since teach pendant cannot exchange data with the controller any more, EStop button that is on the teach pendant has no effect. and that is clearly stated.

    btw image shows that connection is terminated (on purpose) since there ware communication errors. this could be hardware or software related.

    image also shows that to recover one can try turning the mode switch.

    but that's about it - it does not offer much to go on.

    for details you still need to try to see the the actual HMI that runs on the controller (not on smartPad) and this means either connecting external monitor to KRC or doing whatever it takes (rebooting?) until the HMI is displayed on teach pendant again.

    then look through messages that KRC displays (not smartPad). sometimes even messages shown on HMI are not enough. so the best bet is to just collect KRCDiag and forward it to KUKA. that will contain logs (hardware and software) etc.

    well, it is supposed to show that it was added as soon as you go back to it... it looks like something is either wrong with the plugin or file is read only. you can try to edit it manually and then do a cold start with reload files. perhaps post your KLIConfig.xml.

    this is what it looks like on KSS8.5

    have not used KRC5 micro yet but it has a switch. not sure if managed or not. what do you mean it does not save settings? how are you testing? do you mean that added port is not showing up after reboot? if you are trying to ping it from some external node, are you sure you are connecting to correct port? and are you sure you are doing cold boot with "reload files" or merely letting Windows restart?

    should not have touched it. reinstalling software is rather extreme and something to be avoided where possible or at least make two or more forms of backup. (archive and hdd image)

    next check your robot nameplate. all of the listed units are "2000" series but details vary.

    some have different wrist, counterbalance, rotating column or combination of those.

    if you get MADA mismatch, check what is the robot name in RDC (since you have no other backup). make sure to not overwrite data in RDC or you will be just adding problems.

    check robot name in each of the possible MADA for correct one.

    alternatively try to identify robot by mentioned features using robot drawings.

    S = green, Submit interpreter is running

    O = red, drives are off. this is the problem. in T1 drives are enabled by holding enabling switch (deadman switch) that is on the back of the teach pendant.

    R = yellow, Robot interpreter has program selected and it is ready to run... as long as you get drives on.

    can signals should be about 2.5V realtive to V-, so your voltages seem correct...

    also I/O block must end with end-module to terminate the K-bus.

    did you ever cycle power to the bus coupler after configuration? dip switch settings are only read at powerup. if the switches were changed while unit is powered, change will not be immediately active.

    also check your cable. that is not a proper devicenet cable. communication cables have specific impedance and this is matched by terminating resistors. also you only show one terminating resistor... cannot really see resistor value. it is unclear if the cable is shielded and if the shield is properly grounded (no ground loops).

    btw. when cable is wrong type, consider using lowest baud rate.

    as MOM suggested, SWRITE seem to be a bit better than CWRITE and there are more examples, but - this functionality requires overhaul (by KUKA...).

    formatting does not work correctly or as described in the manuals (and i think it never did). an example is %f etc. in fact the very examples for %f do not work. SWRITE is more likely to be convinced to use specified format but this fails too. in general string manipulation is always a challenge and there are special considerations.

    yes... contact KUKA.

    note that separate installer (as was the case with KRC2 for example) is not available. Win and KSS are delivered together as one image containing both C and D partitions in WIM format.

    you need to start by posting details... what robot brand, what model, what OS,... maybe post picture of exchange and groups. in general, reading minds and assuming things are among the poorest way of communication

    robot need to be sized to handle static and dynamic load. before you get robot you can test miter saw and determine empirically working payload and potential kickback when defects etc are encountered. simply accounting for weight of the tooling with parts is not correct, one must also consider the center of gravity relative to flange. KUKA has calculator too called Kuka.Load which is free download. finally you can talk to sales rep and get assistance.

    asking manufacturer for help? heresy... ;)

    recently KUKA finally added support for serial interfaces. but the protocol to exchange data over RS485 would still be something for you to implement unless there is a ready code sample. Normally this would be Modbus RTU but check the product documentation...

    if you are not proficient in KRL, you should make big pass around this option.

    actually the same goes for IO-Link as well.

    so if you ask me, stick with digital I/O...

    KRC4 can have EtherCat I/Os added. the most common solution is to use EK1100+EL1809+EL2089...

    configuring I/O would require use of WorkVisual. this is free software but it need to be installed and configured before use:

    1. need to create profile and import KOP files from your robot controller

    2. need to import device description files for anything 3rd party you are adding yourself and that includes mentioned I/O

    then get backup, get active project from the robot, modify it (add X44 or KEB interface if needed) , save it as new file name, deploy it to controller...

    Btw KUKA does not like missing or extra nodes on Ethercat bus - configuration must match exactly what is physically connected (that includes topology).

    yup, values could be hardcoded or set through variables or be computed in code or some linked sub or function.

    hence there are no shortcuts here.... to optimize cycle one need to understand code and use objective evaluation of improvements (measure things using timers, rather than rely on perceived improvements).

    at the very least use cycle time measurements and make gradual changes to monitor for improvements. but this too may not be enough. even significant increase in programmed velocity for certain move may show no improvements at all if there are other limiting factors.

    in general to optimize motion speed, one need to:

    a) set correct loads (allows PI loops to do their jobs without overshoots and undershoots)

    b) use correct type of motion for each of movements. (PTP for long reposition moves, LIN for short moves where orientation must be maintained)

    c) avoid singularities

    d) use approximation where possible

    e) reduce path fragmentation for some path segment (minimize number of motions)

    f) avoid advance run stop

    g) consider using different motion planner (in general spline type motions tend to perform better but this need to be verified in specific case)

    h) if using search, consider using fast measure interface (X33) instead of regular inputs. or maybe use two stage search (fast search to cover great distance even if not precise, then short but slow search to get required precision).