Messages

Hello Rene,

Here is a custom robot definition for the ultra version of the robot. Note that you need access to a member version of KUKA|prc to use that file.

Best,
Johannes

Good Morning,
I like to avoid posting KUKA manuals directly, so if you search on Google for "KRC2sr Manual" the first result in my case was a PDF, which had section 1.7.2 Wiring Example X11.
For the X11 you always have two channels, so you need to connect one test output with the relevant input, like the E-Stop and do that twice per channel.
Hope that helps!
Best,
Johannes

Hello,
So the Rhino world coordinate system is always considered to be the flange, therefore the position of your custom tool on the flange is correct.
If you want to use the Z-axis as the tool axis, you can enable that in the settings!
Best,
Johannes

Hello,

Just to put it first, that problem is definitely not related to KUKA|prc.
That being said, it is possible that the robot needs to be mastered. Maybe it was handled roughly by students or maybe by the cleaning crew. Ideally you have got an EMD, the mastering process is pretty straightforward and documented in the KUKA instructions. If you don't have an EMD, then there are some creative things that are also possible. I would definitely recommend taking a look into the documentation to get an understanding of the process, no matter if you have got an EMD or not. If needed, I can provide some pointers!

Best,
Johannes

Good Morning Wyatt,

Ah, thanks for the file, that helped a lot. So in the current implementation, the E0X inputs are items, i.e. they are one per spline. But on the robot side it shouldn't be a problem to have one external axis setting per frame.

I've made a new release that I'll send you separately. It works like that, that components that have previously been put into the file use the old implementation, while when you drag a new spline component in, it should support list input for external values.

I put it together quite quickly, so test it carefully and please let me know if it helps!
Best,
Johannes

Hello,
The spline component's plane input is set to use a list of planes (not a tree), so I'm guessing that one of the other values is confusing Grasshopper. Could you try temporarily disconnecting the VEL and E1 inputs?
Or if I misunderstood the question, it would be great if I could have a look at the file, either here in the forum or via email (preferably internalized without requiring additional plugins).
Thanks!
Johannes

Hello Aran,

KUKA does not support external axes on Sunrise, so we never implemented support for it either.
If you just want to experiment with it for visualization, I would suggest creating a 6-axis iiwa through the Custom Robot component and simulating it like a KSS robot. If you go that route, I can provide you with the geometry (or you just bake it from KUKA|prc).

Best,
Johannes

Hello Honza,

What might be useful there is that you can group command in KUKA|prc (but take care to use the KUKA|prc command and not the Grasshopper Group). Then you could use the normal "Weave" component to combine these into one program, alternating between full brick and half brick. For the optimization, the Analysis component outputs an approximate process time. It is not accurate, but you can use it for optimization, i.e. faster = better. With that you build your fitness function for optimization.
Note that you need access to the member version to access the Analysis component!

Best,
Johannes

I think the most straightforward approach would be to set the XYZABC values via your script and then use them as in the example!
You need to enable the Base option via right-clicking the core component, same goes for switching the Custom Tool - Plane component to accept XYZABC input.
Best,
Johannes

Hello,
Sure, it's just regular KRL, so you can use the Custom KRL command. Just note that it won't be simulated if it's only text in KRL.
Or are you referring by "via code" to something like Python within Grasshopper?
Best,
Johannes

Hello,

The Multi-State Tool is mostly for visualization and some IO convenience. If the gripper has got its own library for operation, I would try to hack that into the Java file. So that rather then setting an output in an IOGroup, you toggle the gripper.

Best,
Johannes

Hello,
When we got started in 2009 we used KUKA CamRob which could process CSV or BIN files, but that doesn't exist anymore. Something similar is possible with the OrangeApps PointLoader, which is pretty affordable, in my opinion, and works with KUKA|prc.
The "best" (but most expensive and by far hardest to integrate) solution would be KUKA.CNC which comes with its own pathplanner that is optimized for CNC applications. So while PointLoader is basically the same as running the KRL file (with problems when the path is spaced too tight) KUKA.CNC improves upon that.
We can also generate KUKA.CNC G-code from KUKA|prc.
Best,
Johannes

Hello Jason,

As you wrote in the email, the HL component only shows up with your license installed. I'm pasting that here as well, in case it helps anyone!

"In GH, go into File/Special Folders/Component folder which should open a Finder window, go into KUKAprcGH and place the license file there as KUKAprcLicense.json (without the university name). Then restart Rhino and it should work!"

Best,
Johannes

Hello Michal,

There are many ways as you have already outlined them. In our work, we added a simulated external axis to the robot, set the extrusion value as E1 and then had a program running on the robot that would send the current E1 value to the stepper. However, you need to ensure that the stepper can follow that fast enough as you are sending absolute position values. You could also get the current speed of E1 and send that to the stepper, which avoids some problems, but at the expense of accuracy.

With an analogue output you can theoretically encode like 16m positions (assuming 24bit) but you will have to cope with signal problems etc. Coupling digital outputs into a signal might be easier.
You could consider getting an EtherCAT Arduino shield, that way you don't need many cables.

And yes, you would probably set the parameters via a Custom KRL component. You'll need to make sure that the values are set in the advance run so that the robot doesn't stop whenever your values change.

Hope that helps you get started!
Best,
Johannes

Hello,

We had such solutions, I believe Tongji University had a gantry setup that we initially supported. We have users with two external axis (X, Y) which works fine, I think with Z it was a bit hacky.

Best,
Johannes