On 3/25/2016 9:30 PM, Jon Elson wrote: > On 03/25/2016 02:35 PM, Sebastian Kuzminsky wrote: >> On 03/25/2016 01:26 PM, Nicklas Karlsson wrote: >>> As someone mentioned before a the an axis/joint may/will run away in >>> case of an encoder failure. >>> >>> It would be possible to detect an encoder failure by comparing output >>> signal with encoder signal. A velocity signal may be integrated and >>> do not allow to wander to much or an encoder error will be detected. >>> A torque signal would be worse. >> An encoder that fails into runaway (motion erroneously detected when >> none is occurring) or that fails into stop (no motion detected when >> motion *is* occurring) will both result in a following error, precisely >> for the reason you say above: linuxcnc compares the commanded position >> with the feedback position from the encoder. >> >> > It will not detect a following error if the failed encoder > is on an axis that does not have any motion commanded at > that time. This may not cause a catastrophic runaway on > some systems like Mesa and Pico Systems analog velocity > controlled servos with tachometers, but a slow creep toward > the limits. Some other systems might have an integrator > that will just keep winding up without feedback. > > Old Allen-Bradley controls generated an absolute velocity > analog signal from the encoder, and compared that to the > absolute value of the tach signal. If the tach came out 20% > above the encoder-derived value, it caused an E-stop. This > was in the days of incandescent lamps in the encoders, so > these errors did occur. They also used 4-sensor encoders, > where they had a separate optical sensor for the A and the > A-not signals. (Same for B and B-not.) These 4 signals > went to Xor gates that made sure the A and A-not and B and > B-not were complementary. If A and A-not were equal for > more than a few us, that caused an E-stop. This detected a > failed lamp. > > Jon >
>>>It will not detect a following error if the failed encoder is on an axis that does not have any motion commanded at that time. << OK, I get it. The commanded position would be changing since it is following a path, yet the encoder is not changing since it is non-functional so there is a following error created. If the commanded position doesn't change and the encoder stops working, then the loop goes unstable and pushes the drive in one direction or the other. I have seen this issue occur when an encoder cable was broken and the machine was restarted. Dave ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
