Recent Posts

Pages: 1 2 [3] 4 5 ... 10
Support / Re: Problem calibrating turntable root point
« Last post by bridgewater studio on April 18, 2018, 11:07:23 PM »
From the turntable manufacturer, we were directed to simply set the A, B, C values to zero for the Root Point using the Numeric Input option. His reasoning was that since the table was leveled, which he also directed us to do, that we were simply rectifying the machine data with the actual table.

I just want to state for the record that his advice was fundamentally unsatisfying. I really want to know why the machine made the incorrect calculation to begin with. I get worried that this is the result of crossed wires in the data cable. It should be noted that this same manufacturer sent us a power cable with 4 of the wires in reversed positions; I had to track this problem down myself, open the cable to expose the leads, reverse the positions of the brake power lines and the mains power lines, and reassemble. It all now works. But that isn't to say that the data cable was wired correctly, which I haven't yet checked and don't know how to check.

All that said, our table and the simulation are rotating in the same direction - initially. I have a gh definition that you had made for one my colleagues here and I modified it so that the generic turntable component matches our turntable location as well as to incorporate some changes I had made to our hotwire tool. With another adjustment to the opoint of the Orient Plane component to get the tool to align correctly, I got CORE to solve and generate code that does run in our robot.

However... the robot still thinks it's upside down relative to the table, even though I zeroed A/B/C as seen in the picture: X/Y/Z are all negative. So when I run the program the robot wants to push the TCP to the positive position relative to the table top, which in this case would be underneath the table top. If I then change the C value in the robot back to 180, the program will execute again, but when I gets to about line 14, I think, it links with the table and the TCP and the table start synchronously rotating counter-clockwise, opposite of programmed rotation. Eventually, the robot hits an axis limit and halts movement.

I fully realize that you're not responsible for our hardware problems, but I'm hoping you might have some insight as to what is causing this or maybe direct us to information somewhere, somehow that will reveal what we are fundamentally missing.

As to our calibration method, I've marked the reference point on the table as (395,0,0,0,0,0) [X,Y,Z,A,B,C] per the manufacturers specification, which is also set in the Axis Configurator in the variable $ET1_PINFL. When I calibrate the table, I first unmaster the table, then master in Dial mode with the table top more or less square to the base and in the location that I want to use it for this project. I have created a tool for the reference point using the same input as the Axis Configurator. I used a previously calibrated TCP with a metal point mounted as the measure tool. I followed through with the procedure lined out inside the Root Point measure tool inside Setup.

The way all of this is setup, I would expect that the positive X direction in the Rotary base for the external kinematic should point from the center of the table toward the reference and the positive Y perpendicular to the left of that vector. In fact, after calibration, using the newly calibrated Rotary1 base coordinate system, the positive X lies in the direction of what I thought should be negative Y and positive lies in the direction of what I though should have been negative X. And as you might guess, positive Z is down into the table. No matter what I do, it keeps thinking the table is upside down.

This is why I thinking we've got crossed wires somewhere, or a secret button wasn't set correctly inside some as yet unseen configurator that no one wants to tell me about.

We just can't make any progress at all because of this problem and I just don't know what else to do.

I've attached the rhino and gh files to see our setup. This will run in our robot, just not like what you see in the simulation.
Support / Re: Problem calibrating turntable root point
« Last post by Johannes @ Robots in Architecture on April 18, 2018, 07:59:05 AM »

Can you check if the positive rotation direction is the same on both the simulation and the actual turntable?
I guess that it might be going in different directions.

Support / Re: Problem calibrating turntable root point
« Last post by bridgewater studio on April 17, 2018, 07:43:53 PM »
I've been simply setting C to 0 in the turntable tool in PRC just to make it work. I'm worried that this will cause everything to flip once I run the program at the robot.

And yes, whatever tool I set, if associate with the external kinematic system, then when I jog the table the robot TCP will stay fixed to the table and jog with it.
Support / Re: Problem calibrating turntable root point
« Last post by Johannes @ Robots in Architecture on April 17, 2018, 06:00:34 PM »

Is the turntable synchronizing correctly, i.e. the robot's tool keeping its position in relation to the turntable when you're moving E1 (in a Cartesian movement mode, after having calibrated and activated an offset base)?
If that is the case we can also simply adjust the turntable model in KUKA|prc. Or you could simply add 180 to -179 and see if that works.
But before we proceed to PRC, it's important that the calibration is right, otherwise we're accommodating a broken calibration through software, which usually leads to more problems down the road!


Support / Problem calibrating turntable root point
« Last post by bridgewater studio on April 17, 2018, 05:52:47 PM »
We've gotten to the point where we're trying to use the rotary table with CAM software, but there's a problem calibrating the root point. I've repeatedly followed these directions, but keep getting a wrong calibration. I've attached a picture of the saved settings.

Correct me if I'm wrong with your directions:

1) Locate table where it is to be used and level it. (I've also mounted a steel point in a small spindle and calibrated a TCP for that to use. I used that steel point TCP to find the rotary center of the table by rotating the table top with the steel point touching it near the center and jogging the tip until I found the center of the table. From there I repositioned the table top to be square with the base. From my homemade table top center point, I jogged the tool tip 395 mm to one edge of the table (the table measures 400mm from the center to closest edge) to make the mark for the Tool Reference Point. I numerically entered this data as (395, 0, 0, 0, 0, 0) (X, Y, Z, A, B, C) as a Tool in the Kuka.}

2) Unmaster External Axis 1 and remaster using Dial mode. (I'm not sure if I need to unmaster every time I move the table, but I have been doing that.)

3) Measure the External Kinematic Root Point using the Tool Reference Point created above using the 4 point method with the calibrated tool already mounted.

Can anyone see anything here that I did incorrectly? I ask because I consistently get a C value of +/- 179°. Why does the robot keep calculating the table to be upside down?

The software we're using to program the robot with the rotary is Kuka|PRC. If I enter these values or any C value like this into the generic turntable component, it flips the table relative to the robot, which won't work. I don't understand what could be causing this C value.

If anyone have any ideas or other sources to find answers, please let me know.

General Discussion / Rob|Arch 2018 Registration is Open!
« Last post by Johannes @ Robots in Architecture on April 17, 2018, 07:48:27 AM »
Hello Community,

We'd like to inform you that the registration for the upcoming Rob|Arch 2018 conference at ETH in Zurich, Switzerland is now open at
It will again consist of 3 days of intensive, hands-on workshops and two days of scientific conference sessions. Both parts can be booked separately, though we of course recommend attending a workshop first and then exchanging ideas and experiences at the conference, with its presentations as well as social events!

Currently there is still "early bird" pricing in effect, it will get more expensive closer to the event. Members of the Association for Robots in Architecture get a special, reduced fee. Send an eMail to with the names of the people who will be attending. We can provide a maximum of 5 reduced registrations per regular member, and 1 reduced registration per student member.

We hope to see many of you at Rob|Arch in September!

- on behalf of the Rob|Arch conference team
General Discussion / Re: BCO Motion Error (1058)
« Last post by Johannes @ Robots in Architecture on April 17, 2018, 07:41:11 AM »
That's great, thanks for sharing the solution! Hibernate saves the current data on the hard drive, so a BIOS reset wouldn't delete it. I've disabled hibernate on all my robots so that they cold-boot all the time.

General Discussion / Re: BCO Motion Error (1058)
« Last post by d2b Design on April 17, 2018, 12:57:04 AM »
Problem solved! We cold booted the machine by going to Configure> Special Functions > On/Off Options > Force Cold Startup. For reference, we're running a KRC2 controller with a KRC1 pendant (it sounds like the options might be a little different on the later versions of the pendant).  The KUKA tech told me that some machines have a hibernation function, so they save certain states during a reboot...I'm not sure why the BIOS reset didn't erase the saved states, but we're up and running now!

General Discussion / Re: BCO Motion Error (1058)
« Last post by Johannes @ Robots in Architecture on April 14, 2018, 03:33:19 PM »
Hmm... I never had that problem, so I'm just making guesses: You might want to check if a button is stuck. That hasn't happened to me ever, but as you tried everything else I would have recommended (the "official" troubleshooting and rebooting, not sure if it's a good idea to reset the BIOS for every error) I'd push the Start plus and minus buttons a few more times with a bit more force, just in case. Also the green button on the back!
Then change into a higher user group and activate the Start-Up mode (where it overrides the X11 safety, but only allows T1), just to see if it changes anything when you run a program.
Finally, go into the safety settings, change something and then change it back, as BCO is a safety-relevant feature maybe it helps.
Last idea: Select a program and then do block selection on an axis movement - could be just the first axis movement, or another one further down.

If that doesn't help, get in touch with the KUKA hotline, they are usually really quick with those obscure problems.
Please let us know what helped!

General Discussion / BCO Motion Error (1058)
« Last post by d2b Design on April 14, 2018, 06:21:54 AM »
Hi everyone,

I just ran into a 1058 Error "BCO Motion: Press Start Plus" and am having difficulty getting our KUKA to run a program again. I successfully ran programs earlier today, and only got the error after running part of a program in reverse.

So far I've:
- checked the robot speed (set to 100%)
- edited backwards.ini, set Implicit BCO = TRUE, and later changed back to FALSE (per the error manual)
- cancelled & reset the program
- rebooted the controller
- reset the BIOS
- remastered the robot

But the error is still there...  :o

Any suggestions would be great!

I'm running a KR250 with a KRC2 controller.

- Dante
Pages: 1 2 [3] 4 5 ... 10