Re: [Emc-users] reducing rigid tapping overshoot

[Gene Heskett]

On Wednesday 28 April 2021 11:23:44 Jon Elson wrote:

> On 04/28/2021 01:53 AM, John Dammeyer wrote:
> > I'm running LinuxCNC 2.7 on a PC.  Which of these would I select for
> > that?
> >
> > https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/tag/1.8.2r
>
> I'm not sure you need any of these.  Most Linux installs
> have fpc in their software library, it can be installed with
> something like :
>
> sudo apt install fpc
>
> sudo dpkg -i fpc
>
> Jon
>
And I'm allergic to pascal. And I'm not about to clone github until I can 
read the missing README.md

> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[Gene Heskett]

On Wednesday 28 April 2021 02:53:39 John Dammeyer wrote:

> I'm running LinuxCNC 2.7 on a PC.  Which of these would I select for
> that?
>
> https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/tag/1.8.2r
>
> Thanks
> John
>
Where is the README.md?
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[John Dammeyer]

The idea behind Lazarus is write once, compile anywhere.  So I've been working 
on a few projects that unfortunately make that philosophy a bit of a stretch 
(polite term).  Programs written and compiled under windows didn't even compile 
properly on a Pi or Beagle.
 
The thing about fpcupdeluxe is that it's an interface that lets you choose a 
specific version of both FPC and Lazarus.
For example, "sudo apt install lazarus" gets version 1.6.7 I believe.
 
But when you install it for a windows PC you get 2.0.10.  With the fpcupdeluxe 
I was able to get and build that specific version for both the Beagle and the 
Pi.  After that, since the libraries now matched, the applications compiled and 
ran.  Although still not exactly the same.
 
Graphical components appear to have an issue.  What works on Windows doesn't 
work correctly on the Beagle or Pi.  So I tried it on the LinuxCNC pc with rev 
1.6.7.  Same problem there so it's an issue with an object descended from 
TGraphicControl.  
TjdSevenSegDisplay = class(TGraphicControl)...
 
Note in the photo when the component rectangle on which the segments are placed 
is dragged away from the 0,0 corner the segments don't come with nor do they 
resize correctly when the rectangle is expanded.  On windows it works 
perfectly.  On Linux it doesn't.  The 6 digit display doesn’t have the problem 
so I'm on track for trying to figure out what's different at the base level of 
the component design.
 
cid:image001.png@01D73BB9.185437C0
 
Anyway, that's why I want to be able to install the same version on full sized 
Linux system since I can't break the component on the WIN-7 or WIN-10 PCs and 
it takes way to long using a Pi or Beagle as the working desktop PC to do 
anything.
 
And in the long run one of my goals is to develop some graphical based tools 
that run on Windows and LinuxCNC for machine control with CAN bus.  That the 
sockets.pp interface for Lazarus is behind the sockets.c is another issue with 
socketCAN not yet supported by Lazarus.
 
John
 
 
> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> Sent: April-28-21 8:24 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] reducing rigid tapping overshoot
> 
> On 04/28/2021 01:53 AM, John Dammeyer wrote:
> > I'm running LinuxCNC 2.7 on a PC.  Which of these would I select for that?
> >
> >  <https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/tag/1.8.2r> 
> > https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/tag/1.8.2r
> >
> >
> I'm not sure you need any of these.  Most Linux installs
> have fpc in their software library, it can be installed with
> something like :
> 
> sudo apt install fpc
> 
> sudo dpkg -i fpc
> 
> Jon
> 
> 
> ___
> Emc-users mailing list
>  <mailto:Emc-users@lists.sourceforge.net> Emc-users@lists.sourceforge.net
>  <https://lists.sourceforge.net/lists/listinfo/emc-users> 
> https://lists.sourceforge.net/lists/listinfo/emc-users
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[Jon Elson]

On 04/28/2021 01:53 AM, John Dammeyer wrote:

I'm running LinuxCNC 2.7 on a PC.  Which of these would I select for that?

https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/tag/1.8.2r


I'm not sure you need any of these.  Most Linux installs 
have fpc in their software library, it can be installed with 
something like :


sudo apt install fpc

sudo dpkg -i fpc

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[John Dammeyer]

I'm running LinuxCNC 2.7 on a PC.  Which of these would I select for that?

https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/tag/1.8.2r

Thanks
John




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[Gregg Eshelman via Emc-users]

KERS = Kinetic Energy Recovery System. Various means of capturing some energy 
during braking then using it to help accelerate out of turns. IIRC Formula 1 
never fully implemented used of any KERS device due to some chassis 
manufacturers complaining about the difficulty and expense of cramming such 
things into the small vehicles, and the practical limitations on how much 
energy could be captured in such small space in such little time, then released 
just as quickly. The impact on fuel use would have been quite minimal. The 
impact on mechanical complexity and thus potential lack of reliability could 
have been as bad as their early years of electronic controls in F1 when races 
often had the majority of the field retire due to computer failures.

F1 has a history of making a bunch of rule changes then making so many new 
changes the next year that the teams must go back to the CAD workstations and 
start over from scratch. When combined with the F1 rule makers keeping an ear 
to the ground for any whispers of competitive advantage concepts they don't 
like then pre-banning them before anyone has so much as started scribbling on a 
cocktail napkin - designing F1 race cars must be one of the most fascinating 
and maddeningly frustrating jobs ever.
IIRC F1 banned KERS before anyone began development, then flip-flopped and 
insisted everyone was going to have to have KERS for "saving the planet"* or 
whatever, then flopped back on it when KERS was proving to be mostly pointless. 
 
*Which made as much nonsense as it did the year NASCAR shortened all their 
races in the 1970s to "save fuel".

On Monday, April 26, 2021, 5:31:38 PM MDT, Gene Heskett  
wrote:  
 On Monday 26 April 2021 17:37:10 andrew beck wrote:

> i have a friend that pulled apart a old 100+ kw vfd and collects caps.
>
> he has buckets of massive ones
>
> On Tue, Apr 27, 2021 at 9:02 AM Leonardo Marsaglia
> 
>
> wrote:
> > From what I could understand gene is using something similar to the
> > old KERS used in Formula 1. I don't know if this is a common
> > practice because it's really good idea. May be the only drawback is
> > the cost of the capacitors and that's why we don't see this approach
> > very often.
> >
KERS is an unk acronym to me.  Yes, I do have quite a bank of caps in 
that psu but the cost was zip, came from an old employee I was told to 
fire 30 years ago, but his building skills were very useful when my door 
had a nameplate with Chief Engineer on it.  I refused, and he had a job 
till we moved the transmitter in 2008. His navy pension isn't that much, 
so we get into a fight everytime I go raid his junkbox because I insist 
on paying him, IIRC that bank of huge caps, which have to be soft 
started else they'll trip a 30 amp breaker, cost me a $20 bill and I had 
to threaten him to get him to keep it.  
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[Gene Heskett]

On Monday 26 April 2021 17:37:10 andrew beck wrote:

> i have a friend that pulled apart a old 100+ kw vfd and collects caps.
>
> he has buckets of massive ones
>
> On Tue, Apr 27, 2021 at 9:02 AM Leonardo Marsaglia
> 
>
> wrote:
> > From what I could understand gene is using something similar to the
> > old KERS used in Formula 1. I don't know if this is a common
> > practice because it's really good idea. May be the only drawback is
> > the cost of the capacitors and that's why we don't see this approach
> > very often.
> >
KERS is an unk acronym to me.  Yes, I do have quite a bank of caps in 
that psu but the cost was zip, came from an old employee I was told to 
fire 30 years ago, but his building skills were very useful when my door 
had a nameplate with Chief Engineer on it.  I refused, and he had a job 
till we moved the transmitter in 2008. His navy pension isn't that much, 
so we get into a fight everytime I go raid his junkbox because I insist 
on paying him, IIRC that bank of huge caps, which have to be soft 
started else they'll trip a 30 amp breaker, cost me a $20 bill and I had 
to threaten him to get him to keep it.

> > El lun., 26 abr. 2021 17:50, andrew beck 
> >
> > escribió:
> > > OK gene.
> > >
> > > I'm all ears . Love To hear how this works.  Maybe put the
> > > relevant
> >
> > code
> >
> > > here.
> > >
> > > Regards
> > >
> > > Andrew
> > >
> > > On Tue, 27 Apr 2021, 1:37 AM Gene Heskett,  
wrote:
> > > > On Monday 26 April 2021 08:02:34 andy pugh wrote:
> > > > > On Mon, 26 Apr 2021 at 11:19, andrew beck
> > > > > 
> > > >
> > > > wrote:
> > > > > > Still need to automate changing ramp
> > > > >
> > > > > If you wanted to do it based on commanded spindle speed, then
> > > > > "lincurve" would probably work.
> > > > >
> > > > > Alternatively, you could consider basing it on spindle.0.revs,
> > > > > noting that a threading pass is unlikely to get higher than
> > > > > 100 full turns between index resets.
> > > > >
> > > > > Or, maybe even just base it on the spindle running in reverse.
> > > > > I
> >
> > think
> >
> > > > > that rigid tapping does a reverse without a stop?
> > > >
> > > > It does indeed do that Andy, zero smarts about that. And I can't
> > > > think
> >
> > of
> >
> > > > a better way to blow a vfd and/or a 30 amp 240 volt breaker
> > > > abuseing a horse or more motor by slamming it into reverse while
> > > > spinning at its normal rpms.
> > > >
> > > > Thats why /all/ of my machines have extra hal code and modules
> > > > loaded
> >
> > to
> >
> > > > control that. I tried to describe the sequence of events that I
> > > > use to control that yesterday. It works, and does /not/ trip 15
> > > > amp breakers doing it. My 11" Sheldon lathe, with a vfd but no
> > > > PID's in the config, has this hal code in it, and additional hal
> > > > code to report the overtravel both in terms of spindle travel in
> > > > turns, and If the gcode makes use of it, travel distance of the
> > > > overtavel provided you tell it what the tpi of the tap loaded
> > > > is.
> > > >
> > > > With a nearly 40 pound 8" 4 jaw chuck mounted, my overtravel is
> > > > at 100 rpms, .25 turns, and I can and have done it at 5 second
> > > > intervals for half an hour at a time without tripping anything
> > > > off, and I'm doing it with a cheap clone vfd that has no
> > > > breaking resistor hookups, controlling the vfd thru a pwmgen and
> > > > a spinx-1.
> > > >
> > > > Similar hal code is used in the go704 and in tlm but tlm's idea
> > > > was to preserve drive parts as none of a 7x12's was ever
> > > > designed for a motor that size with millisecond response times.
> > > >
> > > > The slowdown in the go704 was actually designed to stop the z
> > > > following errors at the bottom of a stroke, it can reverse
> > > > faster than z can keep up, so the overshoot is still substantial
> > > > at 1000 rpms. So I tap at 2
> >
> > or
> >
> > > > 3 hundred rpms in low gear. But it also means that if my gcode
> > > > accidently outputs an m4 while its turning 3 grand, its back to
> > > > 3 grand in reverse in less than 400 milliseconds. Thats a bit
> > > > hard on the
> >
> > filter
> >
> > > > caps, but no great surge from the powerline thanks to Jon's
> > > > pwm-servo being a full 4 quadrant control, so it sucks energy
> > > > out of the spinning motor as it stops it, running the filters up
> > > > to around 170 volts, 40 volts above their rating. but once the
> > > > motor is stopped, it then uses that stored energy to
> > > > re-accelerate the motor in the other direction,
> >
> > so
> >
> > > > the overvoltage only exists for less that 50 milliseconds. I
> > > > usually hear the iron in the motor chirp from the servo amps
> > > > programmed 17 amp limit, which is about 190% of those motors
> > > > nameplate full load amps of 9.7, as both motors are 90 volt
> > > > rated motors getting about 125 to 130 volts if the going gets
> > > > tough.
> > > >
> > > > So it can be done and I'm disappointed 

Re: [Emc-users] reducing rigid tapping overshoot

[Gene Heskett]

On Monday 26 April 2021 16:47:27 andrew beck wrote:

> OK gene.
>
> I'm all ears . Love To hear how this works.  Maybe put the relevant
> code here.
>
I'd love to Andrew, but its long, and the simplest version would be from 
the pi4b running the sheldon. But I just found that for the first time 
in about 18 months of building master for the pi4 on the pi4, has now 
developed a tkinter or python tummy ache, and I haven't a working DRO.  
It worked yesterday so its a recent raspian update, or a recent git 
commit, as both have been updated today.  So sit on this for at least a 
day while this hopefully gets sorted and the pi4 is running normaly 
again.

What I'll likely do is put it up on my web page, it needs an update 
anyway.

I'll post when its there. But right now my tummy is asking if my throats 
been cut. And since I'm the only one here, guess who gets designated to 
fix that. :)

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 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[andrew beck]

i have a friend that pulled apart a old 100+ kw vfd and collects caps.

he has buckets of massive ones

On Tue, Apr 27, 2021 at 9:02 AM Leonardo Marsaglia 
wrote:

> From what I could understand gene is using something similar to the old
> KERS used in Formula 1. I don't know if this is a common practice because
> it's really good idea. May be the only drawback is the cost of the
> capacitors and that's why we don't see this approach very often.
>
> El lun., 26 abr. 2021 17:50, andrew beck 
> escribió:
>
> > OK gene.
> >
> > I'm all ears . Love To hear how this works.  Maybe put the relevant
> code
> > here.
> >
> > Regards
> >
> > Andrew
> >
> > On Tue, 27 Apr 2021, 1:37 AM Gene Heskett,  wrote:
> >
> > > On Monday 26 April 2021 08:02:34 andy pugh wrote:
> > >
> > > > On Mon, 26 Apr 2021 at 11:19, andrew beck 
> > > wrote:
> > > > > Still need to automate changing ramp
> > > >
> > > > If you wanted to do it based on commanded spindle speed, then
> > > > "lincurve" would probably work.
> > > >
> > > > Alternatively, you could consider basing it on spindle.0.revs, noting
> > > > that a threading pass is unlikely to get higher than 100 full turns
> > > > between index resets.
> > > >
> > > > Or, maybe even just base it on the spindle running in reverse. I
> think
> > > > that rigid tapping does a reverse without a stop?
> > >
> > > It does indeed do that Andy, zero smarts about that. And I can't think
> of
> > > a better way to blow a vfd and/or a 30 amp 240 volt breaker abuseing a
> > > horse or more motor by slamming it into reverse while spinning at its
> > > normal rpms.
> > >
> > > Thats why /all/ of my machines have extra hal code and modules loaded
> to
> > > control that. I tried to describe the sequence of events that I use to
> > > control that yesterday. It works, and does /not/ trip 15 amp breakers
> > > doing it. My 11" Sheldon lathe, with a vfd but no PID's in the config,
> > > has this hal code in it, and additional hal code to report the
> > > overtravel both in terms of spindle travel in turns, and If the gcode
> > > makes use of it, travel distance of the overtavel provided you tell it
> > > what the tpi of the tap loaded is.
> > >
> > > With a nearly 40 pound 8" 4 jaw chuck mounted, my overtravel is at 100
> > > rpms, .25 turns, and I can and have done it at 5 second intervals for
> > > half an hour at a time without tripping anything off, and I'm doing it
> > > with a cheap clone vfd that has no breaking resistor hookups,
> > > controlling the vfd thru a pwmgen and a spinx-1.
> > >
> > > Similar hal code is used in the go704 and in tlm but tlm's idea was to
> > > preserve drive parts as none of a 7x12's was ever designed for a motor
> > > that size with millisecond response times.
> > >
> > > The slowdown in the go704 was actually designed to stop the z following
> > > errors at the bottom of a stroke, it can reverse faster than z can keep
> > > up, so the overshoot is still substantial at 1000 rpms. So I tap at 2
> or
> > > 3 hundred rpms in low gear. But it also means that if my gcode
> > > accidently outputs an m4 while its turning 3 grand, its back to 3 grand
> > > in reverse in less than 400 milliseconds. Thats a bit hard on the
> filter
> > > caps, but no great surge from the powerline thanks to Jon's pwm-servo
> > > being a full 4 quadrant control, so it sucks energy out of the spinning
> > > motor as it stops it, running the filters up to around 170 volts, 40
> > > volts above their rating. but once the motor is stopped, it then uses
> > > that stored energy to re-accelerate the motor in the other direction,
> so
> > > the overvoltage only exists for less that 50 milliseconds. I usually
> > > hear the iron in the motor chirp from the servo amps programmed 17 amp
> > > limit, which is about 190% of those motors nameplate full load amps of
> > > 9.7, as both motors are 90 volt rated motors getting about 125 to 130
> > > volts if the going gets tough.
> > >
> > > So it can be done and I'm disappointed that no one is asking me how to
> do
> > > it.
> > >
> > > 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 
> > >
> > >
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> > >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> Leonardo Marsaglia
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

Re: [Emc-users] reducing rigid tapping overshoot

[Leonardo Marsaglia]

From what I could understand gene is using something similar to the old
KERS used in Formula 1. I don't know if this is a common practice because
it's really good idea. May be the only drawback is the cost of the
capacitors and that's why we don't see this approach very often.

El lun., 26 abr. 2021 17:50, andrew beck 
escribió:

> OK gene.
>
> I'm all ears . Love To hear how this works.  Maybe put the relevant code
> here.
>
> Regards
>
> Andrew
>
> On Tue, 27 Apr 2021, 1:37 AM Gene Heskett,  wrote:
>
> > On Monday 26 April 2021 08:02:34 andy pugh wrote:
> >
> > > On Mon, 26 Apr 2021 at 11:19, andrew beck 
> > wrote:
> > > > Still need to automate changing ramp
> > >
> > > If you wanted to do it based on commanded spindle speed, then
> > > "lincurve" would probably work.
> > >
> > > Alternatively, you could consider basing it on spindle.0.revs, noting
> > > that a threading pass is unlikely to get higher than 100 full turns
> > > between index resets.
> > >
> > > Or, maybe even just base it on the spindle running in reverse. I think
> > > that rigid tapping does a reverse without a stop?
> >
> > It does indeed do that Andy, zero smarts about that. And I can't think of
> > a better way to blow a vfd and/or a 30 amp 240 volt breaker abuseing a
> > horse or more motor by slamming it into reverse while spinning at its
> > normal rpms.
> >
> > Thats why /all/ of my machines have extra hal code and modules loaded to
> > control that. I tried to describe the sequence of events that I use to
> > control that yesterday. It works, and does /not/ trip 15 amp breakers
> > doing it. My 11" Sheldon lathe, with a vfd but no PID's in the config,
> > has this hal code in it, and additional hal code to report the
> > overtravel both in terms of spindle travel in turns, and If the gcode
> > makes use of it, travel distance of the overtavel provided you tell it
> > what the tpi of the tap loaded is.
> >
> > With a nearly 40 pound 8" 4 jaw chuck mounted, my overtravel is at 100
> > rpms, .25 turns, and I can and have done it at 5 second intervals for
> > half an hour at a time without tripping anything off, and I'm doing it
> > with a cheap clone vfd that has no breaking resistor hookups,
> > controlling the vfd thru a pwmgen and a spinx-1.
> >
> > Similar hal code is used in the go704 and in tlm but tlm's idea was to
> > preserve drive parts as none of a 7x12's was ever designed for a motor
> > that size with millisecond response times.
> >
> > The slowdown in the go704 was actually designed to stop the z following
> > errors at the bottom of a stroke, it can reverse faster than z can keep
> > up, so the overshoot is still substantial at 1000 rpms. So I tap at 2 or
> > 3 hundred rpms in low gear. But it also means that if my gcode
> > accidently outputs an m4 while its turning 3 grand, its back to 3 grand
> > in reverse in less than 400 milliseconds. Thats a bit hard on the filter
> > caps, but no great surge from the powerline thanks to Jon's pwm-servo
> > being a full 4 quadrant control, so it sucks energy out of the spinning
> > motor as it stops it, running the filters up to around 170 volts, 40
> > volts above their rating. but once the motor is stopped, it then uses
> > that stored energy to re-accelerate the motor in the other direction, so
> > the overvoltage only exists for less that 50 milliseconds. I usually
> > hear the iron in the motor chirp from the servo amps programmed 17 amp
> > limit, which is about 190% of those motors nameplate full load amps of
> > 9.7, as both motors are 90 volt rated motors getting about 125 to 130
> > volts if the going gets tough.
> >
> > So it can be done and I'm disappointed that no one is asking me how to do
> > it.
> >
> > 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 
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
Leonardo Marsaglia

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[andrew beck]

OK gene.

I'm all ears . Love To hear how this works.  Maybe put the relevant code
here.

Regards

Andrew

On Tue, 27 Apr 2021, 1:37 AM Gene Heskett,  wrote:

> On Monday 26 April 2021 08:02:34 andy pugh wrote:
>
> > On Mon, 26 Apr 2021 at 11:19, andrew beck 
> wrote:
> > > Still need to automate changing ramp
> >
> > If you wanted to do it based on commanded spindle speed, then
> > "lincurve" would probably work.
> >
> > Alternatively, you could consider basing it on spindle.0.revs, noting
> > that a threading pass is unlikely to get higher than 100 full turns
> > between index resets.
> >
> > Or, maybe even just base it on the spindle running in reverse. I think
> > that rigid tapping does a reverse without a stop?
>
> It does indeed do that Andy, zero smarts about that. And I can't think of
> a better way to blow a vfd and/or a 30 amp 240 volt breaker abuseing a
> horse or more motor by slamming it into reverse while spinning at its
> normal rpms.
>
> Thats why /all/ of my machines have extra hal code and modules loaded to
> control that. I tried to describe the sequence of events that I use to
> control that yesterday. It works, and does /not/ trip 15 amp breakers
> doing it. My 11" Sheldon lathe, with a vfd but no PID's in the config,
> has this hal code in it, and additional hal code to report the
> overtravel both in terms of spindle travel in turns, and If the gcode
> makes use of it, travel distance of the overtavel provided you tell it
> what the tpi of the tap loaded is.
>
> With a nearly 40 pound 8" 4 jaw chuck mounted, my overtravel is at 100
> rpms, .25 turns, and I can and have done it at 5 second intervals for
> half an hour at a time without tripping anything off, and I'm doing it
> with a cheap clone vfd that has no breaking resistor hookups,
> controlling the vfd thru a pwmgen and a spinx-1.
>
> Similar hal code is used in the go704 and in tlm but tlm's idea was to
> preserve drive parts as none of a 7x12's was ever designed for a motor
> that size with millisecond response times.
>
> The slowdown in the go704 was actually designed to stop the z following
> errors at the bottom of a stroke, it can reverse faster than z can keep
> up, so the overshoot is still substantial at 1000 rpms. So I tap at 2 or
> 3 hundred rpms in low gear. But it also means that if my gcode
> accidently outputs an m4 while its turning 3 grand, its back to 3 grand
> in reverse in less than 400 milliseconds. Thats a bit hard on the filter
> caps, but no great surge from the powerline thanks to Jon's pwm-servo
> being a full 4 quadrant control, so it sucks energy out of the spinning
> motor as it stops it, running the filters up to around 170 volts, 40
> volts above their rating. but once the motor is stopped, it then uses
> that stored energy to re-accelerate the motor in the other direction, so
> the overvoltage only exists for less that 50 milliseconds. I usually
> hear the iron in the motor chirp from the servo amps programmed 17 amp
> limit, which is about 190% of those motors nameplate full load amps of
> 9.7, as both motors are 90 volt rated motors getting about 125 to 130
> volts if the going gets tough.
>
> So it can be done and I'm disappointed that no one is asking me how to do
> it.
>
> 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 
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[Gene Heskett]

On Monday 26 April 2021 08:02:34 andy pugh wrote:

> On Mon, 26 Apr 2021 at 11:19, andrew beck  
wrote:
> > Still need to automate changing ramp
>
> If you wanted to do it based on commanded spindle speed, then
> "lincurve" would probably work.
>
> Alternatively, you could consider basing it on spindle.0.revs, noting
> that a threading pass is unlikely to get higher than 100 full turns
> between index resets.
>
> Or, maybe even just base it on the spindle running in reverse. I think
> that rigid tapping does a reverse without a stop?

It does indeed do that Andy, zero smarts about that. And I can't think of 
a better way to blow a vfd and/or a 30 amp 240 volt breaker abuseing a 
horse or more motor by slamming it into reverse while spinning at its 
normal rpms.

Thats why /all/ of my machines have extra hal code and modules loaded to 
control that. I tried to describe the sequence of events that I use to 
control that yesterday. It works, and does /not/ trip 15 amp breakers 
doing it. My 11" Sheldon lathe, with a vfd but no PID's in the config, 
has this hal code in it, and additional hal code to report the 
overtravel both in terms of spindle travel in turns, and If the gcode 
makes use of it, travel distance of the overtavel provided you tell it 
what the tpi of the tap loaded is.

With a nearly 40 pound 8" 4 jaw chuck mounted, my overtravel is at 100 
rpms, .25 turns, and I can and have done it at 5 second intervals for 
half an hour at a time without tripping anything off, and I'm doing it 
with a cheap clone vfd that has no breaking resistor hookups, 
controlling the vfd thru a pwmgen and a spinx-1.

Similar hal code is used in the go704 and in tlm but tlm's idea was to 
preserve drive parts as none of a 7x12's was ever designed for a motor 
that size with millisecond response times.

The slowdown in the go704 was actually designed to stop the z following 
errors at the bottom of a stroke, it can reverse faster than z can keep 
up, so the overshoot is still substantial at 1000 rpms. So I tap at 2 or 
3 hundred rpms in low gear. But it also means that if my gcode 
accidently outputs an m4 while its turning 3 grand, its back to 3 grand 
in reverse in less than 400 milliseconds. Thats a bit hard on the filter 
caps, but no great surge from the powerline thanks to Jon's pwm-servo 
being a full 4 quadrant control, so it sucks energy out of the spinning 
motor as it stops it, running the filters up to around 170 volts, 40 
volts above their rating. but once the motor is stopped, it then uses 
that stored energy to re-accelerate the motor in the other direction, so 
the overvoltage only exists for less that 50 milliseconds. I usually 
hear the iron in the motor chirp from the servo amps programmed 17 amp 
limit, which is about 190% of those motors nameplate full load amps of 
9.7, as both motors are 90 volt rated motors getting about 125 to 130 
volts if the going gets tough.

So it can be done and I'm disappointed that no one is asking me how to do 
it.

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 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[andy pugh]

On Mon, 26 Apr 2021 at 11:19, andrew beck  wrote:

> Still need to automate changing ramp

If you wanted to do it based on commanded spindle speed, then
"lincurve" would probably work.

Alternatively, you could consider basing it on spindle.0.revs, noting
that a threading pass is unlikely to get higher than 100 full turns
between index resets.

Or, maybe even just base it on the spindle running in reverse. I think
that rigid tapping does a reverse without a stop?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[andrew beck]

Hey everyone just a quick reply here.
Jon yep I have a braking resistor.

So I have the spindle accel and decel running through a limit component.
 Constraining rate of change.

Which works quiet nice.

And I am have a custom m code that increases rate of ramp when rigid
tapping.   So I can do nice high speed ramping with low overshoot.  I get
about half a turn of overshoot max.

Still need to automate changing ramp

So any ideas on what is the best way are welcome.

Options I know of are bash script or owords subs.   Or maybe python


Regards

Andrew

On Mon, 26 Apr 2021, 4:54 AM Jon Elson,  wrote:

> On 04/24/2021 05:00 AM, andrew beck wrote:
> >
> > if I try rigid tap at 1000 rpm at 1mm pitch i get a over travel of about
> > 5mm.  I can reduce the deceleration ramp in the altivar 71 schiender
> drive
> > to 0.5 secs and then the over travel is about one revolution of the
> > spindle.  but if i leave the settings in vfd like that and then run
> spindle
> > at 9000rpm the spindle goes into overvoltage faults.
> >
> Do you have a braking resistor on the drive?  That is needed
> to absorb the returned energy when decelerating the
> spindle.  If you don't have one, you need it.  It is
> possible to use an old-style "cal rod" stovetop heating
> element as a braking resistor.
>
> Also, you may be able to use a limit3 or lowpass hal
> component to slow the accel/decel of the spindle command.
>
> Jon
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[Jon Elson]

On 04/24/2021 05:00 AM, andrew beck wrote:


if I try rigid tap at 1000 rpm at 1mm pitch i get a over travel of about
5mm.  I can reduce the deceleration ramp in the altivar 71 schiender drive
to 0.5 secs and then the over travel is about one revolution of the
spindle.  but if i leave the settings in vfd like that and then run spindle
at 9000rpm the spindle goes into overvoltage faults.

Do you have a braking resistor on the drive?  That is needed 
to absorb the returned energy when decelerating the 
spindle.  If you don't have one, you need it.  It is 
possible to use an old-style "cal rod" stovetop heating 
element as a braking resistor.


Also, you may be able to use a limit3 or lowpass hal 
component to slow the accel/decel of the spindle command.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[Scott Harwell via Emc-users]

 Andrew,
Is a geared head? If so what are the ratios?

On Sunday, April 25, 2021, 6:30:19 AM CDT, andrew beck 
 wrote:  
 
 hey guys

not sure if my emails are coming through to you guys.  hope they are.

i have just successfully set up my encoder for rigid tapping using index
signal from spindle motor encoder

just got a few questions for the group

is it possible to set different ramp values depending on spindle speed.

if I try rigid tap at 1000 rpm at 1mm pitch i get a over travel of about
5mm.  I can reduce the deceleration ramp in the altivar 71 schiender drive
to 0.5 secs and then the over travel is about one revolution of the
spindle.  but if i leave the settings in vfd like that and then run spindle
at 9000rpm the spindle goes into overvoltage faults.

just wondering if I can maybe set use the ramp internally to linuxcnc to
give me more control

http://linuxcnc.org/docs/html/examples/spindle.html

if i could specify a max rate of change and also a max ramp setting I think
I could set the values up so that at high speed the max rate of change
slows the spindle slowly enough that it doesn't  trip vfd.  while at low
speed say under 1000 rpm the spindle can stop faster.  or maybe I am just
miss reading this all


regards

Andrew

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
  
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[Gene Heskett]

On Sunday 25 April 2021 08:24:49 Leonardo Marsaglia wrote:

> Hello Andrew,
>
> Is there a baking resistor installed on your drive? I think a proper
> one should solve your problem and you can keep the good deceleration
> rates.
>
> Leonardo Marsaglia
>
> El dom., 25 abr. 2021 08:30, andrew beck 
>
> escribió:
> > hey guys
> >
> > not sure if my emails are coming through to you guys.  hope they
> > are.
> >
> > i have just successfully set up my encoder for rigid tapping using
> > index signal from spindle motor encoder
> >
> > just got a few questions for the group
> >
> > is it possible to set different ramp values depending on spindle
> > speed.
> >
> > if I try rigid tap at 1000 rpm at 1mm pitch i get a over travel of
> > about 5mm.  I can reduce the deceleration ramp in the altivar 71
> > schiender drive to 0.5 secs and then the over travel is about one
> > revolution of the spindle.  but if i leave the settings in vfd like
> > that and then run spindle at 9000rpm the spindle goes into
> > overvoltage faults.
> >
> > just wondering if I can maybe set use the ramp internally to
> > linuxcnc to give me more control
> >
> > http://linuxcnc.org/docs/html/examples/spindle.html
> >
> > if i could specify a max rate of change and also a max ramp setting
> > I think I could set the values up so that at high speed the max rate
> > of change slows the spindle slowly enough that it doesn't  trip vfd.
> >  while at low speed say under 1000 rpm the spindle can stop faster. 
> > or maybe I am just miss reading this all

I don't have a spindle system quite like what Andrew has described, 
probably the closest would be on my lathe with a vfd.

There, and two other machines that can rigid tap, its a rather complex 
bit of hal I can email (PM, just ask) the files for, but that is best 
described:

I treat the change in direction from motion by detecting it with an xor, 
so it works for both direction switches. Direction actually fed to the 
spindle controller is captured by the one shot timing out as the spindle 
is stopped by the limit3 in series with the speed signal, the initial 
action being a zeroed input to the limit3, with the limit3 output going 
to the controller.

I also use Jon's (PICO) pwm-servo amp with dc motors, and like the vfd, 
its a full 4 quadrant controller, extracting the energy from the motor 
as its stopping and feeding it back into the power supply.  Stopping 
either motor to a slow enough speed that a oneshot timing out due to the 
lengthening time between encoder pulses makes a good stopped indicator.

When that oneshot times out, the mux2, functioning as a sample-hold is 
finally updated so it sends the new direction to the controller and the 
xor2. The xor2 then restores the speed signal to the input of the limit3 
controller and that ramps up the speed to its former value. In the case 
of the sheldon lathe with a vfd fed by a pdm-generator driving a 
spinx-1, which controls the vfd, I can reverse a 40 lb 8" chuck, and I 
have some more hal watching and displaying that overtravel, and I have 
hub clamps on the backing plates to prevent unscrewing themselves from 
the spindle. The overtravel at 100 rpm is .25 turns, and at 500 rpm is 
just a bit more than 3.5 turns. Not much faster if I have an er42 collet 
in the spindle as the rest of the drive chains mass prevents making it 
any faster. Lots of spinning mass in an E-400 drive even w/o that big 
chuck.

I can go a wee bit faster but the vfd goes into an overvoltage shutdown 
if I push the limit3 setting any faster. But still, .25 turns is pretty 
impressive for turning around a 40 lb chuck.

I use the same basic idea on TLM, and my GO704 as both use Jon's 
pwm-servo as the motor controller, but for different reasons, on TLM to 
keep it from breaking drive parts which were never sized for a nearly 2 
hp peak motor, and on the GO704, with a better quality but identically 
rated PMDC motor, to stop the following errors because the Z can't keep 
up with instant reversals. It takes z around 350 millisecs to turn 
around at 500 revs, but can do it in 400 even at 3000 revs.

Thats a bit extreme on the go704's spindle power supply, running its dc 
voltage up to around 170 from its normal 126, considerably above the 130 
volt rating of its filter caps, but its so quickly used up by 
re-accelerating the motor in the other direction that no measerable 
leakage heating has developed, and its been doing that for about 6 years 
now. No failures. And no circuit breaker trips.

I bought a breaking resistor for the 6040's 24k motor, but have never 
hooked it up, it does not have the moxie to tap, and no encoder exists 
in the motors available for less than $3k bucks. No Z room to do 
anything about it either, that combined with the damp noodles for X 
suspension rods, makes light cuts with a mister running the order of the 
day.

> > regards
> >
> > Andrew
> >
> > ___
> > Emc-users mailing list
> > 

Re: [Emc-users] reducing rigid tapping overshoot

[Leonardo Marsaglia]

Hello Andrew,

Is there a baking resistor installed on your drive? I think a proper one
should solve your problem and you can keep the good deceleration rates.

Leonardo Marsaglia

El dom., 25 abr. 2021 08:30, andrew beck 
escribió:

> hey guys
>
> not sure if my emails are coming through to you guys.  hope they are.
>
> i have just successfully set up my encoder for rigid tapping using index
> signal from spindle motor encoder
>
> just got a few questions for the group
>
> is it possible to set different ramp values depending on spindle speed.
>
> if I try rigid tap at 1000 rpm at 1mm pitch i get a over travel of about
> 5mm.  I can reduce the deceleration ramp in the altivar 71 schiender drive
> to 0.5 secs and then the over travel is about one revolution of the
> spindle.  but if i leave the settings in vfd like that and then run spindle
> at 9000rpm the spindle goes into overvoltage faults.
>
> just wondering if I can maybe set use the ramp internally to linuxcnc to
> give me more control
>
> http://linuxcnc.org/docs/html/examples/spindle.html
>
> if i could specify a max rate of change and also a max ramp setting I think
> I could set the values up so that at high speed the max rate of change
> slows the spindle slowly enough that it doesn't  trip vfd.  while at low
> speed say under 1000 rpm the spindle can stop faster.  or maybe I am just
> miss reading this all
>
>
> regards
>
> Andrew
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] reducing rigid tapping overshoot

[andy pugh]

On Sun, 25 Apr 2021 at 12:30, andrew beck  wrote:

> just wondering if I can maybe set use the ramp internally to linuxcnc to
> give me more control

Possibly, if you were to add a limit2 component to the hal. That would
limit the _rate_ of speed change, not the time.

It might be better done at the VFD, though, if there is a way to
configure one of the digital inputs to be a speed ramp control.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] reducing rigid tapping overshoot

[andrew beck]

hey guys

not sure if my emails are coming through to you guys.  hope they are.

i have just successfully set up my encoder for rigid tapping using index
signal from spindle motor encoder

just got a few questions for the group

is it possible to set different ramp values depending on spindle speed.

if I try rigid tap at 1000 rpm at 1mm pitch i get a over travel of about
5mm.  I can reduce the deceleration ramp in the altivar 71 schiender drive
to 0.5 secs and then the over travel is about one revolution of the
spindle.  but if i leave the settings in vfd like that and then run spindle
at 9000rpm the spindle goes into overvoltage faults.

just wondering if I can maybe set use the ramp internally to linuxcnc to
give me more control

http://linuxcnc.org/docs/html/examples/spindle.html

if i could specify a max rate of change and also a max ramp setting I think
I could set the values up so that at high speed the max rate of change
slows the spindle slowly enough that it doesn't  trip vfd.  while at low
speed say under 1000 rpm the spindle can stop faster.  or maybe I am just
miss reading this all


regards

Andrew

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users