Question about GRBL's Homing function and strange Z Axis stepper behavior

Mostly Printed CNC - MPCNC Troubleshooting
1

I’m working on my first MPCNC machine, and it’s coming along quite well. I’ll post some pictures in the next couple of days.

I have one new middle Z part left to print and should have that done tomorrow, then I’ll see how well the gantry goes together.

In the mean time I have X and Y motion working well, and have the Z Axis motor in its mount just sitting on the desk and have that working (sort of).

Running a UNO with a CNC shield.

I’ve added limit switches for X and Y and was playing with the Homing function ($H) in GRBL. For now I’m faking the Z Axis limit switch action manually.

When I issue the $H command the Z Axis starts spinning and when I pulse the Z Axis limit input on the CNC shield then X and Y move quickly to the limits and stay there until I pulse the Z Axis limit input again, then X and Y move to “center” and life appears to be good. Hard limits work fine too so things won’t crash and burn by trying to go past the physical limits.

Here’s the strangeness:

If I set the Homing seek ($20) in GRBL to 200 mm/min the X and Y axis appear to move just fine, but the Z stepper stutters, and doesn’t rotate smoothly.
If I drop the Homing seek to 120 mm/min then the Z stepper appears to rotate smoothly. GRBL uses the specified Homing seek rate for all 3 axis.

I haven’t tried swapping out the Z Axis stepper to see if there is something wrong with it. It appears to be wired correctly and is running smoothly at the slower rate.

I haven’t swapped the driver module, but I’ve tried different current settings low and high with no difference. I’ll try swapping the driver out first since that easier. If that doesn’t change things then I’ll swap the stepper out, but that will be more of a pain since don’t have a spare.

Note no micro-stepping involved at this point, and I need to fine tune things for the number of teeth on the pulleys, etc. This is just an early test to get everything working.

Has anyone seen something similar?

Is anyone using the Homing function with their MPCNC? If so where did you put the limit switch(es) for the Z Axis?

Thanks in advance,
Burt

2

I’m not sure about the uno but we hit the processing wall on the z-axis on the mega.
Check your step rate, step/mm, and how fast the uno processor is.

On the mega with 32nd stepping and 5/16" we max out the processor at about 16.8mm/s for the z axis and 197mm/s for the x and Y. Huge difference. If you can step down to 16th stepping and you can go faster.

3

Would one of the 32 bit boards that are available work as seamless replacement for RAMPS and Mega combo that most of us are using? This would allow us to use that 32nd stepping with no concern about processor speed.

4

Well, Burt says he isn’t using microstepping, so he’s probably way under the limit, but that depends on Burt being in the right ballpark for steps/mm. What steps/mm are you using Burt? Are you starting with the 4500ish number from the stock machine?

I haven’t used grbl, but this page (for 0.9, not sure what version you have) https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9 Shows that $20 is a boolean, and there are other limits (separated by axis, $110, $111, $112) for speed. Can you try with just adjusting the speed, and then driving it to a position manually to make your test easier?

Jason, Are you talking about the ramps FD with an arduino due? http://reprap.org/wiki/RAMPS-FD . You could definitely get that to work, but I don’t know if the screen works, and the marlin firmware doesn’t seem to support it natively, AFAIK (there is a marlin FD fork on github). I’ve used repetier firmware on my mega, and it seems to act very similar, so you could switch to that.

The easier thing to do is just remove the jumper on the Z axis, to go to 16 steps and reduce the steps/mm by 2 on just the Z axis. With 2k steps/mm instead of 4k steps/mm, I doubt there will be a noticeable difference on the Z.

5

Thanks All,

Yes, right now not doing any micro stepping. I was starting with some fairly slow values.

Initially I’m starting with defaykt feed if 250 mm/min and default seek of 200 mm/min

Acceleration at 10 mm/sec^2 Homing feed ($20) which is what is being used to set the common feed rate for homing on v 0.8. v0.9 has split those out but I’m currently not running v 0.9 GRBL. The step pulse width is set at 10 usec

So I have homing feed set to 250 mm/min which is used for the 3 axis. X and Y appear to be just fine but Z is just sputtering around at that rate. If I drop the common homing feed rate to 120 mm/min then Z runs smoothly. Again in this case I’m not driving the z Axis assy, just the Z motor in the mount with the coupler pressed against the bearing as recommended in the assy instructions. But just in case I even pulled the coupler up a bit to make sure that nothing was binding. After that test I pushed the bushing back down tight on the bearing as there was no change.

I do have a Mega and there is a RAMPS board on the way so I may need to test with that.

I was just surprised that the Z Axis was behaving the way it does when X and Y (with the two steppers in parallel) appears to move just fine.

I have to compute the finally steps/mm and other bits since I’m just using something that is fairly close (as measured with X and Y axis movement.

The steppers are ones that I had gotten a couple of years ago when I first was considering building a CNC machine but had too many other projects going on to get to it until now.

They are Minebea 17PM-K402-P4V
Basic specs are:
Rated voltage 6.00 Rated current per phase .80 Winding resistance 7.5 ohms per phase Holding torque 3400 g-cm Rotor INertia 75 g-cm^2 Detent Torque 200 g-cm

If I need to I’ll change out the steppers, but it seems like these should work OK.

Currently running with a 12V power supply. Maybe I need to increase to 24V?

I don’t think that it is a bad stepper since I had tested with the steppers and a simple program on the UNO a while ago and they all appeared to perform the same. So baring a failure while the motor was sitting around I expect the issue is elsewhere. I may pull the Z axis driver and install it on a 2nd CNC shield / UNO that I have sitting around and test the stepper there, unless someone sees something that leaps out in the basic GRBL settings.

Burt

6

Ryan’s idea was that it was not able to step fast enough, which depends on the number of steps/sec. Which is the steps/mm * mm/sec, so you’ve only looking at half the equation. In the final machine, with 32nd stepping, the number will be near 4500, which is a lot different than the 200 for x, y. What do you have them set at?

Also, what is attached to the Z? Just the coupler, to the threaded rod, through the bearing? Do you also have the nuts on at the end?

7

Wasn’t referring to any specific board or combo… Currently the default config is a Ramps 1.4 + arduino. I was wondering if there is a 32 bit board available that would basically a swap in seamless transition.

8

I plan on moving to 16th stepping for a few reasons so this shouldn’t matter too much. 32 bit might help withe the laser stuff a bit but for everything else no worth whatever extra it will cost.

9

OK, I figured it out. One of those Duh! moments. I hadn’t looked at the docs for the micro stepping in a LONG time so I made the assumption that no jumpers was Full step. Of course it was Sixteenth Step.

What I’ve found so far is that I do Quarter step and run everything at 500 mm/minute.

I couldn’t do any better than about 120 - 170 mm / minute on Z with Sixteenth micro step on the UNO.

So I’ll do some more testing but I may have to wait for my RAMPS board and integrate that with my Mega to nudge the processing speed up a notch, but for now it’s working better for testing and I’ll dial in the configuration a bit more while waiting for the last Better Middle-Z part to finish printing.

Sorry for the oops on the micro-stepping, I guess what really amazed me was that the X and Y appeared to be working OK (but maybe they were missing some steps that weren’t obvious.

In any case I’ve cranked the seek speeds up to 500 mm/min which seems to be a pretty safe value for right now.

Burt

10

Must actually be having a Senior Moment. I re-read the jumper mapping one more time and I was correct originally. If no jumpers are installed then the stepper should be doing full steps.

So it is still a bit strange. With the drivers configured for micro stepping I was able to get the Z Axis working at a higher seek rate but something is still a bit funky, so I’ll have to do some more digging and wait for the RAMPS board to get here.

11

OK,

Now that I, finally, have the correctly jumpers set for 8 micro steps things are much better. I still can’t get the Z Axis to run as fast as the X and Y but it is tolerable for now.

Looks like the UNO just runs out of steam when trying to keep up with the Z Axis at the same seek rate as the X and Y axis, which makes sense since it takes many more steps to move Z one millimeter.

The good thing is that I have X and Y (and most likely Z) pretty well dialed in. When I move 10 mm it is about as close as I can measure it to 10mm. And I expect that the Z should be correct too, but won’t really know until I can work on getting the middle completed and the Z Axis fully installed and mounted.

Then I’ll see how it goes when I get the RAMPS board try that with my Mega that is sitting idle right now.

Now off to neaten things up to get a few pictures in the works.

12

If you aren’t changing the grbl firmware, or setting the steps/mm with gcode commands, then it is making sense.

The arduino doesn’t know anything about the stepper driver configuration, so when you remove all the jumpers, it sends out one pulse, which rotates the stepper 1.8deg. So when you have no jumpers and you ask for a 1mm movement, it steps 4500 times (if this is what your steps/mm is set to in grbl), which is 2500 degrees. Way too much, and if it’s doing that very fast, then you will have problems of the physical hardware not being able to keep up. If you add some jumpers, then it takes 16 steps to move 1.8degrees, so it will only move 156 degrees in the same amount of time, which is at least physicall possible.

Whenever you change the jumpers, you also have to change the steps/mm in grbl, either by configuring and reflashing the arduino, or by using the gcode/$ commands to set them.

13

Yes, I finally got things sorted pretty much with getting the proper steps / mm adjusted for the number of micro steps. And I didn’t realize initially that it would take a LOT more steps to get Z to move the required distance, so when the movement rate was set high then Z became the limiting factor.

For one of the other responses I just had the Z motor mounted with the coupler pressed against the bearing in the Z motor mount. No rod, nuts or anything else.

I was changing the GRBL configuration settings using the $N commands.

I upgraded to GRBL 0,9 and it is MUCH better. Much smoother and I was able to bump the speeds up approaching numbers that others were discussing.

Reproducibility of positioning looks to be quite good.

I’ll still be interested to see how the Mega / RAMPs configuration compares, but certainly for right now it’s looking pretty good. I can get Homing working after a fashion since don’t have a real Z stop yet, but sometime I miss manually triggering the Z stop during the Homing cycle.

BTW, v0.9 swapped the spindle control and the Z stop pins. I took the easy way out and just moved my Z-stop cable to the (previous) spindle control pin on the CNC shield and that appears to be working fine.

I have my middle piece ready to install so probably tomorrow I’ll have that in place as well as the Z axis installed, then the fun will begin for sure.

Thanks all,
Burt