Z axis acting up

Mostly Printed CNC - MPCNC Troubleshooting
1

Hi. First off all…wow, what a fun start with the MPCNC. So happy so far.

IMG_0207
IMG_02074032×3024 2.62 MB

But yes, like some others, I suffer from weird z-axis movement. I have read a lot of topics, but I can’t get my head around it. I changed the steps per mm to get the correct result. That is no issue.

It works fine with a pen. After that, I have added a router. It’s a beefy one I had laying around… specs are hardly readable.

My first tests were engraving the crown and some other models. Sometimes, the z-axis kept going lower and lower during travel up & down. I have added forced cooling on the stepper drivers, it’s not getting hot, and checked the reference voltage 0,9V for a 2A stepper. And I have changed the acceleration.

The T8 screw is running very smoothly and giving both G01 and G00 commands on the z-axis just keeps working all the time… never fails.

But when I generate a whole sequence in Estlcam, it just starts wandering off. Most off the time, it runs great at the start, but it keeps going higher and higher, just routing in free air. The Estlcam cnc program seems to be OK with nice G00 z5 commands to move back up to the clearance, followed by the G01 z-12 command to go to the next layer. When looking in repetier-host, I can see that it’s at z=-12 but actually, it is 2mm above where it started instead of 12mm lower.

So… just to be sure : if repetier host says it’s on -12 … and it’s not… then I am missing steps right ?

Painfully, it never happens when sending manual commands.
What are my best options ?

  • step1: have a program that runs without the router on in mid-air and check Z-movemens to rule out wire interference from the router mains wire ?
  • step2: have a program that runs without the router attached to see if it’s the weight of the system that does it ?
  • step3: check the temperature of the z-axis motor during all that ?

any idea’s are welcome.

SENDING:M503

echo: G21 ; Units in mm (mm)
echo: M149 C ; Units in Celsius
echo:; Steps per unit:
echo: M92 X200.00 Y200.00 Z3200.00 E200.00
echo:; Maximum feedrates (units/s):
echo: M203 X50.00 Y50.00 Z15.00 E25.00
echo:; Maximum Acceleration (units/s2):
echo: M201 X180.00 Y180.00 Z40.00 E180.00
echo:; Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo: M204 P180.00 R3000.00 T180.00
echo:; Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> J<junc_dev>
echo: M205 B20000.00 S0.00 T0.00 J0.04
echo:; Home offset:
echo: M206 X0.00 Y0.00 Z0.00
echo:; Endstop adjustment:
echo: M666 X0.00
Y0.00

2

Maybe important sidenote, maybe not:

  • running the dual endstop firmware, but not homing yet.
  • z endstop is not connected to anything ( could this be an issue )
  • I can understand missing steps when travelling up, but going down should always word right? because it’s in mid-air.
    I use an arduino-ramps system
3

I’m a total newbie here. Just in the process of tuning up my mpcnc. I noticed from the start when drawing the crown that my Z axis just got lower and lower.

Turns out the 12mm/sec crown file has Z moves at a 2100 rate. All they do is make the stepper motor whine! It doesn’t move.

For the suggested max speeds F500 should be the maximum rate for Z. Although my Z axis turns easily, F500 is still too fast.

I found F50 worked, but haven’t explored the limits yet.

Could it be that your system is doing something similar to mine. Up and down limits do seem to be different. So I suspect the erratic moves up or down are possible. Marlin doesn’t seem to limit the rate to the max as far as I can see. I thought it should?

4

Your Z motor has to move 4x faster than usual. That means you need to drop the Z speed (not just acceleration) to avoid losing steps. I’m guessing you have a 1 start leadscrew instead of the usual 4. If you reduce your max Z speed in the firmware to about 3-4mm/s, it should do ok.

1 Like
5

Hi, thanks for noticing that. I had read a topic in this forum about 4 start vs. 1 start. It was al little confusing :slight_smile:

4 start has way bigger pitch, so requires more torque, but has 4 leads to carry the load → heavier router possible

1 start has smaller pitch, requires much more steps but far less torque → smaller loads.

Is that about right ? So 4 start would be a safer / better way to go?

I’ll drop the speed and have another test , but I still can’t wrap my head around the fact that it would lose more steps when going down then when going up. I could understand that it could be that way when you are pushing down against the workpiece, but in my case, it’s happening mid-air. And going up happens with the G00 command and going down with the G01 command ( from Estlcam ) so I would assume that G00 tries to go faster then G01.

I’ll try and keep you posted. Many thanks.

6

Marlin firmware doesn’t differentiate between G00 and G01 moves.

1 Like
7

Not exactly. The 1 start has the same amount of thread (or nearly) in the nut. And in our applications, if the nut fails, it is because something ground through it. The 1 start would be useful for larger routers, because it does have more torque. But you either need to slow down, or use a higher voltage psu, or a combination.

I don’t know why it would lose steps down and not up, unless the Z move speeds in the gcode were asymmetric. If it is moving up at 4mm/s and down at 8mm/s, then that can cause it.

G0 is interpreted by Marlin as G1. Whatever soeed was used last in G1 or G0 is used for the next move, if it isn’t defined. The estlcam settings we use make sure every Z move has a speed defined. That saves a lot of headaches. But those were developed when Marlin was having trouble honoring max Z speeds. In recent versions, it is easier to just adjust the max speed in the firmware, and insulate yourself from CAM issues.

1 Like
8

Thanks for the help. Lowered the z-speed and acceleration and now it’s working like a charm. Another hurdle taken. :slight_smile:

1 Like