Mpcnc jittering / Shaking

Mostly Printed CNC - MPCNC Troubleshooting
1

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

126807002_692058777978456_2227957737566056688_n
126807002_692058777978456_2227957737566056688_n1125Ă—1125 169 KB

I am very thankful for any help!

2

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.

3

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)

4

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.

5

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
6

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)

TestLatency
TestLatency1064Ă—644 166 KB

7

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.

8

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

9

Well. That is surprising…

10

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

11

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.

12

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
13

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

1 Like
14

Hello, @vicious1, @jeffeb3 , I really appreciate your answers! I mentioned a few things in an earlier post perhaps I need to repeat it to make some stuff clear:

  • The exact same Gcode used to work perfectly without any issue on my older set up ( Some older version of Marlin, series wired and without dual end-stops.
  • I already did the crown test and had the exact same issue.
  • I printed these tests from the Sd card and removed the serial Cable and the endstops as well in order to maybe easily identify the issue as @robertbu suggested.

I modified my Gcode anyway as you suggested and made a small test again. The average line Segments length is 1.5mm which i think is totally fine. I even removed the Z0 and reduced the speed. This didn’t change anything at all. I attached two videos and Gcode, one for a freeform curve and the other for a circle. It is really hard to detect any pattern at what time this delay is happening, seemed like it doesn’t not really have anything to do with the geometry, because when i send the same Gcode again it happens on different positions. The weird thing is when drawing a circle it might happens only 3 times for the first half and then it works perfectly, which does not make any sense for me.

Here is the Gcode i am not sure how helpful it is to run it on your own machines, it is possible to print on 500x500 Cnc machines.

Please pay attention to the sound in the videos!

This issue is driving me crazy! I would be very thankful for any help !

Freeform test
Circle test
Fixed Gcode Lattency Issue 2 tollerance 0.01.gcode (21.3 KB)

15

It must be ghosts. :ghost:

Did you have repetier host connected when you were running from sd card?

When, approx. did the original working firmware come from?

Are you on v508 of the new software?

Experimentally, this all points to some bug in Marlin in the latest firmware. But what is getting me is, this firmware has been tested with the rambo and we haven’t seen this issue.

16

It is best to stick with the test crown then for any tests as this has been extensively proven to work, fits on all builds, and is fairly quick. So we can all test the same thing, rule out any CAM or CAD on your end. I am not sure if I will get any work time in today but will try it as soon as I can. As this could be part of the laser issue I am seeing…but For me it is a speed thing. I can slow down and it goes away, I use the lasers as fast as possible.

Jeff’s questions are solid, waiting on those.

17

haha, ghosts seem to be the most logical answer after this hassle :slight_smile: No, as I mentioned I removed all the unnecessary cables including the USB Serial. I tried flashing the last 4 releases of Marlin`s firmware (V508 2.0.7.2, V507 2.0.7.1, V5.6 2.7, V505 ). I bought the parts in mid-2019 from V1 Engineering. If it were a bug, then how come that you guys never heard of this issue before? I am so confused!

18

All four of those releases do not work with the crown? I have tested most of those on a Rambo with the crown and seen no issues.

If that is the case we are looking for something like a bad connection. Looking at your first picture I would start by removing the power adapter you have on there and plug it in directly. The little plug to two wire terminal on your power connections is a know weak point. Cut your power wire right behind the barrel connector and hardware it like I have shown in the instructions.

19

The other thing to try is isolate your LCD cables from everything else. If they are bundled with the stepper wires like it seem to be in the first picture you could be picking up line noise.

20

Hey Ryan! Thanks for the tips.

I have tried wiring the Power connection as you have shown, I also separated the Lcd screen from the Stepper Motor wires but it didn’t change anything again.
Should I keep the Stepper motor wires bundled or this could a problem as well?