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

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

Reply via email to