Inneresting Fadal quirk....

Dec 31, 2008 1 Replies

Awl --



Yesterday, my '98 3016L alarmed out a cupla times, from what I think are occasional overloads on 3-axis rapids at 100%.



Used to be so bad I couldn't use 100% rapid at all on 3-axis moves, but Fadal had me change a parameter setting, which largely cleared the problem. The remaining vestiges of the problem seem to be from middling rpc power. Actually, my rpc is way better than most, because I went through great pains to balance the legs with a switchable capacitor bank, but rpc is still rpc....



But this is just background to The Quirk.



So what I did was remove the Z move from my 3-axis initial move, so the machine would start out with only a 2-axis rapid. And then all hell broke loose, the operative word being "broke".



The reason?



The fadal 88cs control does not like to see an H word without a Z word -- at least not in the context of x,y moves. When I moved the Z move to the next line (to get rid of the 3-axis rapid move), the machine went haywire -- even tho I also re-stated the H word with the Z word. All because the H word was also left on the previous line, without a Z move!



The machine would then not recognize Z0 or even the m0's that I included as part of my sleuthing. Thank god it still recognized the HOLD button!



But, every time I checked Z0 via MDI, it *would* recognize Z0. Yet, in the midst of all this, recognizing machine Z0 (for the carousel) was not a problem.



Wow.... caused all kinds of trouble, broke a $40+ em (the last one, of course), etc.



Inyone else experience program quirks like this, or other quirks?


Just a warning here--(depending on firmware version perhaps) but your Fadal probably won't recognize feedhold in the event you use jog return.

It's not really a "quirk"--rather, the function of "H" is to cause the machine to initiate an immediate offsetting movement in the Z axis by whatever amount and sign happens to be stored as "H value" for that tool in the offset tables ( and at whatever feedrate is currently active ) ...FWIW, this behaviour is same as with fanuc and pretty much any other controller that I've ever dealt with.

Maybe take time to re-read the programming manual as a kind of refresher.

That said, most programmers today probably still tend to split xy from z during rapid moves, positioning XY first and then the Z whenever moving towards the workpiece , and when moving away Z is retracted first.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required