You should be famous 
. I’ve been mentioning gcodeclean in other forums when it’s appropriate and picked up a few users for you. It’s especially great for CAM program that don’t use rapids for retracts, plus the arc conversion from zillions of teensy line segments that can make grbl choke
So for anyone who is following this thread… I changed my power source from 5 amps to 10 amps. I wiped all of my settings and reinstalled M2.
Still the same jittering, same location as before. No improvement.
Next, I’ll try the G-code optimizer
Here’s something I just noticed. With even slight hand pressure on the sled, it deflects downward about an 1/8". I’m not sure where the deflection is coming from, but it appears to be from the chains (sled is centered). I assume this is accounted for in the variable such as chain sag.
Has anyone considered using stainless aircraft cable instead of chains?
the specs on cable stretch are worse than chains. There’s also the problem of
getting a good grip on it if you aren’t winding it on a spool, and if you are,
the variable diameter as it layers on top of itself is a problem.
we’ve talked about it and found issues. doesn’t mean the issues can’t be solved,
but it’s not a no-brainer win.
David Lang
David
I did raise my top bean 12" yesterday. Still have the stutter although it has changed ‘frequency’. It seems more widespread out (wider) than before. The sled still hops up at about a 10-12" interval as it moves along the top of the arc. This seems like a communication break. I’m using the Rasp PI4 webserver.
I have gone back to Fusion to simplify my arcs, but there is no improvement.
I there a more powerful processor than the arduino that I can swap-in?
I’ve been looking on Amazon and I see a NodeMCU that uses the Arduino IDE
Thanks
Can you tell if its one motor or both that are causing the jumps? I don’t think it’s a processing power issue, maybe it’s a driver power issue? The fact that it only happens at the top of the sheet makes me think that it’s related to how much strain the motors are under because that is the region where they have to work the hardest.
Hey David
I’m still fighting the motor stutter problem. I was thinking about changing out the x-y motors, but then I seem to recall that someone mentioned Arduino motor stutter. I looked on-line and there are many posts addressing this same issue. Evidently the Arduino CPU is so basic that it cannot handle complicated switching back and forth. I also think that the very slow baud rate on the M2 may be a contributing factor. Have you heard anything in that regard? I suppose I’m the only person facing this problem. Probably because I’m trying to long arcs using the full 4x8 sheet.
I’ve ordered a NodeMCU controller and motor shield which is Arduino IDE compatible. May be wasting more time, but I need to get this problem solved.
Also, my sled will not go to 0,0 in Calibration. I suppose I need to reset my chains once again…
Thanks in advance
have you posted the gcode in question? especially if you have run it through the
optimizer and still have a problem, it may be orth taking a look at it.
David Lang
Not yet. Hopefully today I can recalibrate and try the cleaned gcode. If, after that it still stutters, then I will post the code
David,
I just reset my chains and to save some time, I did not do either edge or precise calibration. I loaded and ran an Inkspace/Easel svg gcode file. The stutter has changed. Now instead of being at the top of the arc it occurs when the sled is moving down and across to the lower right.
The next experiment will be to bypass the Raspberry PI4 wireless and hook up a usb cable to an old laptop.
I’m still thinking that the Arduino is at fault–not enough horsepower. I will let you know what happens
In the meantime attached please find two gcodecleaned files and one Fusion gcode file (24.3kb).
Let me know if you see anything strange.
I do greatly appreciate your assistance
French Curve GRBL, 8-28-2021–1st pass.nc (24.3 KB)
Easel French Curve 48x96, 8-31-2021.nc (232.2 KB)
FrenchCurveGRBL-gcc.nc (3 Bytes)
David
My experiment to bypass the PI4 wireless worked. No stutter–gone. Albeit I haven’t cut anything yet. I just did a aircut to see if there was any stuttering and there was none. I will try cutting something tomorrow.
No all I have to do is figure out why the streaming gcode is stuttering over the wireless.
I did use the gcodecleaned file from my earlier post
BTW, the sled will still not return to home. I do it manually. I get an error message stating something about a soft limit. This is after pausing the routine half way through and then requesting the sled to return home.
Thanks for your help
1 Like
does your raspberry pi run the desktop version of the raspberry pi operating system? Are you running makerverse on that raspberry pi and using the browser on the same raspberry pi to operate it?
can you show us a picture or video of the problem happening.
Orob
I was running the Makerverse webserver image on the PI4, using the wireless capabilities to connect with my laptop indoors. My frame is too big to fit in my garage so it is in my driveway in front of my garage door. I am using a usb video webcamra plugged into the PI4 to monitor movements. I am also using a wireless ‘hotspot’ to boost the signal since it needs to go thru a couple of walls to get to my router and laptop inside.
I still need to use the wireless approach but for now I’m just happy to be able to cut something.
David
I will need to go back to the wireless setup in a couple of days. For now I just want to be able to cut my arcs. I do prefer to use the wireless system for remote monitoring. I also don’t want to leave an unattended laptop in my driveway.
Maybe I can get back to it Monday, Labor Day.
Thanks!
Hey All
Back again after a hiatus. For a brief moment I thought rhat I had solved my jitter problem by directly connecting to a laptop using usb. Not so. The jittering problem has just morphed. I replaced both X-Y motors, then I replaced the M2, thinking it might be a bad capacitor. Still have the jittering problem. Tried the usb cable aain (bypassing the Rasp PI4 webserver) Am using the latest version of Makerverse with the new M2.
My arcs are still jittering. Now it is most prevalent when the sled is moving downward.
It appears that this is not a hardware problem.
My drawing file was created in Autocad, then ported into Fusion. I also used Inkspace to create an svg file that was converted in gcode. Then I tried importing into Easel and exporting its gcode. I used David’s gcode cleaner. It greatly reduces the file size, but I still get jitters. Not cutting anything, just doing air cuts with weights that approximate the routers weight.
All approaches yield the same result: jitters. BTW, I tried moving my sled horizontally across the wasteboard and it jitters, which is why I replaced the M2. I also wrapped my motor cables in aluminum foil thinking it might be an RF problem. No change, still jittering.
Is it possible that Grbl cannot process large arcs? The arcs are over 8’ long, extending from upper left to the lower right corner.
My other thought, previously mentioned, is that Arduino Due is just too slow, or the baud rate is too slow. I’ve seen other comments online that Arduinos cause motor stutters with servo motors.
Does anyone have any ideas?
This is potentially possible, it could be an issue with floating point math on the arduino. Basically what happens is that the arduino uses a type of math called “floating point” which basically means it isn’t able to do perfect calculations and those small errors could be adding up. The solution there would be to export the gcode with only straight line G1 commands.
My second thought is that maybe it is a PID tuning issue. Maybe the control system is jittering for some reason, but I can’t think why that would be or why it would only be happening on arcs. Just thought I would throw the possibility out there.
Thanks bar
I’m familiar with floating point. 15 digits to the right of the decimal point. This would defintely slow things down since I believe arcs are processed as a number of lines–at least in Acad. I wonder if there might be a g-code command that would truncate this down to three or four places? I suspect that probably wouldnt change anything at the processor level
I’m unclear about PID. What is that?
The problem is that 15 points to the right of the decimal requires double
precision floating point. The Arduino only supports single precision floating
point (~5 digits in scientific notation IIRC).
You can send longer numbers to the arduino, but it will silently truncate them.
I think the gcode cleaner that Lee wrote has an option to trim decimal places
(webcontrol and groundcontrol do as well). I thought the gcode cleaner had an
option to replace really shallow arcs with stright lines.
If this is repeatable, please try to narrow down what part of the work this is
happening at, and then e can examine the gcode to see if something odd is
happening there.
David Lang
1 Like
Would it be possible in your opinion to emulate this effect? e.g. import the “offending” g-code file into Matlab, manually truncate the resultant doubles using different levels of precision and plot the deltas? Would this approach even make sense given Maslow’s theoretical accuracy of (I believe) 1/32 inch?
Does the PID incorporate any anti-windup mechanism?
Would it be possible to emulate the loop’s ideal behavior taking the manually truncated file as a reference and then feeding it the non-truncated version and looking at the deltas in behavior? (just spitballing here in case it wasn’t already obvious 
)
It would be tricky since the emulation would be running on a 32 or 64 bit computer while the actual gcode is running on 8 bit Arduino mega. Can you try some of the suggestions in this forum thread to see if the issue is the very large arcs being computed on an 8-bit computer:
I don’t think that there is a specific anti-windup mechanism, but the derivative term should prevent the windup from causing overshooting.
1 Like