Hi,
Message No. 1422: "Read access to a variable that has not been initialized or has an invalid value, e.g. "$POS_INT" read outside an interrupt program."
Fubini
Hi,
Message No. 1422: "Read access to a variable that has not been initialized or has an invalid value, e.g. "$POS_INT" read outside an interrupt program."
Fubini
Hi,
there is no such variable with the respect to $BASE = $WORLD = $NULLFRAME, but using the geometric operator the position of the TCP in $WORLD is easily calculated by means of
$BASE:$POS_ACT
(see e.g. https://www.robot-forum.com/robotforum/kuk…29249/#msg29249)
Fubini
Hi,
Compare your values $SOFTN_END[] and $SOFTP_END[] inside R1/$machine.dat to the values on your installation CD for your robot type.
Fubini
Hi,
as far as I know plain KRL does nor support milling. Do you have some addition Tech-Packages like KUKA.CNC?
What exactly does your program look like?
Fubini
Hi,
also die Meldung sagt schon mal, dass es sich um ein reines Turnproblem handelt, da du um die gewünschte Position anzufahren über einen Softwareendschalter der Achse 5 hinausfahren müsstet und Softwareendschaltermeldungen sind spezifisch bei Turnproblemen. Wäre es ein Statusproblem müsste eine Meldung "Work Limit Exceeded" oder auf deutsch "Arbeitsraumfehler" kommen. Eine Möglichkeit hier weiter zu kommen wäre wahrscheinlich die Achsen 4 und 6 des Roboters über $AXIS_TYPE[] aus der R1/$machine.dat auf endlosdrehend (=5) zu schalten. Im Defaultfall sind sie nämlich auf endlich (=3) gesetzt, was dann nur knappe Zweivollumdrehungen der Achsen 4 und 6 zulässt. Je nachdem von welcher Position man startet kann dass dann eventuell nicht mehr reichen um den gewünschten Turn anzufahren. Ich hoffe das endlos schalten ist bei den KR5 auch erlaubt. Bei den großen KUKA ist es sicher zulässig.
Fubini
Hallo johny311,
es gibt auch ein deutsches Forum unter http://www.roboterforum.de, das von den gleichen Leuten wie dieses hier betrieben wird. Natürlich behebt das dein Problem nicht aber wenn man sich leichter verständigen kann hilft es ja schon oft weiter.
Zu deinem Problem: Wie sich Status und Turn auswirken hängt natürlich auch von deinen Bases und Tools ab. Nur anhand der kartesischen Posen kann man da nicht allzuviel dazu sagen außer dass natürlich Status und Turn ursächlich für deine Beobachtungen sein können. Aus deinem Post wird mir auch nicht klar was du eigentlich erreichen willst.
Gruß
Fubini
Undefined tool/base after boot up + Alpha 5 singularity and cartesian jogging?
$TOOL_KIN is a preparation for tool kinematics. The KRC up to now knows two different types of external kinematics:
1) Robroot-Kinematic: The robot is mounted on the external kinematic (most common is a single linear axis like a KL), see $ROBROOT_KIN and $EX_KIN.ETx = #ERSYS
2) Base-Kinematic: The external kinematic is independent of the robot, see $BASE_KIN and $EX_KIN.ETx = #EASYS or #EBSYS or ... or #EFSYS
Theoretically there is a third type called Tool-kinematic (even though not fully implemented inside the KRC and hence not allowed for customers), where the external kinematic would be mounted to the robots flange. Maybe this feature will be available in the future.
Fubini
Hi,
to cover the angle jump I would do the following:
FrameResult = INV_POS(FrameA):FrameB should give $NULLFRAME if the positions and orientations are the same. Hence you should check:
REAL EPSPOS=1E-5 ; Or whathever precision you need
REAL EPSORI=1E-5 ; Or whathever precision you need
IF ABS(FrameResult.X) > EPSPOS OR ABS(FrameResult.Y) > EPSPOS OR ... THEN
...
ENDIF
IF ABS(FrameResult.A) > EPSORI OR ABS(FrameResult.B) > EPSORI OR ... THEN
...
ENDIF
Fubini
Hi,
I have checked your machine data and as long as the machine fits to your real robot they seem ok (at least to in comparision to the newest machine data for your robot type).
Hence I suspect a mechanical problem.
Fubini
Hi,
this is the wrong $machine.dat. There are two files called $machine.dat on the controller.
The first one located in C:\KRC\ROBOTER\KRC\R1\Mada describing in part the machine.
The second one located in C:\KRC\ROBOTER\KRC\STEU\Mada describing mainly IO related stuff.
You sent the second one but the first one would be needed.
Still better you could create an archive of your controller and send it here.
Fubini
Thats a windows system library, so probably your Windows is corrupt. Hence I suggest setting up everything from scratch startin with Windows Embedded.
Fubini
Probably external kinematics might not be used asynchronous if they are defined as a robroot kinematic inside $machine.dat ($EX_KIN is set to #ERSYS). Have you tried setting $EX_KIN to #EASYS or EBSYS or ... or EFSYS instead?
Do not forget: $VEL_ACT only works for CP-motions (LIN or CIRC). In PTP-motions its value is zero.
Hi,
The EK function is for activating geometric coupling on calibrated external base kinematics predefined in R1/$machine.dat. Hence the $BASE is attached to the flange of a external base kinematic and the robot moves together with the external kinematic (the robot is attached to the chosen external kinematic).
Die EK-function has the following syntax:
$BASE = EK (<Root>, <Kinematic identifier>, <Offset>)
where:
<Root> = Position of external kinematic root in $WORLD
<Kinematic identifier> = #EASYS or #EBSYS or ... or #EFSYS
<Offset> = (optional) additional offset frame from the external kinematic flange
(for examples see bas.src on you controller, which does set the correct $BASE for measuerd in external bases).
Geometric coupling is deactivated by assigning a different $BASE:
$BASE = <Frame>
For RoboTeam/Motion Cooperation there is a similar command called LK(...) allowing you to attach a robot to another robot.
For attaching on a conveyor the EB(...) command is used.
Fubini
QuoteSo, does this mean that on the KRC4 there's no longer any copy of the serial number, hour meter, etc, stored on the robot hard drive?
Thats right. Cal-File and Pid-File are other examples. By the way: If you read the EPROM content to generate an archive/KRCDiag the created RDC-Folder on HD is deleted if you restart the controller.
In KRC4 the serial number is not stored on HD. It is set by KUKA on the EPROM attached to your robot and plugged into the RDC. Hence the serial number now is unique for the robot and by plugging the EPROM into a new RDC the serial number always stays with the robot. Moreover a defect RDC does not require "programming" a new serial number anymore but simply plugging the EPROM into the new one. The RDC folder is only created in case you are creating an archive or a KRCDiag. In this cases the EPROM is read and the files on the EPROM are written on HD to be included in the archive/KRCDiag.
QuoteCan you really not specify a tool def for example as [0,0,0,0,120,0]?
Of course you can. But this orientation is equal to {X 0,Y 0,Z 0,A 180,B 60,C 180} as you can see by entering {X 0.0, y 0.0, z 0.0, a 0.0, b 120, c 0.0}:$NULLFRAME in e.g. VarCor. Its just like sinus or cosinus functions which have a standard interval of [0,2pi], but any other interval of length 2pi will lead to the same results. Internally the controller always converts the orientation to the standardized intervals given previously by SkyeFire. On this standardized intervals the values A,B,C are unique (apart of the Euler singularity at B exactly +-90°, where only the sum of A and C is unique).
Fubini
Just to clear it up. KRC4 still has an interpolation cycle time of 12ms. But there is a new interface called "Fast Sensor Interface" running at 4ms allowing the sensors to run and apply corrections at a faster interval. If this fast mode is already supported by RSI I do not know for sure.
Fubini
Ah the correct English version of the message text for no. 1133 is "Gear torque exceeded axis %1".
So you are only driving axis 6 using the buttons on the right hand side of the KCP? Did you check if somebody tampered with your machine data? Is the robot newly calibrated?
Taking a look at your currently programmed loads might be helpfull too.
Fubini