open-dobot movement MoveWithSpeed() algorithm

I've been digging through the movement algorithm implemented in open-dobot's MoveWithSpeed() function. It seems pretty solid to me, although I have a couple questions.

First, let me describe the algorithm just to check if I understand it. The user specifies a speed and an acceleration. A vector equation for a line in 3D space is calculated based on the starting and destination points. Based on the speed/acceleration, one can calculate the distance that the arm will move in 20ms and slice up the line into slices based on the calculated distance for each 20ms interval. Looping through the slices, the number of steps for each motor is then calculated to get from the starting point of the slice (or interval) to the ending point of the slice. From here, the number of steps to move in 20ms can now be sent to the arduino. Note that the motors will naturally always move in the same direction during these 20ms intervals (though the motors certainly do sometimes change direction during movement along a line). Also, I noticed that the algorithm keeps track of fractions of steps that are lost due to the limited stepper motor resolution (very nice).

If I understand the algorithm correctly (please correct me if I don't; I'm not 100% confident in my understanding of it), moving very slowly will generate a line with higher resolution (i.e. very linear movement). On the other hand, moving very fast will generate a line with less resolution (i.e. the arm movement is not as linear). One question I have is what is the maximum number of steps that can be executed in a 20ms interval? I'm having a hard time understanding the firmware code. I saw the comments that the timer 5 ISR toggles pins at maximum 20kHz, but I'm not sure how exactly that relates to the maximum number of steps per 20ms. Similarly, I'm confused as to how the number of ticks relates to the maximum number of steps per interval.

To better illustrate my confusion, I'm confused about the meaning of the following code:

// At 50kHz how many ticks pass between TIMER5_COMPA_vect ISR calls.
#define TICKS_PER_CALL 40
// Coefficient that is used in DobotDriver to calculate stepping
// period.
#define STEPS_COEFF 20000
// How long delay does the TIMER1_COMPA_vect ISR introduce.
// This is to be acoounted for make corresponding adjustments.
#define ISR_DELAY 80

and the following code:

// Timer5 compare match Interrupt Service Routine.
// Toggles pins at maximum 20kHz.
ISR(TIMER5_COMPA_vect)
{
if (stepsX) {
ticksLeftX -= TICKS_PER_CALL;
if (ticksLeftX < 0) {
X_STEP_PORT ^= (1 << X_STEP_PIN);
if (X_STEP_PORT & (1 << X_STEP_PIN)) {
stepsX--;
}
ticksLeftX += ticksX;
}
}

For the first code block, I don't really understand the significance of those variables. My naive thought is that 40 ticks per call (which occurs every 20ms?) means that the step pins can be toggled a maximum of 40 times per call (and since the pins need to to be toggled to HIGH and LOW for a step to occur, that limits the number of steps per call to 20). Certainly though, my understanding must be severely flawed as the comments state "Toggles pins at maximum 20kHz." and the code seems to be able to execute more than 20 steps per 20ms. Also, for the second code block, I don't know what the bitwise operators are doing (though I imagine they must be changing the step pin state). I'm also confused on the difference between PIN and PORT, I thought these were sort of the same thing.

Despite my confusion, assuming I understand the general algorithm correctly, the caveat that I wanted to bring up for discussion is that based on the current movement algorithm (Algorithm 1), the "movement resolution" (how linear the movement actually is) seems to be dependent on the speed. The faster the speed, the less slices that the line will be divided into and movement resolution suffers. At slower speed, the line will be divided into more slices and movement resolution will be very good. Is this the best (or most ideal) algorithm? I'm really only worried about a loss of movement resolution at high speeds, but in all fairness it seems to work well at practical speeds..

Another approach (Algorithm 2) that I can think of is that the line can be divided into an arbitrary number of slices to ensure some maximal level of linear movement resolution. From there, a step sequence can be generated, but this sequence of steps will be time independent. Steps/sec could then be calculated based on a desired speed (mm/sec) specified and the length of the line. The formula would be: line length/(desired speed in mm/sec) = time; # of steps in step sequence/time = steps/sec.  One caveat of this approach is I think that there might be a delay of up to 10ms when motor direction needs to be reversed during a line movement.

Again, in all fairness, the first algorithm seems to work very well at realistic speeds and the second algorithm might be more time consuming for not much benefit. Also, my thinking could very much be flawed, especially since I'm still confused by the firmware code. Any clarification on that would be appreciated.

In sum:

1. Do I understand the movement algorithm in the MoveWithSpeed() function correctly?

2. What is the maximum number of steps that can be executed in a 20ms interval? And how does the code that I posted relate to that maximum number? (I'm most interested in the answer to this question).

3. Any thoughts of whether Algorithm 1 or 2 are better than the other? I will try and implement algorithm 2 out of my own curiosity, and also because my current linear algorithm is more suited to that version. In any case, it's super simple for me to use the open-dobot MoveWithSpeed() function with my GUI and so, I will do that first. Also, I'll add in error checking (seeing if angles that the arm moves to along the line are valid). I think I did a decent job with that.


Best,

Mike