Hello Guest it is April 28, 2024, 10:15:33 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - HimyKabibble

141
General Mach Discussion / Re: Mach3 Bug? Causing overrun of drives
« on: March 17, 2013, 06:20:40 PM »
IIRC, v3.043.022 is the version I had that problem with.  However, it was only an issue when the Z axis was set for lower velocity/acceleration than the other axes, and only when transitioning from a 2-axis arc move to a three-axis move.  Mach3 would ignore the Z axis acceleration, and command it to accelerate at the rate of the other two axes, which, of course Z could not do.  I've been told it was fixed quite some time ago.

Have you tried running with a more recent version of Mach3?  That one is quite old.

Regards,
Ray L.

142
ALL CAM programs will generate bad code at times.  I haven't looked at that G-code editor in some time.  I use CutViewer Mill for simulation.  It's a bit crude, and limited in some ways, but as a mean of validating G-code, it works extremelty well, and gives you a rotatable/pannable/zoomable 3D view of the part as it's being cut.  I don't think the CNCCookbook one does that - it only showed toolpaths last time I looked at it.  CutViewer has a free trial, so you can always download it and use it to check your code.

Regards,
Ray L.

143
General Mach Discussion / Re: Mach3 Bug? Causing overrun of drives
« 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.

144
Sounds like at the end, the machine was exactly where Mach3 thought it was?  If so, then it's not a position loss, but an error in the G-code.  You need to look at the code that caused the bogus move, and you should find something there, or just preceding it, that will explain what happened.

Regards,
Ray L.

145
General Mach Discussion / Re: Mach3 Bug? Causing overrun of drives
« 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.

146
General Mach Discussion / Re: Mach3 Bug? Causing overrun of drives
« 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.

147
General Mach Discussion / Re: G83 Random Bug
« on: March 15, 2013, 11:38:24 AM »
Ray,

Did you always work with the 1024 screen?

Dennis


Dennis,

No, I used a completely custom screen set.  I also used a SmoothStepper - both USB and Ethernet.  We always suspected what I saw was some obscure communications issue between Mach3 and the SmoothStepper.  You're the only person besides me I've ever heard of who's had this problem.

Regards,
Ray L.

148
General Mach Discussion / Re: G83 Random Bug
« on: March 15, 2013, 10:37:22 AM »
Hood,

I don't recall Brian ever making such an offer to me, and I don't how I could've done it anyway.  The "PC" is an integral part of the entire controller on that machine, which is a 24x24x12" steel box jam-packed with electronics, weighing probably 150#.  Moving it is simply not practical.  He did do everything he possibly could remotely, as did Greg, but it seemed every time the thing was "instrumented", it would behave.  As soon as I tried to get any real work done, it would act up again.  We found and fixed several other problems, but not this one.

Regards,
Ray L.

149
General Mach Discussion / Re: G83 Random Bug
« on: March 15, 2013, 10:15:16 AM »
Ray,
 Just a shame you declined Brians offer to fly you up with your computer to try and find your issue, didnt realise this was one but good to know.
Hood

Say what?  There was no such offer.  And even if there was, no guarantee it would've led to a solution.  It could sometimes work for days at a time with no problem, other times I couldn't do even one hole.

Regards,
Ray L.

150
General Mach Discussion / Re: G83 Random Bug
« on: March 15, 2013, 08:46:30 AM »
Ha!  I stopped using Mach3 over a year ago because of exactly that bug!  It broke dozens of drills.  I spent hours on the phone with both Brian Barker and Greg Cary over a period of several months trying to isolate it, and we never were able to.  On the rare good days, I could drill hundreds of holes without a problem.  Other days, I was lucky if I could drill three holes before it tried to rapid the drill to China partway through a drilling cycle.  It was completely random, and in my case had nothing to do with G83, as I used hard-coded peck cycles.

Just curious - Are you using a motion controller, or just the parallel port?

Regards,
Ray L.