Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: joe2014 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
-
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.
-
Sounds like a controller problem. Mach is tellign it to do the cycle but the controller has to actually do it.
(;-) TP
-
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.
-
Well I can tellyou for SURE that the LPT version does not have that problem (;-)
Just a thought, (;-) TP
-
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.
-
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.
-
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
-
Ahh, thanks Roger - so it could be the v.066 that has the issue ??
Tweakie.
-
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
-
OK, hopefully a LAST post from me regarding this issue.
I just installed the older version of Mach3, version 062 to see how it handles the G64 code and it behaves the same as version 066. So, I'll just make sure I don't use G64 in the header of any of my jobs.
Not sure if I'll go back to version 066 or stay at 062 since both appear to have the same issues.
I should probably think about moving to Mach4 but will have to rewrite a dozen scripts or more when I make the move. I'm a bit confused on the Mach4 licensing, I'm a hobbyist and I currently use the same licensed copy of Mach3 on my CNC Mill and CNC Router, two separate PCs. Will I have to purchase two Mach4 hobby licenses if I switch or can I just generate two keys, one for each PC via the single Mach4 hobby license?
Thx,
Joe
-
So much for a last post.....
I'm now getting the bad peck cycle even with the G64 code removed. I SWEAR I was able to verify earlier the G64 code was causing the problem but now it doesn't appear to be. One thing for certain (I think) is that if I let the first peck drill operation complete, albeit screwed up, then all following peck drill cycles work properly. Even if I load a new job, they all continue to work properly. If I then terminate Mach3 and restart it, I get the problem again, until I let it complete one screwed up peck drill cycle. I've also seen the first peck drill cycle work properly if I run some other job first, even if the job does not have a drill cycle in it. I'm a retired software engineer and it just appears to me that some internal Mach3 variables key to the peck drill cycle are not getting initialized properly when Mach3 first starts up.
I'm really tired screwing with this but I need a reliable peck drill function. I'm really surprised others have not run into this, perhaps most others are using the old printer interfaces and they don't seem to have this problem, only smart controllers.
-
it just appears to me that some internal Mach3 variables key to the peck drill cycle are not getting initialized properly when Mach3 first starts up.
This is far more likely. We already know that it can take two spin commands (eg S100) to get the spindle spinning at the required speed at the start.
As a ridiculous and horrible (but probably quite effective) work-around, you could consider inserting a dummy G83 command at the start - up in the air without any drill bit for instance. How about trying the idea out and reporting back?
Cheers
Roger
-
Well, I think I have a way to make the peck drill cycle work properly on the first and all proceeding drill cycles.
The problem I’ve been fighting is definitely related to the machines “Velocity Mode” when the job starts. If the mode is set to “Constant Velocity”, G64, the first peck drill cycle will not work properly and will jam the drill bit down to the final hole depth on each peck retract cycle. After the first hole, all following peck drill operations will work properly.
I’ve found that if I explicitly put Mach into “Exact Stop” velocity mode, either by including the G61 code in Mach’s initialize string or by including G61 in the jobs G Code file header, all the peck drill cycles work properly, including the first. If I omit the G61 from the initialize string AND the job G Code header, the first peck drill cycle fails.
So, to be safe (hopefully), I have included G61 in Mach’s initialize string AND will include it in the header of all my CamBam generated G Code files.
Thanks for all the input and suggestions:
-
Interesting.
Now, I wonder ... what happens if you put G61 into the Mach initialise string, and G64 into the CamBam header?
Cheers
Roger
-
It fails.
-
How very odd.
But not entirely unexpected. It would seem that it is not just in starting Mach3 that there are some 'funnies', but also in loading a program. Sigh.
Cheers
Roger
-
I am having a similar problem with a G81 cycle. I can run the program once ,and then it will not react to the Feed code and just rapid into the work. If I restart Mach 3 it is fine again for the first run. I am going to check tonight using G61 inserted.
Rick.
-
Right now I cannot see why G81 would be affected by G61. It is not possible to run a drill cycle in anything other than 'exact stop'.
I have not had any problems with repeated G8x cycles.
Cheers
Roger
-
Here is what my machine is doing. Let's say we are drilling 4 holes , .75 spacing on the x axis , G81 cycle f10.0. I am using MACH3 ver 062 with ess, windows xp.
My machine rapids at 100 ipm , and usually I have the rapids turned down until I know things are going right. If I set the rapids to 50% as Mach boots up ,the first run is
fine, but by the 2nd or 3rd run it will just always move at the reduced rapid feed rate all the time , and if I take off the rapid overide while still in run mode , then it just moves at 100% rapid. Does not matter if g64 ,or g61 is model , I tried it both ways.
I did notice when it does this , the feed rate displays the rapid feed of 50 ipm , when usually this would always display the commanded F10.0 , unless the feed rate changed in the program. I have to reboot Mach in order to clear this.
Now if I have rapids set 100% when I first boot it up , and run the program at least once , it seems ok and I can even lower the rapids after that.
Anybody ever experience this?
Rick.
-
There are some things I do not meddle with, and feed&spin at boot time is one of them. Yes, we KNOW there are some bugs in Mach3, including this area. We just avoid them.
Cheers
Roger
-
Yes, feed-rate override is dodgy as hell, I'm on v066 ;)
Its ok for a slight tweak while running but i always return it to 100% at shutdown.
Its not so bad <100% but not good >100%
-
Just to make sure we are on the same page , I am talking about reducing the Rapid feed rate , not the commanded feed rate for the drill cycle .
-
How are you reducing it??
-
On the settings page. Rapid OR box.
Rick.