Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Sinij kot on March 04, 2011, 12:25:21 PM
-
I’ve been having a problem with Z axis on a BP series1 milling machine during reverse in tapping cycles.
The stepper on Z stall anytime the feed is set for more than 13 IPM. It seems that gcode calls for more acceleration than the motor can provide.
I have changed motor tuning options in all sorts of way and I can overcome this problem by setting the acceleration really low to 0.4 IPM with velocity of 100 IPM.
Here are my equipment specs:
Series1 BP mill
NEMA42 1150oz 8-wire 1.8deg steppers wired in parallel for most power
80V supply on each axis.
Microstepping driver set for 9.5A and 10 steps (2000steps/rev)
Ballscrews with 5TPI
Motor settings:
velocity 100IPM
Acceleration 4IPM
10000 steps per rev (2000 steps/rev * 5tpi)
Looking at the motor chart, it looks like I should be able to run about 80 IPM (400rpm/5tpi) and full power. In motor tuning screen I can set the velocity to max of 150IPM with acceleration set at 10IPM and have no trouble moving the axis.
So why is the stepper stalling on the retract part of the tapping cycle with federates exceeding 13IPM?
feed rate but without any time for acceleration and I think this is what stalls the stepper.
Thisngs I tried so far:
swapping harware channels (motors, drivers) and I still get the same issue. Although when I sawp Z with X, it seems to have higher limit as to at what feed rate in stalls. Also, I believe the reason the stepper is stalling in retract portion of the cycle is due to more load due to gravity. I checked out the machine and it is not hanging up or binding in any way.
I also changed microsteping to 5 from 10 I am not sure if it made a difference.
Tried Shirline pulsing, no difference.
Could it be the way gcode calls for feed? It seems to want full feed rate without trying to accelerate the motor, maybe this is how it needs to be, but I don't have this problem when I'm milling in x-y with higher feeds. I included TAP file with the tapping cycles that I'm trying to do and also my XML.
I would appreciate any input at this point.
-
Are you using a floating holder for tapping or are you trying to rigid tap?
Hood
-
Hood, good point, I use floating. I should mention that I am testing while air cutting.
I'm having issues with attachments. I will add XML.
G-code:
%
O5000 (FT44144 18TPI.TAP)
( MCV-OP ) (26-FEB-2011)
(SUBROUTINES: O2 .. O0)
G90 G17
G80 G49 G40
G54
G91 G28 Z0
G90
M01
N1 M6 T2
G90 G00 G40 G54
G43 H2 D32 G0 X0. Y0. Z0.05 S500 M3
M8
(------------------)
(D-DRILL-T2 - DRILL)
(------------------)
X0. Y0. Z0.3
M29 S500
G98 G84 Z-0.87 R0.079 P0 F27
X1. Y-0.
X2.
X3.
X4.
X5.
G80
M30
%
Here is motor chart:
(http://i290.photobucket.com/albums/ll259/Sinij_kot/Bridgeport%20Series%201%20CNC%20Mill/motorchart.jpg)
-
XML
-
Try lowering the Velocity and you may find you can increase the accel. I did that on my Bridgeport, went from 2500mm/min to 2300 or somthing like that and could increase the Accel from 40 to 120.
Hood
-
Hood, I did try velocity of 40 without much difference. So you're thinking that the motor just can't accelerate fast enough?
I'll play with lower velocity some more, but what's interesting is setting the acceleration to 0.4 makes things work except the axis behaves like it has a ton of inertia (keeps going for some time after you release the button).
Looking at my settings and the fact that the axis can rapid very fast doesn't it seem strange that it stalls during g-code?
-
The reason it goes on after you release is because of the slow accel, when you release Mach will slow at the accel rate so if its low it will be a while after you release the jog key.
Will go read your post again, was thinking it was the Z that was stalling.
Hood
-
Ok read again and it is your Z but it was the last post I didnt read correctly ;D Thought you had said X Axis, must be needing my eyes tested.
What happens if you simply command a G1 Z move up and down via MDI
Hood
-
Tried g0z1 at all different rates from 10th IPM to 90IPM without any issue. Is it in the g code? Hood, can you try my code to see how it runs?
Thanks.
-
Its after midnight here but will test it out tomorrow but my mill has servos so it may not show up.
Hood
-
You may want to try programming the G84 in Feed per Rev mode. I vaguely remember a problem with g84 and feed per min mode where mach could violate the max accell rate at times. It would also trip my servos here and they are 1kw drives.
FPR mode makes it much easier to program the cycle with(;-) and never had a tripping problem in FPR mode.
ALSO N42 motors are famous for mid range resonance problems. Gecko drives have a setting for them other drives may not.
Just a thought, (;-) TP
-
Works fine on my mill, see vid http://www.youtube.com/watch?v=deYcqlBMhsA
However possibly worth trying what Terry suggested.
Hood
-
I'm narrowing this problem down. The first time I started having this problem was right after hooking up VFD which gave me ability to do semi-rigid tapping. I spent a week chasing noise issues but couldn't find anything and realized that it has something to do with motor acceleration. In my troubleshooting I disabled spindle control and things were working normally which is why I originally concentrated on VFD. One thing clicked today. It has to do with spindle spin up delay.
When spindle control is disabled mill runs fine; spindle goes down and right back up. In automatic spindle control MACH uses spin up delay. In this mode spindle goes down and stops, spindle starts in CCW, comes up ~0.060" waits for the amount of spin up delay, attempts to move up and this is where the stepper stalls.
So, I removed the spin up delay for CCW (tap retract) and now it works fine without stalling. This is O.K. because of the floating holder but I am really curious as to why I have a problem if there is a spin up delay in CCW direction. I could see this becoming a problem based on the RPM and the amount of float in the holder.
Hood, there is no need to test the g-code, I think I ruled it out. Thanks.
-
Hood, there is no need to test the g-code, I think I ruled it out. Thanks.
Too late I already did and posted a link to the video ;D
Hood
-
You may want to try programming the G84 in Feed per Rev mode. I vaguely remember a problem with g84 and feed per min mode where mach could violate the max accell rate at times. It would also trip my servos here and they are 1kw drives.
FPR mode makes it much easier to program the cycle with(;-) and never had a tripping problem in FPR mode.
ALSO N42 motors are famous for mid range resonance problems. Gecko drives have a setting for them other drives may not.
Just a thought, (;-) TP
BR549 I'll research G84 acceleration violation issue you mention. I didn't have a speed feedback when I started so I always programmed in IPM now with index and VFD an FPR approach sounds like a better way to go. I'll give that a try.
My drive and motors are a bit dated (1999) but the drive has anti-resonance feature and the motor is set for maximum power band according to the motor curve I attached earlier in the thread.
Hood I really appreciate your effort. It's cool seeing other machines running the same code.
-
No problem :)
Hood
-
Even if you don't have the spindle speed index signal IPR works fine it just assumes that what you programmed for spindle speed is what it is.(;-)
Do not try to sync the spindle in mach mill as it is broken on the mill side and it messes up the G84 tap cycle.
To test further you can always program the tap cycle as a sub program and let it run. That would simulate the cycle but do it as straight gcode.
(;-) TP