Slight stepping artifacts; any ideas?

Using a stepdown of .005", or something small, in the waterline section is the best way to show a shift. That tends to jog the X and Y axis around a lot to cut the profiles and the small stepdown gives plenty of time for any shifts to occur.

Without seeing the CAD file, I’m not sure if the scallop should have been cleared. If that represents the edge of the stock in MeshCAM then it would not be cleaned up by the waterline. If that surface is modeled in the CAD file, then it probably should have.

There’s no reason the X should be drifting under normal use so there are no fudge factors to compensate for them. The only time a shift will occur in a “normal” machine is if you take a very aggressive cut. Sometimes the cutter will grab and shift just a little each time it happens.

Send me a photo of the test cut tonight

Rob

Thanks! I will do so. Hey, you might be on to something about why the scallop line is not being cleared. It’s not the edge of the stock in MeshCAM, but you’re right - it’s not modeled into the CAD file - it’s where I set the “area to be machined”. i.e. there are no high walls in the CAD file, just a low floor larger than the stock size. The area to be machined is defined to be slightly smaller than the stock, so the remaining area makes the walls. I should not have assumed that it would have cleaned up those outside edges…

The waterline toolpath will only follow the CAD file. If you have a machine boundary (whether you define it with the Set Machine Region command or use the stock boundary) that is not coincident with a part of the CAD file, the waterline toolpath will not go there.

Don’t worry about the assumption- you’re not the only one to have made the same guess before.

Rob

Hi, just an update - I’ve done a few other tests confirming that I do in fact have an X axis drift. I did a waterline test as you suggested on renshape and it does show taper - about 1/16" taper during the rough pass job with huge obvious chunks and scalloping and stepping only visible on the +X-facing walls, and then (after rehoming), about a 1/32" taper during the waterline-only job.

A previous test showed a shift of about 1/16" over an hour or so.

I also sent an email to the support@carbide3d.com (actually, a bunch of emails as I ran more tests).

Do you know if this kind of error is fixable by me, or will I have to send the machine back?

Thanks,

Can you post a picture of the taper?

-Rob

Sure thing! Did you guys get the emails I sent to support@carbide3d?

Anyway: I wanted to do a waterline test on a 1"x1"x.625" block, so the first thing I did was to do a roughing-pass only job just to get most of the other stuff out of the way, so I roughing-passed a 1.125"x1.125"x.625" block.

Here’s the result of that:

So it is drifting pretty aggressively to the +X. Here’s a view of the side where you can see the scallops and steps:

The bottom of the block measures a tiny bit larger than 1.125" (I assume because the roughing-only pass leaves a little bit of material on? But the top of the block measures around 1.0625", so it’s off by about 1/16" by the bottom.

After this I did my actual waterline-only test, with a stepdown of .005" as you suggested earlier. This also had some taper, but not quite as much as the roughing only job. I rehomed the machine but did not remove/replace the stock or rezero the machine, and I verified with jogging the machine around that 0,0,-.625" was where it should be. This is what it looked like several waterline passes through:

You can see that the waterline block is not centered on the roughing-pass block (because the left wall of the roughing pass was shifted over ~1/16" by the drift of the previous job), so the ledge on the left is smaller than the ledge on the right.

And here’s pictures of the taper and the tapered wall after the waterline test is complete:


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?