Messages

Hello,
I cannot comment on Karl's video, but in general you would get 5-axis G-code e.g. from our customized postprocessor in Fusion and then use the provided GH component to import the G-code and to set some parameters to turn it into 6-axis robot code that can run on the robot.
Note that those components are only available to users with a valid membership or license!
Best,
Johannes

Hello,

The way I always interpreted it, DAT files are primarily a way to structure data in a nicer way. So while the overall sequence of commands is in the SRC file, the DAT contains some variables etc. You could e.g. define all your robot positions in the DAT file as E6POS and then call it as PTP VariableName.

I've never used ArcTech but I assume that when you teach a position via the smartPad, it will store some ArcTech specific data along with the position in the DAT file.
But there is no particular "magic" in the DAT file, chances are good that you could just find out the relevant variables and methods and call them from the SRC file as well.

So I don't think just generating a DAT file alongside the SRC file will solve your issues.
To be able to support you, I would need to know with quite a lot of detail what kind of functions you need, their syntax etc. and then I can see if it's possible to integrate it into KUKA|prc.

Best,
Johannes

Hello,
It is not surprising that there is an inconsistency between your harddrive and the robot's RDC, as you applied a new image from another machine. Check out e.g. this thread: https://www.robot-forum.com/robotforum/thread/19810-rdt-data-of-rdc-and-hard-disk-inconsistent-check-robot-data/
I would suggest starting there and then seeing if that also resolves your other problems.
Best,
Johannes

Hello,
XYZ is tricky from the visualization strategy, personally I'd keep it at two axes.
We have got partners with a system with a 5m rail in one direction and 20m in the other and that works fine.
Best,
Johannes

Hello Rene,

I have replied to your other post!
Best,
Johannes

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