Re: [Emc-users] CSS and spindle-at-speed during a G33

[andy pugh]

On 30 January 2018 at 22:42,  wrote:

>  We read that G33 will wait for spindle-at-speed before looking for the
> index pulse.  But our spindle-at-speed signal seems to be high during the
> full cycle once the spindle speeds up the first time.


How is your spindle-at-speed signal calculated?

-- 
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, 1916
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] CSS and spindle-at-speed during a G33

[Gene Heskett]

On Sunday 04 February 2018 13:52:33 andy pugh wrote:

> On 30 January 2018 at 22:42,  wrote:
> >  We read that G33 will wait for spindle-at-speed before looking for
> > the index pulse.  But our spindle-at-speed signal seems to be high
> > during the full cycle once the spindle speeds up the first time.
>
> How is your spindle-at-speed signal calculated?

I went back to the OPost, and my question would have been why is Tom 
mixing CSS with a threading operation? From my personal experience, a 
solidly set spindle speed, and a stiff control are needed for best 
quality threads. Throwing any CSS into that pot would "poor form".

HMMV of course, but thats my $0.02.
-- 
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)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] CSS and spindle-at-speed during a G33

[tom-emc]

That is a good question, and one we have recently asked ourselves.  In fact we 
changed our threading routine to fix the RPM because at least then the spindle 
is not constantly accelerating and decelerating.  But, to be honest, CSS should 
work fine, all it does it change the spindle speed for a given diameter.  It 
does add a variable to the synchronization though (since it needs to 
accel/decel).  

However, even with fixed RPM we still cut better threads if we start well off 
of the start of the thread giving the machine more time to synchronize.  That 
is, when we start threading from 0.25 to -1 we get better threads then we start 
threading from 0 to -1.
-Tom

> On Feb 4, 2018, at 2:08 PM, Gene Heskett  wrote:
> 
> On Sunday 04 February 2018 13:52:33 andy pugh wrote:
> 
>> On 30 January 2018 at 22:42,  wrote:
>>> We read that G33 will wait for spindle-at-speed before looking for
>>> the index pulse.  But our spindle-at-speed signal seems to be high
>>> during the full cycle once the spindle speeds up the first time.
>> 
>> How is your spindle-at-speed signal calculated?
> 
> I went back to the OPost, and my question would have been why is Tom 
> mixing CSS with a threading operation? From my personal experience, a 
> solidly set spindle speed, and a stiff control are needed for best 
> quality threads. Throwing any CSS into that pot would "poor form".
> 
> HMMV of course, but thats my $0.02.
> -- 
> 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)
> Genes Web page 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] CSS and spindle-at-speed during a G33

[andy pugh]

On 4 February 2018 at 23:50,  wrote:

> That is a good question, and one we have recently asked ourselves.


It might be more useful to answer it than ask it :-)

-- 
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, 1916
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] CSS and spindle-at-speed during a G33

[Gene Heskett]

On Sunday 04 February 2018 18:50:50 tom-...@bgp.nu wrote:

> That is a good question, and one we have recently asked ourselves.  In
> fact we changed our threading routine to fix the RPM because at least
> then the spindle is not constantly accelerating and decelerating. 
> But, to be honest, CSS should work fine, all it does it change the
> spindle speed for a given diameter.  It does add a variable to the
> synchronization though (since it needs to accel/decel).

True, and in either case, g76 or g33.1, I never start closer than around 
5 turns off the end of the workpiece. And once you see its not carving 
up the fixtures you must resist the temptation to up the spindle speed 
and get it done, for that, find some scrap in the corner, if it works, 
then crank it up and do it right.

(but on coarse threads, stay below 50% of the axis speed capability. It 
must have that reserve to get properly synchronized)

I just replaced a bob in my mills setup. Between the first bobs piss poor 
opto speeds, and the inductance of a 1600 oz/in motor, my z speed was 
maxed out and in danger of a stall at 27 ipm. Replacing the motor with 
an 8 wire 940 wired in parallel, driven by an ac powered driver, got me 
to around 65 ipm. Just recently I replaced that bob with a $22 fleabay 
Sainsmart, no opto's in its outputs, and that same motor is now lifting 
the G0704's head at 110 ipm. The diff is the lag of the opto's that 
aren't there anymore. I still had to bypass the opto's in the encoder 
inputs, but then a 1000 line encoder on the back of the motor, which 
gives something over a 7000 for a scale, quit working with the opto's at 
around 275 real rpms. Without the opto's it tracks perfectly to 3000 
rpms.


Temporarily at least, I am a happy camper. Till I decide to find out how 
much faster I can move the xy's, (I might get them above 100 ipm too!) 
but ATM I am trying to see if theres a chance of a snowball in replacing 
the pi running the big lathe, with a rock64.

> However, even with fixed RPM we still cut better threads if we start
> well off of the start of the thread giving the machine more time to
> synchronize.  That is, when we start threading from 0.25 to -1 we get
> better threads then we start threading from 0 to -1. -Tom

Thats to be expected, and in round figures for the thread sizes I've cut, 
a good starting point. Bigger, coarser threads will need more room of 
course.

> > On Feb 4, 2018, at 2:08 PM, Gene Heskett 
> > wrote:
> >
> > On Sunday 04 February 2018 13:52:33 andy pugh wrote:
> >> On 30 January 2018 at 22:42,  wrote:
> >>> We read that G33 will wait for spindle-at-speed before looking for
> >>> the index pulse.  But our spindle-at-speed signal seems to be high
> >>> during the full cycle once the spindle speeds up the first time.
> >>
> >> How is your spindle-at-speed signal calculated?

This is still a good question, Tom.  If using a wcomp, how is it being 
setup in your hal?

-- 
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)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] CSS and spindle-at-speed during a G33

[Gene Heskett]

On Sunday 04 February 2018 21:20:11 Gene Heskett wrote:

> On Sunday 04 February 2018 18:50:50 tom-...@bgp.nu wrote:
> > That is a good question, and one we have recently asked ourselves. 
> > In fact we changed our threading routine to fix the RPM because at
> > least then the spindle is not constantly accelerating and
> > decelerating. But, to be honest, CSS should work fine, all it does
> > it change the spindle speed for a given diameter.  It does add a
> > variable to the synchronization though (since it needs to
> > accel/decel).
>
> True, and in either case, g76 or g33.1, I never start closer than
> around 5 turns off the end of the workpiece. And once you see its not
> carving up the fixtures you must resist the temptation to up the
> spindle speed and get it done, for that, find some scrap in the
> corner, if it works, then crank it up and do it right.
>
> (but on coarse threads, stay below 50% of the axis speed capability.
> It must have that reserve to get properly synchronized)
>
> I just replaced a bob in my mills setup. Between the first bobs piss
> poor opto speeds, and the inductance of a 1600 oz/in motor, my z speed
> was maxed out and in danger of a stall at 27 ipm. Replacing the motor
> with an 8 wire 940 wired in parallel, driven by an ac powered driver,
> got me to around 65 ipm. Just recently I replaced that bob with a $22
> fleabay Sainsmart, no opto's in its outputs, and that same motor is
> now lifting the G0704's head at 110 ipm. The diff is the lag of the
> opto's that aren't there anymore. I still had to bypass the opto's in
> the encoder inputs, but then a 1000 line encoder on the back of the
> motor, which gives something over a 7000 for a scale, quit working
> with the opto's at around 275 real rpms. Without the opto's it tracks
> perfectly to 3000 rpms.
>
>
> Temporarily at least, I am a happy camper. Till I decide to find out
> how much faster I can move the xy's, (I might get them above 100 ipm
> too!) but ATM I am trying to see if theres a chance of a snowball in
> replacing the pi running the big lathe, with a rock64.

Having brought the subject up, I went out and played with the mills .ini 
file. When I sat down to do that, it was maxed at around 70" for xy. And 
around 90 for z. When I turned it and the lights off and got up, it had 
been moving at 140 ipm for the first 3 axis's for several minutes. Thats 
taking advantage of the much faster pulses coming out of the sainsmart 
bob.  It does make a difference! And I'll goto bed with a satisfied grin 
on my face. :)
>
> > However, even with fixed RPM we still cut better threads if we start
> > well off of the start of the thread giving the machine more time to
> > synchronize.  That is, when we start threading from 0.25 to -1 we
> > get better threads then we start threading from 0 to -1. -Tom
>
> Thats to be expected, and in round figures for the thread sizes I've
> cut, a good starting point. Bigger, coarser threads will need more
> room of course.
>
> > > On Feb 4, 2018, at 2:08 PM, Gene Heskett 
> > > wrote:
> > >
> > > On Sunday 04 February 2018 13:52:33 andy pugh wrote:
> > >> On 30 January 2018 at 22:42,  wrote:
> > >>> We read that G33 will wait for spindle-at-speed before looking
> > >>> for the index pulse.  But our spindle-at-speed signal seems to
> > >>> be high during the full cycle once the spindle speeds up the
> > >>> first time.
> > >>
> > >> How is your spindle-at-speed signal calculated?
>
> This is still a good question, Tom.  If using a wcomp, how is it being
> setup in your hal?



-- 
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)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users