[mflux_gamblej]

I seem to have a talent for bringing out the best, as well as the worst in my fadal lately.

I decided to run a program from internal memory tonight, the part ran great through several tools all the way up to the final toolpath - rigid tapping some 2-56 tapped holes 0.125" deep in aluminum using a form tap. The rigid tapping cycle seems to not work well at all when run from internal memory. The spindle jerks around really bad to the point that it just stops a lot, then tries to resume, then stops, then resumes, and all the while the lights are flickering and the spindle drive cannot be very happy through this violent jerking.

When I run the exact same code over DNC, no trouble at all - works great like the spindle does a little ballet at 500 RPM.

I may have noticed that when run over internal memory that I didn't see the spindle do it's usual 3 or 4 turns before actually stepping down and running the rigid tap cycle. I believe this is used to get the speed readout correlated with the encoder / c-axis controller card.. I don't know.

It's like the spindle over-shoots its speed target then has to try and slow down, which it overshoots too and comes to a halt. All the while during this spindle jerking the processors are trying to keep the z axis sync'd up with all the bullsh*t spindle behavior, which it doesn't do so great. The tap didnt break, but the threads are very loose and messy.

I went back to DNC, and - no problem at all.

Maybe its some kind of gain setting issue? ..no idea.

wtf, again.

[carbidecraters]

Depending on the machine and post processor a S100.2 F40. is invalid or a M3 in there. The .2 is common for mastercam to put in after the S-FEEDRATE code snippet. The other thing that can cause rigid tapping dance is a dirty encoder. They have to sync to work and if they dont o you have a bad code in there youll see it. Post your code.

[mflux_gamblej]

I'm getting this problem again, now run on DNC - so that makes me feel better in a way.

Now, to troubleshoot I've increased the tapping RPM from 500RPM to 550RPM, and I get an overload message, error #13 which has to do with the overload number programmed in the SETP menu.

I'm not sure what to think - maybe it is just a dirty or trashed encoder on my spindle? I've tapped many holes without issue that I've detected. This is the second time I've had this error come up. Last time it would run OK over DNC but not from internal memory - a coincidence? I don't know. strange though.

I will try setting the overload parameter to 3 instead of the default 2 and see what happens.

any previous experience would be helpful here.

[carbidecraters]

That can be caused by a dirty encoder. If your willing to gamble you could take the cap off the encoder on top of the motor and wipe the disk. Its about $150 to replace with new. Spindle jerking and error #13 are classic symptoms.

[mflux_gamblej]

That can be caused by a dirty encoder. If your willing to gamble you could take the cap off the encoder on top of the motor and wipe the disk. Its about $150 to replace with new. Spindle jerking and error #13 are classic symptoms.

I set the overload parameter in setp all the way to 8 and I get the error#13 just as fast. This means that something unrealistic is happening. Although, it does the overload / error on reversal during the tapping cycle so maybe being 8 turns behind isnt so unrealistic if the encoder is messed up.

Another symptom that points down this road is that I've had problems with spindle orientation ever since I bought this machine. The spindle will orient, stop, seem to slip past the mark, does a full turn, orients, stops, slips past, full turn again, orient, stop - most of the time at this point it will settle in, and the tool change will happen. Sometimes though I get an error saying the spindle orientation failed. At this point, I do an HO, SETCS, HO, and restart the machine at the mains.

Oddly (to my knowledge) after the restart, the machine will then orient just fine on the first try and the error is gone the rest of the day - but it will return the next day until I go through this error-out + restart routine.

Maybe it is just dirty / ruined encoder games after all. The jerking adds up very well with a dirty encoder issue - it misses some lines, tries to accelerate instantly, overshoots and sees many lines, tries to decelerate instantly, notices that the speed is too low, then goes over the bad lines again and accelerates - this describes jerky quite well. I haven't measured the speed of my spindle with a laser tach. I will do this tonight before I take the covers off to get at the encoder.

Another potential symptom is that my load meter seems to read bullsh*t all the time unless you really put it under a load, say like 3" face milling 0.08" deep at 5000 rpm and 0.005" in/tooth - then it will read like 60% to 70% and appears steady. All other times it will read some dumb value like 35% when the tool isn't cutting anything.

The spindle sounds nice and smooth though all the time, and only jerks during rigid tapping. I have a baldor H2 newer spindle drive so i bet that's in good shape.

One final potential symptom is that my spindle motor shakes a lot when in the low range belt. I read that this could be caused by a dirty encoder, although once its at speed there's no jerking.

The only other piece that I am suspicious of is the magnetic orientation sensor, which I have read in the fadal manuals is used to calibrate RPM just before the rigid tapping cycle.

[carbidecraters]

Orientation sensor failure, weak arm will cause that motion. There is also an orientation factor speed setting in the SETP parameters.. Spindle motor shaking COULD potentially be that issue it would be found in low range in the upper realm of low range 1200-2500rpm and that is another classic sympton of a dirty encoder. The load meter could be the actual spindle motor/aging meter or voltage leaking into the circuit from not grounding and being around hi-frequency machines.

[mflux_gamblej]

Do you know which encoder I need to buy? (not having looked at it..). The manuals don't spell it out. I am assuming that I need the more expensive ENC-0004 rather than the cheaper US digital one. I have a 1992 4020HT which has the 10K spindle, and larger 15HP baldor motor.

I suppose I'll have to overnight an encoder, and then tare it all down and retune the spindle drive, etc. Looks like I have a day of not getting sh*t done ahead of me tomorrow.

[mflux_gamblej]

Well, a couple things:

I inspected the spindle encoder, it's clean as can be. Its the fancier ENC-0004, not the more open US digital one. The disc inside looks super clean.

I inspected the z-axis resolver - the voltage output was good, but mechanically it was pretty worn out. So, I put a new resolver on the z-axis.

I zero balanced my spindle drive, and also ran the feedback check auto diagnostic - passed both

So, I ran my tapping program, and, NO CHANGE. goddamnit.

Angry with this result, I ran another different program from a couple of days ago, and what do you know, that one runs perfect. rigid taps without any problem what so-ever. WTF!

this must be some kind of distance prior to tapping thing, or who the hell knows. Maybe its just my luck that a certain number in the code f*cks it all up. no matter what this seems like BS to me. at least the machine taps (with certain g-code) and I suppose the new resolver on the z won't hurt (except my wallet). I'll post back when I find out what in the g-code was messed up. Here are the codes so far:


Works:
N3 G90 G17 G40 G80 G00
N166 T20 M06 *6-32 Form Tap*
N168 G00 E1 G90 X1.473 Y-0.814 S500 M03
N169 G43 H20 Z1.5
N170 Z1.
N171 G84.2
N172 G98 G84.1 X1.473 Y-0.814 Z-0.505 R-0.03 S500. F15.625
N173 X6.213

Does Not Work:
N1 G90 G17 G80 G00 G40
N359 T7 M06 *2-56 forming tap*
N361 G00 E1 G90 X4.3175 Y-1.802 S500 M03
N362 G43 H7 Z1.5 M07
N363 Z1.1
N364 G84.2
N365 G98 G84.1 X4.3175 Y-1.802 Z.12 R0.33 S500. F8.9286
N366 Y-2.557

[mflux_gamblej]

on consulting the trusted fadal manual for fixed cycles:

when rigid tapping, you can program a G84.2 to get the machine to do it's RPM calibration during the H offset application movement. This means that you have to call G84.2, then the H offset. I wasn't doing it this way.

the manual also says that you have to Not turn on the spindle, and in fact their examples use an M5 in the codes prior to calling the rigid tap cycle.

I'll try these things out and see if it fixes the problem.

[mflux_gamblej]

O... K...

time to admit being stupid I suppose. upon getting my post to spit out rigid tapping g-code according to the fadal manual, guess what, it all works just great.

It means that my old way of doing the code was wrong, and was prone to failure duing the spindle speed calibration cycle that the machine does just before rigid tapping. here's my new code that works:

N1 G90 G17 G80 G00 G40
N140 T7 M06 *2-56 forming tap*
N142 G00 E1 G90 X4.3175 Y-1.802 S500.1 M05 M90
N143 G84.2
N144 G43 H7 Z1.5 M07
N145 Z1.
N146 G98 G84.1 X4.3175 Y-1.802 Z-0.12 R0.23 S500. F8.9286
N147 Y-2.557

[mflux_gamblej]

So, the story isn't over afterall.

My test file that worked as described below was just the tapping toolpath alone. I'm sure that doing the tapping g-code according to the manual is better or something, but it turned out not to be the cause of the rigid tapping problem.

I found the problem though for sure now.

It turned out that I went to run the rest of my part program after seeing that the tapping 'worked' as described previously. When I ran that program, BAM the tapping doesnt work and its all jerky again. WTF!!! So, it became clear that it was something in the g-code. Knowing that the tapping cycle code was line for line identical, I worked on removing other portions of the full part code. Through process of elimination, I figured out that it wasn't something prior to or during the tapping code - the trouble causer is actually AFTER the tapping cycle in the g-code.

The next tool path in the code after the tapping uses fadal's fancy Advanced Feed Forward (M94.2) to get through some high speed machining. It turns out that the control is actually looking ahead of the tapping cycle, and is executing AFF related stuff that f*cks up the rigid tapping cycle.

Sure enough, the very old code from when I first started this thread that worked over DNC, but not when run from internal memory - it uses AFF too. Its just that the control can look farther ahead when its in internal memory than it can when its running over DNC - and for that reason, on the old program from when I started this thread - tapping was fine when run over DNC, but not when run from internal memory.

So I have a cause of the problem - if the control sees an M94.2 / AFF in the future of the executing program, rigid tapping gets f*cked up and does all the jerking and so on.

I do not have a solution. Maybe there is some way to disable look ahead? heh. I saw that you can do this by using M0, but that causes the machine to go to a waiting state, and I'm not always around to press buttons so that is not an acceptable solution. I also wish to use AFF so that my high speed portion runs smooth and doesn't gouge (i also paid for AFF, so i better be able to use it, and tap damned holes too).

What a stupid problem - this is a fadal software bug, not a machine mechanical problem, not an electrical problem - its a damn software bug and that means I cannot fix it. F*CK

[mflux_gamblej]

and now, in a surprise and satisfying finish - I am bailed out by Macro statements.

The macro command #WAIT

makes the machine execute the existing buffer before loading any further, but then it keeps on executing after the WAIT statement without operator interaction. holy crap.

it works though. what a day

[motionman]

I have those days all the time. Kudos on the fix

[mflux_gamblej]

An add-on to this problem / solution to the problem is more about the buffer look ahead when running from internal program memory.

Despite having implemented the #WAIT statement prior to any AFF call that happens after a rigid tap routine, I had jerky tapping again today. In this case, I had a tapping cycle after a pocket that uses AFF. this should not be a problem as AFF gets cancelled after any AFF cycle. well, I got bit again by the look ahead buffer. My tapping cycle happens last in the program, and the AFF cycle happens first in the program - so when i start the next part it goes to an AFF cycle.

alright, so it seems that the machine will read into the code and buffer it up when in 'auto' mode / from internal memory, even after the program is over; its buffering for the next run of the program in an endless loop.

now in my code I just put a #WAIT prior to any AFF call no matter what. where before I only did it if it was after a tapping cycle. it turns out that if the machine can see the AFF call anywhere in the program, as imagined as an endless loop (no end no beginning, just a position in the loop), the jerk tapping problem will happen.

fyi

just put the #WAIT code before any call to AFF. the only pain in the ass is that AFF type cycles use G1 motion only and that most programs like that have high feed rates - so you may run out of the 256 long buffer pretty fast if the feed rate is very high. guess that's life.

[Konstrukter1]

Hello,

regarding the rigid tapping, is this also ok (G84.2 after H)?


%
N1 O1 (D_DRILL1.NCC )
N2 (24-JAN-2016)
N3 (10:14:54) G17
N4 T2 M6 ( ** Tool 2 - Diameter 6.0 ** )
N5 G0 G90 S250 M3 E1 X-8. Y-10. M3 (Could stay, to start with program and with additional M5 stop the spindle and prepare my Fadal for tapping?)
N6 H2 D2 Z50. M8
N7 ( ** D-DRILL1 - DRILL ** )
N8 M5
N9 ( ** Tap tool M6.0** )
N10 G84.2 Preparation for G84.1 (Does need to be before H2? or is it ok to pt it here?)
N11 M00 Additional stop (Checked, double checked....)
N12 G0 X-8. Y-10. Z10.
N13 G98 G84.1 Z-5. R2.P100 S250. F250
N14 G80
N15 M5 M9
N16 X0 Y0 Z0 E0 H0
N17 M30
%
%

Thanks in advanec for any hint!

[mflux_gamblej]

Hello,

regarding the rigid tapping, is this also ok (G84.2 after H)?


%
N1 O1 (D_DRILL1.NCC )
N2 (24-JAN-2016)
N3 (10:14:54) G17
N4 T2 M6 ( ** Tool 2 - Diameter 6.0 ** )
N5 G0 G90 S250 M3 E1 X-8. Y-10. M3 (Could stay, to start with program and with additional M5 stop the spindle and prepare my Fadal for tapping?)
N6 H2 D2 Z50. M8
N7 ( ** D-DRILL1 - DRILL ** )
N8 M5
N9 ( ** Tap tool M6.0** )
N10 G84.2 Preparation for G84.1 (Does need to be before H2? or is it ok to pt it here?)
N11 M00 Additional stop (Checked, double checked....)
N12 G0 X-8. Y-10. Z10.
N13 G98 G84.1 Z-5. R2.P100 S250. F250
N14 G80
N15 M5 M9
N16 X0 Y0 Z0 E0 H0
N17 M30
%
%

Thanks in advanec for any hint!

you should have started a new thread for this question. its not related to the aff issue.

here's some rigid tapping code anyhow: (just read the fadal manuals and do what they say to do, whether you think its a good idea or whatever. did u design the fadal control software?).

as another note, do Not run rigid tap code on a non-rigid tap machine because it won't error out and stop - it will crash right into your part.


N3 G90 G17 G40 G80 G00
N162 T18 M06 *4-40 STI Tap*
N165 G00 E12 G90 X2.09 Y-0. S500.1 M05 M90
N166 G84.2
N167 G43 H18 Z4. M07
N168 G04 P1600
N169 Z4.
N170 G98 G84.1 X2.09 Y-0. Z1.865 R2.225 S500.1 F12.5
N171 X1.71
N172 G80
N173 A120.
N176 Z4.
N177 G98 G84.1 X2.09 Y-0. Z1.865 R2.225 S500.1 F12.5
N178 X1.71
N179 G80
N180 A240.
N183 Z4.
N184 G98 G84.1 X2.09 Y-0. Z1.865 R2.225 S500.1 F12.5
N185 X1.71
N186 G80
N187 A0.
N188 M09
N189 M05


the P1600 up there is a delay to wait for the coolant to be running nicely prior to approaching the part.

also, if there are multiple holes and not a 4th axis as shown above, you can just list the xy locations prior to the g80 and they will work - check the manual for code that looks like that. this code does that, but it might not have been obvious about the stuff going on for 4th ax. you see the code with g98 calls an xy location, then right after that there's a second tapped hole at a different x position.

[Konstrukter1]

Sorry for hijacking the thread. I wrote here, because its rigid tapping issue and forum is full practical the same topics....
To answer, yes I did this post myself. I have this structure practical identical for some other usage (High speed speeder,...) and i could write post for tapping in the same structure that Fadal show in their manual. But that is not what i would like to have.
So is there a problem to have G84.2 after H and if is it ok to simply add M5 after spindle start? Then again, thanks for P1600 tip (I will certainly add them all holes prior to tapping).

Best regards

[Konstrukter1]

So nobody knows answer? (So is there a problem to have G84.2 after H and if is it ok to simply add M5 after spindle start? ) Would code structure as this work OK for rigid tapping?

%
N1 O1 (D_DRILL1.NCC )
N2 (24-JAN-2016)
N3 (10:14:54) G17
N4 T2 M6 ( ** Tool 2 - Diameter 6.0 ** )
N5 G0 G90 S250 M3 E1 X-8. Y-10. M3 (Could stay, to start with program and with additional M5 stop the spindle and prepare my Fadal for tapping?)
N6 H2 D2 Z50. M8
N7 ( ** D-DRILL1 - DRILL ** )
N8 M5
N9 ( ** Tap tool M6.0** )
N10 G84.2 Preparation for G84.1 (Does need to be before H2? or is it ok to pt it here?)
N11 M00 Additional stop (Checked, double checked....)
N12 G0 X-8. Y-10. Z10.
N13 G98 G84.1 Z-5. R2.P100 S250. F250
N14 G80
N15 M5 M9
N16 X0 Y0 Z0 E0 H0
N17 M30
%
%

Best regards,
Franc

[Konstrukter1]

It works fine. I try and it flies like a spoon in a bucket of marmalade......

Best regards,
Franc