Deceleration calculated next step time negative?

[jazbaatbadalgaye]

I wrote a snippet to verify if I understand how the next step time is generated for acceleration and deceleration phase. I am getting sensible values when I print values out for acceleration but when I print values for deceleration, I am getting negative values. I have set up some dummy values for the variables and my best guess is some of those values might be incorrect. Any help is appreciated

#DECELERATION
####################################################
#Move G0 X5
totalsteps=400
totaldistance=5
stepsPerMm = totalsteps/totaldistance
topSpeed=500
requestedSpeed=400
deceleration=1500
endSpeed=0
startSpeed = 300
StepClockRate = 937500
acceleration = 2000 
compensationTime = 0.3
shiftfactor = 3 
nextStep = 200 #no of steps done 

stepsTillRecalc = (1 << shiftfactor)-1 #store number of additional steps to generate
compensationClocks = compensationTime*StepClockRate
decelDistance= ((requestedSpeed**2) - (endSpeed**2))/(2*deceleration)
decelStartDistance = totaldistance - decelDistance
accelDistance = ((requestedSpeed)**2 - (startSpeed)**2)/(2*acceleration)
steadyTime = (decelStartDistance -accelDistance)/topSpeed
accelStopTime = (topSpeed - startSpeed)/acceleration
decelStartTime = accelStopTime + steadyTime
fTwoCsquaredTimesMmPerStepDivD=StepClockRate*StepClockRate*2/(stepsPerMm*deceleration)
print(fTwoCsquaredTimesMmPerStepDivD)
topSpeedTimesCdivDPlusDecelStartClocks=(topSpeed*StepClockRate)/deceleration + decelStartTime*StepClockRate 
adjustedTopSpeedTimesCdivDPlusDecelStartClocks = topSpeedTimesCdivDPlusDecelStartClocks - compensationClocks
print(adjustedTopSpeedTimesCdivDPlusDecelStartClocks)
nextCalcStep = nextStep + stepsTillRecalc
temp = fTwoCsquaredTimesMmPerStepDivD * nextCalcStep
print(temp)
fTwoDistanceToStopTimesCsquaredDivD =((topSpeed*StepClockRate)/deceleration)**2+ ((2*decelStartDistance*StepClockRate*StepClockRate)/deceleration)
if temp < fTwoDistanceToStopTimesCsquaredDivD:
    nextCalcStepTime=adjustedTopSpeedTimesCdivDPlusDecelStartClocks - (fTwoDistanceToStopTimesCsquaredDivD - temp)**0.5
else:
    nextCalcStepTime =  adjustedTopSpeedTimesCdivDPlusDecelStartClocks
print(nextCalcStepTime)

[bot]

Just a wild guess here, but perhaps RRF uses negative values in that context to indicate deceleration vs acceleration.

That, or the lookahead queue is being overrun and the move can't be adjusted (or whatever happens), causing the time to be invalid.