Our system is KRC4 8.5.7 HF1 and KR 90 R3100 extra HA, robot mounted on a non-Kuka track (but with Kuka-motor) and two KP1 positioners.
Between the two positioners, a tube can be placed, so that the two positioners can continuously rotate the tube (the tub is in the center of the two positioners).
The two postioners and the robot track are kinematically coupled to the robot.
The purpose of the application is that the robot can weld a layer on the tube. This done by continuously rotating the tube while the robot slowly moves from one side of the
tube to the other. What is the prefered way to program this application : make the KP1's rotate continuously (in master-slave) and meanwhile the robot moves from one side to another, creating a
weld pattern in a spiral shape. All axes are kinematically coupled.
Robot with KP1 manipulators
- Plc_User
- Thread is Unresolved
-
That's very vague.
If the spiral is of constant pitch, you could potentially program the entire spiral with a single motion command. For example, for a spiral of 10mm/deg, 1 meter long, you could use something like LIN {X 1000, E1 100}. This assumes the X axis is along the length of the tube, and E1 is the KP1s rotational axis.
OTOH, if your spiral requires multiple revolutions of E1, you might need to use a series of LINs or LIN_RELs, because the "natural" behavior of an Endless rotational axis is to jump to the nearest multiple of 360deg -- that is, if E1 is at 0 deg, and you command it to {E1 361}, E1 will only move 1deg, because the physical endpoint is the same.
-
Kss version?
Synchronous ext axis?
Program sample?
-
Is this in Teach mode? Are you getting the message "Approximation not possible"?
-
what is the approximation distance used? are you SURE that value is set?
-
what is the value of $ADVANCE?
what is the declaration of PowerOnPreheat (signal?)
what is the declaration of CycleStep_PreheatKP1 (signal?)
what is the declaration of NegDirectionPreheatKP1 (signal?)
-
Since it is a HA machine it also has absolute accuracy. Therefore also check load dat changes. You can not blend over load data changes in case of absolute accuracy.
Fubini
-
For that code, the motion should be continuous. There's no obvious reason for the behavior you describe.
I would try something like this:
Code
Display MoreDEF E2Test() DECL E6POS _eTestPos DECL INT _nIndex DECL INT _nIncrement $ADVANCE=3 _nIncrement = 1 _eTestPos.E2 = 0 ; PTP test PTP {E2 0} FOR _nIndex = 1 to 100 _eTestPos.E2 = _eTestPos.E2 + _nIncrement PTP _eTestPos C_PTP ENDFOR ; LIN test PTP {E2 0} FOR _nIndex = 1 to 100 _eTestPos.E2 = _eTestPos.E2 + _nIncrement LIN _eTestPos C_DIS ENDFOR ; PTP_REL Test PTP {E2 0} FOR _nIndex = 1 to 100 _eTestPos.E2 = _nIncrement PTP_REL _eTestPos C_PTP ENDFOR ;LIN_REL test PTP {E2 0} FOR _nIndex = 1 to 100 _eTestPos.E2 = _nIncrement LIN_REL _eTestPos C_DIS ENDFOR ENDTry different settings of _nIncrement and see if/how the motion behavior changes.
-
If you're only moving E2, why not use PTP? Are you using an interpolated motion?
The value of $APO depends on your requirements, and the configuration of your axes. A small value might work for low-inertia conditions, but for situations with high inertia or axes that require long accel/decel ramps, the path planner might have to reduce speed before reaching the approximation radius (in other words, the acceleration distance exceeds the $APO value).
The quick answer would be to try your test program with different $APO values and see if increasing them makes a difference.
Also, since E2 is kinematically integrated, it's possible that your limiting factor might be $APO.CORI, rather than CDIS -- depending on your configuration of E2 relative to your TCP, the path planner might be seeing the E2 motion as a change in TCP orientation, rather than position.
Advertising from our partners
