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

[Gregg Eshelman via Emc-users]

Apply spinach to the X axis and there will be carnage?

On Wednesday, February 7, 2018, 12:51:16 PM MST,  wrote:  
 
 Thanks Chris…for both the information and one of the most apropos example of 
autocorrect I have ever seen.

"The spinach is turning in x-direction the carnage in z”

I think this will be my new signature line ;-)
-Tom  
--
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 Wednesday 07 February 2018 16:43:38 andy pugh wrote:

> On 7 February 2018 at 20:02, John Kasunich  
wrote:
> > LinuxCNC will NOT reduce the spindle speed based on the limits of
> > your Z axis.
>
> That is true currently. But might not always be so, there is a
> proposal to either warn or reduce the spindle speed.
>
> https://github.com/LinuxCNC/linuxcnc/issues/167
>
> (I vote to include it)

I would vote for a warn and refusal. vfd's in general aren't capable of 
doing the required speed reduction within the pre-roll. My pmdc stuff 
can, but vfd's seem to rule this roost.

-- 
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]

A warning would be nice.  A warning with option to continue with spindle slowed 
would be a bonus.
-Tom


> On Feb 7, 2018, at 4:43 PM, andy pugh  wrote:
> 
> On 7 February 2018 at 20:02, John Kasunich  wrote:
> 
>> 
>> LinuxCNC will NOT reduce the spindle speed based on the limits of your Z
>> axis.
> 
> 
> That is true currently. But might not always be so, there is a proposal to
> either warn or reduce the spindle speed.
> 
> https://github.com/LinuxCNC/linuxcnc/issues/167
> 
> (I vote to include 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


--
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 7 February 2018 at 20:02, John Kasunich  wrote:

>
> LinuxCNC will NOT reduce the spindle speed based on the limits of your Z
> axis.


That is true currently. But might not always be so, there is a proposal to
either warn or reduce the spindle speed.

https://github.com/LinuxCNC/linuxcnc/issues/167

(I vote to include 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

[tom-emc]

My experience corroborates Peter and John’s descriptions.  

I tried cutting an SFM that was above the capability of the Z-axis to move, 
just for fun.  Rather than a thread, I essentially got a bored out cylinder 
with some thread-like lines as a finish.  So it doesn’t slow the spindle to the 
axis limit.

Also, when I start very close to the beginning of the part/thread, the first 
thread is too wide.  If I back off and start .125" or so from the part it works 
fine, the thread is consistent.  I am sure this is related to my machine 
acceleration limits.  I may also have some issues with spindle-at-speed not 
tracking the encoder, but rather the VFD.  I am going to experiment with that 
config as well and see if it helps.

-Tom


> On Feb 7, 2018, at 3:02 PM, John Kasunich  wrote:
> 
> 
> 
> On Wed, Feb 7, 2018, at 2:35 PM, Chris Albertson wrote:
>> The G33 says to do a synchronized move.   This is physically impossible.
>> The Z axis has some limit on it's ability to go from zero speed to the
>> commanded speed.   So the controller is reducing the spindle speed so as to
>> match the ability of the z-axis motor.
> 
> Minor (or maybe not) nit to pick here.  G33 is NOT like other multi-axis 
> moves.
> LinuxCNC will NOT reduce the spindle speed based on the limits of your Z axis.
> You need to choose a spindle speed and thread pitch that are within the 
> capability of your Z axis.  You also need to start far enough away from the 
> part that Z will be able to accelerate to match its target speed before it 
> starts cutting.
> 
> A concrete example:  you want to cut a 1/4"-20tpi thread (0.050" lead) at 
> 1000 rpm.
> Your Z axis needs to be able to move at least 0.050 x 1000 = 50 ipm.  If it 
> can't, you will get a bad thread and maybe a following error depending on how 
> your limits are set.  In practice, you really need some margin on Z speed, at 
> least 10-20%.
> 
>> ALL multi-axis moves are this way.   You see it best on a milling machine
>> where perhaps the z-axis is also the slowest.  Say you are milling a 45
>> degree ramp that climbs upward to the left.  The X motor would have to slow
>> to match the max speed of the z motor.
>> 
>> When a lathe cuts threads it is in real-life cutting a ramp. The spinach is
>> turning in x-direction the carnage in z.  You can only cut as fast as the
>> slowest motor can move.  And nether of the motors has infinite acceleration.
>> 
>> On Tue, Jan 30, 2018 at 2:42 PM,  wrote:
>> 
>>> We have CSS on and are threading with a G33 on our Emco lathe and we are
>>> seeing the spindle decelerating during the cut.  Seems like the spindle
>>> speed should be fairly steady at a given X location during a G33 and what
>>> it seems like is that the spindle is still decelerating to speed while it’s
>>> in the cut rather than before the cut.
>>> 
>>> We are rapid-ing (G0 in Z) out of the part at the center of the part (X=0)
>>> and so CSS spins the spindle up to full speed as I’d expect (*) but it
>>> appears that our spindle is still decelerating to speed as the next
>>> threading pass is happening.  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.  It seems like spindle-at-speed should go
>>> low after rapiding out of the part as it moves to it’s next X location and
>>> decelerates to it’s next speed at the cutting diameter.  Or are we
>>> misunderstanding spindle-at-speed when CSS is in effect?
>>> 
>>> 
>>> (*) Is it normal that a G0 move also triggers CSS to spin up (or down)?
>>> Seems like the trajectory planner would know where the next cutting move is
>>> and not adjust the spindle speed until it needs to.  In our case we are
>>> rapiding out of the part at X=0 and the spindle speeds up when it doesn’t
>>> really need to.
>>> 
>>> -Tom
>>> 
>>> 
>>> 
>>> --
>>> 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
>>> 
>> 
>> 
>> 
>> -- 
>> 
>> Chris Albertson
>> Redondo Beach, California
>> --
>> 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
> 
> 
> -- 
>  John Kasunich
>  jmkasun...@fastmail.fm
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slas

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

[John Kasunich]

On Wed, Feb 7, 2018, at 2:35 PM, Chris Albertson wrote:
> The G33 says to do a synchronized move.   This is physically impossible.
> The Z axis has some limit on it's ability to go from zero speed to the
> commanded speed.   So the controller is reducing the spindle speed so as to
> match the ability of the z-axis motor.

Minor (or maybe not) nit to pick here.  G33 is NOT like other multi-axis moves.
LinuxCNC will NOT reduce the spindle speed based on the limits of your Z axis.
You need to choose a spindle speed and thread pitch that are within the 
capability of your Z axis.  You also need to start far enough away from the 
part that Z will be able to accelerate to match its target speed before it 
starts cutting.

A concrete example:  you want to cut a 1/4"-20tpi thread (0.050" lead) at 1000 
rpm.
Your Z axis needs to be able to move at least 0.050 x 1000 = 50 ipm.  If it 
can't, you will get a bad thread and maybe a following error depending on how 
your limits are set.  In practice, you really need some margin on Z speed, at 
least 10-20%.

> ALL multi-axis moves are this way.   You see it best on a milling machine
> where perhaps the z-axis is also the slowest.  Say you are milling a 45
> degree ramp that climbs upward to the left.  The X motor would have to slow
> to match the max speed of the z motor.
> 
> When a lathe cuts threads it is in real-life cutting a ramp. The spinach is
> turning in x-direction the carnage in z.  You can only cut as fast as the
> slowest motor can move.  And nether of the motors has infinite acceleration.
> 
> On Tue, Jan 30, 2018 at 2:42 PM,  wrote:
> 
> > We have CSS on and are threading with a G33 on our Emco lathe and we are
> > seeing the spindle decelerating during the cut.  Seems like the spindle
> > speed should be fairly steady at a given X location during a G33 and what
> > it seems like is that the spindle is still decelerating to speed while it’s
> > in the cut rather than before the cut.
> >
> > We are rapid-ing (G0 in Z) out of the part at the center of the part (X=0)
> > and so CSS spins the spindle up to full speed as I’d expect (*) but it
> > appears that our spindle is still decelerating to speed as the next
> > threading pass is happening.  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.  It seems like spindle-at-speed should go
> > low after rapiding out of the part as it moves to it’s next X location and
> > decelerates to it’s next speed at the cutting diameter.  Or are we
> > misunderstanding spindle-at-speed when CSS is in effect?
> >
> >
> > (*) Is it normal that a G0 move also triggers CSS to spin up (or down)?
> > Seems like the trajectory planner would know where the next cutting move is
> > and not adjust the spindle speed until it needs to.  In our case we are
> > rapiding out of the part at X=0 and the spindle speeds up when it doesn’t
> > really need to.
> >
> > -Tom
> >
> >
> > 
> > --
> > 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
> >
> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> --
> 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


-- 
  John Kasunich
  jmkasun...@fastmail.fm

--
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

[Peter C. Wallace]

On Wed, 7 Feb 2018, Chris Albertson wrote:


Date: Wed, 7 Feb 2018 11:35:03 -0800
From: Chris Albertson 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] CSS and spindle-at-speed during a G33

The G33 says to do a synchronized move.   This is physically impossible.
The Z axis has some limit on it's ability to go from zero speed to the
commanded speed.   So the controller is reducing the spindle speed so as to
match the ability of the z-axis motor.

ALL multi-axis moves are this way.   You see it best on a milling machine
where perhaps the z-axis is also the slowest.  Say you are milling a 45
degree ramp that climbs upward to the left.  The X motor would have to slow
to match the max speed of the z motor.

When a lathe cuts threads it is in real-life cutting a ramp. The spinach is
turning in x-direction the carnage in z.  You can only cut as fast as the
slowest motor can move.  And nether of the motors has infinite acceleration.


Spinach and carnage aside,

Actually for G33 moves LinuxCNC does not change the spindle speed but rather 
gears the Z axis motion to the spindle rotation, of course at the start of a 
thread the Z axis must accelerate to match the spindle rotation.


Heres some information from the LinuxCNC documentation on G33:

"Technical Info

At the beginning of each G33 pass, LinuxCNC uses the spindle speed and the 
machine acceleration limits to calculate how long it will take Z to accelerate 
after the index pulse, and determines how many degrees the spindle will rotate 
during that time. It then adds that angle to the index position and computes 
the Z position using the corrected spindle angle. That means that Z will reach 
the correct position just as it finishes accelerating to the proper speed, and 
can immediately begin cutting a good thread."



Note that the "gearing" from encoder count can result in noise in the Z axis 
motion because of position or timing jitter or position extrapolation errors 
if the encoder resolution is low.


Peter Wallace
Mesa Electronics



--
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]

Thanks Chris…for both the information and one of the most apropos example of 
autocorrect I have ever seen.

"The spinach is turning in x-direction the carnage in z”

I think this will be my new signature line ;-)
-Tom


> On Feb 7, 2018, at 2:35 PM, Chris Albertson  wrote:
> 
> The G33 says to do a synchronized move.   This is physically impossible.
> The Z axis has some limit on it's ability to go from zero speed to the
> commanded speed.   So the controller is reducing the spindle speed so as to
> match the ability of the z-axis motor.
> 
> ALL multi-axis moves are this way.   You see it best on a milling machine
> where perhaps the z-axis is also the slowest.  Say you are milling a 45
> degree ramp that climbs upward to the left.  The X motor would have to slow
> to match the max speed of the z motor.
> 
> When a lathe cuts threads it is in real-life cutting a ramp. The spinach is
> turning in x-direction the carnage in z.  You can only cut as fast as the
> slowest motor can move.  And nether of the motors has infinite acceleration.
> 
> On Tue, Jan 30, 2018 at 2:42 PM,  wrote:
> 
>> We have CSS on and are threading with a G33 on our Emco lathe and we are
>> seeing the spindle decelerating during the cut.  Seems like the spindle
>> speed should be fairly steady at a given X location during a G33 and what
>> it seems like is that the spindle is still decelerating to speed while it’s
>> in the cut rather than before the cut.
>> 
>> We are rapid-ing (G0 in Z) out of the part at the center of the part (X=0)
>> and so CSS spins the spindle up to full speed as I’d expect (*) but it
>> appears that our spindle is still decelerating to speed as the next
>> threading pass is happening.  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.  It seems like spindle-at-speed should go
>> low after rapiding out of the part as it moves to it’s next X location and
>> decelerates to it’s next speed at the cutting diameter.  Or are we
>> misunderstanding spindle-at-speed when CSS is in effect?
>> 
>> 
>> (*) Is it normal that a G0 move also triggers CSS to spin up (or down)?
>> Seems like the trajectory planner would know where the next cutting move is
>> and not adjust the spindle speed until it needs to.  In our case we are
>> rapiding out of the part at X=0 and the spindle speeds up when it doesn’t
>> really need to.
>> 
>> -Tom
>> 
>> 
>> 
>> --
>> 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
>> 
> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> --
> 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

[Chris Albertson]

The G33 says to do a synchronized move.   This is physically impossible.
The Z axis has some limit on it's ability to go from zero speed to the
commanded speed.   So the controller is reducing the spindle speed so as to
match the ability of the z-axis motor.

ALL multi-axis moves are this way.   You see it best on a milling machine
where perhaps the z-axis is also the slowest.  Say you are milling a 45
degree ramp that climbs upward to the left.  The X motor would have to slow
to match the max speed of the z motor.

When a lathe cuts threads it is in real-life cutting a ramp. The spinach is
turning in x-direction the carnage in z.  You can only cut as fast as the
slowest motor can move.  And nether of the motors has infinite acceleration.

On Tue, Jan 30, 2018 at 2:42 PM,  wrote:

> We have CSS on and are threading with a G33 on our Emco lathe and we are
> seeing the spindle decelerating during the cut.  Seems like the spindle
> speed should be fairly steady at a given X location during a G33 and what
> it seems like is that the spindle is still decelerating to speed while it’s
> in the cut rather than before the cut.
>
> We are rapid-ing (G0 in Z) out of the part at the center of the part (X=0)
> and so CSS spins the spindle up to full speed as I’d expect (*) but it
> appears that our spindle is still decelerating to speed as the next
> threading pass is happening.  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.  It seems like spindle-at-speed should go
> low after rapiding out of the part as it moves to it’s next X location and
> decelerates to it’s next speed at the cutting diameter.  Or are we
> misunderstanding spindle-at-speed when CSS is in effect?
>
>
> (*) Is it normal that a G0 move also triggers CSS to spin up (or down)?
> Seems like the trajectory planner would know where the next cutting move is
> and not adjust the spindle speed until it needs to.  In our case we are
> rapiding out of the part at X=0 and the spindle speeds up when it doesn’t
> really need to.
>
> -Tom
>
>
> 
> --
> 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
>



-- 

Chris Albertson
Redondo Beach, California
--
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 Tuesday 06 February 2018 10:20:49 tom-...@bgp.nu wrote:

> As I replied to Andy, spindle-at-speed is just coming from
> vfd-at-speed in custom.hal. net gs2-at-speed motion.spindle-at-speed
> <= spindle-vfd.at -speed
>
Nothing at the link. And my vfd on the sheldon has an output, but no clue 
what its telling me. If the motor is working within its load, the speed 
should be within 5% of the indicated frequency, factored by the number 
of motor poles. IOW, 60 hz should get you at least 1750 revs from a 4   
pole motor. 120 hz = 3550 etc. Mine, without a lot of low speed boost, 
can run at 9 hz for long enough to get the job done w/o serious motor 
heating. Conversely, while the motor will run at 240 hz on the table, 
phase slippage from low winding current won't let me go above 120 hz, 
when pulling the lathe, as spindle bearings are bronze and drag too 
much, using up all its limited torque. Warms them up too.

But a near or wcomp, near preferred, really should be setup to tell 
motion the spindle is at speed, independent of any signals from the vfd. 

10% tolerance is generally fine. I have an led rigged in postgui to tally 
that. It only controls whether or not the cycle starts, but has no 
effect once its underway, and with a tap bigger than say 5mm, its not 
uncommon to see the led turn red once the loading of the tap hits.  The 
near is much easier to calibrate if the two signals, input to the 
pid.command, and return from the encoder are at the same scale factor. 
So scale them either to rps, or to rpm's.

You have several outputs from motion:
==
 motion.spindle-speed-out OUT FLOAT
  Desired spindle speed in rotations per minute
(assuming its a signed value, the man page doesn't state)

   motion.spindle-speed-out-abs OUT FLOAT
  Desired spindle speed in rotations per minute, always 
positive regardless of spindle direction.

   motion.spindle-speed-out-rps OUT float
  Desired spindle speed in rotations per second

   motion.spindle-speed-out-rps-abs OUT float
  Desired spindle speed in rotations per second, always 
positive regardless of spindle direction.
=
And generally the encoder will be scaled to rps, so the above rps outputs 
should about match at the near inputs. Because I am using the OEM 1hp at 
90 volts motor on my mill and a similar escapee from a treadmill on TLM, 
both are being driven by Pico's PWM-SERVO amps, so I've some additional 
hal stuff to keep the PWM from exceeding 98% duty. Hit 100% for more 
than a few milliseconds and the Pico goes into a self protection 
shutdown.

Separately, if you run the encoder output thru an abs before hitting the 
gui's tach indicator, then it runs showing a fwd reading in either 
direction. If using the tach dial meter, I've not used the sliding bar 
version enough to recall if it runs to the right in reverse, but the 
number displayed s/b signed.

> I am not using wcomp or near component as suggested in the manual:
> http://linuxcnc.org/docs/html/examples/spindle.html#_spindle_at_speed
>
Thats not ideal Tom. Do something like shown in that link above.
> -Tom
>
> > On Feb 4, 2018, at 9:20 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.

True.

> > But our spindle-at-speed signal seems to 
> > be high during the full cycle once the spindle speeds up the
> > first time.

This shouldn't be. The starting position in radii s/b the right end of 
the white line, under the g76 section and the spindle-at-speed needs to 
be false the instant the move to that "parking while waiting" position 
starts, and which should slow the spindle, and remains false until the 
css drive has actually reached the indicated speed. It might even be 
wise to cut a bottom of stroke clearance groove if the screw going in 
the hole could touch the exit ramp shown in that diagram. But I've never 
considered that despite my abuse of G73 to cut tapered threads in the 
past.

The biggest argument against using css while thread cutting, is that the 
change in the instant cuts diameter while its waiting at the right end 
of the white line for at speed and index, also changes the spindle speed 
on a per stroke basis AND that changes the movements phase lengthwise so 
you will be cutting a wider thread with the trailing edge of the tooth. 
If you really had the machine characterized, it might be possible to 
change the Q argument a few degrees plus to compensate.  Worth the 
effort in time saved?  Probably not unless you have several thousands of 
that part to make.

-- 
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 

---

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

[tom-emc]

> On Feb 6, 2018, at 10:28 AM, andy pugh  wrote:
> 
> On 6 February 2018 at 15:20,  wrote:
>> 
>> As I replied to Andy, spindle-at-speed is just coming from vfd-at-speed in 
>> custom.hal.
>> net gs2-at-speed motion.spindle-at-speed <= spindle-vfd.at-speed
> 
> That should work, as long as the spindle-vfd component at-speed output
> works correctly (perhaps it doesn't)
> 
> One thing that might cause the problem you are seeing is if there is a
> lowpass between the motion.spindle-xx-out and the spindle-vfd.speed-in

Andy,
We don’t have a lowpass filter on the spindle-xx-out but we do have one between 
the encoder velocity and motion.spindle-speed.in…
-Tom



#***
#  SPINDLE SECTION
#***
# ---Encoder feedback signals/setup---

setphm2_5i25.0.encoder.00.counter-mode 0
setphm2_5i25.0.encoder.00.filter 1
setphm2_5i25.0.encoder.00.index-invert 0
setphm2_5i25.0.encoder.00.index-mask 0
setphm2_5i25.0.encoder.00.index-mask-invert 0
setphm2_5i25.0.encoder.00.scale  [SPINDLE_9]ENCODER_SCALE

net spindle-revs hm2_5i25.0.encoder.00.position motion.spindle-revs
setp lowpass.1.gain 1
net spindle-vel-fb-rps   hm2_5i25.0.encoder.00.velocity lowpass.1.in
net spindle-vel-fb-rps-lp lowpass.1.out motion.spindle-speed-in
net spindle-index-enable hm2_5i25.0.encoder.00.index-enable 
motion.spindle-index-enable

net spindle-revs ddt.0.in

setp scale.0.gain 60
setp lowpass.0.gain 0.01

net spindle-vel-fb-rps=> scale.0.in
net spindle-fb-rpm   scale.0.out   =>   abs.0.in
net spindle-fb-rpm-abs   abs.0.out =>   lowpass.0.in
net spindle-fb-rpm-abs-filtered  lowpass.0.out
#***
#  END SPINDLE SECTION
#***


Custom.hal:
# Include your custom HAL commands here
# This file will not be overwritten when you run PNCconf again

loadusr -Wn active-gcodes python activegcodes.py

# Classic Ladder
loadrt classicladder_rt
addf classicladder.0.refresh  servo-thread
loadusr classicladder --nogui emcolathe.clp

# load the user space component for the Automation Direct GS2 VFD's
loadusr -Wn spindle-vfd gs2_vfd -r 9600 -p none -s 2 -n spindle-vfd -A 1 -D 2.0 
-X

# connect the spindle direction pin to the GS2
net gs2-fwd spindle-vfd.spindle-fwd <= motion.spindle-forward

# connect the spindle on pin to the GS2
net gs2-run spindle-vfd.spindle-on <= motion.spindle-on

# connect the GS2 at speed to the motion at speed
net gs2-at-speed motion.spindle-at-speed <= spindle-vfd.at-speed

# connect the spindle RPM to the GS2
# scale pulley ratio on spindle (1/0.833133)
setp scale.1.gain 1.154
net commanded-speed scale.1.in motion.spindle-speed-out
net gs2-RPM spindle-vfd.speed-command scale.1.out



--
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 6 February 2018 at 15:20,  wrote:
>
> As I replied to Andy, spindle-at-speed is just coming from vfd-at-speed in 
> custom.hal.
> net gs2-at-speed motion.spindle-at-speed <= spindle-vfd.at-speed

That should work, as long as the spindle-vfd component at-speed output
works correctly (perhaps it doesn't)

One thing that might cause the problem you are seeing is if there is a
lowpass between the motion.spindle-xx-out and the spindle-vfd.speed-in


-- 
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

[tom-emc]

As I replied to Andy, spindle-at-speed is just coming from vfd-at-speed in 
custom.hal.
net gs2-at-speed motion.spindle-at-speed <= spindle-vfd.at 
-speed

I am not using wcomp or near component as suggested in the manual: 
http://linuxcnc.org/docs/html/examples/spindle.html#_spindle_at_speed

-Tom


> On Feb 4, 2018, at 9:20 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?

--
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

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

[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

[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

[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

[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