2D Adaptive clearing craziness

I’m surprised nobody has asked about your gcode sender.

Are you using universal Gcode Sender? If so, is it a 1.X version and not the 2.0 (nightly) build? I also use fusion 360 and I’ve never had an issue out of its grbl post processor.

I’ve had similar issues where it would carve perfect one run and completely screw up with the exact same code on other runs. The issue was UGS.

The 1.X versions use a method of sending commands where it knows how big the Arduino buffer is and sends enough commands to fill it without overflowing. The problem with this is if you tell the program to stop, it executes everything left in the buffer. The Biggest issue, and one that you are likely encountering is that this version of UGS does not, and cannot stop the machine if a line of code failed for some reason. And circular/arc gcode was ALWAYS the culprit for me. The machine thinks it reached the end of the arc but it really doesn’t causing a shift in the x-y axis positions resulting in incorrect homing. You can verify this by looking at UGS command table and you’ll see a lot of “error” showing up on the gcode arc commands.

The 2.0 “platform” nightly build (not the latest “stable” version as I found it unstable) is a better interface than the classic and it sends commands differently and more reliably. It sends a command and verifies it returns ok before sending another. I thought this would cause issues but I’ve never experienced any. It fixed ALL of my arc issues and finally made my machine reliable after months of debugging.

There is a minor annoyance with the UGS 2.0 platform version. It throws an unknown command on the tool change “T” commands. So I just modified the post processor to not spit those out. If you do a find for “T” (including quotes) in the post processor, you should find a couple of places. The only place that really needs commented out is the line that has the “T” and the “M” on the same line.

1 Like

Good info, @JoshuaHendrix. I think a lot of problems are caused by the popularity of UGS.
That said, the OP said he’s run adaptive toolpaths with helical ramps without issue previously.
The sender could always be the issue, though.

The errors for me would occur erratically. Like I said, mine would work perfectly for a while and then decide to throw lots of errors and mangle my parts with the exact same code.

I believe its absolutely possible his experience could have been fine for a while and then have errors pop up on this carve.

And running the checking feature would verify its proper code but when it executed, it still errored for me. The 2.0 build fixed all my issues.

Try CNCjs

I attached the Fusion file to the original post
Thanks

$0 = 10 (Step pulse time, microseconds)
$1 = 225 (Step idle delay, milliseconds)
$2 = 1 (Step pulse invert, mask)
$3 = 2 (Step direction invert, mask)
$4 = 0 (Invert step enable pin, boolean)
$5 = 0 (Invert limit pins, boolean)
$6 = 0 (Invert probe pin, boolean)
$10 = 3 (Status report options, mask)
$11 = 0.010 (Junction deviation, millimeters)
$12 = 0.002 (Arc tolerance, millimeters)
$13 = 0 (Report in inches, boolean)
$20 = 0 (Soft limits enable, boolean)
$21 = 0 (Hard limits enable, boolean)
$22 = 0 (Homing cycle enable, boolean)
$23 = 0 (Homing direction invert, mask)
$24 = 50.000 (Homing locate feed rate, mm/min)
$25 = 800.000 (Homing search seek rate, mm/min)
$26 = 250 (Homing switch debounce delay, milliseconds)
$27 = 2.000 (Homing switch pull-off distance, millimeters)
$30 = 1000 (Maximum spindle speed, RPM)
$31 = 0 (Minimum spindle speed, RPM)
$32 = 0 (Laser-mode enable, boolean)
$100 = 200.000 (X-axis travel resolution, step/mm)
$101 = 200.000 (Y-axis travel resolution, step/mm)
$102 = 800.000 (Z-axis travel resolution, step/mm)
$110 = 1200.000 (X-axis maximum rate, mm/min)
$111 = 1200.000 (Y-axis maximum rate, mm/min)
$112 = 800.000 (Z-axis maximum rate, mm/min)
$120 = 100.000 (X-axis acceleration, mm/sec^2)
$121 = 100.000 (Y-axis acceleration, mm/sec^2)
$122 = 100.000 (Z-axis acceleration, mm/sec^2)
$130 = 315.000 (X-axis maximum travel, millimeters)
$131 = 400.000 (Y-axis maximum travel, millimeters)
$132 = 80.000 (Z-axis maximum travel, millimeters)
ok

Thanks for the recommendation. I am currently using UGS 2.0 and having the issues. I also tried the previous version and gives me the same result. It also doesn’t show any error when running.
I usually would manually erase the T2 M6 line. How did you change it on the post processor?

The displayed work coordinates does not show an offset when the bit returned to intended zero although it is physically offset as well!!!

This indicates a problem with something mechanical or electrical.

What post are you using? I have a couple modified ones based on generic grbl.

What machine do you have? Maybe the acceleration values are too high?

Absolutely.

@PhilPar
What motors do you use / stepper drivers and input voltage?

So far I have check for:

  • Tried different versions of UGCS
  • Different Post processor than Fusion 360 built in
  • All mechanical components along with tighten all nuts and bolts

Will check for electrical. My gut tells me is the controller.

I have an Openbuilds machine with v-wheels lead screws and a crafty built CNC controller. (Phoenix CNC controller by Hayri)

Have you tried the same code but with say half or a quarter of the current feed?
Or running identical code but change $120-122 to 50?
What are the stepper drivers, DRV8825?
What is your input voltage, 24V?

I got DQ542MA Stepper Motor Driver and 24v.
I will play around with those settings. The settings I shared in the post above I have being using for a long time and haven’t had an issue with those.

But your system isn’t working right either… So the more we can rule out the closer we are :slight_smile:

Good point.

Any recommendations for an Ethernet/USB controller? What do you guys currently run?

I am just running an Arduino UNO with Leadshine DM556´s and DM856.

So I tried reducing acceleration and speed and the machine still doing the same thing just slower
Don’t know what else to try at this point
how can I check the controller to determine if it is working properly? I got an arduino based board (Phoenix CNC controler by Hayri)

This seems pretty low…try raising it to 0.1 or so.
image

1 Like

I had a similar issue once because the set screw on the z-axis pulley had loosened a bit. I wasn’t loosing physical steps but the physical movement didn’t align because of a small amount of pulley slippage. Check that set screw to make sure it’s still tight.