[volkl_ac3]

Hi guys,

Never realized that Granite devices had a forum here so I hope that I can contribute and get help.

I'm currently experiencing random motion fault errors on my y-axis primarily (I think that I once got an x-axis problem) and I can't figure out what is going wrong. They don't happen often, but it seems that once it happens they can be repeated in the exact same position if you rerun the gcode. If you plug in the GDtool and just rerun the position plot than it goes away and doesn't trip in that same spot anymore.

Machine: 3 axis Acer knee mill, 5hp spindle
Servo: Baldor 5.8 amp cont brushless, 33 amp peak, 1000 pos encoder
Drives: 3 VSD-E drives and the GD breaktout board
Settings: 5.9 amp cont, 16 amp limit
Graphs: I have the torque and position tuned very well, they have about 5-6 encoder count errors, but I have the limit set to 15. Accel is set to 1, and speed is set to 5000.
Mach 3: Speed is 700, accel is 25. (the code runs the machine at about 432 during cutting and 700 during transitions. Usually happens during a cutting pass.)

I noticed that if my accel value was high in the drives/mach3 than it was very difficult to keep the motion fault error below 10 even if the graphs looked perfect. Moving the table would trigger the faults. Since then I lowered the accel and this solved my problems apart from this random motion fault error that happens sporadically.

Any ideas? I'll post pics of the graphs tonight. I'm planning on putting in a piece of fence post and just turning on a big project to get the machine cutting for several hrs to try and force the error.

Cheers,
Sebastian

[neilw20]

Program the drives with the GDtool for the maximum practical speed, and acceleration, then ensure Mach3 settings are less than you have set in the drives, so it can't be commanded to exceed the limits.
If it still does it, then Mach3/PC train of pulses is being interrupted, causing impossible acceleration/deceleration demands.

Encoder count errors?
There may be dust on the encoder disk, or more likely magnetic whiskers on the hall sensor magnet.
To remove magnetic whiskers (and you might not be able to see them!) use sticky tape. Spottlessly clean is mandatory.

Faulting will occur if the hall sensor puts out an impossible pulse sequence, which is always quadrature, but breaks the quadrature transition possibilities.
Motor turns the wrong way (or the hall sensor says it does) and the encoder and hall sensor direction sensed mismatch.

It is also possible noise is getting into the wiring between the motor and the controller. Separate the power and signal cables.
Make sure shields are only connected at one end.

[volkl_ac3]

Thanks for the suggestions Neil. To clarify, when I said random fault error I really meant a one in a million type of situation but I think that I found the reason for it last night. I've been experimenting with feed speeds and it seems that the probability for an error is high if I play with the spindle rpm speed while it is doing reposition movements to see if a lower/higher rpm on the next cut will be better. This happened to me last night during my first test cut, and then after when I stopped touching the rpm during the entire cut program it never occured again. I don't have chatter marks or squealing of the tool during cutting so I don't see why small rpm changes up and down could have affected it. Anyways, several hrs of cutting last night without problems. Will do longer programs in the next several days and see if it remains reliable.

Cheers,
Sebastian

[neilw20]

Changing the spindle speed is probably causing higher currents while the rpm changes, and these higher currents are corrupting either the encoder and/or the hall sensor signals.
Make a short program that cuts air and does lots of speed changes and see what happens.
In Mach3 reducing the acceleration on the spindle channel might help to reduce abrupt changes to the spindle currents.
At least you have narrowed it down. Well done.

[Xerxes]

Sebastian, before we go digging the reason deeper, can you verify if it is really the "motion fault"? You can find the led blinking pattern for motion fault to confirm if this is the same error than you have.

Anyway, there is "motion fault threshold" parameter in GDtool. Try setting it to 0 to disable that fault completely. Or increase the threshold to avoid the fault but have it still active.

[volkl_ac3]

I ran some more cuts last night and the problem has not resurfaced so I'm happy

Xerxes: I apologize for my typo, I meant to say following error. Red blinks, nothing else. I know that if I set the motion fault value to a high number than it will never trip the error, but then you never know when your machine is making small mistakes. Isn't the point of this value to be very low but high enough to have a little tolerance for small errors?

I will run my large products tonight and report back.

[neilw20]

That was nice help from Finland.

[Xerxes]

Thanks for clarification! Following error is caused only by one scenario: target and achieved positions differ more than the limit value specified in GDtool. So good tuning and proper follow error limit should keep this error away.

[volkl_ac3]

So what should I set my fault trip limit to? I know that I can run the step response graphs with a error value of 10 since the actual error seems to be around 6-7 (I turned on the fault limit graph option), but I played it safe and set it to 15. I'll copy my graph output and post it tonight/tomorrow.