Slight stepping artifacts; any ideas?

It looks like @Randy is having a similar problem and already took his machine apart. ( I just watched a 30 minute video of his machine jogging back and forth with a dial indicator)

Jorge and I are thinking it could be an electronics problem so we’re overnighting a new PCB to him. If that fixes it, we’ll work out the best way to make that repair with you as well.

-Rob

That is so strange that it only affects the X+ side of the cube, while the X- side is perfectly smooth. Can you post your g-code programs? I’d like to put Grbl through its paces to see if it’s caused by something I’m doing in the code.

chamnit, it is actually an overall offset of the X axis. The left side is just being machined all the way up as the axis drifts. Here is a little cross-section picture where the dotted green outline is the desired shape and the red outline is the acutal shape.

The offsets are really exaggerated, but at each level the cutter traces the same size and shape. The shape is only the correct size right at the bottom–previous passes have removed what would be an overhang on the left side.

Yeah, that’s exactly what’s happening - the bottom is the right shape, but offset to the right. The top of the right wall is in the correct location, but the top of the left wall (which was in the right location only after the very first pass) has been shaved off to the right with each successive pass.

@robgrz: Great, keep me up to date! I’d love to have my machine up and running this weekend if it’s at all possible!

Thanks,

Well, the ball is in my court. FedEx website says the board is waiting at home for me (thank you, Rob and crew!) and I’ll install and test it after work and report back here and to support@carbide3d before the night is out.

Ok thanks for the clarification. That makes more sense. Could you still post the g-code program(s) somewhere so I can download it? I’d like to try to reproduce the issue and check if there isn’t anything that is caused by Grbl itself. It looks like something with the electronics, but I’d like to make doubly sure.

Hi, I believe that I am having a similar issue. I have been doing some prototyping using hardwood (poplar to be exact) and I am noticing an artifact on a single corner of my design. The design is just a series of cubes next to each other and the corner between the left side and the top on every cube is where the artifacts are.

Here is the 3D rendering of what it is supposed to look like:

Here are the images of the finished piece:

The two holes on either end are where I drilled countersink holes so that I can screw the material directly to the plate on the Nomad as I was having issues with the tape.

My settings for the “Carbide Auto Toolpath” are as follows:

Detected Geometry: Prismatic
Material: Wood - Hard
Cutter: #102 - 0.125 Inch Flat
Finish Quality: Highest

Any ideas what could be causing the issue with that one corner?

@wakin66

Does the simulator, or the StL itself show any issues on the top left corner of the
blocks?

I do not know what the dimensions of the part are, Do you have enough
tool length to cut the space between the blocks without the upper part
of the cutter or the ER11 hitting the block? Do you see anything like this
happening when you watch it cut? Is the left side of the block vertical or
does it slope in or out?

I also had trouble with the tape holding until I switched to this tape and it
has worked quite well for me.
http://www.amazon.com/dp/B0049RAEA6/ref=wl_it_dp_o_pC_nS_ttl?_encoding=UTF8&colid=1TDW9D87BHBGB&coliid=I10DMNWOYEZCX1

@kjl, there is good news and bad news.

The bad news is that it doesn’t look like you will have use of your machine over this weekend.

The good news is that we are homing in on the problem. The new stepper driver board did not help matters. X was still flaky and Y was still rock-solid. I talked with Rob and he suggested swapping the X and Y motors at the driver board. I obvously could not go through the homing or tool-measurement sequence becuase the axes were swapped, but I could hand-position the axes, turn on the machine, fire up Carbide Motion and load a gcode without homing. I had to use relative movements (g91) to just move the X or Y axis from where it currently was, but that was enough to determine that the problem is in the axis drive and not the motor (since now the flakiness was in the Y axis driven through the X circuitry).

Since the old and new driver boards behave the same, that just leaves the Arduino board itself (edit 6/1/15 - in hindsight that was a bad conclusion–from later testing a more likely conclusion is that both the original and replacement stepper boards could have come from the same “bad batch” of boards…), and Rob will send a replacement tomorrow. he is thinking that there might be a marginal component on that board (which looks like the only purchased PCB) that is picking up intermittent noise or maybe marginal on logic level when feeding the driver board.

So even with next-day shipping it will be Friday before I can try the replacement Arduino board.

@Randy: Bummer! But glad things are slowly getting debugged.

BTW, I did a test job (just the same roughing pass test job I did earlier), but without turning the spindle on and without actually placing any stock on the table so that the head is just tracing out a pattern in midair. Without all the extra noise of the grinding, I can absolutely hear the glitches that you mentioned you could hear, when it is going along the +X axis. Interesting how random it is - sometimes it’ll track left and right 3 inches each time for a number of passes without any glitches, and then sometimes it’ll glitch out 2-4 times in a single 3 inch pass. I guess that’s how random works, though - it clumps. Also, I think I hear a Z glitch on the way down -Z during the measuring phase sometimes.

Also interesting: the glitches are all when the mill is moving to the RIGHT, but the overall drift is also to the RIGHT. So that means it’s not skipping steps/missing instructions - it’s doubling a step or getting extra moves each time the glitch happens? So weird.

Hey, I have a (related?) question for you (and @robgrz): do you know how to make MDI mode work, and/or allow me to enter jog mode without homing first? Instead of running the previous test I had, I originally wanted to just tell the mill to go left and right a bunch of times and listen for the glitches. When I go into MDI mode, a simple move g0x0 (after g21,g90) sends the head zooming over to the far right (even if it already thinks x is positive) until the limit switch gets hit. I tried homing it first with the tool change command (since it looks like the tool change line in the NC file - M6 T102 - is the thing that makes the nomad home), but grbl didn’t understand the command when I entered it in by hand.

Anyway, long story short, after my job had completed, I wanted to jog the head back to the “origin” to see just how far off it had gotten, but I was unable to enter jog mode in carbidemotion without it forcing me to rehome, and I was also unable to move it at all in mdi mode without it crashing into the +x limit switch.

It is a little frustrating to not be able to jog without the machine homing. That is why I had to do things the way I did–pre-position the axes, ignore the coordinate readouts and use relative moves after setting up my dial indicator.

MDI operates in machine coordinates, referenced to the home switches. So G0 X0 Y0 will take the head and table to the home switches. To move to a specific user-coordinate you would need to know what the current offsets are from the machine zero position. I don’t know if there is a way to determine that. Someone in another thread here has requested a full-time display of machine coordinates as well as the current user coordinates.

On my machine at least, there are glitches in both directions. I can watch the dial indicator move in both directions in little increments–it’s about .0015" per glitch, which Rob says works out to 3 micro-steps.

Hmm, makes me think it could be a noisy power supply. If I recall, the X-axis stepper driver is closest to the input power. Do you have a way to test another power supply?

Also, could someone please post a problematic g-code program still? I’m the lead developer of the Grbl CNC project that Carbide3d uses. I’d like to make sure its not a problem on my end.

Oh, I see; so grabbing a g-code program that meshcam generates and copy-pasting it straight into the mdi interface is not the same thing as running the program? So if the absolute movement coordinates are relative to the home switches, that renders that basically useless for me, but I suppose I could put it in relative movement g91, look at where the nomad thinks it is (X,Y,X coordinates relative to wherever you zeroed it out to), and move it back to 0 that way, yeah?

@chamnit - oops, sorry, I keep on totally forgetting to attach that. This is the roughing-pass-only code that produced the block with the really bad stepping and really bad taper (first two pictures of post#20):

Great thanks! Got the file. I threw it into a visualizer, and it’s a bit unusual in the way it does the tool path. It does a lot of diagonal z-x pull-outs and plunges, rather than straight z motions. It’s not wrong by any means, but something I wasn’t expecting. I’ll dig a little deeper.

Do all of your problem tool paths do this z-x diagonal motion? Do any with a straight z-only plunge do the same thing?

Also, could someone try changing the junction deviation Grbl setting to $11=0.01 or $11=0.005 and try re-running this job? It’ll cause Grbl to slow down more into a direction change. It’s also possible that this value is set too aggressively high. (Make sure you revert it to the old value after you’re done.)

That is MeshCAM’s “3D roughing”. It tries to blend the roughing levels together. It’s ot really necessary on a block-shaped object, but really helpful on freeform 3D surfaces to help avoid the jaggies left in regular roughing. It is common in MeshCAM to enable this setting.

But the glitches are definitely present in my single-axis handwritten gcode also.

I had overlooked the $11 variable. Does that mean that path-blending is enabled all the time? G61 isn’t in the list of accepted Carbide Motion gcodes so I kind of assumed that exact stop was enabled by default. Can I set $11 to 0 to emulate exact stop?

It’s not quite path blending, but it calculates how fast it can go into a tool path line junction based on stepper acceleration limits and the speed. Grbl still moves along the exact path. I wrote a blog post on it. Theoretically if you set $11=0, it will behave like exact stop, but I can’t recall if I checked the math on this to make sure there isn’t some exception or divide by zero.

In practice, this works great, but, if the $11 value is set too high, Grbl can move too fast through a junction and cause it skip steps. What does the Nomad have it set at? A value of about 0.005-0.02 is about what I’ve found works on the machines I’ve tested. Balancing speed with maintaining accuracy.

On the Nomad $11=0.02 (mm) Thank you for the blog post link. You’re One Hoss Shay guy! I didn’t know that. I’ve read some of your blog posts in the past (the tapping block is one I remember). So the $11 variable isn’t path blending at all, as you say. So there’s no reason to set it to 0. But one thing I want to look at after the glitching unplesantness is solved, is machining feedrates with the Nomad. It looks like by far the biggest consideration for accurate machining is the spring rates of the X and Y drive belts, not chip load or tool deflection (which is probably saying the same thing). More at issue will be how much material to leave during the roughing phase vs. the finishing feedrate to minimize the path “deflection” due to the belt compliance…

Thanks! Since you said that the problem still occurs with hand written g-code, which is probably simple straight lines, then it’s probably not the $11 setting or Grbl. It also sounds like its intermittent and not occurring when it changes direction. So, it’s likely electrical… I’m still suspicious of the power supply though.

As for feedrates and belt stiffness, you’re right. Compliance is an issue when pushing a machine hard, like you would when roughing, but it’s a problem in all machines, even on nice Haas production machines. The faster and harder you push a machine, the less accurate it becomes. Finding that balance between roughing and finishing is something that comes with experience.

Hi, I am having same issues as CookieMonster with Tutorial #2. I have attached the image, can you guys please suggest how to fix this issue?

Thanks