Added support to set different values for pullin and pullout speed

[ramboerik]

Hi again @luni64!

I started to write a motion planner with your library and encountered a problem when I tried to set different values for the pullin and pullout speed. I looked into the code and discovered that the implementation treated the acc and dec phase as the same and some parts wasn't fully implemented. This issue refers to #82 where you can find my attempt to fix what I think is left for full support for different pullin and pullout speed.

The implementation

• The implementation splits the acc and dec phase into two different segments and calculate them individually. If both phases fit within the desired steps all is fine and the result should be somewhat as before.
• If the sum of acc and dec phase don't fix within desired steps then a new target speed is calculated that can be reached within the desired steps.
• If the end speed cannot be reached the whole distance will be an acc/dec segment and a best attempt is made to reach the end speed.
• The pullin and pullout speeds are limited to max tartget speed.

Here are some samples:

Known bugs

• (MINOR) There is one minor bug in the stm32f4's interrupt handler that causes one interrupt to be delayed.
• (MINOR) Slow last step when running with low pullout speed with teensy
• (MAJOR) I had two cases when the teensy's interrupt stopped to be generated.

I would be very thankful if someone testet this a bit, especially for the teensy target 😄

[ramboerik]

Relates to #48

[luni64]

I had a look at your PR which makes a lot of sense and will do some testing over the weekend (T3x only)

I also ordered an STM32F4 board (https://www.amazon.de/gp/product/B08GB33LZK/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1) to be able to test this as well. But, I probably will need some time to get the toolchain running. Any pitfalls to take into account? I assume PIO supports it?

[ramboerik]

Yes, pio has great support for both stm and teensy :) Have you used it before? I use Visual code + platformio with the following platformio.ini in the root of the TeensyStep repo:

[env:nucleo_f429zi]
platform = ststm32
board = nucleo_f429zi
framework = arduino

[env:teensy35]
platform = teensy
board = teensy35
framework = arduino

and then I just write the tests in src/main.cpp. You will probably need to change nucleo_f429zi into genericSTM32F411CE as you have a different board.

That should be enough and the first compile will download all toolchain stuff for both boards and setup everything right. When running compile&upload it will build both targets and upload to corresponding board.

[ramboerik]

I will do some more minor commit(s) for the stm32f4 to tune the timer further but I get quite nice results from both boards now. Here is another run with vPullin != vPullout and the only thing that differs between the generated pulses is the 10ms start delay for the teensy.

[airgoing]

If the torque of the stepper motor is large, especially when the motor is under no-load and load conditions, the coil drive current of the stepper motor is also very different. How to ensure the same acceleration time and the same deceleration time?

[luni64]

For any stepper motor operated under its specified conditions, the movement only depends on the sequence of the step/dir pulses. Thus, acceleration/deceleration will not depend on load/ coil current etc. In fact, TeensyStep doesn't know anything about actual motor parameters, it just generates step/dir pulses.

[airgoing]

Thank you, luni64 I agree with you, but there will be some differences in actual use. Especially when the motor starts and stops under heavy load, even if the same step/dir pulses signal is given, the execution(mechanical) process may be different in the actual process, and at the same time, there is no monitoring to detect. This may make the reciprocating actuator unable to return to the origin. Of course, I also knew that this is not in the controller's algorithm, but it will actually go out of this situation.

[luni64]

Of course, if you are accelerating / moving too fast for a given load/motor the rotor can not follow the pulses. Usually this is called step-loss. But this is definitely not a normal mode of operation and needs to be avoided. Most often, once the motor lost sync with the pulses it is not able to move at all and stalls until the step frequency falls below the pull in frequency. I never saw a stepper just accelerating slower, it either works or it stalls.

As you wrote, you have no chance to detect this malfunction without additional sensors and you will loose all positioning information for the motor. So, if you are afraid that your stepper can't follow your pulses you should think of redimensioning the mechanics, motor size, driver etc.
If, for some reason, you can not avoid this overload condition you might be better of with a servo. They often also come with a step/dir interface but they always have an internal position feedback so that they will always reach the target position. Modern CNC machines practically always use servos instead of steppers.