Need help understanding this problem

I’m trying to understand what is causing the problem I have with my mpcnc.
I’m drawing this gcode, 5 identical rectangles 300x30mm separated by 20mm
test 2.gcode (559 Bytes)

and this is what my mpcnc prints:

Sorry the picture quality is not great, but I think you can understand the issue: when working close to the lower left corner of the mpcnc the X-axis “loses” some millimeters, the first rectangle is ~295mm and does not close.
The bottom rectangle is the first to be drawn.
The 4 upper rectangles are pretty good, they are pretty much identical, the upper one is maybe 1mm too big.
Can you point me to the cause of this problem?

There are a number of reasons why an MPCNC can lose steps. What is strange here is that 1) you only appear to lose steps in one specific place, and 2) it is a large single slippage. What firmware are you running, and what did you use to generate the g-code? I see a few things in the g-code that are a bit strange compared to most g-code I’ve looked at:

  • I’ve never seen a T1 or a G17 in a g-code file before. They are both supported by Marlin, but I’ve just never seen any of the g-code generating tools outputting them before.

  • Line 7 which reads ‘S16000M3’ appears to be mangled. If you are using Marlin, I’m not sure if it will process this line or not. I believe the line should read, '‘M3 S16000’, and would turn the spindle on clockwise at 16000 RPM if your control board is set up to turn the spindle on at a specific RPM. If so, I’ve never seen a M3 appended to the end of a line.

  • There is no feedrate specified before your first G0 commands. In particular line 8 which reads ‘G0X30.000Y25.000Z5.000’ is executed before any feedrate commands are executed. It will be made at some default feedrate.

  • Your Z feedrate is a bit above the max suggested feedrate for the Z axis of an MPCNC. This is unlikely to be the root of your issue here.

Losing steps is typically a mechanical issue. Loose grub screws that hold the pulley to the stepper motor shaft is a very common reason to lost steps. Some sort of mechanical binding is also possible…and trying to move the steppers too fast will also lose steps.

Things you can try:

  • If you are running Marlin, you can use a M203 g-code to set the max feedrate for all three axes. If you have a display, it is likely there is a settings menu for these values also. M203 uses mm per second, and the general advice is to limit X and Y movements to 35 mm/s and Z to 4 mm/s.

  • Retry the example, but start with the paper at a different place on the spoil board. If this is a binding issue, the problem will be different (or absent) if you move to a new starting point.

  • While I don’t think grub screws are the problem, you should check them anyway.

  • Run the pre-made crown test. You can find it here.

When you run this test again, pay attention to where the bit ends up at the end of your run. Your g-code returns the machine to (0,0), so if this is a slippage issue, you should see the bit offset from the starting point at the end of your run.

There are other reasons for losing steps, but they don’t fit very well with your problem.

What speed are you running at?

The most simple explanation is you are pressing to hard with the pen. Try a felt tipped fine point with less than .5mm pressure. That explains all the issues you are having. If you were skipping steps you would have a stair step pattern on at least one edge vs the next.

FYI: he is drawing at 889 mm/s and is dropping the pen 1.2mm to start drawing. I’ve drawn nothing since my crown, so I have no idea if these are reasonable numbers.

Yikes! Absolutely not. I should have looked at the gcode, thanks for that. Try 20mm/s and less than 1mm pen pressure.

Sorry for my mistake. It was 889 mm/min…14mm/s. From his file:

G1Y55.000F889.0

and for Z:

G1Z-1.200F254.0

1 Like

Thanks for the replies, you are very kind.
I understand about 50% of what you are saying, I still have a lot to learn…
I’m controlling the MPCNC with an Arduino with GRBL 1.1h, and a CNC SHIELD V3 with A4988 drivers.
To generate the gcode I’m using a program called Cut2D Desktop.
I have no idea about T1 or G17 or S16000M3, sorry.
Could “plunge rate” be equivalent to the Z feedrate you are referring to? I can’t find a Z feedrate setting in the program I use to generate the gcode, but there is a “plunge rate”. It’s 15 inches/min. That should be 381 mm/min, is that too much?
Anyway, I checked the grub screws and they were a bit loose on the X-axis steppers. After adjusting them a bit I tried printing again the original gcode I posted, starting at the same starting point, just to see if the screws were the problem:

And I think they were! The print is perfect this time.
I’ll keep testing, and learning.
I have a question about adding Loctite to the screws to avoid them loosening again: is “thread locker” the right product? When I look for “loctite” on amazon in my country I get a lot of results, most of them being some kind of glue…

One of us! You are one of us! Welcome to the “check the grub screw” club!

3 Likes

is “thread locker” the right product?

‘Threadlocker’ or ‘thread locker’ is the right kind of product. Locktite is a brand name that originally only made thread locker products but has since branched out into a line of glues as well. I use medium-duty, ‘blue’ Locktite threadlocker for my MPCNC, but I don’t know if that is the right or best thread locker for the job. And there are other brands that make thread locker products.

And I think they were! The print is perfect this time.

I’m not 100% convinced that grub screws were the only problem here. Typically, with grub screws, you see multiple step losses during the job, not a single, large loss. You may have something binding, that, combined with the grub screws, caused the slip.

…with A4988 drivers.

You want to make sure you have the voltage reference set correctly for these drivers. Having the current set too low, combined with some other issue(s), is a possible reason to see lost steps.

but there is a “plunge rate”

Plunge rate is probably the right setting, but the actual Z feedrate being used in the g-code is 254mm/min, not 381mm/min, so I’m not sure what is going on. As mentioned above, 254mm/min is a bit beyond the recommended limit for the Z feedrate, but I don’t think that played a role in your slippage issue. I don’t know much about GRBL. Did you establish any feedrate limits when you set it up?

1 Like