Yes, they are shipping the v2 with the 4.2.2 board. My understanding is that the 4.2.7 board has a change in the stepper driver pinout but is otherwise the same as 4.2.2. The change in the pinout allowed them to change the stepper driver package as the stepper driver vendor appears to be changing that spec. I've used both boards in my V2 with no ...
I notice that in "configuration_adv.h" for the BIGTREETECH-SKR-mini-E3, which uses TMC2209 drivers, the similar section has:
#define HOLD_MULTIPLIER 0.5 // Scales down the holding current from run current
#define INTERPOLATE true // Interpolate X/Y/Z_MICROSTEPS to 256
According to 'The-EG' comment in this GitHub issue, Add Creality Ender 2 Pro config #633, you can often determine the stepper drivers by one of a few ways:
Listen to the sound. The 'TMC22**' will sound much quieter
Look for a marking in Sharpie on the SD Card reader
C = HR4998
E = A4988
A = TMC2208
B = TMC2209
H = TMC2225
Remove the heat sync
Stepper motors "want" to keep their position as they are told to by the firmware, therefore they do whatever it's needed (accelerate and brake) to follow the orders they received.
The question is: is the firmware telling them to move/accelerate/brake faster/harder than they can? if yes, they won't keep up (because of inertia and much more) so you'...
The problem turned out to be mechanical. The arm that I mounted the camera on had developed a crack where it connects to the build platform. I used some superglue to repair the crack and the camera shaking went away.
The lesson here is to check EVERYTHING mechanical before trying to blame shaking on the firmware.
I'm having the exact same issue, SKR1.4 Turbo with 2209's on i3 clone and it started when I tried to enable G34 auto-alignment. I very briefly had it fixed by disabling the auto-alignment and I wish I knew how because now I can't even fix it with a fresh download of Marlin and no G34 to begin with.
I took the gantry off and watched the motors turning because ...
You can fix this.
The current switching portion of the driver appears fine, as does the motor.
First check the improbable, but easy to fix
Although I think it is unlikely, something could have been changed in your configuration file. It would be work a quick glance to see if there has been any obvious damage.
It is probably a board-level (not chip level) ...
You cannot change the Vref of a UART operated stepper driver, setting the current directly is the way to go on UART operated stepper drivers; in fact that is actually what you are doing on non-UART operated stepper drivers, you change the Vref to change the current through the stepper motor, the higher the voltage the higher the current through the stepper ...
Have a look at the boards pinout:
You'll need 3 pins for each additional driver - enable, step, and dir.
The AUX-2 connector should give your 8 GPIO pins for that, without losing other functionality like the display.
You might also be able to wire your Y axis motors in series, saving one stepper driver. You could then use E1 and three of the four servo pins ...
By avoiding pin 3 entirely, the Z-axis steppers have started to move correctly. My bed heater went out a while ago, so I redefined the connections in Marlin to use that pin (pin 12) as the Z-step pin, connecting it to the A4988 accordingly. This has caused no issues other than small noise problems so far. Unfortunately, I can't speak to any potential issues ...
I've replaced the Z-axis stepper driver with an off-board Pololu-style A4988 driver by soldering leads to pins 2 and 3 on the Melzi board, then connecting those to the driver on a separate board. The Z-axis now moves correctly. When I encountered issues with the step pin (pin 3), I connected it to pin 12 (bed heater) instead, leaving the bed to be heated ...