Not in KRL. Once a motion command has been loaded into the motion planner, it's values (endpoint, speed, accel, etc) cannot be changed.
Without controlling $OV_PRO from the SPS, or installing RSI and using superposed motion, your options are:
1. Use an Interrupt with RESUME to terminate the active motion and start a new motion to the same endpoint with a lower speed. Will cause a stop&go, however -- it won't work on the fly.
2. Create a subroutine that divides the entire motion into a series of continuous small motions, and adjusts the VEL parameter on the fly.
DECL FRAME _fShiftFrame
DECL E6POS _pStartPos
....
_pStartPos = $POS_ACT_MES
FOR _nI = 0 TO 600
_fShiftFrame = $NULLFRAME
_fShiftFrame.Z = _nI
IF $IN[1] THEN
$VEL.CP = 0.2
ELSE
$VEL.CP = 2.0
ENDIF
LIN _pStartPos : _fShiftFrame C_DIS
ENDFORDue to the Advance Run Pointer, this approach will always have some "lag" between the Input and the speed change. The steps need to be small enough to minimize this, but still large enough that the path planner doesn't have issues approximating between them. That size needs to be worked out experimentally.
motion planner needs to know ALL motion settings BEFORE initiating motion.
if you do what SkyeFire proposed, you would need to generate set of short LIN segments and use approximation.
but this also means you need get familiar with advance run. that IF statement is reading an input so that would cause advance run stop.
but this also means you need get familiar with advance run. that IF statement is reading an input so that would cause advance run stop.
I knew I was forgetting something! Yes, the Input check would need to have a CONTINUE or be part of a TRIGGER command.
If I assign my speed value to a variable and I change this value via using this variable , still not ?
Doesn't make any difference. Whether you're assigning it to a numeric value, or a variable, the path planning and look-ahead still work the same.
