[gnea/grbl-Mega Issue#90] Stepper drivers not the same steps?

未分类 bolang 4个月前 (10-15) 26次浏览

Issue #90 | 状态: 已关闭 | 作者: lulu3d | 创建时间: 2019-02-16


Hi all,

I’m building my MPCNC with the use of my old MKS Base V1.5 board, and GRBL.

When I configure my stepper motors (stnd nema 17/ 1.8°) the same way in the config.h (steps, rate, acceleration and travel) I have my X stepper doing a 360° on 10 steps, and the Y and Z about 45°?! Even when swapping motors, it’s always the X that has a bigger step rate (so not a motor issue)?!

Since my card came from my old 3D-printer, it always worked OK with Marlin and steppers where equally operating.

Do I miss something? Does someone know how can I get all the steppers work the same way?
(MKS Base 1.5, has the build in A4982 steppers)

Thanks so much,


评论 (9)

#1 – langwadt 于 2019-02-16

microstepping is configured differently on some of the drivers?


#2 – lulu3d 于 2019-02-16

I thought about that too, but where in the GRBL code I can find the config for that?! (I have no jumpers or something on this board to set microstepping)


#3 – easytarget 于 2019-02-17

Now this is a co-incidence; I fried my woodpecker last week and threw a MKS-BASE 1.5 card in it’s place. And had microstepping issues.. In particular, X was running at 1/4 stepping (eg 8x faster than Y or Z),

The one of the few bits of documentation you can find for these cards says ‘1/16 microstepping preconfigured for all drivers’, so I played around with a scope and a loupe lens. The wiring looks correct but the microstep pins on the (smd) driver were, indeed, configured wrong on the X driver. Tracing back to the resistor array that pulls these pins high I could see they were correctly powered, but the whole line still low. Looks like a (faulty production) short to ground on that line. But rather than ‘debug’ with my soldering iron I simply switched to the E0 stepper and changed pins:

//#define STEPBIT0 0 // X Step – Pin A0
#define STEPBIT0 4 // X Step – Pin D26 (E0 step)
..
//#define DIRECTIONBIT0 1 // X Dir – Pin A1
#define DIRECTIONBIT0 6 // X Dir – Pin D28 (E0 direction)

//#define STEPPERDISABLEBIT_0 7 // X Enable – Pin D38
#define STEPPERDISABLEBIT_0 2 // X Enable – Pin D24 (E0 enable)

in cpu_map.h. This worked like a charm and my CNC is definitely a bit nicer with bigger buffers ;-)

(PS: This card is an oddball, only ever shipped with some cheap printer kits, Tevo’s, He3D etc..and quite possibly itself a clone of a clone but I digress.)


#4 – lulu3d 于 2019-02-17

Hmm Easytarget, this may well be a good explanation, I’m afraid. I guess this is exactly what’s happening with my card. Strangely I never had problems while using it for my CoreXY printer (who has a nice Duet card right now ;-)) ?
Unfortunately I don’t see much options, as to abandon the dual end stop option and use the E0 and wire in series. Oh well.., cheap chinese stuff, be prepared for some surprises.. lol.


#5 – lulu3d 于 2019-02-18

OK, guess what? I reinstalled marlin 1.9 and tested the steppers using Repetier Host. The result is, that all steppers behave normally?!?! There must be some difference in how Marlin 1.9/2.0 and GRBL uses these microstepping settings for this board. I prefer to go with GRBL, instead of continuing with the Marlin CNC, but I’m a bit lost at where to look to correct the behaviour in the code. If someone have a clue, please don’t hesitate to share your thoughts ;-)


#6 – easytarget 于 2019-02-18

Microstepping is done in hardware on RAMPS boards. (It’s different on advanced cards like the Duet, where you can set it in the config, they use advanced driver chips and have additional bus hardware/software to talk to them digitally.

On our boards the microstepping is configured by hard-soldered pin voltages. The ‘steps/mm’ value you enter to marlin/grbl is in motorsteps*microsteps. Neither grbl or marlin know, nor care, about the microstepping factor, they assume you have set your steps/mm correctly to allow for it.

Finally; if you reconfigure your X motion onto E0 you have only changed the motor control pins, nothing else, the X limit pins and operation will remain the same


#7 – lulu3d 于 2019-02-18

It’s all OK, I close the subject. Thanks easytarget for your explanations. I decided to go with Marlin and the dual z setup for my MPCNC, although I would have preferred going the GRBL way. I just don’t have the time and knowledge to check it all out to have it work in GRBL, and the Marlin way works for me.


#8 – easytarget 于 2019-02-18

Good luck! marlin is not a terrible choice ;-), and twin Z motion isn’t really built into Grbl (the grbl-mega5x port has stepper pairing, I think).

If you want to go the grbl route I’d suggest looking at the esp8266 port of grbl:
https://github.com/bdring/Grbl_Esp32
(I have one of the developers cards destined for a large laser rig, I need to duplicate both the Y and Z axes, which I will do with a breakout board and external wiring, not config.)


#9 – reisher 于 2024-02-04

> Now this is a co-incidence; I fried my woodpecker last week and threw a MKS-BASE 1.5 card in it’s place. And had microstepping issues.. In particular, X was running at 1/4 stepping (eg 8x faster than Y or Z),
>
> The one of the few bits of documentation you can find for these cards says ‘1/16 microstepping preconfigured for all drivers’, so I played around with a scope and a loupe lens. The wiring looks correct but the microstep pins on the (smd) driver were, indeed, configured wrong on the X driver. Tracing back to the resistor array that pulls these pins high I could see they were correctly powered, but the whole line still low. Looks like a (faulty production) short to ground on that line. But rather than ‘debug’ with my soldering iron I simply switched to the E0 stepper and changed pins:
>
> “
> //#define STEPBIT0 0 // X Step - Pin A0
> #define STEPBIT0 4 // X Step - Pin D26 (E0 step)
> ..
> //#define DIRECTIONBIT0 1 // X Dir - Pin A1
> #define DIRECTIONBIT0 6 // X Dir - Pin D28 (E0 direction)
> ...
> //#define STEPPERDISABLEBIT_0 7 // X Enable - Pin D38
> #define STEPPERDISABLEBIT_0 2 // X Enable - Pin D24 (E0 enable)
>

>
> in cpu_map.h. This worked like a charm and my CNC is definitely a bit nicer with bigger buffers ;-)
>
> (PS: This card is an oddball, only ever shipped with some cheap printer kits, Tevo’s, He3D etc..and quite possibly itself a clone of a clone but I digress.)

Any additional things you did?
I have the same issue and I applied the changes and connected it to e0 but it behaves weird and does not move at all on X


原始Issue: https://github.com/gnea/grbl-Mega/issues/90

喜欢 (0)