[eman5oh]

The more I am reading, I am thinking that my next build will be a linux cnc build with mesa hardware, the ethernet anything io boards look like a good route to go. Anyone have a link to build or more info on this?

[SCzEngrgGroup]

...and possibly make custom screens for KmotionCNC as Ray has done (although it is definitely more cumbersome to do).

Cris,

I went a step further, and wrote my own controller app. I don't use Mach3 or KMotionCNC.

I'm quite sure the acceleration problem referred to here was fixed several years ago. Certainly in any version newer than 2-3 years ago this should no longer be a problem.

Regards,
Ray L.

[RCaffin]

The video was interesting, but I still have no idea what the problem was. Sure, the router moved around in both cases, but I couldn't see any differences. The close-ups of the timber were interesting but the camera kept moving all the time, so I had trouble seeing any differences there either. That's the problem with videos: very 'youtube' and entertaining, but not very helpful for fine detail.

I am wondering whether the Mach problem is restricted to high speed operation with very low look-ahead? I am cutting metal, not wood, and I run a much bigger look-ahead buffer, and I have not seen any problems. Would the problem go away at high speed if the look-ahead was changed from 10 lines to, say, 500 lines?

What would be of real value would be some high-res still pictures with good focus of the output from Mach and Kflop showing the differences, if that is possible?

Cheers
Roger

[SCzEngrgGroup]

What would be of real value would be some high-res still pictures with good focus of the output from Mach and Kflop showing the differences, if that is possible?

Pictures of what, exactly? They will both do exactly the same things, product identical parts, assuming Mach3 doesn't suffer one of its brain farts.... From a user perspective, the only difference is the appearance of the GUI, and the reliability. KFlop/KMotionCNC works 100% correctly, ALWAYS. In 3+ years, I have yet to have it do anything unexpected.

Regards,
Ray L.

[BanduraMaker]

However I am not one of the users that have had any issues with MACH3 so I am assuming that I will be okay.

This is my biggest beef with Mach3 - I had it tuned so that everything was working perfectly. Worked for about a year without a stall. Then I launched a new product line that had larger programs and more complex 3D moves and boom - stalling and ruined parts. I re-tune it for the new parts and now the old parts look like krap.

I'm currently setting up a machine with a Kflop/Kstep/KmotionCNC control system. So, I'll have handy - Mach3, UCCNC and Kmotion CNC. It will be very interesting to compare the 3.

Today I just finished writing Macros like Ger's for UCCNC. Hoping to put it into production within a day or two....

[RCaffin]

Pictures of what, exactly?

Well ... at the moment I have no idea what sort of errors are being found. I've been running Mach3 for a couple of years now and not had that sort of problem you see. As you probably know, I have found plenty of other bugs in subroutine handling, but that is not what we are talking about here?

So what I would love to know is what to look for. Pictures of good and bad parts would be great.

Cheers
Roger

[BanduraMaker]

Here's a picture of a bad part. I made about a hundred similar parts to that one before with no problems but then with this part I got that gouging. Lowered the lookahead and it went away...untill I got my next problem and had to re-tune further. There are pictures of some similar 'good' parts cut with UCCNC in the video. I've thrown away at least $500 of good wood thanks to issues like this.

[RCaffin]

This is my biggest beef with Mach3 - I had it tuned so that everything was working perfectly. Worked for about a year without a stall. Then I launched a new product line that had larger programs and more complex 3D moves and boom - stalling and ruined parts. I re-tune it for the new parts and now the old parts look like krap.

Well, I don't know what parts or products we are talking about here, so I am a bit in the dark. So maybe I am just waffling.

But whenever I ran into that sort of problem myself, on either a manual machine or a CNC machine, I have always found that I could fix my problems by fixing what I was doing. Wrong tool tip height on a lathe is a mistake I have made a few times - I am still learning. Stalling - not quite what I would call a SW problem in my experience. Has happened a bit with under-powered stepper motors during machine development (rather old and apparently demagnetised round steppers.)

And yes, I have been making some fairly complex 3D parts in a gentle production mode. The products sold quickly.

Educate me, please!

Cheers
Roger
PS: I have NO financial interest in Mach whatsoever. I just use it.

[BanduraMaker]

Stalling - not quite what I would call a SW problem in my experience.

The stalling occurs when Mach 3's TP violates the acceleration limits. It does it at seemingly random lines of code but it's completely repeatable. Make a tiny change to the file and the problem might go away or it might move to a different spot. The fix for this is to lower the acceleration by 50% of your maximum safe accel. (apparently Mach 3 will violate by a maximum of 200% of the set acceleration in motor tuning).

The rounding is because Mach 3 has very poor tolerance control when in CV mode. There is a distance tolerance setting but it basically goes into 100% exact stop mode when you set it to a low number like .001" or something. When you're starting and stopping so often it increases the cycle time probably 4 to 10x.

Basically, I'm done wasting my time and money with Mach 3. As I said in a previous post, I've spent at least $500 on wasted stock because of the bad TP and perhaps even more. If you're in a low pressure environment where you can deal with longer cycle times, it's not a big deal. You can tune your machine to run slowly and safely and everything will be fine.

I'm also kind of irritated that I'm spending time trying to convince someone that this is real. If you don't have a problem, then fine. Move on. When you do have a problem, you'll remember this thread and you can use it for guidance on how to fix your problem. Here's another thread on the Mach 3 CV mode bug that may be useful - http://www.cnczone.com/forums/mach-s...-stalling.html

[RCaffin]

Ah, a picture! Thank you.
Very odd. Two gouges on the nearby corner, and two similar ones on the far corner. Is there a 3rd on the far corner - I can't tell.

Does it look like the cutter started downwards as it approached the corner, when it should have been running horizontally? Can't tell.

It's a bit hard to even imagine how this could happen, especially as I don't know how the part was machined, or with what cutters. I am guessing many passes with a ball-nosed cutter (going off the grooves)?

The next Q is what sort of machine made them, and does it have steppers or servos? LPT or SS, or other gear?

Difficult. I sympathise about the valuable wood.

Cheers
Roger

[BanduraMaker]

It's a bit hard to even imagine how this could happen, especially as I don't know how the part was machined, or with what cutters. I am guessing many passes with a ball-nosed cutter (going off the grooves)?

It happened because Mach3's trajectory planner isn't very good. Dropping the lookahead setting eliminated the problem but increased the time to make the part. (and yes, 1/4" ball-nose cutter)

For comparison, using UCCNC, a similar part machined about 4 or 5 minutes faster and had a better surface finish.

[SCzEngrgGroup]

For the vast majority of users, Mach3 works fine. For the rest of us, there are problems. Exactly which problems a particular user might experience can vary greatly. For me, there were several, and they were severe. I sometimes got bit by a bug in the planner that occurred only when in CV mode, and transitioning from a 2-axis move in XY to a helical move in XYZ. The Z axis was given no acceleration - it was simple expected to instantly come up to full speed. Naturally, that did not work well at all. This was a known bug in many version of Mach3, and was finally corrected several years ago.

I also saw truly bizarre, random behavior on G31. Every once in a while, it would move in two axes, or move the wrong direction. The one that finally made me throw in the towel and move to KFlop was one that bit me when peck drilling. It would work fine for a while, then suddenly decide to drill to China at rapid speed. There were days I'd break a dozen or more drills because of that one. Spend weeks working with Brian Barker (Mr. Mach3) and Greg Cary (Mr. SmoothStepper) to try to debug the problem. Along the way we found quite a few other bugs, but never did get to the bottom of that one.

The point is, if it's working for you, don't worry about. If it screws up, odds are about even it'll be something nobody else has reported. That is the nature of the beast. So, I don't see that pictures of someone else's problems do any good. There are LOTS of bugs in EVERY version of Mach3. Most are minor, and many can be worked around. But it's HIGHLY version-dependant. The current latest version (3.043.066) has a particularly bad reputation, though, again, it works fine for many people.

The Mach3 development process has a looooong history of fixing one bug, only to replace it with a different one. That is due to the big hairy can-of-worms nature of the source code, that lack of any regression testing, and the overall lack of a defined system architecture, and is precisely why the Mach4 project was started (5+ years ago!), and why virtually NO Mach3 code was used in creating Mach4 (only about 1%).

Regards,
Ray L

[RCaffin]

Hi Andy

> For comparison, using UCCNC, a similar part machined about 4 or 5 minutes faster and had a better surface finish.
Interesting. Thank you.

Cheers
Roger

[Hirudin]

...I'm also kind of irritated that I'm spending time trying to convince someone that this is real.
...

You're also trying to convince someone who is very successful making 3D parts to a 5-atom tolerance but is unfamiliar with the detrimental effects of a short look-ahead... and is combative about it.

[RCaffin]

Hi Ray

Yeah, can of worms sometimes.

> transitioning from a 2-axis move in XY to a helical move in XYZ.
I have never seen that one - but maybe I run more slowly. Certainly, given the cost of thread mills, I do go cautiously when threading.

> truly bizarre, random behavior on G31.
Oh yeah - me too!

> That is due to the big hairy can-of-worms nature of the source code, that lack of any regression testing, and the overall lack of a defined system architecture,
Ah yes, I know it well. Go down too many subroutine layers and - poof!
Race conditions in bits of the code - untraceable because debug inserts change the problem.

But, to be fair, Mach1 was simply designed to let Brian/Art ( I forget) machine something, nothing more. It got ... extended and stretched and enhanced - like Windows. The base layer was NEVER fixed (up to Mach3; Windows is still built on quicksand).

More learning, and work-arounds. Thank you.

Cheers
Roger

[BanduraMaker]

You're also trying to convince someone who is very successful making 3D parts to a 5-atom tolerance but is unfamiliar with the detrimental effects of a short look-ahead... and is combative about it.

Actually, the short lookahead solves the problem. A longer lookahead compounds the problem because the TP ignores small design elements.

[RCaffin]

> very successful making 3D parts to a 5-atom tolerance
Please - I never claimed 5 atoms.
Now 10, maybe...

'Combative'? Nah, just a blunt Australian. Cultural thing. But I like learning - which I am doing here.

Learnt today: Mach has problems with CV mode (which I do use) and can try to go to 2x permitted acceleration. Yeah, I can see problems there!
The look-ahead thing puzzles me a bit, but I can believe in bugs.

One thought: I wonder whether part of the problem lies in the style of the CAM outputs? It seems that a lot of CAM puts out very, very short segments, which might cause some problems. I gather (?) that some CAM systems out put lots of short straights instead of using g2/g3 as well? I hand-write my own code in a parametric style, using g2/g3 where possible, so segments are always much longer. Does this make a difference? Dunno, but I am curious.

All that said, I should add that I am machining 6061, 2011 and Fortal, not wood, so my feeds are much lower.

Cheers - really
Roger

[BanduraMaker]

I'm quite sure the acceleration problem referred to here was fixed several years ago. Certainly in any version newer than 2-3 years ago this should no longer be a problem.

As I'm winding down for bed I was re-reading this thread and noticed this post. Perhaps there was more than one acceleration problem. I've experienced an acceleration problem and the guys at UCCNC have actually measured it and it definitely still exists. For reference - according to UCNC, the mach 3 TP won't go above 200% of the acceleration limits set in the motor tuning pages so dropping whatever acceleration you come up with there by 50% should be safe.

In my experience, I was able to run at 40"/s^2 for a long time with no problems but had to drop down to 23 when I introduced a new part. Dropping down to 23 required me to re-tune my lookahead down to I think 10 lines to tame the corner rounding/gouging. With UCCNC software I had it running at 80 but that scared me so I dropped down to 60 just to be safe and my tests have been very positive. Haven't run any actual test part yet though, only air cuts. I think this is still useful though because Mach 3 would cause a stall whether cutting material (wood mostly) or in air - and always at the same line until the code changed even a little bit - irrespective of whether using parallel port or the UC100 plugin.

It will be very interesting to see how KmotionCNC performs compared to UCCNC - I've heard nothing but good things about the KmotionCNC TP.

[BanduraMaker]

The look-ahead thing puzzles me a bit, but I can believe in bugs.

One thought: I wonder whether part of the problem lies in the style of the CAM outputs? It seems that a lot of CAM puts out very, very short segments, which might cause some problems. I gather (?) that some CAM systems out put lots of short straights instead of using g2/g3 as well? I hand-write my own code in a parametric style, using g2/g3 where possible, so segments are always much longer. Does this make a difference? Dunno, but I am curious.

One more thought and I'm off to bed...really

Just to be clear here, there are two separate issues:

1) Acceleration but - sometimes out of the blue, Mach 3 will pick on one line of code and violate the accel limits so badly that the machine will stall (if running steppers which I do - zero experience with servos).

2) Corner rounding when using CV at high feed rates - the lookahead issue.

Issue #2 almost certainly has something to do with my CAM software spitting out millions of tiny line segments. The G-code for my guitar necks is over 120k lines long. That and I cut at 350ipm or almost 9meters/min. If your feed rate is relatively low and your axis accelerations are relatively high, it won't be a problem. As I slowed my accelerations, the corner rounding got much worse until I dropped the lookahead down. The faster the acceleration, the less this issue will manifest...until Mach 3 goes over by 200% and causes a stall :tired:

[RCaffin]

Mach 3 will pick on one line of code and violate the accel limits so badly that the machine will stall (if running steppers which I do - zero experience with servos).

Yeah, very different results. A stepper can stall within just a few pulses (I have one stepper, on a rotary table). But a servo does not have to stall. I use Gecko 320X drivers and you can set these things to tolerate a brief period of not-quite-keeping-up. For instance, they might fault when they see a follower error of 256 pulses, or 512, or 1024, or even 2048 pulses. That means they can be very tolerant, especially at the corners. Perhaps that is saving me?

Cheers
Roger