Hello Guest it is July 16, 2019, 01:01:31 AM

Author Topic: Mach3 Bug? Causing overrun of drives  (Read 8224 times)

0 Members and 1 Guest are viewing this topic.

Offline P_D_B

*
  •  35 35
    • View Profile
Mach3 Bug? Causing overrun of drives
« on: March 16, 2013, 05:49:36 PM »
I have an interesting issue.  I have had this happen with three different programs.  When I load a complex 3d modelling program in Mach that has more than five toolpaths all in the same program, when I start the program the program starts as normal but when it moves in G00 rapid the steppers will overrun.  My cam program is Aspire 4 but this also happened with programs I made with 3 as well.  If I output single toolpaths or split the program in half ie. 3 toolpaths in each program, it will work fine.  I am at a loss but like I said only with certain programs.  I have run more than 100 programs. The programs range in number of lines from 300,000 to 600,000.  Any suggestions.

Pete
------------------------------------------------------------
Remember Einstein said this...."We can't solve problems by using the same kind of thinking we used when we created them."
__________________________________

Pete

Offline Hood

*
  •  25,849 25,849
  • Carnoustie, Scotland
    • View Profile
Re: Mach3 Bug? Causing overrun of drives
« Reply #1 on: March 16, 2013, 07:29:29 PM »
What do you mean they overrun? Physically go further than they are meant to? Do the DROs correspond to that overrun?
Hood

Offline P_D_B

*
  •  35 35
    • View Profile
Re: Mach3 Bug? Causing overrun of drives
« Reply #2 on: March 16, 2013, 11:05:50 PM »
Hood,
By overrun I mean it is driving the steppers so hard it actually loses steps.  It will happen with any axis.  But it will only do it with certain programs.  It acts the same as if you are in motor tuning and have the velocity too high.  It will miss a lot of them and be off by many inches (centimeters).  It only happens at tool change.  Going to or when returning from.  The tooling is not any different than other programs I am running.  I have looked at the G code and it is the same calls that are in the other programs.  The only thing I noticed but I do not remember if it was normal was that when I load a program and it say generate toolpaths, that dialog process bar will complete really fast but until the program is ready to run is a while afterward.  So why would it do this when all toolspaths are output to a single file but if you output a single toolpath to a single file it will not.  If you output all toolpaths to a single file again, it will rapid so fast to over drive the steppers.  I have loaded gcode, over driven, closed gcode, loaded again, still does it, powered down for several minutes, restarted tried again, still over drives, load another program, works fine, load that program again, over drives, load only a single toolpath, works fine.  I almost give up.

Sorry for the long rant, only trying to give you the steps I have taken so far.
------------------------------------------------------------
Remember Einstein said this...."We can't solve problems by using the same kind of thinking we used when we created them."
__________________________________

Pete
Re: Mach3 Bug? Causing overrun of drives
« Reply #3 on: March 16, 2013, 11:41:54 PM »
If you're suggesting this is somehow a problem in Mach3, I suggest you come up with another theory.  It is almost certainly something in your machine - either a mechanical or electrical problem.  It could be something in the configuration of your PC causing excessive jitter in the step pulse timing.  If you're operating near the mid-band resonance of your steppers, a small vibration can cause the steppers to fall out of position, losing a step.  Electrical noise can also cause step pulses to be lost, or added.  If you work at it, you should be able to come up with a very short, simple sequence of G-code commands that will induce the failure at a high rate.  That has to be the first step towards finding a resolution.

Regards,
Ray L.
Regards,
Ray L.

Offline P_D_B

*
  •  35 35
    • View Profile
Re: Mach3 Bug? Causing overrun of drives
« Reply #4 on: March 17, 2013, 12:05:43 AM »
Ray,
I somewhat understand what you are referring to.  I just do not understand why it will repeatedly do it with the same gcode.  I have re-run many of the other gcodes and it does not happen. It only happens on the same programs.  The feeds are the same.  There has to be something I am missing.  The sequence in the Gcode appears to be the same.  Losing a step is one thing.  One step is 0.0003" but I am losing up to 3.0000" when it happens.  That is a lot of steps.  The problem programs will not run at all, it always happens.  That is what has me confused.
------------------------------------------------------------
Remember Einstein said this...."We can't solve problems by using the same kind of thinking we used when we created them."
__________________________________

Pete
Re: Mach3 Bug? Causing overrun of drives
« Reply #5 on: March 17, 2013, 12:21:28 AM »
Which is exactly why you need to narrow down *exactly* what it is about the section of code that causes the problem.  You need to whittle it down to a short, simple section of code that reliably induces the failure.  There absolutely is such a sequence.  That will be the quickest path to finding the actual root cause.

Regards,
Ray L.
Regards,
Ray L.

Offline Tweakie.CNC

*
  • *
  •  7,838 7,838
  • Super Kitty
    • View Profile
    • Tweakie.CNC
Re: Mach3 Bug? Causing overrun of drives
« Reply #6 on: March 17, 2013, 03:46:40 AM »
Hi Pete,

If you could zip and post (or e-mail me) a copy of the GCode which has the repeatable problem I would be happy to run it here and if the problem shows on my system then perhaps I could suggest a possible solution.

Tweakie.
Success consists of going from failure to failure without loss of enthusiasm.  Winston Churchill.

Offline Hood

*
  •  25,849 25,849
  • Carnoustie, Scotland
    • View Profile
Re: Mach3 Bug? Causing overrun of drives
« Reply #7 on: March 17, 2013, 03:49:52 AM »
Can you attach your xml and the code and if you can say where roughly in the code it happens it may help but a Ray says its more likely mechanical/e,ectrical.
Hood

Offline P_D_B

*
  •  35 35
    • View Profile
Re: Mach3 Bug? Causing overrun of drives
« Reply #8 on: March 17, 2013, 12:58:04 PM »
My work is an electo-mechanical technician by trade, so I believe you that there is something a miss.  However Rapid is Rapid not matter where the G00 is called.  So why is it that it only happens on certain programs.  I am trying to build a good sequence of events that lead up to it and this is the common denominator.  That being said.  I am also going to look at the tool change macro.  I am using Mach Blue Probing by  Big Tex screenset.

Here is the xml.  The programs are large I will try to Zip them.  One program runs through 2 toolpaths fine until the third tool change (I will note a readme in the zip file).  That is when it always happens.  And the other happens right at the beginning tool change. If they do not zip small enough, give me time to set up a ftp.

Thanks for the help.
------------------------------------------------------------
Remember Einstein said this...."We can't solve problems by using the same kind of thinking we used when we created them."
__________________________________

Pete
Re: Mach3 Bug? Causing overrun of drives
« Reply #9 on: March 17, 2013, 02:15:57 PM »
However Rapid is Rapid not matter where the G00 is called.  So why is it that it only happens on certain programs.

I will disagree with that slightly.  This is a dynamic system, so that one move, by itself, may not really be the issue.  There is another move leading into it, and one leading out of it.  Those can also have an effect, both in the trajectory that Mach3 produces, and in the dynamics of actually executing the moves on the machine.  If you snip a several lines of code both before and after the problem rapid, pre-position the machine, and execute just those lines, does the problem still occur?  If so, then start removing lines from the front and back end, and see where the problem goes away, if at all.  Make sure you duplicate, as fully as possible, the full "environment" as it is when the whole program is running - spindle/coolant, on, etc.

Regards,
Ray L.
Regards,
Ray L.