Messages

Sorry, I phrased that wrong - you are right of course that A4 is the missing axis compared to the regular 6-axis version.
If you say that A4 and A6 are doing "the same", does that mean that A5 is 0? Then you are in an area that is a singularity for 6-axis robots. If KUKA shares a lot of code with the 6DOF version, then this might still be problematic with your 5DOF robot.
What kind of movements are you using? PTP? LIN? Axis?

Best,
Johannes

Hello,

But if it is a fivve version, it is missing the sixth axis. Could that be the reason?

Best,
Johannes

Hello,

I've attached a ZIP file with some Rhino/GH files and a Word file with links to the tutorial videos. They were made during the lockdowns, but the general concepts still apply!
Hope that helps!

All the best with your new robot!
Johannes

Hi,

That went better than expected. I'll send you an email with something to test in a minute!

Best,
Johannes

Hi,

Unfortunately that doesn't exist yet. Honestly it is one of the features where I didn't know if anyone was actually using them.
It might be simpler to implement it on the Grasshopper side - I'll check if I can introduce a setting override for that and put together some simple code. But that will take a while to integrate...

Best,
Johannes

Hello,
I recently fixed some issues, send me an email if your issues is still current and I can send you a new build!
Best,
Johannes

Hi Sam,

That shouldn't happen. We had some issues with tiny arcs that the robot controller really didn't like, but those are resolved in the import code. Are you sure that the units are accurate? That would be my first guess - that your file was output in m and therefore the arcs are 1/1000 of their actual size and replaced with lines.
If you can share a file, I can take a closer look!

Best,
Johannes

Hello,

But if you compare the two screenshots you shared, the new model is of much higher resolution?
If you need to go even higher, you would have to define a Custom Robot. I can help with that, if needed. The integrated robots have to take a middle ground between resolution and performance.

Regarding the singularity, you can change the Singularity Factor in the Analysis graph window if it is not sensitive enough. Otherwise I can also take a look at the file - if it's confidential, you can send it to me via email as well, of course.

Note that the goal of the singularity checker is to identify areas where the axis speed is exceeded. Maybe you are going through a singularity but slow enough that it isn't a problem. Are you running the robot at 100% AUT speed? That can also help. Of course you need to be careful so that a proper speed is used, as the robot will try to exactly match the programmed speed. But the robot runs "best" on 100% AUT, compared to let's say 20% T1.

Best,
Johannes

Hi,

You must have enabled the low-resolution robot model in the Advanced Settings - then it will show up nicely again.
There is no real reason to use that unless you are displaying 100s of robots for some evolutionary optimization algorithm.
And KUKA|prc should highlight potential singularities in yellow in the Analysis graph! Please take a look if that matches with your experience!

Best,
Johannes

Hello,

I guess you are referring to singularities, in your case most likely when the wrist (A5) is close to 0, so around when the object reaches the height of the robot?
Unfortunately there is no easy fix, the best levers are to change the position of your work object and the angle of the tool holder. But that only postpones the singularity to another point in the process.

Beyond that there isn't that much you can do, singularities are inherent to the standard industrial robot kinematic setup. Technically you could try to use tightly spaced PTP motions on areas where singularities occur (with a switch in posture where A5 transitions), but I would say that something like this is only useful, if you produce an object many times and you can afford the time to hand-tune everything, with some verification cycles on the actual robot.

Regarding the screenshot: In Rhino, right-click the name of your viewport in the upper left corner of each viewport. Like "Perspective". Then go to "Capture" and select either Clipboard or File. In the next window you can then also set a multiplier for the resolution.

Best,
Johannes

Hi Kailey,

I wrote back with some troubleshooting steps.
My best guess at the moment is that the robot model isn't the right one.

Best,
Johannes

Hi,
Thanks for the detailed description, that is indeed strange.
Generally with a tool like yours, B=-90 is correct, that is what I would expect to work.
Could you please send me your GH/3DM file plus the generated SRC output? Either here as an attachment or to johannes@robotsinarchitecture.org
Then I can take a look!
Best,
Johannes

Hello,
It seems that you created your toolpath once and then shifted it multiple times in Z to create the multiple step downs. I think that is what is causing the tool to move up and down.
I would try the following: that after the "Trim with BRep" component you take the start point of each curve, take it's Z value and then sort the curves according to that. If the order within a layer is critical, you could then sort again depending on e.g. the distance to the center of the element, so that it goes from outside to inside.
Best,
Johannes

Hello,
I just tried it here and it just makes a tiny movement and then goes to the end position.
I've attached my file. How does it look on your side?
Best,
Johannes

Hi Charlie,

The DKP500 just seems to have a different standard orientation than the DKP400. I'll send you a build with DKP500 and the KR8R1440-2 arc HW in a few hours.

Best,
Johannes