Stepper motor sensing and reproducing

[Itamakatz]

Hi,

I'm building a complex 3D printer using the Marlin firmware on the arduino mega with the ramps 1.4 shield, and I need to intervene and correct the z-axis.

The stepper driver I'm using is the DRV8825 and I'm implementing the above by connecting the enable, step, dir pins of the z-axis through a logic level converter to a teensy 3.6 (along with other sensors to for the system feedback) while the teensy is the one connected to the stepper driver.

The idea is simple - the teensy should do all that received by Marlin and on top of that correct when needed.

My problem is that I'm not managing to recreate the stepper movements received, and if I can, the steps are very rough and the motor makes a lot of noise.

Most of the sensor algorithm is written down so I'm now only focusing on this problem (code attached is only relevant to this and not the sensors)

I'm using 3 interrupt pins as well as digitalWriteFast and digitalReadFast.

Since the speed of a step is defined by the pulse length, I divided the step interrupt into rising and falling so I retain the pulse length.

I'd be happy if someone could tell me what's wrong with my code or how to implement it better given that i'm using the teensy.

One last thing, pins M0-M2 are fixed by jumpers and not implemented by the code. (I'm using 16 microsteps/steps)


Marlin - http://marlinfw.org/
Ramps 1.4 - http://reprap.org/wiki/RAMPS_1.4
DRV8825 - https://www.pololu.com/product/2133
DRV8825 Data sheet - https://www.pololu.com/file/0J590/drv8825.pdf


View attachment intermediator.ino
View attachment stepper_corrections.cpp
View attachment stepper_corrections.h

Thanks

 

[luni]

Since the speed of a step is defined by the pulse length, I divided the step interrupt into rising and falling so I retain the pulse length.

This usually is not the case. The motor speed is defined by the frequency of the step pulses. The step pulse width is usually fixed. Note: the 8825 is quite picky about the step pulse width. IRC the datasheet requires > 3µs. My experience is that it needs about 10µs to run smoothly. I assume you did test it without your intercepting board and it ran fine? BTW: The 8825 is known to have issues with microstep generation at low (12V) supply voltages http://hackaday.com/2016/08/29/how-accurate-is-microstepping-really/ which might lead to strange noises.

I don't quite understand why you are doing

digitalWriteFast(PASS_STEP, LOW);
digitalWriteFast(PASS_STEP, HIGH);

in step_received_rising (and similar in step_received_falling). The first DigtalWrite doesn't seem to be necessary?

Edit:
Other interrupts could delay the call to your rising / falling interrupts. If for example the rising interrupt is delayed the generated step pulse could be much shorter than the incoming step pulse which might generate the observed issues. Try to increase the priority of your interrupts...

 

[PaulStoffregen]

On Teensy 3.6, digitalWriteFast() without any delays is too fast. By default pinMode configures the pin with slew rate limiting, which greatly reduces high speed switching noise. But 2 successive digitialWriteFast() can execute faster than the pin's voltage is able to change with the slew rate limit.

Here's a conversation about how to actually get these extremely fast signals.

https://forum.pjrc.com/threads/4187...lator-example)?p=132363&viewfull=1#post132363

However, I do not recommend running without the slew rate control. You should use something like delayMicroseconds() with digitalWriteFast() to get predictable waveforms.

 

[Nominal Animal]

The DRV8825 in particular requires that you set the DIR pin to the correct state at least 650 ns before the rising edge of the step pulse; the rising edge of the step pulse is what triggers the next step. STEP must stay high for at least 1900 ns, and low for at least another 1900 ns before the next step.

The timing diagram in the datasheet shows that you need to keep DIR at the correct level 650 ns before and after the rising edge of the STEP pulse. Since STEP needs to be kept high for 1900 ns = 1.9 µs, it is perfectly okay to update the DIR state (for the next step) when you pull STEP low.

Note that when running at X MHz, 2 µs = 2000 ns = 2*X clock cycles.

Other STEP/DIR controllers I've seen are similar, although the timings do vary (but are specified in the driver chip datasheets).

 

[luni]

If I understood his code correctly he is _not_ toggling the pin with full speed. When he enters the ISR the pin is already low (high), he then calls digitalWriteFast(PASS_STEP, low(high)). So the first of the two digitalWriteFasts has no effect. The width of the step pulse will be approximately the width of the incoming pulse (if the interrupts are not delayed). If they are delayed the width of the generated pulse can be significantly shorter than the incoming pulses.
Anyway, looks like the OP is gone, or not interested anymore....