On Thursday 16 April 2020 20:45:58 Jared McLaughlin wrote: > Gene, > > Okuma does it based on... I think one sensor near the spindle nose. > They are the only ones I know of building it in to a production > machine, and the reviews are good. Detecting the emergence of chatter > is wildly obvious when you look at the frequencies. I've even checked > out audio of chatter and it's really easy to pick out in the frequency > plots. I think it'd be doable in software. > > Once it's detected there's a very simple algebraic expression from the > current chattering spindle speed to get one that doesn't. My only > concern is that you would also have to monitor load on the spindle in > case dropping the spindle speed overloaded the spindle, requiring > reducing feed until the spindle load dropped to a reasonable value. > > Jared > Its been my experience that raising the speed to get above the resonance pays bigger dividends faster, often in just a few percentage points. And that would generally indicate for a higher feed rate. Thats if the spindle can, which is not a problem with my lashup below 2800 revs, and I can peak at 3 grand. I'm bangin on a std 1hp PMDC motor to around 2hp actual. Nothing has complained in about 4 years.
> On Thu, Apr 16, 2020, 5:42 PM Gene Heskett <[email protected]> wrote: > > On Thursday 16 April 2020 16:46:59 Jared McLaughlin wrote: > > > Gene, > > > > > > Specifically I think it would be interesting to make things like > > > spindle speed a "we will try to get there, unless ..." instead of > > > a PID loop sort of behavior. Think of how you might implement > > > something like Okuma's "Machining Navi" where it takes the spindle > > > speed, monitors vibrations and adjusts the spindle speed to a more > > > appropriate speed based on feedback. Basically, a lot of machining > > > has zero feedback loops outside of "did we get to the desired > > > spindle speed and x,y,z location"? Things like chatter are > > > probably best controlled in the controller (as in the Okuma > > > system), but tolerances are probably best controlled in the CAM > > > system. > > > > > > But, wouldn't it be more interesting if a pocketing canned cycled > > > could take the target Material Removal Rate, Surface Finish, and > > > Spindle Speed ( aka SFM ), and juggle the radial and axial depths > > > of cut, engagement angle, and spindle speed? Maybe one where you > > > call out a max spindle speed and max feed rate based on tool life > > > and tool deflection, and let the software do the rest. More of a > > > concept than a fully fleshed out idea. > > > > > > Jared > > > > I am for it, but that would take more hardware monitoring than we > > are currently building into or onto our machines. Since different > > parts of our machines resonate at different frequencies, how many > > vibration pickups would we need to get adequate coverage? I don't > > know without actually building such a beast. But in terms of overall > > production speed, I can well imagine that if properly applied it > > would pay for itself by picking up the production time involved in > > putting that part in the ship it bin faster. > > > > > On Thu, Apr 16, 2020 at 2:35 AM Gene Heskett > > > <[email protected]> > > > > wrote: > > > > On Wednesday 15 April 2020 23:51:38 Jared McLaughlin wrote: > > > > > To be fair, I haven't touched a Heidenhain controller in at > > > > > least ten years. And I wasn't that great with them, anyway. > > > > > > > > > > I just feel like, outside of drilling routines, most canned > > > > > cycles don't have very robust algorithms - it's not like they > > > > > are optimizing for anything but ease. The seem mostly to have > > > > > a constant step over that doesn't account for things like > > > > > angle of engagement in corners, etc. Obviously, lathe turning > > > > > cycles are a different beast. > > > > > > > > > > There was a point in time, when I wrote all my gcode by hand, > > > > > that I wrote out some cycles for myself in sub programs - but > > > > > even those weren't that great compared to what I know now. > > > > > Given the right sort of feedback, it'd be super interesting to > > > > > see canned cycles for linuxcnc that take in to account > > > > > feedback and adapt on the fly - but I'm pretty sure that's out > > > > > of scope for this discussion. > > > > > > > > Why? That is how we spread ideas is it not? With a full command > > > > of the language, there very very little we cannot do. > > > > > > > > We may have to bounce data back and forth between gcode and hal, > > > > But we can do it. You see me asking questions about the latter > > > > because even after 15+ years, I do not consider that I have a > > > > full command of the language. ATM I have a rigid tapping routine > > > > that if it knows how deep the blind hole is, will not ever hit > > > > the bottom of the hole and break the tap even if the overshoot > > > > at the bottom as it turns around is 3 or more turns which it > > > > could easily be if the 40 lb 8" 4 jaw chuck is mounted. To be > > > > really complete it will have to measure the holes depth first, > > > > but that requires I modify a bar holder to both measure the > > > > blind holes depth, then hold a tap hat to thread the hole with, > > > > but my problem with the GO794 has distracted me. That's now > > > > fixed, and the need to purchase a rider because my place us > > > > turning into a jungle, plus the ever increasing needs of my > > > > bride of 30+ years as she is close to dying from COPD. That and > > > > medical emergencies since I am diabetic and now halfway around > > > > my 86th trip around this aging yellow star we call the Sun. My > > > > goal is code that will peck-tap without breaking a tap on any > > > > machine from TLM, thru the G0704 mill to the 11x54 Sheldon. That > > > > will take hal mods on TLM in addition to making tap hat holding > > > > tool holders. The overshoot measuring stuff hasn't been hacked > > > > into its config yet. > > > > > > > > Stay healthy all. > > > > > > > > > > > > Cheers, Gene Heskett > > > > -- > > > > "There are four boxes to be used in defense of liberty: > > > > soap, ballot, jury, and ammo. Please use in that order." > > > > -Ed Howdershelt (Author) > > > > If we desire respect for the law, we must first make the law > > > > respectable. - Louis D. Brandeis > > > > Genes Web page <http://geneslinuxbox.net:6309/gene> > > > > > > > > > > > > _______________________________________________ > > > > Emc-developers mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > > > _______________________________________________ > > > Emc-developers mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > Cheers, Gene Heskett > > -- > > "There are four boxes to be used in defense of liberty: > > soap, ballot, jury, and ammo. Please use in that order." > > -Ed Howdershelt (Author) > > If we desire respect for the law, we must first make the law > > respectable. - Louis D. Brandeis > > Genes Web page <http://geneslinuxbox.net:6309/gene> > > > > > > _______________________________________________ > > Emc-developers mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene> _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
