Posts by robonovak

Alright, we've solved the problem, and have a good guess at why it happened.

Our PLC, even when we changed our WV project, was writing a TRUE value to $IN[140]. This input is marked as used by the system, and (presumably) controls the activation switch. We didn't notice because we were doing grouping in WorkVisual, 16 bytes at a time.

Solution:

1. Unlink any $IN bits marked with "SYS" in your PLC system

2. Upload WV project without IO linking (we factory reset the robot, but I reckon it doesn't matter so long as the IO

3. Cold Boot the robot.

Not fully sure that this is how to fix it, but we're pretty loathe to start trying to reproduce the error. To whomever reads this next, godspeed.

Howdy all,

Background:

We have a "new" (purchased from Kuka in the last 6 months, not run more than a few hours) KR 500 MT with a KRC4 controller, mounted on a Gudel rail. The robot has been moveable for a few weeks now, and we have been working on linking I/O to an external PLC and getting the safety system up and running to begin manufacturing with it.

Problem:

After a project upload, the pendant began to display the following warning (see pic):

"Enabling switch timeout. Release enabling switch and press it again"

This error prevents us from moving the robot even in "Service > Startup Mode", and cannot be confirmed.

Attempted Solutions:

- We cold booted the robot - the error still exists after restart

- We switched pendants with another identical robot that we have in the shop that runs normally - the error persists

- We reverted to an older WorkVisual project that we keep around to troubleshoot these kinds of errors - it's a minimal project, no I/O linking, that just integrates the rail. The error persists.

Thoughts:

Since we were doing some I/O mapping, a possible guess is that we mapped some high input to a section of the $IN array that is used for deadman switch monitoring? This doesn't make sense, though, as the older project has no such mapping, and the error persists.

Not a lot online about this error that basic search has given me. We have a ticket in with Kuka right now. Any of y'all got ideas?

principemestizo Note that this switch is only possible if you are going to be working at low pressures. If you stick to manual input-output, you should be fine, but if you ever switch to a higher-pressure application, the internal seals of the cylinder's rod will potentially fail.

Hydraulics (seals, fittings, etc) are designed to function at high pressures, while pneumatics are designed to function at low pressures.

I work on both systems - our hydraulics operate at 3000 PSI (low for a hydraulic system), while our pneumatics operate around (I think) 120 PSI.

(Possibly) Related Post: KRC2 X211c/X11 Pinout

Sorry for delay, more critical project swamped me this week.

Cynergy Jake you and I may have similar issues vis-a-vis KRC2 ed05 X11 connections. My (unresolved) forum post on the subject is here: KRC2 ED05 X11 Connector Unexpected Behavior

I haven't looked closely on the cabinet-internal wiring harness that we have installed... I'll have to take a look. I've been a bit sidetracked with more critical projects this week.

SkyeFire

Good things to reference and look for, thanks. I'll go do an inspection of the safety hardware in the cabinets either today or Monday, and peruse our electrical diagrams.

I also intend to systematically remove each of the unknown jumpers on the KR 360 and look for error messages that could point me in the right direction. Will update here once that's complete.

JM212

Quote from JM212

"b'<Sen Type=\"ImFree\"><EStr>Message from RSI Control Server - PPG !</EStr><AxisCorr A1=\"" + x_str + "\" A2=\"" + z_str + "\" A3=\"" + y_str + "\" A4=\"" + "0" + "\" A5=\"" + "0" + "\" A6=\"" + "0\"" + "/><RKorr X=\"0.00001\" Y=\"0.0000\" Z=\"0.0000\" A=\"0.0000\" B=\"0.0000\" C=\"0.0000\" /><IPOC>" + test2.c_str() + "</IPOC></Sen>\n'";

This is not correct, but is closer than the other packet you pitched.

WIth regards to packet format, the format is mostly determined by which ***_CORR blocks you are using in your KRL program. If you have AXISCORR, then you will need the <AKorr ...> subtag. If you have POSECORR, then you will need the <RKorr ...> subtag.

Note: the above is not STRICTLY true - depending on your program, you can structure the corrections within the XML in whichever way you want. This might be easier for you to get rolling, though.

Note: You don't have to supply both cartesian correction and axis corrections. Indeed, I'm not sure what happens if you try to use both at the same time. Nothing good, I expect. The only time I've done this was when I was driving a 7-axis robot - we drove the robot position through POSECORR, and the external rail through AXISCORR.

The IPOC must be an integer that matches the IPOC entry of the packet you just received. Otherwise the link gets unhappy. That might be what you're doing with the test2.c_str() entry, but I can't be sure.

This thread (and my response in it) is relevant to you:

self-developed UDP server can receive xml file from robot but cannot send xml su

JM212 it sounds like you have two problems:

1. Your RSI connection is timing out

Quote from JM212

Signal flow(running): Object ETHERNET1 returns error RSITimeout.

RSI, when running over an ethernet TCP connection and not in IPO_FAST mode, sends a query to your server every 12ms, and expects a reply within 8ms (if I recal). If the response from the server is received outside of that window, the packet is marked as "delayed", and the Delay counter in the next query packet is incremented by 1. When that delay counter reaches the configured maximum count of delayed packets, the link will break.

Workstation PCs are NOT realtime systems, and while they can usually run quite fast, any given process is not protected from being sidelined by the OS task scheduler in favor of a higher priority process. An example of a high priority OS process is a video/audio player, as these tolerate very little delay.

Fixes for this are multiple. You can make your RSI link code faster, or get a faster PC. You can increase the priority of the processes managing the link, or move that component of your system onto a Realtime system.

2. Your Correction Limits are Too Low

Once you manage to get your server to run fast enough to support an RSI link, your corrections are exceeding the correction limits. I know that when using RSI with KRC2s, the solution is a simple ST_SETPARAM() call targeting a ST_PATHCORR object. with KRC4, you're probably gonna have to RTFM to figure out how to increase the correction limits.

Note that increasing the correction limits puts you at risk for horrendous, robot-destroying crashes if you f up. We've implemented our own full trajectory management and build volume monitoring processes for our RSI application, and it wasn't a small amount of work. You have been warned.

Quote from Skyefire #3

You have to close the DRIVES OFF channel, and the External Enabling channels.

I am inclined to agree with you, as the Titan requires that jumper - when it is removed, the drives will not activate. However, the KR360 requires no such connector, and you can activate the drives as normal without it. spoooky . . .

This odd behavior is repeated with the other jumpers you mentioned - it's as if the X11 interface on the KR360 requires different jumpers than the interface on the KR 1000.

SkyeFire you're right, I should have been more specific about the behaviors.

The KR360 jumper came with the robot when it was purchased, I did not build it. The KR360 functions normally with no error messages when the connector shown in post #2 is plugged in.

The EStop pictured with the connector in post #2 does not estop the robot, and no additional messages display when it is pressed. The robot acts as if there is no external EStop.

Wiring Diagrams:

The following are two wiring diagrams of the X11 configurations in question.

KR360 (C13 Bus Board):

Notes:

• Several undocumented pins (13 - 16, 31 - 34, 84 - 85)
• Seemingly no need for "required" jumpers (41 -> 42, 38 -> 50, 39 -> 51)
• Estop shown does not work.

KR 1000 (C13 Tech Board):

Notes:

• Includes all "required" jumpers
• No undocumented pins
• Estop shown works as intended

Hey all,

TLDR:

The X11 safety interface on my KRC2 ED05 controller does not match the cabinet documentation and behaves unexpectedly.

Background:

I have a KR360-2 with a 7th axis and a KRC2 ED05 controller. The robot is fully functional with no error messages, and we have been using it for the past several months. I am trying to hook up an external EStop through the X11 interface, and am following the typical X11 documentation for my controller: BA KR C2 ed05 V5 en (Kuka ID: PB4846).

My warehouse has a KR 1000-F titan with a KRC2 ED05 controller and an X11 interface. I have successfully integrated an external EStop, drives activation button, safety gate, etc. I have some experience with the X11 system from this, and a working system to test out hypotheses.

Issue:

The X11 jumper currently used on the robot is odd - Some of the pin pairs that the manual says must be jumpered are not jumpered, while other pin pairs that aren't covered by the manual are jumpered (further details in posts below). However, the KR360 accepts it without any errors.

When I hook up an External 2-channel estop to the connector (1 -> 4, 19 -> 22), the robot does not change behavior. There is no acknowledgement of the Estop at all.

Hypothesis:

The documentation mentioned above mentions multiple possible C13 boards that could be installed in the cabinet.

• KR 1000: C13 Tech Board (This is the one that works as expected)
• KR 360: C13 Bus Board (This is the one that doesn't work as expected)

According to the documentation regarding the C13 Bus Board:

Quote from KRC2 edition 2005 Operating Instructions

The SafetyBUS p Gateway board is plugged onto the CI3 bus board and connects the ESC circuit with the SafetyBUS p manufactured by PILZ

This implies (to me) that the C13 Bus Board could be modifying the safety system operation. Unfortunately, referencing Kuka's documentation for SafetyBUS Gateway (Kuka ID: FI3663) contains no mention of the X11 interface

To my knowledge, the forums are not the place to ask for Kuka hardware quotes. You can check on

Kuka Marketplace, but will have to register with MyKuka (see READ FIRST...).

Kuka Marketplace doesn't stock every part (it's relatively new), but it looks like you're in luck: 71-040-031

geraldft has a good point here about timing consistency is an important one. I've been working on a system involving a PC running RSI servers and streaming corrections to Kuka robots for a little over a year now, and can say that putting the 12ms server loop on the PC can cause delay issues <Delay D = "#"> when some process pre-empts your server. It might not happen often, but after flying the robots by RSI-wire for consecutive days at a time, you find frequent cases where the link delays and causes issues.

Moving the response loop to a microcontroller or other realtime system is a good solution to this problem, although if you have more higher-level code that can tolerate some delay, you can keep it in python on the PC.

panic mode always a pleasure when the solution is simple, thanks for the help. Turns out, the titan does have 2 RDCs (X02 and X03), with two X32 connectors (X32 and X32.1). Upon attempting to master again, I found that A1-A2 were on X02, and A3 - A6 were on X03.

SkyeFire I knew the titans had the dual-servos (it's why we purchased them, after all), but I didn't stop to think about how that would affect the RDCs. Interesting to note that the mastering divide in servos implies only 5 servos on X03, and 4 on X02. Wonder why they chose to distribute it that way.

Related Posts:

KRC2 will not master all of the sudden

- The solution in this post was to reboot the robot, which did not work in my case.

- Additionally, I am not losing mastering on power-down.

Hey all,

Background:

I have a KRC2 Titan that I am trying to master. The previous mastering was done manually with a dial indicator, and I'd like to do it with an EMT to make it more repeatable (which is critical to our application).

- KR 1000

- KSS 5.6.12

- KTL-Justage-Set 00-109-835 (EMT)

Problem:

The EMT fails to master the robot when it passes over the mastering notch, but only on axes 3, 4, 5, and 6. Axes 1 and 2 master normally.

Diagnosis:

I have performed the following tests:

- Mastered other KRC2 robot axes with this EMT, before and after attempting to master the Titan. This proves to me that the mastering kit is not the problem.

- Mastered A1 and A2 before and after attempting to master A3-6. This proves that the problem is fully isolated to those axes, and not the robot.

- Tested each gauge cartridge plunger by hand with an allen key. This was done to ensure that none of the gauge cartridges were sticky, which they were not.

- Visually inspected the notches on A3 and A5, looking for damage. I found no significant blemishes near the notch on either feature.

- Watched the light indicators on the back of the EMT. The lights indicated that the EMT properly identified the notch (lights switch rapidly when crossing it), but the EMT did not stop the robot and continued to attempt to master until hitting the "distance limit exceeded" error.

I'm relatively confident that the problem is mechanical in nature, due to its isolation to those joints and the fact that the EMT works elsewhere on the robot. Has anyone else seen similar behavior, or have suggestions on further tests to run?

PUNCHLINE: Clean the button contacts where they plug into the backing circuit board.

SOLUTION:

1. Turned off controller and unplugged pendant

2. Removed all screws and separated casing halves

3. Tested traces on button-backing circuit board with pressed and released button

- Sure enough, the "DRIVES OFF" button was functioning normally and the "DRIVES ON" button was intermittently connecting

4. Removed button-backing circuit board, used contact cleaner on both button leads and circuit board insertion points

5. Reassembled pendant, plugged in, tested successfully.

ANSWER: Of course, posting on the forum prompted a coworker to mess around with the system and find the solution to my problems. The answer is some faulty connection in the pendant. If you squeeze the pendant in just the right place, pressing "DRIVES ON" will activate the drives as normal. I'm going to (carefully) take the pendant apart and see if it's just the adapter circuit board come loose.