Lookup FORWARD() KRL-function in forum search. E.g.
https://www.robot-forum.com/robotforum/kuk…48133/#msg48133
Fubini
Lookup FORWARD() KRL-function in forum search. E.g.
https://www.robot-forum.com/robotforum/kuk…48133/#msg48133
Fubini
Values of zero for Status and turn are valid. Check out Status and Turn Monitoring (see $CP_STATMON) and
https://www.robot-forum.com/robotforum/kuk…rum/read-first/
Fubini
"Block change at STOP" never is the reason why a stop happens. Instead it is an additional message if a stop happens at the instance of a block change (switching from Motion command to the next). So what are all other Messages that appear?
No. 1140: "Block change at STOP"
Cause: In the event of dynamic braking or path-maintaining braking during a block change, it is not possible to calculate $POS_RET and the system time. $POS_RET and the system time are detemined by the start of the new block.
Remedy: Modify operation in such a way that the stop does not occur at the same time as the block change.
Fubini
Hi,
both syntaxes are equal in it effects.
Fubini
Well Skyefire, lets try:
Basically do not mess with these two switches, because depending on these switches you will need different machine data for the robot to work properly. Unfortunatly I can not go to far into this because there are company secrets involved. KUKA delivers fitting machine data for a certain setting of OPT_MOVE and ADAP_ACC for a certain robot type. Moreover usually there only exits one set of machine data for a certain robot type. So in theory you could create fitting machine data for any switch setting, but since the determination procedure for each setting is very expensive and time consuming this is not done. Additionally there is a historic component to this. Newly constructed machines (Quantec, Agilus) will always get setting OPT_MOVE and ADAP_ACC at #STEP2 which supposedly is the overall best setting. Older machines (parts of the KR2000 Family) might only have #STEP1 because the necessry algorithms (higher motion profile) for #STEP2 where not yet included in the controller when the machine data layout was done.
Last but not least: These switches only affect how fast the robot can run but have nothing to do with path accuracy, collision detection or stuff like that. They are basically switches for different trajectory planning modes.
I hope this answer is not to vague.
Fubini
If I understand you correctly your question is: Why the defaults from $config.dat are not used inside your program before adding them manually? Thats becaus the subroutine call
;BAS (#INITMOV,0 )
in your program is commented out. Try removing the ";" and lookup bas.src which implements the routine BAS(#INITMOV, 0).
Fubini
external or additional axes.
NO. Your program probably is fine. The value of $ACT_BASE is only changed when you use inline forms and yes also if you use the menu to choose the current base (I forgot about this case). The base is set correct.
Fubini
Yes it changes if and only if you use inline forms.
Fubini
The value of $ACT_BASE is only adapted if you use inlineforms! Actually the bas.src sets it whenever a base is set using the inline forms. So in expert programs you will have to set it yourself.
Fubini
Speaking Mathematically the KUKA-Spline is a Spline. More precise a spline with polynoms of order 5. Hence to get a unique representation you need at every programmed spline positions three values (position, first and second order derivative on the spline start and end). This ist done by estimating the higher order derivatives using the positional information of the four neighbouring spline positions. E.g. consider
SPLINE
SPL XP1
SPL XP2
SPL XP3
SPL XP4
SPL XP5
ENDSPLINE
In this case the shape of the SPL-Segment leading to XP3 is defined by estimated higher order derivatives using positional information of XP1, XP2, XP4 and XP5. Please note I can not give the exact formulas because this is confidential KUKA knowledge and rather complex considering orientation represaentation and external axes. Furthermore if you have SLIN or SCIRC segments inside your blocks
SPLINE
SPL XP1
SLIN XP2
SPL XP3
SCIRC XP4, XP5
SPL XP6
ENDSPLINE
these dominate the SPL segments. Hence the necessary higher order derivatives are not estimated anymore but defined unique by the neighbouring SLIN or SCIRC segments. Hence having all positions inside a spline block the geometry of the splines ist defined unique. Thats probably what Skyefire means with precomputed. One other thing is the relation of spline blocks to the advance run. A spline block is treated as a single motion command. Therefore considering $ADVANCE the whole spline block is treated as a single old motion command (LIN, CIRC or PTP). Hence in the previous example you can not e.g. modify XP6 when you are already started interpolation of the spline block.
Also there a two types of spline blocks cartesian spline blocks and ptp spline blocks and both types can also be used as single position commands. E.g.
SPTP XP1
is exactly the same as
PTP_SPLINE
SPTP XP1
ENDSPLINE
and
SLIN XP2
is exactly the same as
SPLINE
SLIN XP2
ENDSPLINE
So basically the single positioncommands are just convinience functions to not having to write (PTP_)SPLINE ... ENDSPLINE all the time.
Fubini
Correct LOAD_DATA (including A3)? This message comes from the warmup routine for cold robots. Lookup $WARMUP_RED_VEL in R1/$machine.dat. Try deactivating warm up.
Fubini
Panic post was not to show you how to simulate, but to show you how a posts need to be formulated that users can help you. We Need a lot more specific Information what you are trying to do and with which software versions.
Fubini
Hi,
Directly: Edit $RAT_MOT_AX in R1/$machine.dat. But this is not WorkVisual safe.
Indirect: Open your current Project inside Work Visual and enter the external axis configuration. Change the Gear Ratio Motor /Axis there (the comment also states $RAT_MOT_AX). Then redeploy your WorkVisual Project.
Fubini
You can not set $VEL_AXIS_C in a program. Only advance run variables can be set in programs. Main run variable mainly are for evaluation and diagnosis.
Fubini
Quotewonder why he just didn't complain about an axis reaching it's angular limits though...
Because this error has nothing to do with angular limits. Try reaching a position 20 meters from your robots base with a maximum reach of maybe 3 meters. If you can not calculate axis angles corresponding to a certain cartesian position you can not find feasable axis angles.
Fubini
"work envelope" is not "workspace". Probaböly you have message 1342:
https://www.robot-forum.com/robotforum/kuk…78954/#msg78954
Fubini
Hi,
your problem probably is that in old releases you where only able to mount robots in certain positions on a KL. Hopefully remembering correctly only mounting angles of only +-90 deg where allowed (see $ERSYSROOT in $machine.dat). In newer releases this restriction was lifted. So upgrading to a V5.6 should solve your problem .
Fubini
Hi,
try $SR_RANGE_OK[] (section 9 in documentation).
Fubini