Mpcnc jittering / Shaking

Hello fellows,

I am kind of frustrated with this issue, my Mpcnc is executing the Gcode with stoping in between coordinations for 10-30 milliseconds as you can see in the video. This is leading to jitter effects and unsmooth movement of the X and Y-Axis (Only with Curvy movements) Linear movement seems to work as usual. Important to know is :

-The Mpcnc had a perfectly smooth movement just before I decided to change the setup to Dual end-stop and flashing the new firmware. Before it was wired in series with an older version of Marlin.

-The issue has nothing to do with the belts because I tried to execute the same Gcode without any belts and the steppers did also show the same jittering effect.

My Setup :
Rambo1.4
MarrlinV2.0
Power supply 12V 6A
All hardware bought from V1 Engineering
Control software: Repetier-Host

here are 3 Videos to show the problem from 2 perspectives, please pay attention to the sound.
Perspective 1
Perspective 2
Gcode

I am very thankful for any help!

I have no idea about your problem, but a couple of ideas on how you can collect more information.

  1. There are a couple of different versions of Marlin you can try. The latest version you can find here, and an older version can be found here. Note that the older version likely will not compile using the Arduino IDE but will compile using platformio. You could list the version of Marlin you are using to demonstrate the problem.

  2. If you have a display, you could try a run off an SD card rather than using Repetier-Host over an USB cable and see if that makes any difference.

  3. I doubt the issue is g-code related, but since you had a video of your g-code file, you could attach the file to this question. I believe that g-code files can be attached directly, but if not, they can be put in a ZIP file.

  4. If you have the source code for the serial version that worked correctly, you can compare the Configuration.h and the Configuration_adv.h from that version with your current version. If you don’t already have one, there are a variety of free difference tools for text files. And if you are not comfortable with this task, you could attach both the new and old versions of these files in a ZIP file to this question for someone else to take a look at.

  5. If you still have your Y cables from your serial setup, you can plug your dual connections that are currently at the board into the Y cable and revert to Serial. This will allow you see if a current Serial version of Marlin has this same problem without having to undo any of your dual wiring.

Again, no solution but a list of the kinds of things I might try as next steps to collect more information if I had this problem.

Hey Robert,
I am really thankful for your answer! These are the stuff that I have tried as you suggested.
1- I have tried to flash many older and new versions of marlin but this didn’t change anything.
2- Also tried to send the G code through the SD card again it didn’t change anything.
3- I will attach the Gcode here but I also tried the classical Crown test again with the same problem.
4- I sadly don’t have the Marlin version I had earlier because it was the original which was already flashed as I bought it.
5- I don’t have the old cables anymore and to connect it on serial again could be a lot of work as I don’t really think that I have a wiring issue.

I am really stuck on this. Cannot think of anything more I can try. Is there any important stuff in any Marlin version that I have to consider changing or checking at least? Do I need to post-process the G code or do something before sending it? Could it be an issue of low current because it can maximum output 6A?

I would be very very thankful for any help!

curves Endstopper test3.gcode (61.9 KB)

If this relates to a Marlin setting that has changed, you need someone with intimate knowledge of Marlin and perhaps an understanding of how Marlin has changed over time. Let’s see if @Jeffbe3 has some idea(s).

Note that the things you’ve tried, especially running the g-code off an SD card, have eliminated several potential sources of the issue. I have two ideas of what might be going on…more driven by my playing with Arduino boards than anything I’ve seen with the MPCNC. The first is that you are needing g-code to be handled faster than Marlin on the 8-bit microprocessor can process it. The second idea is that you are running into a timeout issue of some sort.

If this was my issue, I’d author a cut of a square, a large circle, and a curve. I’d unplug all unnecessary electronics including end stops and the USB connection, and I’d run the specified cuts at different feedrates off of an SD card. If the problem occurs regularly at different feedrates and/or for different kinds of shapes, then it suggests to some sort of timeout issue. If it varies with the type of cut and/or the feedrate, then it suggests a throughput issue.

Note that throughput issues can be mitigated in many CAM programs. G-code cuts curves by breaking the curve into line segments, and there is a tolerance that determines the length of those line segments. The looser the tolerance, the less line segments are generated for a given curve. Looking at your g-code I doubt this is the issue, but I’m not sure. I calculated of a few line segments that were sketching the curve, and they were around 1.5mm which doesn’t seem overly tight to me.

I don’t know what CAD/CAM program you are using to generate your g-code, but do see a serious issue in your g-code. I don’t think it has anything to do with the jittering issue. Your feedrate is too fast for the lead screw on the Z axis. Most Z feedrate limits I see for the MPCNC are around 500mm/min. Take a look at these three lines:

G1 F2942
G28 R30 X Y
G1 X0 Y0 Z47

You are attempting to move Z at nearly 3000 mm/min.

During most of the “cutting” moves, your Z feedrate matches your XY feedrate of “only” 1597mm/min, which is still 3x what I think the maximum feedrate for Z should be. The reason I don’t think this is related to your jittering is because Z does not change during the “cutting” moves, so the high feedrate should not have an impact.

First, related to the marlin config. From the old version to the MarlinBuilder releaaes, we tried to mostly just recreate the same settings, but with a scripted, more repeatable update system. The MBR do track the current stable version of Marlin. Any number of things could have happened in Marlin, but there are a lot of users on these versions and I haven’t seen this issue.

Onto the problem. The main two sources of this are: 1. The gcode is asking for arcs (G2/G3 commands) and the cpu can’t do the trigonometry fast enough. Ryan tested this a bunch with Jamie and they came up with settings that should be fine even for the 8bit rambos. You’re not using G2/G3 anyway. Or 2. The commands are so short that they aren’t getting to Marlin before the tool is finished with the last move. Ironically, replacing a lot of little moves with arc commands can fix that issue. So it is worth a try turning on arcs in your cam software and see if that huge arc can become just one command.

Adding to the data that this might be #2 is the streaming gcode view. It looks to me like it pauses when repetier host sends M105 (which requests temperature). I am guessing the gcode is coming in just in time and the slightly longer M105 is causing a visible pause. You should see if you can turn off the temperature updates in RH. It may still be pausing, but not as long. Adding arcs might be enough to speed it way up.

It is also worth mentioning that a bad usb cable can make a large fraction of the characters fail to get sent the first time. The result is that even a 250k connection will slow way down. A new usb cable could help. If you use an LCD with an SD card, you will get much more reliable and faster gcode playing. They are not expensive, like $10.

1 Like

Hey Robert,

Thanks for answering again! I did the test as you suggested, I also attached a picture and the Gcode in the post. I have drawn An array of rectangles Circles and free curves in order to test the Issue. I then made 3 versions out of the exact same geometry, in each I tried different tolerance of line segments. To make it clear I have built my own algorithm which generates the Gcode out of any drawn curve. Here are the results:

  • The Geometry plays a role when this jittering happens, it doesn’t happen at rectangles at all because it is just 4 commands of Gcode I guess. In Circles and free form curves it happened but with a kind of random pattern, I mean I couldn’t realize any connection between the Gcode commands and the time this Latency is happening even in a circle that should be regularly splitter in equal segments of lines.
  • This happens as well for different feed rate speeds. it almost didn’t play a role.
  • For the three versions of Gcode with different curve tolerances it also didn’t change much for the curves where there are dense line segments (small tolerance). it worked well without jittering as the circle wasn’t smooth anymore but this is not what I am trying to achieve. Somehow this problem occurs only for curves which I don’t understand.
  • Very important thing is that the Gcode I generate with this algorithm used to work perfectly before upgrading to dual stop. that’s why I am eliminating the issue that my Gcode is shitty.

yeah about the Z I know that I have a crazy feed rate but I am not using it yet for cutting that’s why it’s not a problem. And it’s definitely not related to the issue as you said.
I don’t really want to use these G2 G3 Commands to give arc movements as @jeffeb3 Jeff suggested because then I have to use a Cam software which I am trying to prevent. I generate my Gcode in a custom generated algorithm Grasshopper/Rhino environment if you are curious to know.

Could it be any Current electronic issue? is it possible that I damaged the Board while upgrading. Or maybe not enough current going to the stepper motors.

This issue is getting me crazy, I am completely out of ideas about what to try next.

Latency delay troubelshooting test Tolenarnce 0.015mm.gcode (63.9 KB)
Latency delay troubelshooting test Tolenarnce 0.002mm.gcode (173.6 KB)
Latency delay troubelshooting test Tolenarnce 0.055mm.gcode (34.4 KB)

Not really. If the steppers were losing steps, you would have errors in the shape. Once it started again, it wouldn’t know it lost steps.

The pieces on electronics that I think are involved are the USB cable and the USB to UART chip.

A test running from an SD card would be really helpful. It is possible the software has a bug that is causing the pause, but it is also very possible the software is handling the incoming gcode differently. I don’t know how old the firmware you had was, but it is possible to find older firmware if we knew how old.

Hey Jeff,
I did the test on the SD card as well, the results were almost the same!

Well. That is surprising…

@vicious1, I wonder if this is related to the laser artifacts you were seeing.

Hi Kinan,

You’ve had a frustrating time. I have a next step and I’m sorry I did not think of it sooner. Someone should run your g-code on their (same/similar) machine to see if it exhibits the same problem. I have a Rambo 1.4 and dual end stops. Unfortunately I’m out of town for the holiday. If no one else gets to it, I’ll be glad to run your g-code on Monday evening. This would be a very telling test.

Also I wanted to make sure you ran your SD card test with all non-essential cables unplugged from the control board including the USB cable and the dual end stops wiring.

Your gcode is set to 6 decimal places, that is too much. Two is fine, three is pretty serious. There is also no reason to send Z0 with every command. I think you are just flooding the planner.

Also whatever you are using to generate it check your accuracy setting, maxing that out is unnecessary.

The crown test is the best way to test new firmware. I am seeing this as a CAM problem/accuracy overkill. Best guess. Try the crown if that doesn’t work we have an issue.

2 Likes

You are also trying top run at 65mm/s. The firmware is limited to 50.

1 Like