Weird Vectric/Mach3 issue- design "smearing"

[Datamancer]

Hey folks, I hoped you could help me with this one because I'm stumped. I tried to run a long file last night and when it finished, the design look like you took a real-life Photoshop "Smudge" tool to the whole thing. Take a look at the attached pics.
The first is what it's supposed to look like...



Perfectly symmetrical, and about 26 inches long.

Here's how it came out...





The Vectric file looks fine, as you can see, and the tap file in Mach3 seems to be ok. I skimmed the G Code and it looks like it never goes further than 13" in one direction and -13" in the other, but the file is skewed way out of those boundaries (it even munched-up my mounting screws, which should have been about 2.5" away from the nearest cut).
I ran some tests on the table again, and it jogs just fine, and is very accurate, so the motor math is ok too.

Whatever this error was, it was something in the file, not something simple like the table slipping, because it reproduced the error across many, many passes.

Any ideas? I'm stumped. Nothing adds up here. The table worked fine about a week ago and nothing has changed since then.

Thanks,
-Rich

[ger21]

Check all your couplings for anything that might be loose.

[Datamancer]

Check all your couplings for anything that might be loose.

Thanks, but I don't think anything being loose would cause this. The error was reproduced over many passes, radiating outward from the center.

-Rich

[osphoto]

I had a similar issue.

However it was with a word font being cut in 3 passes. When it got to the 3rd letter, it would off set the cut in the 2nd pass of the letter. The off set didn't occur until 3 more letters into the cut.

I checked my machine OVER and over. I eventually cut individual letters and had NO issues.

Turned out it was the Gcode being generated from Visuamill. I even checked with their tech support, however, they couldn't regenerate the error.

I re-ran the gcode with a slight difference, did a recut and had no issues.

Never did figure out the actual code issue, but did find the fix.

Perhaps it was a rounding issue?

Perhaps regenerate the code? Maybe try a smaller scale so not to waste so much time?

[Datamancer]

I have recalculated the gcode twice now with no change in the problem. The third time I tried cutting the file as a Raster (bottom to top) rather than Offset (spiral outward from center) to see if it would fix the issue. Every single time it seems to "push" the design to the right.

I'm not exactly sure what you meant by a rounding issue but I have opened the gcode in notepad and the maximum positive x value is 13 and the minimum x value is -13. Meaning that the gcode reads 13 inches to the right and 13 inches to the left. Yet it remains smeared to the right in the actual cut.

I have considered that it may be too large of a file so the computer's memory is running out but I have no evidence to confirm this.

I had a similar issue.

However it was with a word font being cut in 3 passes. When it got to the 3rd letter, it would off set the cut in the 2nd pass of the letter. The off set didn't occur until 3 more letters into the cut.

I checked my machine OVER and over. I eventually cut individual letters and had NO issues.

Turned out it was the Gcode being generated from Visuamill. I even checked with their tech support, however, they couldn't regenerate the error.

I re-ran the gcode with a slight difference, did a recut and had no issues.

Never did figure out the actual code issue, but did find the fix.

Perhaps it was a rounding issue?

Perhaps regenerate the code? Maybe try a smaller scale so not to waste so much time?

[osphoto]

Rounding issue, may not be the correct description. I say that based on years ago, some computer processors would have rounding issues in some calculations. Not sure that being the case any more but... I know in using "arcs" in calculations of cuts, I often wonder if Mach's interpretation of the G-Code causes issues? I base that on my experience resulting in a similar issue to yours.

I've had code simulated as intended, take it to Mach and watch Mach produce extra cuts, etc. And it typically resulted when I used "arc" functions. However, to fix these issues, I'd have modify the decimal tolerance from .0001 to .001 when using arc's.

If you picked a different object/part/design to cut, would you have the same issues? If you don't, then the problem is in your current object. Your current object is causing some sort of "calculation issue".

What if you took your part, cut it in half, re run the gcode on just a portion of the part and then have your machine cut that portion, would it produce the same results or would it come out as you expect?

My experience say's your problem leans more towards your g-code and not your machine. Can you modify your tolerance of G-code accuracy? In Visual Mill I can modify my arc tolerances/accuracy. Do you have that ability?

I also want to say you can set that accuracy in Mach some place.

Are you making you cuts in one pass or multiple? Is your first pass spot on? Can you see where your machine is skewing your cut based on the gcode?

The good news is your machine seems to be constant in smudging your part. So, I say the code is causing your issue and not the hardware.

[blowlamp]

Looks like missed/lost steps to me.

If you can run the gcode through a simulator and it looks OK, then it's got to be a machine/controler related problem.

Try turning off the realtime Display thing in Mach 3, because that can cause missed steps with large files and a (possibly) borderline computer.


Martin.

[keebler303]

Another vote for loose coupling or missed steps here. Just jogging won't reproduce the problem but cutting will increase the load and cause it to slip/lose position. This may only happen one way due to climb/conventional cutting, not sure how your toolpath looked.

Matt

[Datamancer]

Thanks for the help, everyone! I've solved the issue and it appears to be that the computer I was using did not have enough RAM and was missing steps, as a few of you suggested.
I had 2 Gigs RAM in this machine (and it used to be a budget gaming PC) so I thought that was major overkill, but apparently it wasn't quite enough for these larger carvings. I hooked up an older PC that actually has a slower processor than the current machine, but it has 4 Gigs of RAM, and the carving came out perfectly. Time to go shopping for some more DDR2!

Thanks again,

-Rich

[keebler303]

Rich

It's a lot of work crunching all those numbers for 3D carving. Even commercial controllers have limitations on that. If you have problems in the future, a slower feedrate will give mach3 more time to think and should make for a more reliable machine.

Matt

[ger21]

Thanks for the help, everyone! I've solved the issue and it appears to be that the computer I was using did not have enough RAM and was missing steps, as a few of you suggested.
I had 2 Gigs RAM in this machine (and it used to be a budget gaming PC) so I thought that was major overkill, but apparently it wasn't quite enough for these larger carvings. I hooked up an older PC that actually has a slower processor than the current machine, but it has 4 Gigs of RAM, and the carving came out perfectly. Time to go shopping for some more DDR2!

Thanks again,

-Rich

RAM is not the issue. I run Mach3 on a 1Ghz PIII with 512MB of RAM, and I've run programs with 500,000 lines of g-code.
It must have been some other issue with the other PC.

[Datamancer]

RAM is not the issue. I run Mach3 on a 1Ghz PIII with 512MB of RAM, and I've run programs with 500,000 lines of g-code.
It must have been some other issue with the other PC.

Yeah, it seemed strange to me as well, but it was the most obvious difference between the 2 machines. Aside from that, they both have fresh Windows installs on them, native parallel ports on the motherboards, the same install of Mach3, etc.
Maybe it's a RAM issue, except the issue is that one of the RAM sticks went bad on the first machine. As you mentioned, 2 Gigs SHOULD be massive overkill.

Well, "if it ain't broke, don't fix it", as they say, so I'll stick with the old machine until I get some downtime and finish this large burst of CNC work I have, then revisit the old machine later.

Thanks for your help, everyone.

-Rich