Messages

That is a question for the KUKA manual, which says:

The following options are available for moving the manipulator without drive energy after an accident or malfunction:
> Release device (optional)
The release device can be used for the main axis drive motors and, depending
on the robot variant, also for the wrist axis drive motors.
> Brake release device (option)
The brake release device is designed for robot variants whose motors are
not freely accessible.
> Moving the wrist axes directly by hand
There is no release device available for the wrist axes of variants in the low
payload category. This is not necessary because the wrist axes can be
moved directly by hand.

Hello,
It depends on what you want to achieve. If your program is called program1 then you can make a "master program" that calls the three programs just via program1(), program2() and program(3) each in a new line.
If you just want the robot to got to $HOME, then use e.g. PTP $HOME in a Custom KRL command. Note that Custom KRL commands won't be simulated in KUKA|prc.
Best,
Johannes

What is shown on the monitor?
The robot might have a problem booting up; it may ask you to press a button to proceed, etc.
The goal is just to do basic Windows troubleshooting so that it starts again. Once booted up, the smartPad should connect as usual.

Best,
Johannes

Hello,
Assuming that you are using a KSS robot, there is no tool with two TCPs. However, you can simply calibrate each tool with a separate tool number and then do a tool change with the Tool Change component.
That should do the trick!
Best,
Johannes

All the best, hope everything works out!
Best,
Johannes

Hello,
If you look at the Iontec documentation that I chose as an example, then you have "Fig. 7-5: Connecting the connecting cables" that shows you the ground connections on the back of the robot. To get the ground connections on the controller, you need to look into the documentation of the controller (not the robot, as the robot may be available with different controller generations).
Best,
Johannes

Hello,

If you go to KUKA Xpert, log in with your account (Basic is enough), look for your robot and click on "Product Information". That brings you to the product page.
For an Iontec, that would get you there: https://xpert.kuka.com/service-express/portal/project1_p/document/kuka-project1_p-basic_AR47164_en
On the right there is "Documentation", then click "Assembly Instructions". The manual is in parts generic, but should get you started. In general, always check the numbers of the plugs and only connect the cables accordingly.

Best,
Johannes

Hello,
That is quite a specific question; at least I personally don't have a lot of experience with IO setup pre-WorkVisual (the software used on KRC4+ robots).
You might be better off asking that in the robot-forum(.com). But try to be more specific, i.e. WHAT is not working. Just saying that you are having difficulties is too vague.
Best,
Johannes

Hello,

The idea of this approach is that your toolpath stays at the same location. Because if you place the robot at the global 0, then the toolpath would have to move in turn. It's not an ideal approach and e.g. when you use a positioner the toolpath has to move anyway. But in my opinion the advantages are greater than the disadvantages.

What you can always do is simply take the meshes and colors of the robot, create a Custom Geometry component and visualize the robot yourself at the global zero point.

Best,
Johannes

Hello Richard,

The nice thing about the iiwa is that you can debug it and step through code like you would do it for any Java software.
So going into the Debug view, setting a breakpoint at that line and then checking which variable is null would be the best approach.

Note that a tool has got a tool name and a TCP, so make sure they both exist. Also, check the IO Group if it exists or set it to null.

Best,
Johannes

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