Greetings all; Up to now I have been tripping on an excess of pid.0.error, suitably lowpass filtered.
Setting a trip point in the hal file, and a hystersis value there too, I have only been feeding comp.0.in1 and using the out as motion enable. So thinking on it (I know, thats dangerous) it seems like I should be feeding comp.0.in0 with something that would tend to scale its sensitivity according to how fast it was turning, eg more sensitive at the slower speeds where a dig in and locked rotor won't generate enough error to trip, but could cause it to blow the real fuse anyway. At very low creep speeds, under 1 rps, it won't hit it hard enough to blow the real fuse, but at 3rps it can clear it in 200 ms. Thread cutting and such are usually at 4-8 rps, right it that area where I don't have (yet) good load protection. So it seems like I ought to be able to just compare the pid.0.command to pid.0.feedback, and arrive at a working "overload" detector. Thoughts? Or am I off the rails? Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! Authors are easy to get on with -- if you're fond of children. -- Michael Joseph, "Observer" I was taught to respect my elders, but its getting harder and harder to find any... ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
