Hello Guest it is March 29, 2024, 06:43:41 AM

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

0 Members and 1 Guest are viewing this topic.

Re: Whose Fault Is ThIs?
« Reply #20 on: December 02, 2009, 12:20:39 PM »
This sounds eerily familiar


If someone is working on this problem, they should also consider that this behavior is present on, or is triggered by the A axis.

Under certain conditions, if the A axis and the X axis (for example) start moving together, MACH ignores acceleration and just slams the X axis from zero to feedrate. I don't recall off hand the circumstances, but I posted some details on this quite some time ago.

Sounds like this may be a symptom of the same bug, so I thought it worth mentioning.

I've had issues with the A stalling in a similar fashion, rates were WELL below anything that would cause the axis to stall.  Interestingly enough I found that reducing the rates themselves in the program did nothing to stop the stalling behavior, but when I backed down the FRO even just a tiny bit, it would no longer stall. 
Re: Whose Fault Is ThIs?
« Reply #21 on: December 02, 2009, 12:28:57 PM »
This sounds eerily familiar


If someone is working on this problem, they should also consider that this behavior is present on, or is triggered by the A axis.

Under certain conditions, if the A axis and the X axis (for example) start moving together, MACH ignores acceleration and just slams the X axis from zero to feedrate. I don't recall off hand the circumstances, but I posted some details on this quite some time ago.

Sounds like this may be a symptom of the same bug, so I thought it worth mentioning.

I've had issues with the A stalling in a similar fashion, rates were WELL below anything that would cause the axis to stall.  Interestingly enough I found that reducing the rates themselves in the program did nothing to stop the stalling behavior, but when I backed down the FRO even just a tiny bit, it would no longer stall. 

The problem, as I understand it, affects "secondary" axes, and helical moves.  If you have one or more axes in motion at a reasonable speed, then do a helical move that brings in a "secondary" axis, Z in my case, the CV code does not correctly account for the acceleration capability of the secondary axis, resulting in the primary axes entering the helical move too fast, thus requiring the secondary axis to accelerate essentially instantaneously.  Apparently, it's not that the correction is not being done correctly, but rather that it's not being done at all!  The code simply wasn't there.  The same problem apparently existed until fairly recently on linear moves as well.  Brian fixed that a while ago, but never got around to making the changes to the helical move code.  He know exactly what to do, and how, so he should have a fix very soon.  I'm actually surprised this hasn't been a much bigger problem for more people.  I suspect once the new code is out, a number of problems will vanish, and many of us may be able to kick up our velocity and acceleration settings closer to the limits.

Regards,
Ray L.
Regards,
Ray L.

Offline simpson36

*
  •  1,369 1,369
    • View Profile
Re: Whose Fault Is ThIs?
« Reply #22 on: December 02, 2009, 03:04:02 PM »
Just to comment a bit further, I've been noodling over why the problem went away for me, and what I assume is that I probably still have the problem with the A axis, but since I went to servo motors and then better servo drives, the issue has not been able to manifest because the motors get a little behind during the 'instant' accell,  but catch up within a tiny amount of movement, and most likely before the cutting tool touches the workpiece, so there is no practical effect.

If I recall correctly, I read somewhere that you are using Gecko drives. They have only a tiny error allowance and not much power (for a big motor), so they are unable to tolerate the error created by the slammed motor.


Be nice to have it fixed in any case . . . .

While I have your attention, Ray, let me repeat my appreciation for the great manual you have produced. Only used it a couple times, but even then it has saved me a lot of time and hassle.
Re: Whose Fault Is ThIs?
« Reply #23 on: December 02, 2009, 03:17:13 PM »
While I have your attention, Ray, let me repeat my appreciation for the great manual you have produced. Only used it a couple times, but even then it has saved me a lot of time and hassle.


Thanks!  If you like that, just wait until you see what's coming in v4....   :-)

Regards,
Ray L.
Regards,
Ray L.
Re: Whose Fault Is ThIs?
« Reply #24 on: December 02, 2009, 07:29:10 PM »
What manual are we talking about?
Regards,
Ray L.
Re: Whose Fault Is ThIs?
« Reply #26 on: December 08, 2009, 10:28:30 AM »
I've also verified the supply voltage is holding well, never dropping more than about 1.5V from its nominal value.

If all 3 axis have a fast excelleration time, the power supply could be the issue.  Did you use a scope to see the supply voltage or DVM?  A DVM will filter out the surge/voltage drop.  You might try a second supply just on the Z.

JH

Offline simpson36

*
  •  1,369 1,369
    • View Profile
Re: Whose Fault Is ThIs?
« Reply #27 on: December 08, 2009, 01:54:11 PM »
As I kicked up the speed and accell higher and higher I got into an area where simultaneous slamming of all the motors at once started to cause occasional faults.

After clearing it with the drive maker, I installed big caps directly across the power terminals on each drive.

Not a single problem since.
Re: Whose Fault Is ThIs?
« Reply #28 on: February 13, 2010, 02:31:13 AM »
Aaaargh!

I just ran into this bug!

Mach is losing steps in Z when doing a ramping helical interpolation in certain scenarios. It actually appears to handle arc center at X,Y of 0,0 just fine, but certain values of x & y causes it to lose steps... and it loses it exactly the same way and place every time.

I've attached a code segment that performs a finishing cleanup on a parabola which triggers the problem for me. Just to make sure I was sane, I put a digital counter on the z step pin and mach is simply not sending enough steps but it displays that it's in the correct position.

If I had to put money on it, whatever algorithm that was used to calculate the number/timing of Z step pulses during the ramping helical interpolation is running into either a casting or flooring issue.
Re: Whose Fault Is ThIs?
« Reply #29 on: February 13, 2010, 10:05:53 AM »
Aaaargh!

I just ran into this bug!

Mach is losing steps in Z when doing a ramping helical interpolation in certain scenarios. It actually appears to handle arc center at X,Y of 0,0 just fine, but certain values of x & y causes it to lose steps... and it loses it exactly the same way and place every time.

I've attached a code segment that performs a finishing cleanup on a parabola which triggers the problem for me. Just to make sure I was sane, I put a digital counter on the z step pin and mach is simply not sending enough steps but it displays that it's in the correct position.

If I had to put money on it, whatever algorithm that was used to calculate the number/timing of Z step pulses during the ramping helical interpolation is running into either a casting or flooring issue.


Any time you run CV mode, and have a move in X/Y followed immediately by a helical move in X/Y/Z, you have the potential for the Z acceleration limit to be exceeded.  If X/Y/X all have the same acceleration capability, there should not be a problem, but if Z is less than X/Y, then its acceleration limit WILL be exceeeded, and it will probably lose steps as a result.  This has *always* been a  bug in Mach3, and has not yet been fixed.  The work-around is to run in exact stop mode.

Regards,
Ray L.
Regards,
Ray L.