Messages

Not directly, however with many robots you can also have A4 rotate infinitely, so you could look into that (at your own risk, ask KUKA first for your robot type). On the KUKA|prc side you can create custom axis limits for A4, there is no button for it.

The problem with priorization is that with a given posture and TCP location there really only is (more or less, excluding axis with >360 degrees range) one solution with a six axis robot. Technically with 3D printing you might gain the rotation around the nozzle as a degree of freedom that you can use to optimize certain parameters - but again there is no easy way to tell the robot to reduce A4 movement.

Best,
Johannes

That's great, appreciate the update!!
Best,
Johannes

They are beautiful!!

Have you tried lowering the $VEL_AXIS_MA[n] value where n is the number of your axis?
You can set it in the R1\Mada\$machine.dat file.
That value cannot be changed in the program, but using $VEL_AXIS_EXT[...] you can set a percentage value (0-100 of $VEL_AXIS_MA[n]) as a Custom KRL command in the program.

Best,
Johannes

Hello Mark,

The Custom Turntable component allows you to define a custom turntable geometry and the associated rotary axis position and speed. It won't change anything directly relating to your code generation.
What problems are you tackling at the moment?

Best,
Johannes

Hello,
There is no need for a .dat file, no worries.
Usually the .dat file contains variables, positions etc. and the .src file the program itself. But in most cases it's not necessary to have both .src and .dat file, you can also fit it into the .src file, as we are doing.
Best,
Johannes

Not really, the simulation slider is relative to the calculated simulation time, and the simulation time is only a rough approximation. You could use the Tag component or the Custom KRL component to add some comments into the file. Or you add a variable that you increment, that way you can check the state when it was last written, even if the program is cancelled.

Best,
Johannes

Hello,

Sorry, but I would need to see the file to do any troubleshooting, then I can debug it and see where the error might be.
Was the KRL file generated by KUKA|prc or somewhere else?

Best,
Johannes

Hello,
I'm not sure if I got the question right, but KUKA|prc by default puts larger programs into a fold, which is like a folder in the SRC file. You can use Open Fold so that it expands and the little arrow will show you where the robot is at the moment. Is that what you are looking for?
If the program is not within a fold, we got weird problems in dense toolpaths where the GUI would lag behind the robot.
Best,
Johannes

Hello,

I had a look at KUKA Xpert and the KR500 570-2 PA model links to the standard KR360-500-2 CAD file.
So if the robot is identical, you can use the existing KR360-500-2 model already included with KUKA|prc.
Only the speed values may be off, but that is not critical as the speed is not very accurate in any case.
To double-check, make a simple file with a Cartesian PTP movement, have the robot move there and then compare the Cartesian and Joint values between the actual robot and the simulation.

Best,
Johannes

Hello,
At the moment it is not available. We can try to implement it, but it will take a while. If you need it soon, you can use the Custom Robot component yourself. Just mesh the robot, divide it into the separate joints and then MeshReduce it to below 10k vertices per part. Please refer also to the example, if you go that route!
Best,
Johannes

Hello,

Checking toolpath collisions is currently not possible, as toolpaths are generally not a collision risk. I understand how for additive processes that may be relevant, but it would be necessary to generate a specific collision mesh for every simulation step along the toolpath - plus somehow differentiate between printing and non-printing paths.
So at the moment, I don't see any way to efficiently implement that functionality...

Best,
Johannes

Sorry, I must have missed that message.
For that I would just define a safe axis position somewhere and do the rotation there.
If you really need to rotate it by itself, you could use a Custom KRL component. However that movement won't be simulated in that case.

Best,
Johannes

Hello,

I'm not 100% if I understood it correctly, but what you are doing is rotating around the Z-axis of your tool - see the video attached.
If you want to rotate around the global Z-axis, then you need to modify your cluster. Currently you are taking the Z-axis if your target plane. Just use Unit-Z instead and select a suitable center point for your rotation.

Also: Your tool mesh has got 500k vertices. Performance will improve a LOT if you use ReduceMesh and get it down to 10k vertices or so.

Best,
Johannes

There really is no universal answer, a challenge is always getting data into an industrial system from small microcontrollers. For us, add-ons like an EtherCAT hat, have worked very well with KUKA robots, without requiring you to purchase any extra tech packages.

Best,
Johannes

Feeling old ;)
But it was just using GH components, which made it somehow interesting to modify and play with. But pretty slow.
If you go deeper into scripting, take care that KUKA|prc wraps its classes into GH-specific classes for transport within GH.
Attached is a simple example!

Best,
Johannes