For Inlineforms 2.0 m/s is maximal in LIN motions. Otherwise usually 2.3 m/s.
Posts by Fubini
-
-
So your question is why is a LIN slower than a PTP with no information on how fast velocities you actually programmed. Difficult. Do not tell what you think you have programmed but share what you really have programmed. Also check if any messages come up and tell us. Try increasing velocity in LIN.
Fubini
-
We are missing a lot of info and honestly I do not quite understand your problem description, so consider
Assuming you need to store the already calculated tool data you can set
TOOL_DATA[<desired tool index>].X = X
TOOL_DATA[<desired tool index>].Y = Y
TOOL_DATA[<desired tool index>].Z = Z
...
and later on call a bas.src function
BAS(#TOOL, <desired tool index>)
from your application. Just study bas.src what it does exactly and it will show you the steps to activate a tool.
Fubini
-
There is no definitive fixed answer to this question. It all depends on your specific application program. But of cours you should be familiar with Status and Turn and be able to react if problems arise from your application and how to handle them. For example if you hit a software limit switch in your application it is usually a Turn issue that needs to be resolved. Even if you do not explicitly state Status and Turn in your application there are rules how the system substitutes them. These rules have been talked about many times in this forum so I will not reiterate them here. Just use forum search with keywords Status and/or Turn and you will find many topics dealing with these two and how to solve problems arising from them.
Fubini
-
Sorry. Can you be a bit more specific. I do not understand what your question is here.
-
Quote
And in other programs I didnt declared these variables though working
In the other programs you probably had a INI fold included at the beginning.Then these values are set using bas.src calls inside the INI-Fold.
The program template you get by creating a new program using the SmartHMI always has a INI Fold you probably did not notice until now.
Thats the difference between the simple user interface using Inline forms and trying to use plain KRL in expert mode. In the first case pretty much all necessary steps are hidden inside the Inline forms and system folds. If you want to use expert programming mode your programs can be a lot more flexible but on the downside you have to take care for everything yourself.
Fubini
-
An the controller is absolutely right: You set the velocity for E1 in line 31 which obviously is after your initial PTP in line 27.
Also you miss out completely on setting the Acceleration on E1 using $ACC_EXTAX[1]. Again the controller speaks the truth.
Fubini
-
Just FYI: 8.7 for KRC5 on the software side of things is 100% identical to 8.6 for KRC4. Only a few internal modifications so that it works with the new KRC5 controller hardware.
Fubini
-
You can not download them anywhere. They are not free software. You have to buy them from KUKA.
KUKA has an office in India, so contact them.
KUKA Customer Service Contacts | KUKA AG
Fubini
-
Then I see three posiibilities:
- The external base measured in the table is not measured correct or the basenumber 17 is the wrong one. The base could be tilted for example. Check if the robob keeps constant position relative to moving base if jogging only the table with active cartesian reference system. $POS_ACT should stand still, $BASE_C move according to the table rotation and you should see the robot tool tip exactly describing the same arc as the table.
- The position of the table relative to robot is not measured correctly. Check extarnal kinematic measurment. This data is stored in $config.dat MACHINE_DEF[2]. See also ROOT part of EK command.
- RoboDk generated positions do not fit. Could be different kinematic models of RoboDksimulated table and real table on the robot. Check both models whetcher they are really the same. Do not only check link lengths but also direction of rotations.
You could also try to use $IPO_MODE = #TCP instead #BASE. This is usually used if you a a fixed tool in space and the robot holds the workpiece. This needs also be considered in correct position generation by RoboDk. But I do not know whether RoboDk offers such a feature as $IPO_MODE at all. Basically it switches the meaning of $TOOL and $BASE and inverts $POS_ACT. From the robots point of you could think about this in the following way: The Robot no longer gets dragged along with the moving base system but pushes the moving base system away from ifself.
Fubini
-
As far as I can see you might not activate a base moving with the table. Line 22 activates a static base. Lookup $bas.src what happens if you call BAS(#BASE, 17). Does a EK get called or not? You could also check if a moving base is active if you halt your programm after line 24 and jog the table with an active cartesian base coordinate system. It should drag along the robot if active. If the robot remains at a hold it coupling of robot and moving base is not active.
If no EK is called I would try replacing line 22 with
EX_BASE(17,2)
or
BAS(#EX_BASE, 17)
Fubini
-
Your robot configuration seems valid. The rest is handled in robot program and $config.dat (setup external base):
And if by any chance you speak German
https://www.roboterforum.de/ro…-den-vel-cp-zu-reagieren/
where exactly the same issues are currently discussed.
Fubini
-
Well I am guessing in RoboDK and on KUKA the external axis are setup differently. But I am very confident the robot behaves exactly as it should given its configuration and its given robot program. Hence I would check if the RoboDK setup is correct.
Fubini
-
In $config.dat you can do whatever you like. Important limitations are part of $machine.dat. If you exceed the machine.dat values you will get error messages when running your programs.
Determining optimal values usually depends on specific tasks and therefore this part of your question is difficult to answer in general. Kuka predetermined values are a compromise between system availability, accuracy and performance.
For example if your load data violates kuka specification your robot will get (due to the inbuilt dynamic model) slower and slower the more kuka specification is violated. Finally you will reach a state where the robot does not move at all because it will no longer be able to produce enough torque to hold this load.
If you want to check out specific load data you can use KUKA.Load package. This package is free of charge and can be downloaded from KUKA.
Fubini
-
I am not suprised that KUKA is not willing to share these info. This is usually treated as company secret by KUKA. I know in the past there have been shared projects between KUKA and other companies or university partners where these data was handed out. Usually the external partner than had to sign a non disclosure agreement. Also in these projects the initiative usually came from KUKA itself by funding e.g. a joint project. So probably you will not have a chance to get the info. As a former long time R&D developer for KUKA dynamics system and trajectory planning algorithms I know this data by heart, but I am also bound by a non disclosure agreement.
-
You only have to change the machine data $robcor.dat and r1
/$machine.dat to the version including the arm extension
Is your robot equipped with absolute accuracy? In this case your pid file no longer fits. This can only be updated by KUKA. Do you need to reach similar accuracy as before?
-
Can you be more specific since you a posting in the KUKA subforum: Are you talking about a real Denso controller with Denso robot or are we talking about the Denso robot arms integrated into KUKA robot controllers in special software versions 7.x (KUKAs small robot solution before KUKA developed Agilus robot types)?
Fubini
-
Ok. So what you meant to say before was: It does not matter what type of reference frame (Cartesian or axis specific) you use in jogging mode the TCP always moves. As said before this should not be the case for Cartesian reference frames and indicates some error in machine data setup. In theory error could be in robot or external axis data. You could rule out robot if you reorient on the spot the TCP without moving the external axis. If robot machine data (and tool data and mastering) are correct the robot should only show a very small drift from its position.
If this test does not fail you can be pretty sure problem is in the kl machine data. And we are back were we started: compare your data with original kuka data.
Fubini
-
? In krc4 you can not jog in t2 so are we really talking about teaching or jogging in here? Do you have a robot program involved or are you only pushing the buttons on the smartpad. Both are inherently different modes of commanding the robot but can be conducted in t1. Again details matter.
-
Sorry, I still have tremendous difficulties understanding your problem description. So did you check machine data compared to original ones from kuka for your kl? I can not do this for you because I do not have access to this kind of info from kuka (no robot or any software available). But if you hang a kl to the ceiling you normally only have to adapt $ersysroot accordingly. All other data can be used with default values from kuka.
Often you can figure out wrong machine data by simple test as well. If e.g. Rat_mot_ax for e1 is wrong program e1 to run 1 m in one direction. How much does the real axis move. Should be 1 m if data is correct.
And btw usually the robot moves faster then an kl. So if you let the robot stretch to let's say 1 m to the left it is usually faster than letting the external axis move 1 m to the left. Just guessing this is one of your remarks above. But this is no helpful info to help identify whether your machine is setup correct.
My advice also draw the external axis frames (see again my post up there somewhere) on a bit of paper and then compare by measuring on the real kl.
Fubini
