Hello Guest it is March 28, 2024, 05:36:39 AM

Author Topic: Whose Fault Is ThIs?  (Read 28787 times)

0 Members and 1 Guest are viewing this topic.

Re: Whose Fault Is ThIs?
« Reply #30 on: February 13, 2010, 04:22:59 PM »
Hmm... thanks for the suggestion but that's really too bad  :'(

The problem with exact stop is that it will definitely introduce a perceptible point of entry during the finish pass of the reflector. I absolutely needed to have it to have a consistant surface finish and so I even have the software compute the arc length during the ramp to change feedrate and spindle speed to create a consistent surface and also maintain an effective z plunge feedrate and the entry point.

As an added bonus, After I changed to code from a "plunge then pocket" per iteration to the helical ramp to pocket with a helical return to center turned a 45 minute job into 15 minutes.

The only thing I discovered was that as long as I keep at least one of the axises (axii?) of I/J at zero from out outset everything works peachy.

Any other workarounds or alternatives anyone can think of would be highly welcome.
Re: Whose Fault Is ThIs?
« Reply #31 on: July 03, 2010, 09:14:40 PM »
My apologies for posting on a dormant topic. I started to write a separate one but it just seems more appropriate here.

Has there been any word on the fix for this? I am experiencing a problem that seems similar if not the same. My problem happens on rapid moves however. If I only move one axis at a time, I have no problems. But if I move more than one axis, it seems like the secondary axis (not the one with the major portion of movement) will miss steps and stop (even though I can hear the unmistakable sound of step commands with no steps).

It seems like it is busting the Accel/Velocity capabilities of secondary axis. I tried lowering both the accel and velocities in motor tuning, but the thing that made it go away was moving only one axis at a time.

Something interesting also, if I change from G0 to G1 but set the feedrate the same as the maximum in the motor tuning, all is well.

So, has HimyKabibble's bug been fixed? If so, what version of Mach3 did it get fixed? Could my problem be the same?

Thanks!
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Antoine de Saint-Exupery (1900 - 1944)
Re: Whose Fault Is ThIs?
« Reply #32 on: September 12, 2010, 10:48:37 PM »
Nope... I've waited for months for a fix or workaround but at this point I've given up on Mach and am using EMC for now. Its a shame since I ended up buying a couple licenses for Mach before I found out that my parts were coming out
wonky. :( I'm just crossing my fingers and hoping that they'll fix it sometime in the next few years.

I've run into it during thread milling, Running the 4th and 5th axis, etc... The same bug affects other obnoxious places and everyone always says "It's not a bug its a feature OR just use exact stop" Neither of which are reasonable suggestions. It was while I was doing internal thread milling that I just said screw it and built an EMC box.

I've only seen very few mills that would optimally use the same acceleration for all axises. I have a Bridgeport CNC with the Elrod quill drive and ballscrews on all axises, and the X&Y can support a much greater acceleration than the quill.
AND the bug still exists if you set the acceleration the same, my system is running 0.0001 glass scales and I can still see the problem, it's just not catastrophically major if you don't care about a thousandth loss here or there.

Before people say it's my machine, Mach works great for everything else and EMC has no problems running the same code with no problems.
« Last Edit: September 12, 2010, 10:53:52 PM by yaddatrance »
Re: Whose Fault Is ThIs?
« Reply #33 on: September 13, 2010, 12:12:13 AM »
Brian started working on a fix for this when I first found the problem, about a year ago, IIRC.  But, after a few days, he got off on something else.  AFAIK, he's never come back to it.  And I know it was NOT a simple thing to fix either.  Last I heard from him - probably close to six months now - he was spending all his time trying to get v4 done.  I haven't heard anything about his progress on that for a long time either.

Meanwhile, the only solution for this problem is exact stop mode - not a very nice way to work.  Or, avoid starting a third axis while two others are already moving.

Regards,
Ray L.
Regards,
Ray L.
Re: Whose Fault Is ThIs?
« Reply #34 on: September 13, 2010, 12:30:19 AM »
Thanks HimyKabibble, I looked into it myself looking for a workaround and the problem seems to be, from what I can tell from purely external testing, is that mach chops the less significant decimal points that don't fit in the DRO and works off that "massaged" value. This probably helps at the end of a move so you don't have weird ceiling/floor reversals as a response to commanded values, but for "advanced" moves such as a helical interpolation with Z component with differing acceleration, it has a tendency to accumulate errors. Basically rounding off the floating point numbers while within the iteration.

Personally, I could very easily deal with an "out of band" g-code command that says "Set acceleration to the slowest value for all axises" and another one that restores standard values. Or any workaround of that nature. Exact-stop by its very nature defeats the entire purpose of any operation that requires a helical ramp.

Here's to hoping for v4.
Re: Whose Fault Is ThIs?
« Reply #35 on: September 13, 2010, 12:45:58 AM »
No, the problem is a "blended" move, when you're moving in two axes, then bring in a third, the acceleration of that third axis is not handled correctly, so the axis acceleration limit is not respected.  IIRC, it only occurs when the third axis is started up *during* a circular move in one or both of the other axes.  If they're all straight-line moves, it works correctly.  It always happened to me when doing a rapid into a 3-axis helical move.  The instant the third axis (Z) started up, the third axis servo would fault, as it was being asked to accelerate at some horrendous rate.   It has nothing to do with the precision of the math.  The algorithim being used simply does not handle that case correctly, and it expects the third axis to essentially accelerate instantly to what rate is required.

Regards,
Ray L.
Regards,
Ray L.
Re: Whose Fault Is ThIs?
« Reply #36 on: September 13, 2010, 02:06:55 AM »
Hmm, that makes sense, but if the only problem was acceleration, then it should put out the correct number of pulses, just very fast and it isn't. I put a nice counter on the Z axis step line and did a helical ramp and the count value was consistent but wrong. I would also think that in the case of an acceleration bug, it would "skip" steps only during the initial acceleration and I see consistent skips throughout the entire path, for example during thread milling.

During normal linear movements the counter indicates that mach is dead nuts accurate, during a helical ramp with all acceleration set to very safe and identical values, it is off by a thousandths or two, with acceleration of the ramp set to a different value, it has massive problems... surprisingly, if the arc center is (0,0) it behaves itself which is why I never caught the problem before starting a production run.

Re: Whose Fault Is ThIs?
« Reply #37 on: September 13, 2010, 10:46:18 PM »
That's very odd....  Perhaps yet another bug.

On the plus side, I did hear from Brian today, and sounds like v4 is coming along, and may finally be out soon-ish.

Regards,
Ray L.
Regards,
Ray L.
Re: Whose Fault Is ThIs?
« Reply #38 on: July 19, 2011, 02:51:41 PM »
Any update on this issue being solved??
Re: Whose Fault Is ThIs?
« Reply #39 on: July 20, 2011, 10:48:48 AM »
Any update on this issue being solved??

AFAIK, it hasn't been touched.
Regards,
Ray L.