Struggling with "next" direction logic

[martinlong1978]

Can't quite get my head around this...

"If the next direction is different from the current direction, we
should start decelerating to move in the intended direction"

However, if it finds that to be the case, it sets current direction to UNKNOWN, but then the following block checks for UNKNOWN and sets it to RIGHT. This seems to offer no capability of decellerating first.

[jh247247]

So with the deceleration logic, it is essentially a state machine that changes state depending on what the position difference of the expected spindle position and current position.

The "next" position is where we want the spindle to be moving depending on the current instantaneous difference, but the system has inertia so has to decelerate to zero before moving in the "next" direction.

Note that the current direction is only changed when the delay between pulses is the "initial delay" or the jerk velocity. This means that we can theoretically go to RIGHT -> 0 or UNKNOWN -> LEFT over the course of 3 "initial" step intervals.

I think what you've highlighted is a bug though, we shouldn't be able to go from right to left immediately.

[martinlong1978]

@jh247247

Ah, this makes total sense now. I was indeed missing the need to complete the decelleration before it did the switch. I think actually, it probably isn't a bug. It just allows the second piece to run even if the directiont was previously unknown. It's an optimisation.

[martinlong1978]

@jh247247

Ah, yes. I see the bug. So a little while ago you made that logic only operate if the position error was >1 or <-1 - i.e. big enough to send a pulse.

However, that means that if there is no pulse to be sent (actually, this is true for most cycles), then we hit the else clause, setting the m_currentDirection to unknown. That DOES mean that it can then be switched to the opposite direction on the next cycle without going through decelleration.

I suspect the fix here is to set those conditions back to <0 and >0 and deal with whether a pulse should be sent further down. Do you recall why you made that change? It was committed as part of "Add documentation to leadscrew loop". Yes, I'm just as guilty of that. 😄