[DameCore]

I'm new to the mill here in Troy. I was hired on just last week as an electrical/mechanical technician. However, I believe this problem exceeds my area of expertise. Here is the issue:
Initially, the TS-25 went into a "436 Servo alarm: 3 Axis Disconnect". After a day of testing limit switches and the servo pulse coder, this problem seemed to disappear so long as we followed a specific "homing" sequence at the start up of the machine(start by homing 'X', then 'Z' then 'C'). More on this later...
FOUR days later(we had other, smaller projects to clear our heads with as well!) we were still confounded with the new problem that had occurred immediately following the sequential fix: The C-Axis is now failing to engage during program run. We have been able to make it work manually and during a dry run, but as soon as the true program runs, it fails. By 'fail' I mean the spindle begins to disengage and the C-axis begins to engage and the physical component between the two stops dead between the two limit switches(one to engage, one to disengage.)
So...our two suspects were/are a faulty solenoid -which is probably debunked based on the fact that engage/disengage function works properly during dry run- or a faulty programming line -which our programmer insists is not the case (The machine stalls out at M76, just before S2000, M70). We've also ruled out bad limits, bad bit numbers, hydraulic pressures, loose connections, Takisawa USA, and acts of God.

Any help with this project would be greatly welcomed and appreciated. And please, be kind...I'm new here.
Thanks in advance and I apologize if I've posted this in the wrong area.

Oh, by the way, as of yesterday, the "436 Servo Alarm" is back. And this time, it doesn't seem to care about sequence. Despite initial tests, we're leaning toward the pulse coder on this one.

[DameCore]

Does anyone know if parameters can just change themselves? That is one theory that has come out since this project started. I finally got through to a service tech at TakisawaUSA and this is what he beleives is the issue here. Although I'm not familiar with programming type stuff, a parameter changing by itself sounds a little too sci-fi to me.
Does anyone have insight on this particular response?

P.S. The 436 Servo alarm has disappeared...again.

[Switcher]

I don't run the same machine that you have, I run a 5-axis Schutte, a while back we had a problem that coolant was getting into the C-axis, & onto the encoder.

The machine would run just fine until the C-axis would Rapid, then it would fault out, once the encoder was cleaned we never had that problem again.

I'm not saying that you have the same problem that I did, just that sometimes it's the simple things that get ya!

As far as parameters changing themselves, yes that is very much possible (IF) you write a program (g-code) to do that. Again I'm not sure about your control, but it can/is done with Siemens 840D.

What I would do is write a very,very small program (g-code) & just cycle thru all the axis one at a time with a slow feed rate, If everything works ok, bump up the feedrate (Rapid) & run the same small program.

Also double check all your cable connections.


.

[DameCore]

Thanks for your input, Switcher.

After numerous 'discussions' :argue: and field tests, it has been decided that this is most likely an encoder issue, as you suggested. Per TakisawaUSA, we checked all switches, greased the hell out of the machine and added hydraulic oil (it was low). We did not change any parameters because we're all pretty sure that is not really the problem. Our resident expert believes that the encoder on the spindle motor is not functioning correctly. This sediment was previously debunked by the same resident expert (In his defense, however, at first, we were adressing a "436 Servo Alarm: 3-Axis Disconnect", so of course, no one would think the spindle encoder could be at fault...3-axis, we all assumed, meant C-Axis).

Our only problem now is that one of the screws holding the encoder in place is stripped. Once we rectify that situation, we should be able to FINALLY get to the heart of the matter here.

More updates as events warrant.


UPDATE:04/04/07-A thourough inspection of the spindle encoder revealed it to be dry and clean, but slightly ascewed. After holding it in place and cranking the mounting screws down, we perfomred a series of dry runs. These dry runs have been successful (although at the end of one cycle we had a Z-axis Servo alarm). The next step is a series of dry runs with a part in the chuck. The logic here is that we want to check for counter balancing issues. If these tests are successful, we will begin milling the parts. Our magic number is 5. If we can make 5 parts, the machine will be considered fixed.
I'm optimistic.

[DameCore]

I feel like this is more of a blog than a message board, but that's okay, as long as my trials and tribulations help someone else out someday, I will rant on as long as they let me.

Other than the one Z-servo alarm, we have had a flawless run on the TS-25 for the last two days! :banana:

Even though we still have a minor belt squeal, we believe the problem, ultimately, was a loose and/or misaligned pulse encoder. Ain't that a (nuts) !
We will continue to keep an eye on the belts, although a physical inspection shows them to be solid and in good working condition. The squeal is making the programmer a little nervous, but I've reassured him it's nothing to worry about...yet.

[DameCore]

When last we left our hero...

Other than the one Z-servo alarm, we have had a flawless run on the TS-25 for the last two days! :banana:

However, looming in the background, plotting revenge and laying in wait for the proper time to strike...it's the Return Of:

"THE 436 SERVO ALARM: 3 AXIS DISCONNECT!!!"
:bat:

After a month of functioning properly the Takisawa TS-25 now refuses to home out, and proudly displays the above alarm. My first thought was to offer it more money, or better benefits. When that failed, as expected, I began to look closer at the parameters. Unfortunately, my lack of knowledge regarding parameters interfered with my progress.

We are curious about a possible 'axis drift' we have heard about. This seems like it could be our issue, since the proximity switch seems to function properly, but at the wrong moment. It's as if the C-Axis can only home 359 of the 360 required degrees...sometimes. Other times it makes up for it's shortcomings by going all the way to 380 degrees.

Any and all insight on this issue would, as always, be greatly appreciated. More or less, we just want to know if we're on the right track, or has something been overlooked completely.

Thanks.

[RRL]

What model Fanuc control is it?
What is the alarm number on the axis drive?

The 436 is related to the pulse coder. On the 16 & 18 you can check diag. #201.

Diag. Description from 16, 18 Maintenace Manual

ALDF is bit 7
EXPC is bit 4

ALDF EXPC Alarm details
1 0 Built in pulse coder disconnection (hardware)
1 1 Seperartely insatlled pulse coder disconnection (hardware)
0 0 Pulse coder not connected due to software

Hope this helps you out.

RRL

[DameCore]

RRL, thank you for the input. It has been a while since I've worked on this project due to other, more pressing matters. Now that I'm back on it, I need some help deciphering your last response.
First off, we have a Fanuc Series O-T. That much we know.
The alarm number, if I'm reading this correctly, is 436. But I'm not sure I understand your question:
"(What is the alarm number on the axis drive?)"

The next question would be what do the numbers 16 and 18 refer to. We have a ton of manuals here for this machine, but nothing that refers to those numbers (whether it be a series number or reference number or even a print version number...we don't know.)

Finally, even our programmer was confused by the terms "ALDF" and "EXPC". What do these represent, in laymen's terms?

I appreciate, as always, any input from anyone willing to supply it. Thanks in advance. I also apologize for asking stupid questions, if indeed they turn out to be so.

I'm also wondering if anyone knows how any of this may be related to G-Codes and/or parameters in terms of parameters mysteriously changing themselves.

DxCx