Hello Guest it is October 19, 2019, 04:09:49 AM

Author Topic: Problem with MACH3 and first peck drill cycle  (Read 8887 times)

0 Members and 1 Guest are viewing this topic.

Problem with MACH3 and first peck drill cycle
« on: November 24, 2014, 06:09:30 PM »
I'm new to CNC machining and just recently converted a G0759 mill to CNC using Hoss designs and recommendations. All appears to be working well but I just ran into the following problem with peck drilling cycles.

I generated a fairly simple G Code file via CamBam and when I tried to machine the part I ran into problems with the peck drill cycle. Specifically, the first hole or drill cycle is the problem, all holes following are fine. The first hole cycle appears to jump high speed down about .25 inches at the end of each peck. The drill lowers at the correct feed rate of 5.0. The drill then appears to drill down .125” as expected but then the drill goes high speed down another .25” and then retracts out of the hole high speed to where it started. For some reason MACH, or maybe my controller board AKZ250 is adding the additional .25” high speed plunge at the end of each peck.

Strangely, the second peck drilled hole in the G file works properly. I’ve even ended the drill cycle and started a new one in the G Code and it also works fine, just the first hole of the first peck drill cycle in the G Code file behaves this way.

Below is a simple code snipet that demonstrates the problem on MY system which is running MACH3 Version R3.043.066 on Windows 7 and talking to a AKZ250 USB interface controller.

Any help or advice appreciated.

G20 G90 G91.1 G64 G40
G0 Z0.125
M3 S2200
G0 X-0.613
G98
(the following peck cycle exhibits the problem)
G83 X-0.613 Y0.0 Z-0.6 Q0.125 R0.125 F5.0
(the following peck cycle works properly)
G83 X0.613 Z-0.6
G80
G98
(the following two peck cycle work properly)
G83 X-0.613 Y0.0 Z-0.6 Q0.125 R0.125 F5.0
G83 X0.613 Z-0.6
G80
G0 Z0.125
M5
M30
Re: Problem with MACH3 and first peck drill cycle
« Reply #1 on: December 02, 2014, 04:34:17 PM »
Still looking for some input or at least acknowledgment of this apparent bug.

Others have reported a similar problem with the Peck drilling function but have reported it as a random, difficult to reproduce problem. My short G Code example reproduces the problem every time on my machine.

Is this a problem that just showed up on  R3.043.066 release or is this an intermittent problem that has been around for some time? If this is new to  R3.043.066, should I go back to an earlier version of Mach3, if so, what version?

I'm hesitant to use the Peck drill function even if it appears to work with some other G Code file because I don't know if this is an intermittent bug that comes and goes or is a solid bug that has been identified and can or has been fixed in another version of Mach3.

I'm now using the normal G81 drill cycle which seems to work OK but would like to use the G83 Peck cycle provided it works properly and consistently.

Offline BR549

*
  •  6,902 6,902
    • View Profile
Re: Problem with MACH3 and first peck drill cycle
« Reply #2 on: December 02, 2014, 06:40:10 PM »
Sounds like a controller problem. Mach is tellign it to do the cycle but the controller has to actually do it.

(;-) TP
Re: Problem with MACH3 and first peck drill cycle
« Reply #3 on: December 03, 2014, 11:07:10 AM »
Sounds like a controller problem. Mach is tellign it to do the cycle but the controller has to actually do it.

(;-) TP

I would be surprised if the AKZ250 motion controller interprets G code. I would think (don't know for a fact) that Mach3 provides the G code interpretation and sends lower level motion control commands to the AKZ controller. The AKZ then interprets the motion control commands into driver control signals such as step and direction. The AKZ probably doesn't know it is performing a Peck Drill operation, it is simply being told positions and speeds and the AKZ does the low level stepping.

A similar problem was reported about 8 months ago using a Smooth Stepper controller both USB and WiFi http://www.machsupport.com/forum/index.php/topic,23990.0.html so I would be surprised if my AKZ250 controller is the culprit but could be. Really need someone familiar with the internals of Mach3 to comment on this problem. Since I can reproduce the problem at will, this may be an opportunity to corner a nasty intermittent bug.

Offline BR549

*
  •  6,902 6,902
    • View Profile
Re: Problem with MACH3 and first peck drill cycle
« Reply #4 on: December 03, 2014, 06:28:21 PM »
Well I can tellyou for SURE that the LPT version does not have that problem (;-)

Just a thought, (;-) TP
Re: Problem with MACH3 and first peck drill cycle
« Reply #5 on: September 24, 2016, 03:09:53 PM »
OK, 2 years later after reporting this problem I decided to get a new controller. I got a Smoothstepper and a KL-DB25-5 BOB. I tried using the peck drill cycle again and got the SAME problem.... UGH. So I assumed there MUST be something in the CamBam G code causing the problem. The actual code for the drill command looked fine therefore there must be something in the CamBam added post processor. The code added at the start of the file (minus the comments) is:

G20 G90
G91.1 G64 G40

Turns out the G64 code is the culprit!!!!!!!!

If I delete the G64 code, the first and all following peck drill cycles work correctly.

If I leave the G64 code in, the first peck drill cycle behaves as I originally documented and rams the drill down instead of retracting after each peck but only on the first hole. After the first hole completes (broken drill bit and all) the remaining holes in the job drill properly. So, for some reason Mach3 does not like the G64 code and after the first peck drill cycle, Mach3 then correctly performs all the remaining peck drill cycles in the file.

The G64 code sets a constant velocity mode. Not sure why this would cause Mach3 to screw up the first peck drill cycle in a job.

Offline Tweakie.CNC

*
  • *
  •  7,950 7,950
  • Super Kitty
    • View Profile
    • Tweakie.CNC
Re: Problem with MACH3 and first peck drill cycle
« Reply #6 on: September 25, 2016, 04:58:55 AM »
Unfortunately Mach3 is now what it is and it is my understanding that no future changes or bug fixes will ever be made. Your ‘work-around’ of deleting the G64 is probably the way to go and something to be remembered for the future.

However, having tried it here, I can confirm exactly what Terry said earlier that your code snippet (with G64) works perfectly every time when using the Parallel Port and Mach3 version R3.043.062.

Over the last couple of years there have been many reported problems, here on the forum, with version R3.043.066 to the extent that Warp9 now recommend using R3.043.062 with their Smooth Stepper. Would it be possible for you to try version .062 with your set-up and see if the problem persists ?

Tweakie.
« Last Edit: September 25, 2016, 05:04:03 AM by Tweakie.CNC »
Success consists of going from failure to failure without loss of enthusiasm.  Winston Churchill.

Offline rcaffin

*
  •  1,003 1,003
    • View Profile
Re: Problem with MACH3 and first peck drill cycle
« Reply #7 on: September 25, 2016, 05:22:25 AM »
I think I am always by default in G64 mode (constant velocity), and I do use G83 a fair bit. No problems.
Ah, but I am running .062 (+ESS).

Cheers
Roger

Offline Tweakie.CNC

*
  • *
  •  7,950 7,950
  • Super Kitty
    • View Profile
    • Tweakie.CNC
Re: Problem with MACH3 and first peck drill cycle
« Reply #8 on: September 25, 2016, 05:28:55 AM »
Ahh, thanks Roger - so it could be the v.066 that has the issue ??

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

Offline rcaffin

*
  •  1,003 1,003
    • View Profile
Re: Problem with MACH3 and first peck drill cycle
« Reply #9 on: September 25, 2016, 08:07:04 AM »
I do not know.
I have never run .066, but I have heard that the 'bug fixes' really pranged the insides in other places. So it may well be.
I do know that several people here and on CNCZone have solved their problems by switching back from .066 to .062 at the urging of several of us.

The real problem is that the internal architecture of Mach3 has some basic design faults which can NOT be solved short of a total rewrite - which is where Mach4 comes in. Design faults, not coding faults.

Cheers
Roger