The problem is solved. Thank you again, panic mode for your help.
panic mode: sorry for editing your post, just fixed the link...
The problem is solved. Thank you again, panic mode for your help.
panic mode: sorry for editing your post, just fixed the link...
Panic mode, thank u very much for your help. It works...
The right parameter is $ET1_TFLA3={X 1250.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
But I have one more similar problem. We have almost the same robotic cell with one small difference: the robot titled 15 degrees forward as it shown at figure. I thought that it would be easy to configure exernal kinematic for this case, because, as I was sure, the only difference in settings is changing angle B from 0 to 15 degrees (figures 1 and 2). But it was far from it. The system's performence is not good under these settings. You can see it on the video below.
Can somebody tell me, what is my mistake? I can't understand
Quotewhere did 1600mm for $ET1_TPINFL.X come from?
$ET1_TPINFL.X = 1600 it's real offset of the robot mounted on the flange of the E1. 1250 - it's an example from documentation.
Can I ask clarification question?
From your first post I see, that the offset of the robot on the flange of the E1 positioner is $ET1_TPINFL={X 1250.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
From the example at the figure 5.jpg of the original post this is $ET1_TFLA3={X 1250.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
Also from documentation about configuration of kinematic systems:
$ETx_FLA3 defines the offset and orientation of the robot in the FLANGE coordinate system of the kinematic system and is always taken into consideration.
What is right, $ET1_TPINFL.X or $ET1_TFLA3.X?
Thanks, panic mode...
Should I calibrate the robot as the robot mounted on a linear unit after making change?
And, should I change the parameter $axis_type[7] in machine.dat from 3(ROTATORICH) to 1(LINEAR)?
After making changes in machine.dat (EX_KIN $EX_KIN={ET1 #ERSYS,ET2 #EASYS,ET3 #EBSYS,ET4 #NONE,ET5 #NONE,ET6 #NONE} and FRAME $ET1_TPINFL={X 1600.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ) Z direction of the robot in the world coordinate system became horizontal
When I'm rotating E1 axis in world coordinate system, robot is moving too, changing the TCP, actual position doesn't change.
Hi, guys,
We have the robotic cell, which comprises three axis E1, E2 and E3, and KR 16L6-2, mounted on construction driven by E1 axe (figure 1 in the attachment).
If it's possible, we'd like to calibrate the system so that it worked like the system with a robot on a linear unit.
Some people say that it's possible to do so and as a hint sent me figures ( figures 4 and 5 in the attachment).
But, as I was said, this configuration is for KR C2. We have KR C4 system.
We tried different cell configurations by Work Visual (figures 2 and 3 in the attachment), but it doesn't work.
Tell me please, is it possible to calibrate such unusual robotic cell?
And may be somebody has M-410iB/450 and M-410iB/300 maintenance manuals?....Thank u very much in advance...
Hi, guys...
I know, that no more copyrighted fanuc staff allowed on the forum, but has somebody maintenance manual for M-410iB/700?
Hi, NoMad. Thank u for the answer.
Where can I find this file? Now I'm trying to find it in the archive from the robot controller, but there is no file with the extension *.kxr
He everybody.
Can somebody tell me how to use my native language for comments and messages in KRL program language? My native language is Russian. Is it even possible?
The problem was solved by upgrading ArcTech Package.
After upgrading it was available to use spline blocks as arc program operators. Shaking during oscilation disappeared.
Hi, guys...
The problem is solved.
I'll write later about it, because I'm very busy now.
Thank u all very much for trying to help me.
If we set the combination of parameters as ORY_TYP=#CONSTANT and CIRC_TYP=#PATH, the robot works perfectly.
But there is a bug, as I think, in KUKA software, because I can't set CIRC_TYP as #PATH through inline form of ArchTech Basic technology package. CIRC_TYP=#BASE on default in .DAT file. So I changed that parameter in .DAT file of the programm by myself.
The second problem is when motion parameters initialize (BAS(#CP_PARAMS, ATBg_BAS_VELDefinition)), the parameter CIRC_TYP isn't transfered .
So, if you even change CIRC_TYPE in .DAT file, it will not help. The problem is in BAS.SRC. If we want, that CIRC_TYP was transfered during initialization, we should add a pair of lines to BAS.SRC as it shown at bas.jpg.
The solution of this problem was given me at one of the russian robot forums.
And you programmed additional load to zero, because Default would be maximal addition load for A3 and only Zero for A1 and A2?
Fubini
Yes, additional load for A3 is zero.
If you also checked additional loads.
Fubini
No additional load. The robot works with tool exchange system.
Today I removed the torch from the flange of the robot, created a new tool with the same parameters as the real tool but with the mass=0 and other parameters=0 and make a program with oscillation by that "virtual" tool. The result was the same - TCP shaking. So, as I can understand, incorrect mass and other parameters are not the reason of the problem.
Leon Thank you very much for the answer.
I have a question.
When I'm programming path for welding (in my example - circ path), I use ArchTech Basic technology package, installed to the system, and to program the path for welding I should use inline forms for setting welding, path and tool orientation parameters. There are only three options for tool orientation: standard, wrist ptp and constant orientation control. Standard doesn't work, wrist ptp dosen't work and constand orientation control doesn't work too. How can I in this case to set the paremeters you advised?
Hi, guys!
One more problem with KUKA robots performance.
I need in welding circular path on a detail fixed on a two axes positioner. The angle of the torch needed to be aproximately 45 degrees relative to the flange base of the posotioner during welding. The problem is, that at the auxillary circ points the angle of the torch is changing. You can see it on the following video (the tool orientation was set as standard):
If I set tool orientation as wrist ptp, the problem with that partially disappears, but ocsillation doesn't work. This can be seen from the video below:
Somebody knows how to solve this problem?
Hi.
Thank u very much for trying to help.
I'm just working on the problem taking into account all your advices. I'll post here about any results.
Hi, vvelikov.
Do you mean to post the .src file of the welding program?
And thanks for the answer.