subject:"Re\: \[Emc\-users\] Problem with Rigid Tapping on USC Equipped Bridgeport"

On Tuesday 04 August 2020 15:05:10 Thaddeus Waldner wrote:

> Can you or someone else please expand on that?
>
> Most VFD that I am familiar with operate between 10khz and 20khz. I
> personally like to configure them upwards of 16khz because I find the
> squealing noise annoying. I suppose that the main reason to not do
> that is that it increases switching losses.
>
> Do any servos or VFD systems actually run their base frequency higher
> than 20khz?
>
Most try to stay above 17 or 18 khz. The ferrite in the transformers is 
megneto-strictive, which is usually where the noise comes from.

> If not, where do those harmonics come from?

square waves have no theoretical limit to the harmonics generated, so the 
limit is usually the design choice of how fast the transistor can 
switch, and higher speed costs money, more often than not its how fast 
the lower level driver can charge or discharge the gate capacitance of 
the power fet doing the actual switching. The longer it takes to do the 
switch translates into a higher time for the switching transistor to be 
in ohmic territory, increasing its heating. The driver transistor might 
need to src or sink 20 amps or more during this edge transition.  For 
perhaps 5 ns?

> > On Aug 4, 2020, at 11:51 AM, Jon Elson 
> > wrote:
> >
> > On 08/04/2020 08:00 AM, Matthew Herd wrote:
> >> I am guessing that the source of the trouble is probably the VFD,
> >> as 80kHz seems like a plausible base frequency for driving an AC
> >> motor.  Only the USC should be operating at a frequency higher than
> >> 60Hz other than the VFD.  The machine uses three gecko drives and
> >> large steppers, so it’s not very sophisticated.
> >
> > I think 80 KHz is a multiple of the frequency of the Gecko drives.
> > You might try turning off the power to them and see if the issue
> > changes.
> >
> >
> > 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


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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-04 Thread Thaddeus Waldner

Can you or someone else please expand on that?

Most VFD that I am familiar with operate between 10khz and 20khz. I personally 
like to configure them upwards of 16khz because I find the squealing noise 
annoying. I suppose that the main reason to not do that is that it increases 
switching losses. 

Do any servos or VFD systems actually run their base frequency higher than 
20khz?

If not, where do those harmonics come from?

> On Aug 4, 2020, at 11:51 AM, Jon Elson  wrote:
> 
> On 08/04/2020 08:00 AM, Matthew Herd wrote:
>> 
>> I am guessing that the source of the trouble is probably the VFD, as 80kHz 
>> seems like a plausible base frequency for driving an AC motor.  Only the USC 
>> should be operating at a frequency higher than 60Hz other than the VFD.  The 
>> machine uses three gecko drives and large steppers, so it’s not very 
>> sophisticated.
> I think 80 KHz is a multiple of the frequency of the Gecko drives. You might 
> try turning off the power to them and see if the issue changes.
> 
> 
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-04 Thread Jon Elson


On 08/04/2020 08:00 AM, Matthew Herd wrote:


I am guessing that the source of the trouble is probably the VFD, as 80kHz 
seems like a plausible base frequency for driving an AC motor.  Only the USC 
should be operating at a frequency higher than 60Hz other than the VFD.  The 
machine uses three gecko drives and large steppers, so it’s not very 
sophisticated.
I think 80 KHz is a multiple of the frequency of the Gecko 
drives. You might try turning off the power to them and see 
if the issue changes.



Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-04 Thread Matthew Herd

Thanks Gene, I just ordered a Rasmi unit that should be able to mount behind 
the VFD inside the panel (assuming enough depth in the box).  Apparently they 
make them for Yaskawa drives, but my Hitachi has the same bolt pattern.  I’ll 
get it installed and see how it looks.  If that checks out, I’ll probably still 
rewire the grounds to be sure of success.  But I’ll take some measurements 
along the way and see how well it works (or doesn’t).

> On Aug 4, 2020, at 11:42 AM, Gene Heskett  wrote:
> 
> On Tuesday 04 August 2020 09:09:38 andy pugh wrote:
> 
>> On Tue, 4 Aug 2020 at 14:03, Matthew Herd  wrote:
>>> I am guessing that the source of the trouble is probably the VFD, as
>>> 80kHz seems like a plausible base frequency for driving an AC motor.
>> 
>> Add an input filter to the VFD. They are not expensive. Look on eBay
>> for "Rasmi" (one manufacturer, but a good search term)
> 
> Or on this side of the pond, CorCom make's both a single phase and a 3 
> phase filter thats a brick wall above 30 mhz, I have one on both sides 
> of the vfd on the Sheldon.  I can see the vfd, but its under 200 
> millivolts all the way to the scopes 100+ megahertz bandwidth.
> 
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tuesday 04 August 2020 09:09:38 andy pugh wrote:

> On Tue, 4 Aug 2020 at 14:03, Matthew Herd  wrote:
> > I am guessing that the source of the trouble is probably the VFD, as
> > 80kHz seems like a plausible base frequency for driving an AC motor.
>
> Add an input filter to the VFD. They are not expensive. Look on eBay
> for "Rasmi" (one manufacturer, but a good search term)

Or on this side of the pond, CorCom make's both a single phase and a 3 
phase filter thats a brick wall above 30 mhz, I have one on both sides 
of the vfd on the Sheldon.  I can see the vfd, but its under 200 
millivolts all the way to the scopes 100+ megahertz bandwidth.

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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tuesday 04 August 2020 09:00:30 Matthew Herd wrote:

> Yes, I figured as much, but I figure it’s a problem that should be
> solved and the noise looks like a contributing factor.
>
> I am guessing that the source of the trouble is probably the VFD, as
> 80kHz seems like a plausible base frequency for driving an AC motor. 
> Only the USC should be operating at a frequency higher than 60Hz other
> than the VFD.  The machine uses three gecko drives and large steppers,
> so it’s not very sophisticated.  I traced out the grounds briefly and
> while they look fine, I did some dumb stuff.  Like running a ground
> wire from a 12V power supply to a terminal block, then back to the
> ground connection, making no other connections at the terminal block —
> no idea why I’d have done that.
>
If that terminal is isolated from the rest, and the connection is tight, 
it shouldn't have any effect.  A shorter run straight to the bolt is 
better, but if the terminal is isolated, it is not Matts problem.

> > On Aug 4, 2020, at 8:48 AM, andy pugh  wrote:
> >
> > But, random indexes shouldn't actually have the effect described.
> > The index-enable only gets set once at the start of the cycle. It
> > shouldn't matter what the Z-phase does from that point on.
>
> ___
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tuesday 04 August 2020 08:48:28 andy pugh wrote:

> On Tue, 4 Aug 2020 at 13:39, Matthew Herd  wrote:
> >  I’m wondering if there’s any value in isolating power and logic
> > grounds or isolating either one from the machine.
>
> That isn't always possible, even if you want to. The drives themselves
> tend to tie them together.
>
> But, random indexes shouldn't actually have the effect described. The
> index-enable only gets set once at the start of the cycle. It
> shouldn't matter what the Z-phase does from that point on.

This is true but nothing is preventing that noise from looking like an 
index, long before the real one occurs. That will start the rigid tap 
cycle early, and if that same noise is getting into the encoders A/B 
signals all bets are off.

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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tuesday 04 August 2020 08:37:06 Matthew Herd wrote:

> Sorry for the delayed reply.  I did some work on the scope on Sunday
> morning and have attached some pictures of the results.  Let me know
> if they don’t come through.
>
> In sort, the results appear to show a roughly 80kHz noise when the
> machine is turned on, with spikes pretty frequently exceeding 2V
> (where my trigger was set for channel 1, the index channel.  Channel 2
> was the A channel of the encoder and the noise also appeared on there.
>  Results were identical regardless of whether the encoder was
> connected to the USC board or not.  Spindle on/off appeared to have
> little or no impact on the noise.  I also got a picture of the Hal
> Scope for the index pin and it is triggering repeatedly as discussed
> before.  I wasn’t able to reproduce the sawtooth on the
> motion.spindle-revs during G33.1, but it was still randomly failing to
> reverse and retract out of the hole occasionally.  I ran a program
> with numerous cycles and it’d e-stop the machine after a few G33.1’s
> for reasons unknown.  The encoder wires are twisted pairs and they’re
> only separated to allow connection to ground.
>
> Given these findings, it appears that I’ll be rewiring the grounds to
> a single point in the near future.  I’ll re-test once that is done,
> but it’ll be a few weeks.  I was looking it over and while I didn’t
> connect everything to a single point, I did do a fairly thorough job
> of making sure each one was on a separate bolt on the case of the
> respective enclosures.  I’m wondering if there’s any value in
> isolating power and logic grounds or isolating either one from the
> machine.
>
Machine frame must be grounded to that bolt, I have a roll of 3/8" wide 
braid I use for that. And it would not hurt a thing  to ground the table 
to the machine frame by the same method. If you do any shade tree EDM on 
that machine, like burning out a broken tap, I ground whichever polarity 
of the EDM supply that stands the best chance of not causing any arcing 
in the spindle bearings, that can be death on those.

> > On Aug 2, 2020, at 11:34 AM, Jon Elson 
> > wrote:
> >
> > On 08/01/2020 01:37 PM, Matthew Herd wrote:
> >> Thanks Gene, I hope you’re well also.  I disconnected that
> >> grounding wire, no difference observed in the
> >> ppmc.0.encoder.03.index behavior.  The noise seems the same both
> >> when spindle is running and stopped, with a tendency strongly
> >> toward "true" than "false."  Pulses seem to be both long and short,
> >> but I’d guess they’re about 80-90% true.  Not at all what I’d
> >> expect, even with noise.
> >
> > This does not make any sense at all.  The encoder.xx.index reports
> > detecting a falling edge on the index (Z) input.  it is reset every
> > time it is read.  Long true pulses mean it was triggered at least
> > once every millisecond, ie. faster than the servo thread samples it.
> >
> > So, the encoder.xx.index is NOT looking at the STATE of the Z input,
> > but whether a high-to-low transition occurred since the last time it
> > was read.
> >
> > 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


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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-04 Thread andy pugh

On Tue, 4 Aug 2020 at 14:03, Matthew Herd  wrote:

> I am guessing that the source of the trouble is probably the VFD, as 80kHz 
> seems like a plausible base frequency for driving an AC motor.

Add an input filter to the VFD. They are not expensive. Look on eBay
for "Rasmi" (one manufacturer, but a good search term)

-- 
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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-04 Thread Matthew Herd

Yes, I figured as much, but I figure it’s a problem that should be solved and 
the noise looks like a contributing factor.  

I am guessing that the source of the trouble is probably the VFD, as 80kHz 
seems like a plausible base frequency for driving an AC motor.  Only the USC 
should be operating at a frequency higher than 60Hz other than the VFD.  The 
machine uses three gecko drives and large steppers, so it’s not very 
sophisticated.  I traced out the grounds briefly and while they look fine, I 
did some dumb stuff.  Like running a ground wire from a 12V power supply to a 
terminal block, then back to the ground connection, making no other connections 
at the terminal block — no idea why I’d have done that.

> On Aug 4, 2020, at 8:48 AM, andy pugh  wrote:
> 
> But, random indexes shouldn't actually have the effect described. The
> index-enable only gets set once at the start of the cycle. It
> shouldn't matter what the Z-phase does from that point on.

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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-04 Thread andy pugh

On Tue, 4 Aug 2020 at 13:39, Matthew Herd  wrote:

>  I’m wondering if there’s any value in isolating power and logic grounds or 
> isolating either one from the machine.

That isn't always possible, even if you want to. The drives themselves
tend to tie them together.

But, random indexes shouldn't actually have the effect described. The
index-enable only gets set once at the start of the cycle. It
shouldn't matter what the Z-phase does from that point on.

-- 
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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-04 Thread Matthew Herd

Sorry for the delayed reply.  I did some work on the scope on Sunday morning 
and have attached some pictures of the results.  Let me know if they don’t come 
through.

In sort, the results appear to show a roughly 80kHz noise when the machine is 
turned on, with spikes pretty frequently exceeding 2V (where my trigger was set 
for channel 1, the index channel.  Channel 2 was the A channel of the encoder 
and the noise also appeared on there.  Results were identical regardless of 
whether the encoder was connected to the USC board or not.  Spindle on/off 
appeared to have little or no impact on the noise.  I also got a picture of the 
Hal Scope for the index pin and it is triggering repeatedly as discussed 
before.  I wasn’t able to reproduce the sawtooth on the motion.spindle-revs 
during G33.1, but it was still randomly failing to reverse and retract out of 
the hole occasionally.  I ran a program with numerous cycles and it’d e-stop 
the machine after a few G33.1’s for reasons unknown.  The encoder wires are 
twisted pairs and they’re only separated to allow connection to ground.

Given these findings, it appears that I’ll be rewiring the grounds to a single 
point in the near future.  I’ll re-test once that is done, but it’ll be a few 
weeks.  I was looking it over and while I didn’t connect everything to a single 
point, I did do a fairly thorough job of making sure each one was on a separate 
bolt on the case of the respective enclosures.  I’m wondering if there’s any 
value in isolating power and logic grounds or isolating either one from the 
machine.  

> On Aug 2, 2020, at 11:34 AM, Jon Elson  wrote:
> 
> On 08/01/2020 01:37 PM, Matthew Herd wrote:
>> Thanks Gene, I hope you’re well also.  I disconnected that grounding wire, 
>> no difference observed in the ppmc.0.encoder.03.index behavior.  The noise 
>> seems the same both when spindle is running and stopped, with a tendency 
>> strongly toward "true" than "false."  Pulses seem to be both long and short, 
>> but I’d guess they’re about 80-90% true.  Not at all what I’d expect, even 
>> with noise.
>> 
>> 
> This does not make any sense at all.  The encoder.xx.index reports detecting 
> a falling edge on the index (Z) input.  it is reset every time it is read.  
> Long true pulses mean it was triggered at least once every millisecond, ie. 
> faster than the servo thread samples it.
> 
> So, the encoder.xx.index is NOT looking at the STATE of the Z input, but 
> whether a high-to-low transition occurred since the last time it was read.
> 
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-02 Thread Jon Elson


On 08/01/2020 01:37 PM, Matthew Herd wrote:

Thanks Gene, I hope you’re well also.  I disconnected that grounding wire, no difference observed 
in the ppmc.0.encoder.03.index behavior.  The noise seems the same both when spindle is running and 
stopped, with a tendency strongly toward "true" than "false."  Pulses seem to 
be both long and short, but I’d guess they’re about 80-90% true.  Not at all what I’d expect, even 
with noise.


This does not make any sense at all.  The encoder.xx.index 
reports detecting a falling edge on the index (Z) input.  it 
is reset every time it is read.  Long true pulses mean it 
was triggered at least once every millisecond, ie. faster 
than the servo thread samples it.


So, the encoder.xx.index is NOT looking at the STATE of the 
Z input, but whether a high-to-low transition occurred since 
the last time it was read.


Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-02 Thread Jon Elson


On 08/01/2020 11:10 AM, Matthew Herd wrote:

I'm still having issues with the rigid tapping.  It works sometimes and
fails other times.  After scoping the motion.spindle-revs, it appears to be
consistent with what we would expect aside from one possible issue.  The
spindle revs reset to zero upon G33.1 being called, then count up until
they stop, reverse, go negative past zero, then return to clockwise
motion.  However, on the second zero crossing (going positive) the revs go
positive, only to be reset to zero momentarily thereafter.  I'm not sure if
this is normal behavior or not.
I'm not exactly sure what you are describing here.  Most of 
it sounds normal, but I am not aware of a second cycle of 
the index sync function at the end of the G33.1   If you 
have a Halscope picture, that could be interesting to look at.

However, what isn't normal behavior is that the ppmc.0.encoder.03.index
value is loaded with noise.  Not occasional noise, but constantly
triggering in irregular intervals regardless of whether the spindle is
turning.  I'm baffled as to how this could be so noisy and was wondering
where you might look next.  Grounds look fine aside from the fact that the
control cabinet and the power cabinet have a ground wire connecting them in
addition to being grounded through the machine.  When removed from the USC
board, the index can be measured with a multimeter as the spindle is
rotated.  I forgot to bring my scope to the shop today (I didn't think I'd
need it) so I can't scope anything until tomorrow.  Is it possible there's
a pull-up resistor missing?

Well, the index is not actually used except once for each 
G33.1 operation, to start the spindle synch motion.  So, it 
is only important for multiple-pass threading.


But, note that while the A and B transitions are filtered by 
requiring a valid quadrature state transition, the index 
pulse is not.  Even a 10 ns wide dip from +5 to near ground 
will trigger the index logic.
What is the resting voltage of the index signal?  Does it 
need a pull-up resistor to +5 V?  The logic threshold is 2.5 
V.  The USC does NOT provide any pull-up resistor.  If your 
encoders need such, consult the encoder data sheet to 
determine what resistor value is best.


Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-01 Thread Gene Heskett

On Saturday 01 August 2020 18:39:47 Matthew Herd wrote:

> Thanks Chris, that was my thinking as well.  I’ll try that tomorrow
> and see what we find.  I’m not sure there’s much more I could
> disconnect in the ground department, but we’ll start looking at that
> after we isolate the problem to encoder vs. USC board.
>
> > On Aug 1, 2020, at 5:35 PM, Chris Albertson
> >  wrote:
> >
> > On Sat, Aug 1, 2020 at 11:40 AM Matthew Herd  
wrote:
> >> Thanks Gene, I hope you’re well also.  I disconnected that
> >> grounding wire, no difference observed in the
> >> ppmc.0.encoder.03.index behavior.  The noise seems the same both
> >> when spindle is running and stopped, with a tendency strongly
> >> toward "true" than "false."  Pulses seem to be both long and short,
> >> but I’d guess they’re about 80-90% true.  Not at all what I’d
> >> expect, even with noise.
> >
> > Should be easy to see now where the problem is.  Disconnect the
> > encoder cable and look at the actual wire with a real 'scope, not a
> > software hal scope.   Is the signal a clean quadrature when the
> > spindle turns or noisy? If the signal is clean you know the problem
> > is the interface card or a connector and if noisy the encoder itself
> > is the problem
> >
I should mention the obvious, if the encoder is disconnected, that likely 
also removes its power supply, which most of them need to function 
correctly. My advice so far has assumed the encoder is good. But power 
it and check it with a real scope, all 3 outputs.

> > Chris Albertson
> > Redondo Beach, California
> >
> > ___
> > 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


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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-01 Thread Matthew Herd

Thanks Chris, that was my thinking as well.  I’ll try that tomorrow and see 
what we find.  I’m not sure there’s much more I could disconnect in the ground 
department, but we’ll start looking at that after we isolate the problem to 
encoder vs. USC board.

> On Aug 1, 2020, at 5:35 PM, Chris Albertson  wrote:
> 
> On Sat, Aug 1, 2020 at 11:40 AM Matthew Herd  wrote:
> 
>> Thanks Gene, I hope you’re well also.  I disconnected that grounding wire,
>> no difference observed in the ppmc.0.encoder.03.index behavior.  The noise
>> seems the same both when spindle is running and stopped, with a tendency
>> strongly toward "true" than "false."  Pulses seem to be both long and
>> short, but I’d guess they’re about 80-90% true.  Not at all what I’d
>> expect, even with noise.
>> 
> 
> Should be easy to see now where the problem is.  Disconnect the encoder
> cable and look at the actual wire with a real 'scope, not a software hal
> scope.   Is the signal a clean quadrature when the spindle turns or noisy?
> If the signal is clean you know the problem is the interface card or a
> connector and if noisy the encoder itself is the problem
> 
> Chris Albertson
> Redondo Beach, California
> 
> ___
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-01 Thread Chris Albertson

On Sat, Aug 1, 2020 at 11:40 AM Matthew Herd  wrote:

> Thanks Gene, I hope you’re well also.  I disconnected that grounding wire,
> no difference observed in the ppmc.0.encoder.03.index behavior.  The noise
> seems the same both when spindle is running and stopped, with a tendency
> strongly toward "true" than "false."  Pulses seem to be both long and
> short, but I’d guess they’re about 80-90% true.  Not at all what I’d
> expect, even with noise.
>

Should be easy to see now where the problem is.  Disconnect the encoder
cable and look at the actual wire with a real 'scope, not a software hal
scope.   Is the signal a clean quadrature when the spindle turns or noisy?
 If the signal is clean you know the problem is the interface card or a
connector and if noisy the encoder itself is the problem

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-01 Thread Gene Heskett

On Saturday 01 August 2020 14:37:49 Matthew Herd wrote:

> Thanks Gene, I hope you’re well also.  I disconnected that grounding
> wire, no difference observed in the ppmc.0.encoder.03.index behavior. 
> The noise seems the same both when spindle is running and stopped,
> with a tendency strongly toward "true" than "false."  Pulses seem to
> be both long and short, but I’d guess they’re about 80-90% true.  Not
> at all what I’d expect, even with noise.
>
> Matt
>
Then keep disconnecting grounds, looking for those that are grounded when 
the obvious connection is removed.  You want that connection to the 
common bolt, you don't want it anywhere else. 

Using the scope, ground the scope probes ground lead to that bolt, no 
other connection, no matter how handy it may be, will give you valid 
results.  If the scope is AC powered, put one of those usually grey 3 to 
2 adapters on its power cord.  You want that bolt to be the only ground 
the scope see's. Put a 2' clip lead extension on the probes ground lead 
if you have to.  You will see more noise but you'll also recognize the 
noise pattern so your eyes can visually subtract it, knowing that noise 
is the long ground lead. I found on one of my machines several years ago 
now, that a 3 foot length of 3/8" wide flat braid, covered to prevent 
its touching the control box as it was leaving, and screwed solidly to 
the nearest point of the machine frame was a huge help, but I was slow, 
I had to blow the probe input of a card before I grokked that the 
machines frame was not grounded. Disconnected, the machine had 150+ 
volts of noise exceeding the scopes sub 10 ns rise time anyplace I hit 
with a probe.  That was an eye opener for sure, so now they all sport 
that hunk of braided copper. And obviously other grounds are hunted down 
and eliminated. I'm nearly all steppers but I use shielded cable to the 
motors with the shield grabbing that bolt, but the shielding stops in 
one of the smallest Hammond die cast boxes epoxied to the side of the 
motor, taped up so it can't touch the box. All of my tally switches get 
their ground reference from that single bolt.  And now it all Just 
Works. ;-)

> > On Aug 1, 2020, at 1:19 PM, Gene Heskett 
> > wrote:
> >
> > On Saturday 01 August 2020 12:10:55 Matthew Herd wrote:
> >> I'm still having issues with the rigid tapping.  It works sometimes
> >> and fails other times.  After scoping the motion.spindle-revs, it
> >> appears to be consistent with what we would expect aside from one
> >> possible issue.  The spindle revs reset to zero upon G33.1 being
> >> called, then count up until they stop, reverse, go negative past
> >> zero, then return to clockwise motion.  However, on the second zero
> >> crossing (going positive) the revs go positive, only to be reset to
> >> zero momentarily thereafter.  I'm not sure if this is normal
> >> behavior or not.
> >>
> >> However, what isn't normal behavior is that the
> >> ppmc.0.encoder.03.index value is loaded with noise.  Not occasional
> >> noise, but constantly triggering in irregular intervals regardless
> >> of whether the spindle is turning.  I'm baffled as to how this
> >> could be so noisy and was wondering where you might look next. 
> >> Grounds look fine aside from the fact that the control cabinet and
> >> the power cabinet have a ground wire connecting them in addition to
> >> being grounded through the machine.
> >
> > That quite likely is the problem.  Thats a ground loop. Ground
> > things only at a single bolt in the control cabinet, and remove any
> > machine grounds at the encoder end of the wiring.  Ground loops are
> > only good for acting as antennas to pick up noise. And in a machine
> > full of motors which are regulating motor currants by switching on
> > and off to hold the average you or the driver has set, there is 50
> > to 175 volts of noise free for the asking. To ground the machine,
> > connect the third, static ground wire in its AC power cord to this
> > bolt. If more than one power supply, arrange the cordage to come
> > thru a single power strip, with only one of the individual cord
> > grounds completed to that bolt. Ground the switcher supplies earth
> > terminals to that bolt, and if needed, the - terminals of all those
> > supplies to this bolt.  You may need a long bolt, thats ok.
> >
> >> When removed from the USC board, the
> >> index can be measured with a multimeter as the spindle is rotated.
> >
> > If reading to machine ground, thats bad, If reading to logic ground,
> > thats good.  Logic ground can be connected to that single grounded
> > bolt but the distribution of that ground should resemble a star, and
> > any ground wire lifted off that bolt should not have continuity to
> > ground anyplace else.
> >
> > This is also good to protect the electronics in that machine from
> > nearby lightning strikes. That way, the lightning strike may bounce
> > the machine a hundred thousand volts, but its all in unison and the
> > 3.3 volt

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-01 Thread Matthew Herd

Thanks Gene, I hope you’re well also.  I disconnected that grounding wire, no 
difference observed in the ppmc.0.encoder.03.index behavior.  The noise seems 
the same both when spindle is running and stopped, with a tendency strongly 
toward "true" than "false."  Pulses seem to be both long and short, but I’d 
guess they’re about 80-90% true.  Not at all what I’d expect, even with noise.

Matt

> On Aug 1, 2020, at 1:19 PM, Gene Heskett  wrote:
> 
> On Saturday 01 August 2020 12:10:55 Matthew Herd wrote:
> 
>> I'm still having issues with the rigid tapping.  It works sometimes
>> and fails other times.  After scoping the motion.spindle-revs, it
>> appears to be consistent with what we would expect aside from one
>> possible issue.  The spindle revs reset to zero upon G33.1 being
>> called, then count up until they stop, reverse, go negative past zero,
>> then return to clockwise motion.  However, on the second zero crossing
>> (going positive) the revs go positive, only to be reset to zero
>> momentarily thereafter.  I'm not sure if this is normal behavior or
>> not.
>> 
>> However, what isn't normal behavior is that the
>> ppmc.0.encoder.03.index value is loaded with noise.  Not occasional
>> noise, but constantly triggering in irregular intervals regardless of
>> whether the spindle is turning.  I'm baffled as to how this could be
>> so noisy and was wondering where you might look next.  Grounds look
>> fine aside from the fact that the control cabinet and the power
>> cabinet have a ground wire connecting them in addition to being
>> grounded through the machine. 
> 
> That quite likely is the problem.  Thats a ground loop. Ground things 
> only at a single bolt in the control cabinet, and remove any machine 
> grounds at the encoder end of the wiring.  Ground loops are only good 
> for acting as antennas to pick up noise. And in a machine full of motors 
> which are regulating motor currants by switching on and off to hold the 
> average you or the driver has set, there is 50 to 175 volts of noise 
> free for the asking. To ground the machine, connect the third, static 
> ground wire in its AC power cord to this bolt. If more than one power 
> supply, arrange the cordage to come thru a single power strip, with only 
> one of the individual cord grounds completed to that bolt. Ground the 
> switcher supplies earth terminals to that bolt, and if needed, the - 
> terminals of all those supplies to this bolt.  You may need a long bolt, 
> thats ok.
> 
>> When removed from the USC board, the 
>> index can be measured with a multimeter as the spindle is rotated.
> 
> If reading to machine ground, thats bad, If reading to logic ground, 
> thats good.  Logic ground can be connected to that single grounded bolt 
> but the distribution of that ground should resemble a star, and any 
> ground wire lifted off that bolt should not have continuity to ground 
> anyplace else. 
> 
> This is also good to protect the electronics in that machine from nearby 
> lightning strikes. That way, the lightning strike may bounce the machine 
> a hundred thousand volts, but its all in unison and the 3.3 volt logic 
> doesn't see it or get damaged by it unless there is a large capacitance 
> to earth ground to unbalance that bounce.  Thats generally unavoidable 
> when several ton of iron is sitting on a concrete floor. But although 
> the pole that serves this house gets tapped occasionally, I have not 
> lost any electronics to those strikes in several years since I brought 
> the grandfathered in since the early 70's, pre NEC service up to code in 
> 2008 as I was building the garage. The power folks haven't been so 
> lucky, they lost a 25kw can once.  It might have been an askerol filled 
> can which is a time bomb after 20 years or less anyway, but I think they 
> hung a 50kw full of Crisco in place of it.  Outdoors, Crisco is legal, 
> but the PCB's are fireproof.
> 
>> I 
>> forgot to bring my scope to the shop today (I didn't think I'd need
>> it) so I can't scope anything until tomorrow.  Is it possible there's
>> a pull-up resistor missing?
> 
> There might be. I am not using any except the normal pullups in the logic 
> that give a true on the halmeter when no input is connected. Mesa cards 
> generally have adequate pullups without external helpers. Sainsmart 
> bob's don't generally need them either.
> 
>> Thanks,
>> Matt
>> 
> I hope this helps Matt, stay safe and well now.
> 
> 
> 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 
>

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-01 Thread Gene Heskett

On Saturday 01 August 2020 12:10:55 Matthew Herd wrote:

> I'm still having issues with the rigid tapping.  It works sometimes
> and fails other times.  After scoping the motion.spindle-revs, it
> appears to be consistent with what we would expect aside from one
> possible issue.  The spindle revs reset to zero upon G33.1 being
> called, then count up until they stop, reverse, go negative past zero,
> then return to clockwise motion.  However, on the second zero crossing
> (going positive) the revs go positive, only to be reset to zero
> momentarily thereafter.  I'm not sure if this is normal behavior or
> not.
>
> However, what isn't normal behavior is that the
> ppmc.0.encoder.03.index value is loaded with noise.  Not occasional
> noise, but constantly triggering in irregular intervals regardless of
> whether the spindle is turning.  I'm baffled as to how this could be
> so noisy and was wondering where you might look next.  Grounds look
> fine aside from the fact that the control cabinet and the power
> cabinet have a ground wire connecting them in addition to being
> grounded through the machine. 

That quite likely is the problem.  Thats a ground loop. Ground things 
only at a single bolt in the control cabinet, and remove any machine 
grounds at the encoder end of the wiring.  Ground loops are only good 
for acting as antennas to pick up noise. And in a machine full of motors 
which are regulating motor currants by switching on and off to hold the 
average you or the driver has set, there is 50 to 175 volts of noise 
free for the asking. To ground the machine, connect the third, static 
ground wire in its AC power cord to this bolt. If more than one power 
supply, arrange the cordage to come thru a single power strip, with only 
one of the individual cord grounds completed to that bolt. Ground the 
switcher supplies earth terminals to that bolt, and if needed, the - 
terminals of all those supplies to this bolt.  You may need a long bolt, 
thats ok.

> When removed from the USC board, the 
> index can be measured with a multimeter as the spindle is rotated.

If reading to machine ground, thats bad, If reading to logic ground, 
thats good.  Logic ground can be connected to that single grounded bolt 
but the distribution of that ground should resemble a star, and any 
ground wire lifted off that bolt should not have continuity to ground 
anyplace else. 

This is also good to protect the electronics in that machine from nearby 
lightning strikes. That way, the lightning strike may bounce the machine 
a hundred thousand volts, but its all in unison and the 3.3 volt logic 
doesn't see it or get damaged by it unless there is a large capacitance 
to earth ground to unbalance that bounce.  Thats generally unavoidable 
when several ton of iron is sitting on a concrete floor. But although 
the pole that serves this house gets tapped occasionally, I have not 
lost any electronics to those strikes in several years since I brought 
the grandfathered in since the early 70's, pre NEC service up to code in 
2008 as I was building the garage. The power folks haven't been so 
lucky, they lost a 25kw can once.  It might have been an askerol filled 
can which is a time bomb after 20 years or less anyway, but I think they 
hung a 50kw full of Crisco in place of it.  Outdoors, Crisco is legal, 
but the PCB's are fireproof.

> I 
> forgot to bring my scope to the shop today (I didn't think I'd need
> it) so I can't scope anything until tomorrow.  Is it possible there's
> a pull-up resistor missing?

There might be. I am not using any except the normal pullups in the logic 
that give a true on the halmeter when no input is connected. Mesa cards 
generally have adequate pullups without external helpers. Sainsmart 
bob's don't generally need them either.

> Thanks,
> Matt
>
I hope this helps Matt, stay safe and well now.

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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-08-01 Thread Matthew Herd

I'm still having issues with the rigid tapping.  It works sometimes and
fails other times.  After scoping the motion.spindle-revs, it appears to be
consistent with what we would expect aside from one possible issue.  The
spindle revs reset to zero upon G33.1 being called, then count up until
they stop, reverse, go negative past zero, then return to clockwise
motion.  However, on the second zero crossing (going positive) the revs go
positive, only to be reset to zero momentarily thereafter.  I'm not sure if
this is normal behavior or not.

However, what isn't normal behavior is that the ppmc.0.encoder.03.index
value is loaded with noise.  Not occasional noise, but constantly
triggering in irregular intervals regardless of whether the spindle is
turning.  I'm baffled as to how this could be so noisy and was wondering
where you might look next.  Grounds look fine aside from the fact that the
control cabinet and the power cabinet have a ground wire connecting them in
addition to being grounded through the machine.  When removed from the USC
board, the index can be measured with a multimeter as the spindle is
rotated.  I forgot to bring my scope to the shop today (I didn't think I'd
need it) so I can't scope anything until tomorrow.  Is it possible there's
a pull-up resistor missing?

Thanks,
Matt

On Fri, Jul 24, 2020 at 6:38 AM Matthew Herd  wrote:

> Thanks Andy, I’ll give the documentation a thorough read through and see
> how it might be best incorporated.
>
> > On Jul 23, 2020, at 3:07 PM, andy pugh  wrote:
> >
> > On Thu, 23 Jul 2020 at 17:06, Jon Elson  wrote:
> >
> >>> Who is in charge of the integrator’s manual?  I’d like to investigate
> writing some additional sections.
> >>>
> >> You can submit suggested changes to John Thornton, or get
> >> commit access yourself.
> >
> > Fir docs you can edit the asccidoc file live on the web site and
> > create a pull-request with the click of a button.
> > (All you need to do is log in as yourself then click the pencil icon
> > on the file view)
> >
> > --
> > 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
>
>

-- 
Matthew Herd
Email:  herd.m...@gmail.com
Cell:  610-608-8930

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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-24 Thread Matthew Herd

Thanks Andy, I’ll give the documentation a thorough read through and see how it 
might be best incorporated.

> On Jul 23, 2020, at 3:07 PM, andy pugh  wrote:
> 
> On Thu, 23 Jul 2020 at 17:06, Jon Elson  wrote:
> 
>>> Who is in charge of the integrator’s manual?  I’d like to investigate 
>>> writing some additional sections.
>>> 
>> You can submit suggested changes to John Thornton, or get
>> commit access yourself.
> 
> Fir docs you can edit the asccidoc file live on the web site and
> create a pull-request with the click of a button.
> (All you need to do is log in as yourself then click the pencil icon
> on the file view)
> 
> -- 
> 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 mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-23 Thread andy pugh

On Thu, 23 Jul 2020 at 17:06, Jon Elson  wrote:

> > Who is in charge of the integrator’s manual?  I’d like to investigate 
> > writing some additional sections.
> >
> You can submit suggested changes to John Thornton, or get
> commit access yourself.

Fir docs you can edit the asccidoc file live on the web site and
create a pull-request with the click of a button.
(All you need to do is log in as yourself then click the pencil icon
on the file view)

-- 
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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-23 Thread Jon Elson


On 07/23/2020 05:21 AM, Matthew Herd wrote:

I should also note I made an error in my revolutions calculation.  It should be 
RPM / 2 / 60 sec * deceleration time = revolutions to stop, assuming linear 
deceleration.  That’s probably the default for most drives.  For 560 RPM, that 
comes out to 2.8 revolutions.  So my observations at 2.9 revolutions are 
consistent with that.

Who is in charge of the integrator’s manual?  I’d like to investigate writing 
some additional sections.

You can submit suggested changes to John Thornton, or get 
commit access yourself.


Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-23 Thread andy pugh

On Thu, 23 Jul 2020 at 11:24, Matthew Herd  wrote:

> Who is in charge of the integrator’s manual?  I’d like to investigate writing 
> some additional sections.=

We all are. :-)

The "Integrator manual" may not be the manual you need to change, but
is made of these files.
https://github.com/LinuxCNC/linuxcnc/blob/master/docs/src/Master_Integrator.txt

-- 
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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-23 Thread Matthew Herd

I should also note I made an error in my revolutions calculation.  It should be 
RPM / 2 / 60 sec * deceleration time = revolutions to stop, assuming linear 
deceleration.  That’s probably the default for most drives.  For 560 RPM, that 
comes out to 2.8 revolutions.  So my observations at 2.9 revolutions are 
consistent with that.

Who is in charge of the integrator’s manual?  I’d like to investigate writing 
some additional sections.

Thanks,
Matt



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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-22 Thread Jon Elson


On 07/22/2020 08:51 PM, Matthew Herd wrote:


Upon testing, I found that rigid tapping worked as intended,

Excellent.  Glad Robert Ellenberg is watching here, as most 
of us had no idea the trajectory planner had this behavior.


I love rigid tapping, and have made two fixture plates with 
a 1" grid of 10-32 holes.  Also, my PWM servo amps have 12 
or 14 4-40 tapped holes in each mounting plate.  I also did 
some brackets for circuit boards that have a bunch of 2-56 
holes.  Those make me bit my lip just a little.


The neatest thing is combo drill-taps, they have a twist 
drill front end and a tap further back.
You drill through sheet material at a low feedrate, then 
back up a bit and do G33.1 to tap

the hole, all with one tool.

Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-22 Thread Matthew Herd

I got the braking resistor installed, fiddled with all the DC injection braking 
and dynamic braking parameters on the machine, then started turning down the 
deceleration time.  It looks like I only tuned the acceleration time when I 
originally installed the VFD because it was set to the default 10 seconds.  I 
turned it down to 0.6 seconds and tested a reversal of direction up to 1000 
RPM.  Worked great.  Also, since the mechanical brake kicks in automatically 
when stopping, the drive doesn’t fault out even when the varispeed head is set 
to max RPM.  I can’t imagine I’ll need to tap at 1000 RPM, but I estimated that 
1000 RPM to 0 RPM in 0.6 seconds should be approximately equal to 10 
revolutions (assuming a linear deceleration).  I didn’t bother to push it 
further.  No idea how much the braking resistor helps, but it certainly doesn’t 
hurt.

Upon testing, I found that rigid tapping worked as intended, aside from one 
glitch on the first attempt after powering up where it hung in the down 
position and running in reverse.  Not sure of the cause there, but I wasn’t 
able to reproduce the error.  In practice, 560 RPM resulted in an overshoot 
equal to a bit under 3 revolutions.  I figure if I allow 5 revolutions of 
margin to the bottom of the hole, I should be fine.  I tested it repeatedly, 
including running a program tapping two holes in delrin.  Thank you all for 
your help.  I’ll run it a few more times before declaring it solved, but so far 
so good!

As to configuring speed control of the VFD, that’s for another day.  I plan to 
do it eventually, but for now I’m thrilled I didn’t need to resort to more 
sophisticated fixes.  I’m fine with manually setting my speed.

> On Jul 21, 2020, at 8:26 PM, Gene Heskett  wrote:
> 
> On Tuesday 21 July 2020 18:40:35 Scott Harwell via Emc-users wrote:
> 
>> Just got my new Control Engineering in the mail and saw this."Top 5
>> VFD parameter changes explained"
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Top 5 VFD parameter changes explained
>> 
>> Chris Vavra
>> 
>> Learning Objectives Setting five parameters can take care of most VFD
>> programming. Consider VFD control met...
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> "www.controleng.com/articles/top-5-vfd-parameter-changes-explained/"
>> It may help.
>> Scott
>> 
>>On Tuesday, July 21, 2020, 12:17:05 PM CDT, Matthew Herd
>>  wrote:
>> 
>> Hi Rob,
>> 
>> Thanks for the insights.  I suspected something along these lines,
>> even if I might have other problems with noise.  I can confirm, the
>> spindle stops way too slowly and definitely more than 10 revolutions
>> pass before stopping.  Long story short, I can’t readily run the
>> machine in back gear and the slowest I can go at 60Hz is 560 RPM
>> without backgear.
> 
> But if you get the right control signal setup, you can drive that vfd at 
> 5 hertz! I am doing it. And I can do it for an hour at a time without 
> heating the motor so hot I can't touch it. All you need is to find the 
> register that sets the motors FLA, and transfer the FLA from the motors 
> nameplate to that register. That way you are assured that the motor 
> won't be quickly overheated and burned up at even very low speeds.  You 
> may also have to locate the register that sets the minimum run speed as 
> its likely set to faster than that, possibly even turning itself off at 
> 30 hertz or more.  There are registers also to control how fast it 
> accels or decels.  The biggest problem is in translating the Chinglish 
> in the booklets into your local dialect that you understand.
> 
> One thing I've found is that most vfd's are directly controllable by a
> 12 volt swing from a pwm generator, running the pwm at 10 kilohertz.  The 
> vfd's response averages that into an analog signal equivalent, so a 10% 
> duty cycle pwm will run the vfd at say 12 hertz.  And I've some extra 
> stuff in my .hal to measure the overshoot so I'll demo, live, right now. 
> From 200 rpms, entering an m4 to reverse it, gets me a display of 1.0333 
> revs that it overshot, or just a small hair over 1 full turn from 200 
> revs. This is an E400 drive, running in 1st gear, and it has an 8" 4 jaw 
> chuck that weighs just short of 40 lbs mounted. This particular vfd is 
> controlled by a Mesa SpinX1 which has its own analog 0-10 volt output.
> 
> Your B-Port doesn't have near that amount of flywheel, and it ought to 
> beat that time while spinning at 400 rpms.
> 
>> I’ll play a bit more with how quickly I can stop 
>> the spindle with a braking resistor or I’ll attempt to get the HAL
>> file to engage the mechanical brake to help transition faster. 
>> Nonetheless, 10 revolutions seems fairly ambitious based on my best
>> guess of how long it might take to stop the spindle even with a
>> braking resistor.That’s about 1 second, but should be achievable. 
>> Currently the VFD is configured based on the fastest stop time for max
>> RPM, and there doesn’t seem to be a way to decrease stop time for
>> different

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tuesday 21 July 2020 18:40:35 Scott Harwell via Emc-users wrote:

>  Just got my new Control Engineering in the mail and saw this."Top 5
> VFD parameter changes explained"
>
>
>
>
>
>
>
>
>
>
>
> Top 5 VFD parameter changes explained
>
> Chris Vavra
>
> Learning Objectives Setting five parameters can take care of most VFD
> programming. Consider VFD control met...
>
>
>
>
>
>
>
> "www.controleng.com/articles/top-5-vfd-parameter-changes-explained/"
> It may help.
> Scott
>
> On Tuesday, July 21, 2020, 12:17:05 PM CDT, Matthew Herd
>  wrote:
>
>  Hi Rob,
>
> Thanks for the insights.  I suspected something along these lines,
> even if I might have other problems with noise.  I can confirm, the
> spindle stops way too slowly and definitely more than 10 revolutions
> pass before stopping.  Long story short, I can’t readily run the
> machine in back gear and the slowest I can go at 60Hz is 560 RPM
> without backgear.

But if you get the right control signal setup, you can drive that vfd at 
5 hertz! I am doing it. And I can do it for an hour at a time without 
heating the motor so hot I can't touch it. All you need is to find the 
register that sets the motors FLA, and transfer the FLA from the motors 
nameplate to that register. That way you are assured that the motor 
won't be quickly overheated and burned up at even very low speeds.  You 
may also have to locate the register that sets the minimum run speed as 
its likely set to faster than that, possibly even turning itself off at 
30 hertz or more.  There are registers also to control how fast it 
accels or decels.  The biggest problem is in translating the Chinglish 
in the booklets into your local dialect that you understand.

One thing I've found is that most vfd's are directly controllable by a
12 volt swing from a pwm generator, running the pwm at 10 kilohertz.  The 
vfd's response averages that into an analog signal equivalent, so a 10% 
duty cycle pwm will run the vfd at say 12 hertz.  And I've some extra 
stuff in my .hal to measure the overshoot so I'll demo, live, right now. 
From 200 rpms, entering an m4 to reverse it, gets me a display of 1.0333 
revs that it overshot, or just a small hair over 1 full turn from 200 
revs. This is an E400 drive, running in 1st gear, and it has an 8" 4 jaw 
chuck that weighs just short of 40 lbs mounted. This particular vfd is 
controlled by a Mesa SpinX1 which has its own analog 0-10 volt output.

Your B-Port doesn't have near that amount of flywheel, and it ought to 
beat that time while spinning at 400 rpms.

> I’ll play a bit more with how quickly I can stop 
> the spindle with a braking resistor or I’ll attempt to get the HAL
> file to engage the mechanical brake to help transition faster. 
> Nonetheless, 10 revolutions seems fairly ambitious based on my best
> guess of how long it might take to stop the spindle even with a
> braking resistor.    That’s about 1 second, but should be achievable. 
> Currently the VFD is configured based on the fastest stop time for max
> RPM, and there doesn’t seem to be a way to decrease stop time for
> different inertial loads (i.e. lower gear ratios/spindle speeds). 
> However, I understand that the braking resistor should decrease stop
> time by approximately an order of magnitude based on some reading I
> did yesterday.
>
> Thanks!
> Matt
>
> > On Jul 21, 2020, at 1:00 PM, Robert Ellenberg 
> > wrote:
> >
> > Based on the videos and your descriptions of the behavior, you may
> > be running into a TP issue I've seen (in simulation) with very
> > sluggish spindles or very high spindle speeds. Here's what I think
> > is going on:
> >
> >  1. The rigid tapping cycle allows a hard-coded 10 revolutions
> > 
> >  >56> of overtravel beyond the nominal bottom of the hole when
> > reversing direction.
> >  2. The spindle starts reversing direction only after the Z axis has
> >  reached the bottom, so the spindle has to be able to stop in 10
> > revolutions to stay within the budgeted overtravel.
> >  3. If the TP hits the end of the overtravel, it prematurely
> > declares the motion to be complete and stops following the spindle
> > motion.
> >
> > Do you still see this behavior if you run the spindle slower? Your
> > spindle seems to take a long time to reverse, so at high speeds you
> > may be hitting this limit.
> >
> > Best,
> > Rob
> >  >56>
> >
> > On Tue, Jul 21, 2020 at 11:18 AM Matthew Herd  
wrote:
> >> Ahh, so I do use limit switches and a homing routine.  So it’s
> >> homing to the same position (plus or minus a few thousandths or
> >> so).
> >>
> >>> On Jul 21, 2020, at 11:07 AM, Jon Elson 
> >>> wrote:
> >>>
> >>> On 07/21/2020 04:20 AM, andy pugh wrote:
>  On Tue, 21 Jul 2020 at 10:18, andy pugh  
wrote:
> > We are not looking for noise, we are looking for spurious
> > encoder
> >>
> >> count resets.
> >>
>

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Scott Harwell via Emc-users

 Just got my new Control Engineering in the mail and saw this."Top 5 VFD 
parameter changes explained"

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Top 5 VFD parameter changes explained

Chris Vavra

Learning Objectives Setting five parameters can take care of most VFD 
programming. Consider VFD control met...
 |

 |

 |

"www.controleng.com/articles/top-5-vfd-parameter-changes-explained/"
It may help.
Scott

On Tuesday, July 21, 2020, 12:17:05 PM CDT, Matthew Herd 
 wrote:  

 Hi Rob,

Thanks for the insights.  I suspected something along these lines, even if I 
might have other problems with noise.  I can confirm, the spindle stops way too 
slowly and definitely more than 10 revolutions pass before stopping.  Long 
story short, I can’t readily run the machine in back gear and the slowest I can 
go at 60Hz is 560 RPM without backgear.  I’ll play a bit more with how quickly 
I can stop the spindle with a braking resistor or I’ll attempt to get the HAL 
file to engage the mechanical brake to help transition faster.  Nonetheless, 10 
revolutions seems fairly ambitious based on my best guess of how long it might 
take to stop the spindle even with a braking resistor.    That’s about 1 
second, but should be achievable.  Currently the VFD is configured based on the 
fastest stop time for max RPM, and there doesn’t seem to be a way to decrease 
stop time for different inertial loads (i.e. lower gear ratios/spindle speeds). 
 However, I understand that the braking resistor should decrease stop time by 
approximately an order of magnitude based on some reading I did yesterday.

Thanks!
Matt

> On Jul 21, 2020, at 1:00 PM, Robert Ellenberg  wrote:
> 
> Based on the videos and your descriptions of the behavior, you may be
> running into a TP issue I've seen (in simulation) with very sluggish
> spindles or very high spindle speeds. Here's what I think is going on:
> 
>  1. The rigid tapping cycle allows a hard-coded 10 revolutions
>  
>  of overtravel beyond the nominal bottom of the hole when reversing
>  direction.
>  2. The spindle starts reversing direction only after the Z axis has
>  reached the bottom, so the spindle has to be able to stop in 10 revolutions
>  to stay within the budgeted overtravel.
>  3. If the TP hits the end of the overtravel, it prematurely declares the
>  motion to be complete and stops following the spindle motion.
> 
> Do you still see this behavior if you run the spindle slower? Your spindle
> seems to take a long time to reverse, so at high speeds you may be hitting
> this limit.
> 
> Best,
> Rob
> 
> 
> On Tue, Jul 21, 2020 at 11:18 AM Matthew Herd  wrote:
> 
>> Ahh, so I do use limit switches and a homing routine.  So it’s homing to
>> the same position (plus or minus a few thousandths or so).
>> 
>>> On Jul 21, 2020, at 11:07 AM, Jon Elson  wrote:
>>> 
>>> On 07/21/2020 04:20 AM, andy pugh wrote:
 On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:

> We are not looking for noise, we are looking for spurious encoder
>> count resets.
 But, thinking further, even if there _is_ noise on the index line, the
 encoder counter should ignore it. It ignores all the _real_ indexes
 unless index-enable is set true in HAL.

>>> Yes, the only thing I can think of is he's hitting his soft limits. Over
>> time, starting and stopping LinuxCNC,
>>> without homing, the machine limits will drift.  If you have rational
>> limits in the .ini file, you will eventually reach the end of them and have
>> really strange behavior.  it can be fixed by homing in a safe position,
>>> but best to put in home switches and actually home the machine to a
>> repeatable position every time.
>>> 
>>> 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
>> 
> 
> ___
> 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

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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Scott Harwell via Emc-users

 Matt,
Are you seeing overvoltage faults on the VFD? If you are not decrease the decel 
time until you see a fault and then bump it back up until you are fault free. I 
don't know what the breaking resistors will do if you are not seeing a fault 
now, they are used to drop the B+ from the regen during the stop. Is the tap 
sequence M3, M5, M4 or M3, M4. The M3, M4 sequence is normally much better for 
response an far less drift. What model number drive do you have? I have done a 
lot of work over the years with Yaskawa drives the Hitachi drives should be 
close. Lower Hz on the motor will normally help you more, I'm afraid that 
backgear will compound your ramp time. 

Scott
On Tuesday, July 21, 2020, 1:03:06 PM CDT, Matthew Herd 
 wrote:  

 On a related note, I’ve noticed that the G-Code reference for G33 and G33.1 
refers you to the integrators manual, but there’s little documentation on 
spindle synchronized motion.  I’d be willing to add a section based on what I 
learn from this experience.  It might be helpful to make sure there’s more of a 
checklist and some of these cautions and observations in there.

> On Jul 21, 2020, at 1:56 PM, Jon Elson  wrote:
> 
> On 07/21/2020 12:09 PM, andy pugh wrote:
>> On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg  wrote:
>> 
>>>    1. The rigid tapping cycle allows a hard-coded 10 revolutions
>>>    
>>>    of overtravel beyond the nominal bottom of the hole when reversing
>>>    direction.
>> That feels like there should be an error message.
>> 
>> "Maximum rigid tapping limit exceeded. And furthermore I have just
>> broken your tap"
>> 
> That, and maybe some explanation of this behavior in the docs. Maybe a more 
> specific message would be "spindle took too long to reverse while rigid 
> tapping".
> 
> 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

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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tuesday 21 July 2020 14:44:12 Robert Ellenberg wrote:

> I totally agree that a silent failure mode (especially one that can
> break taps) is bad news. Perhaps thankfully, we've gotten away with it
> for a long time: based on the git history, the 10-rev overshoot limit
> and this silent failure mode has been around at least since the 2.6
> days, maybe earlier.
>
> I have a few ways in mind to fix this:
>
>1. Throw an error and abort motion if it reaches some threshold of
>overshoot (say 90% of the maximum), or maybe if the position
> tracking error exceeds some threshold.
>2. Check if the rigid tap motion + max overshoot exceeds the axis
> limits (currently we check before adding the overshoot allowance,
> which in theory could lead to motion past the soft limits)
>3. (optional) Tell motion what the expected spindle acceleration is
> (via HAL pin), so that it can start reversing before it hits the
> bottom of the hole (reducing the overshoot). Leaving this pin at zero
> (default) would give you the current behavior.

Option 3 sounds like a great idea Rob, and it would/could/should be made 
to work with the G33.1 peck wrapper I hasn't published yet. I could even 
imagine 5 or 6 strokes, cutting air and programming that to achieve zero 
overshoot by actively adjusting the Z stop. Making it smarter than the 
average bear.

>  -Rob
>
> On Tue, Jul 21, 2020 at 2:17 PM Gene Heskett  
wrote:
> > On Tuesday 21 July 2020 13:09:16 andy pugh wrote:
> > > On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg 
> >
> > wrote:
> > > >1. The rigid tapping cycle allows a hard-coded 10 revolutions
> > > >
> > > >  > > >c#L8 56> of overtravel beyond the nominal bottom of the hole when
> > > > reversing direction.
> > >
> > > That feels like there should be an error message.
> > >
> > > "Maximum rigid tapping limit exceeded. And furthermore I have just
> > > broken your tap"
> >
> > "Maximum rigid tapping limit exceeded. And furthermore I have just
> >  broken your $85 carbide tap"
> >
> > There, I fixed it for you. :(
> >
> > 10 turns is way too far. I cut air at least once to measure the
> > turnaround (I have that stuff in my .hal file) and in what I have
> > done, that has led me to set a personal limit of 2 turns. Taking a
> > broken tap out of a valuable blind hole via EDM is a genuine PITA
> > and I will do whatever it takes to avoid that. But, I would not
> > uncouple the spindle from the tap either, killing the spindle drive
> > ASAP instead, then one might be able to  back the tap out of the
> > hole with the spindle, salvaging the part so maybe the hole could be
> > finished by hand.
> >
> > 10 turns, breaking the tap is the wrong thing to do. Shutting down,
> > leaving it coupled before the tap breaks is the best thing to do.
> >
> > 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


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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Robert Ellenberg

I totally agree that a silent failure mode (especially one that can break
taps) is bad news. Perhaps thankfully, we've gotten away with it for a long
time: based on the git history, the 10-rev overshoot limit and this silent
failure mode has been around at least since the 2.6 days, maybe earlier.

I have a few ways in mind to fix this:

   1. Throw an error and abort motion if it reaches some threshold of
   overshoot (say 90% of the maximum), or maybe if the position tracking error
   exceeds some threshold.
   2. Check if the rigid tap motion + max overshoot exceeds the axis limits
   (currently we check before adding the overshoot allowance, which in theory
   could lead to motion past the soft limits)
   3. (optional) Tell motion what the expected spindle acceleration is (via
   HAL pin), so that it can start reversing before it hits the bottom of the
   hole (reducing the overshoot). Leaving this pin at zero (default) would
   give you the current behavior.

 -Rob

On Tue, Jul 21, 2020 at 2:17 PM Gene Heskett  wrote:

> On Tuesday 21 July 2020 13:09:16 andy pugh wrote:
>
> > On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg 
> wrote:
> > >1. The rigid tapping cycle allows a hard-coded 10 revolutions
> > >
> > >  > >56> of overtravel beyond the nominal bottom of the hole when
> > > reversing direction.
> >
> > That feels like there should be an error message.
> >
> > "Maximum rigid tapping limit exceeded. And furthermore I have just
> > broken your tap"
>
> "Maximum rigid tapping limit exceeded. And furthermore I have just
>  broken your $85 carbide tap"
>
> There, I fixed it for you. :(
>
> 10 turns is way too far. I cut air at least once to measure the
> turnaround (I have that stuff in my .hal file) and in what I have done,
> that has led me to set a personal limit of 2 turns. Taking a broken tap
> out of a valuable blind hole via EDM is a genuine PITA and I will do
> whatever it takes to avoid that. But, I would not uncouple the spindle
> from the tap either, killing the spindle drive ASAP instead, then one
> might be able to  back the tap out of the hole with the spindle,
> salvaging the part so maybe the hole could be finished by hand.
>
> 10 turns, breaking the tap is the wrong thing to do. Shutting down,
> leaving it coupled before the tap breaks is the best thing to do.
>
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/21/2020 12:43 PM, Matthew Herd wrote:

When I installed the spindle encoder, I used a shaft at the top of the head.  
Due to my failure to investigate more fully, it turns out that it’s geared 1:1 
with the spindle (but is not a part of the spindle).  So when I go into 
backgear, the encoder reads opposite direction and at a different ratio equal 
to the backgear ratio (whatever that is, I’ve never bothered to determine it).  
Fine for running a face mill or fly cutter, but not usable for rigid tapping 
without some HAL to reverse direction and compensate for the ratio change when 
in backgear).  Also, I’ve never gotten automatic spindle speed set up since I 
manually operate the vari-speed drive via push buttons on the head (HAL 
operates the air valves for me).  I also have a +/-10V DAC board to control VFD 
frequency, but have never set that up either.  I’m hoping to get rigid tapping 
working without solving some of these other issues, but if that’s the way it’s 
got to be, then so be it.


On Jul 21, 2020, at 1:27 PM, andy pugh  wrote:

On Tue, 21 Jul 2020 at 18:16, Matthew Herd  wrote:


Thanks for the insights.  I suspected something along these lines, even if I 
might have other problems with noise.  I can confirm, the spindle stops way too 
slowly and definitely more than 10 revolutions pass before stopping.  Long 
story short, I can’t readily run the machine in back gear

I think that's a story cut too short. Why can't you run the machine in
back-gear? I really wouldn't anticipate rigid tapping being done
without 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, 1912


___
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





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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tuesday 21 July 2020 13:09:16 andy pugh wrote:

> On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg  
wrote:
> >1. The rigid tapping cycle allows a hard-coded 10 revolutions
> >   
> >  >56> of overtravel beyond the nominal bottom of the hole when
> > reversing direction.
>
> That feels like there should be an error message.
>
> "Maximum rigid tapping limit exceeded. And furthermore I have just
> broken your tap"

"Maximum rigid tapping limit exceeded. And furthermore I have just
 broken your $85 carbide tap"

There, I fixed it for you. :(

10 turns is way too far. I cut air at least once to measure the 
turnaround (I have that stuff in my .hal file) and in what I have done, 
that has led me to set a personal limit of 2 turns. Taking a broken tap 
out of a valuable blind hole via EDM is a genuine PITA and I will do 
whatever it takes to avoid that. But, I would not uncouple the spindle 
from the tap either, killing the spindle drive ASAP instead, then one 
might be able to  back the tap out of the hole with the spindle, 
salvaging the part so maybe the hole could be finished by hand.

10 turns, breaking the tap is the wrong thing to do. Shutting down, 
leaving it coupled before the tap breaks is the best thing to do.

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] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/21/2020 12:27 PM, andy pugh wrote:

On Tue, 21 Jul 2020 at 18:16, Matthew Herd  wrote:


Thanks for the insights.  I suspected something along these lines, even if I 
might have other problems with noise.  I can confirm, the spindle stops way too 
slowly and definitely more than 10 revolutions pass before stopping.  Long 
story short, I can’t readily run the machine in back gear

I think that's a story cut too short. Why can't you run the machine in
back-gear? I really wouldn't anticipate rigid tapping being done
without it.
I do all my rigid tapping on smaller taps in direct drive 
with the belt on the highest speed setting.
This reduces the effective inertia of the motor, for faster 
reversing.  The motor is usually running
at 15-20 Hz in this mode.  I do 2-56 up to 6-32 taps at 1000 
RPM, and 10-32 and 1/4-20 at about

600 RPM.

Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/21/2020 12:14 PM, Matthew Herd wrote:

Hi Rob,

Thanks for the insights.  I suspected something along these lines, even if I 
might have other problems with noise.  I can confirm, the spindle stops way too 
slowly and definitely more than 10 revolutions pass before stopping.  Long 
story short, I can’t readily run the machine in back gear and the slowest I can 
go at 60Hz is 560 RPM without backgear.
I do not use backgear or belt reduction when doing small 
taps (2-56 up to 10-32).  I do the smaller taps at 1000 RPM, 
and maybe 600 for the 10-32.  So, the motor is running quite 
slowly at these speeds, maybe 15 - 20 Hz.  This makes it 
much easier to stop and reverse the motor.  I DO have a 
braking resistor on the VFD.  You can actually use stovetop 
heating elements for this (look in the back of any Haas 
machine.)

   I’ll play a bit more with how quickly I can stop the spindle with a braking 
resistor or I’ll attempt to get the HAL file to engage the mechanical brake to 
help transition faster.  Nonetheless, 10 revolutions seems fairly ambitious 
based on my best guess of how long it might take to stop the spindle even with 
a braking resistor.That’s about 1 second, but should be achievable.  
Currently the VFD is configured based on the fastest stop time for max RPM, and 
there doesn’t seem to be a way to decrease stop time for different inertial 
loads (i.e. lower gear ratios/spindle speeds).  However, I understand that the 
braking resistor should decrease stop time by approximately an order of 
magnitude based on some reading I did yesterday.
My machine (Bridgeport with 1J head) can reverse in a 
fraction of a second, probably 2 revolutions from 1000 RPM.


Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On a related note, I’ve noticed that the G-Code reference for G33 and G33.1 
refers you to the integrators manual, but there’s little documentation on 
spindle synchronized motion.  I’d be willing to add a section based on what I 
learn from this experience.  It might be helpful to make sure there’s more of a 
checklist and some of these cautions and observations in there.

> On Jul 21, 2020, at 1:56 PM, Jon Elson  wrote:
> 
> On 07/21/2020 12:09 PM, andy pugh wrote:
>> On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg  wrote:
>> 
>>>1. The rigid tapping cycle allows a hard-coded 10 revolutions
>>>
>>>of overtravel beyond the nominal bottom of the hole when reversing
>>>direction.
>> That feels like there should be an error message.
>> 
>> "Maximum rigid tapping limit exceeded. And furthermore I have just
>> broken your tap"
>> 
> That, and maybe some explanation of this behavior in the docs. Maybe a more 
> specific message would be "spindle took too long to reverse while rigid 
> tapping".
> 
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/21/2020 12:09 PM, andy pugh wrote:

On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg  wrote:


1. The rigid tapping cycle allows a hard-coded 10 revolutions

of overtravel beyond the nominal bottom of the hole when reversing
direction.

That feels like there should be an error message.

"Maximum rigid tapping limit exceeded. And furthermore I have just
broken your tap"

That, and maybe some explanation of this behavior in the 
docs. Maybe a more specific message would be "spindle took 
too long to reverse while rigid tapping".


Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/21/2020 12:00 PM, Robert Ellenberg wrote:

Based on the videos and your descriptions of the behavior, you may be
running into a TP issue I've seen (in simulation) with very sluggish
spindles or very high spindle speeds. Here's what I think is going on:

1. The rigid tapping cycle allows a hard-coded 10 revolutions

of overtravel beyond the nominal bottom of the hole when reversing
direction.
2. The spindle starts reversing direction only after the Z axis has
reached the bottom, so the spindle has to be able to stop in 10 revolutions
to stay within the budgeted overtravel.
3. If the TP hits the end of the overtravel, it prematurely declares the
motion to be complete and stops following the spindle motion.


AND, so the guy who actually WROTE THE CODE explains what is 
REALLY going on!

Yes, that explains at least the first video quite well.

Obviously, for rigid tapping, you need a spindle drive that 
is capable of a pretty strong stop and reversal.


Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tue, 21 Jul 2020 at 18:46, Matthew Herd  wrote:

> When I installed the spindle encoder, I used a shaft at the top of the head.  
> Due to my failure to investigate more fully, it turns out that it’s geared 
> 1:1 with the spindle (but is not a part of the spindle).  So when I go into 
> backgear, the encoder reads opposite direction and at a different ratio equal 
> to the backgear ratio (whatever that is, I’ve never bothered to determine 
> it).  Fine for running a face mill or fly cutter, but not usable for rigid 
> tapping without some HAL to reverse direction and compensate for the ratio 
> change when in backgear).

You would also need to pick up an index (but only an index) from
something that does run 1:1.

If you accept that you only do spindle-synched motion in back-gear
then you don't need to do much in HAL.

-- 
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] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/21/2020 10:15 AM, Matthew Herd wrote:

Ahh, so I do use limit switches and a homing routine.  So it’s homing to the 
same position (plus or minus a few thousandths or so).


So, use the # key to show machine coordinates, and then move 
the Z to the safe limits of travel, and note the Z values.  
Then, put these values into the .ini file for MAX_LIMIT and 
MIN_LIMIT.  Then, try to jog beyond those limits and observe 
if the machine makes a controlled stop at those points.  If 
so, you now have the soft limits set right.  Then, try the 
G33.1 again and see if the issue still happens.


Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/21/2020 10:14 AM, Matthew Herd wrote:

The ppmc.0.encoder.03.index pin is something I can halscope easily enough.  I 
was having a little trouble getting used to the halscope interface, and without 
a signal that I know will repeat every revolution, it’s hard to be sure you’re 
not just missing it with your scope parameters.
Well, the way the index pin works, it will stay true until 
read, so it will always be one sample wide.

I’m sure the machine is homed because I tried to run G33.1 and it wouldn’t run 
the command with the machine un-homed.  I can’t say with certainty I have 
enough travel but I do have far more travel than was being used.
OK, if true, then that kills the only idea I had.  But, the 
index function of the encoder would NOT have caused the 
crazy results you showed in the video.  Maybe some halscope 
traces of the G33.1

would make what happened more obvious.

Note that Z moving downward is a -Z move.

Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

When I installed the spindle encoder, I used a shaft at the top of the head.  
Due to my failure to investigate more fully, it turns out that it’s geared 1:1 
with the spindle (but is not a part of the spindle).  So when I go into 
backgear, the encoder reads opposite direction and at a different ratio equal 
to the backgear ratio (whatever that is, I’ve never bothered to determine it).  
Fine for running a face mill or fly cutter, but not usable for rigid tapping 
without some HAL to reverse direction and compensate for the ratio change when 
in backgear).  Also, I’ve never gotten automatic spindle speed set up since I 
manually operate the vari-speed drive via push buttons on the head (HAL 
operates the air valves for me).  I also have a +/-10V DAC board to control VFD 
frequency, but have never set that up either.  I’m hoping to get rigid tapping 
working without solving some of these other issues, but if that’s the way it’s 
got to be, then so be it.

> On Jul 21, 2020, at 1:27 PM, andy pugh  wrote:
> 
> On Tue, 21 Jul 2020 at 18:16, Matthew Herd  wrote:
> 
>> Thanks for the insights.  I suspected something along these lines, even if I 
>> might have other problems with noise.  I can confirm, the spindle stops way 
>> too slowly and definitely more than 10 revolutions pass before stopping.  
>> Long story short, I can’t readily run the machine in back gear
> 
> I think that's a story cut too short. Why can't you run the machine in
> back-gear? I really wouldn't anticipate rigid tapping being done
> without 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, 1912
> 
> 
> ___
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tue, 21 Jul 2020 at 18:16, Matthew Herd  wrote:

> Thanks for the insights.  I suspected something along these lines, even if I 
> might have other problems with noise.  I can confirm, the spindle stops way 
> too slowly and definitely more than 10 revolutions pass before stopping.  
> Long story short, I can’t readily run the machine in back gear

I think that's a story cut too short. Why can't you run the machine in
back-gear? I really wouldn't anticipate rigid tapping being done
without 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, 1912


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

Hi Rob,

Thanks for the insights.  I suspected something along these lines, even if I 
might have other problems with noise.  I can confirm, the spindle stops way too 
slowly and definitely more than 10 revolutions pass before stopping.  Long 
story short, I can’t readily run the machine in back gear and the slowest I can 
go at 60Hz is 560 RPM without backgear.  I’ll play a bit more with how quickly 
I can stop the spindle with a braking resistor or I’ll attempt to get the HAL 
file to engage the mechanical brake to help transition faster.  Nonetheless, 10 
revolutions seems fairly ambitious based on my best guess of how long it might 
take to stop the spindle even with a braking resistor.That’s about 1 
second, but should be achievable.  Currently the VFD is configured based on the 
fastest stop time for max RPM, and there doesn’t seem to be a way to decrease 
stop time for different inertial loads (i.e. lower gear ratios/spindle speeds). 
 However, I understand that the braking resistor should decrease stop time by 
approximately an order of magnitude based on some reading I did yesterday.

Thanks!
Matt

> On Jul 21, 2020, at 1:00 PM, Robert Ellenberg  wrote:
> 
> Based on the videos and your descriptions of the behavior, you may be
> running into a TP issue I've seen (in simulation) with very sluggish
> spindles or very high spindle speeds. Here's what I think is going on:
> 
>   1. The rigid tapping cycle allows a hard-coded 10 revolutions
>   
>   of overtravel beyond the nominal bottom of the hole when reversing
>   direction.
>   2. The spindle starts reversing direction only after the Z axis has
>   reached the bottom, so the spindle has to be able to stop in 10 revolutions
>   to stay within the budgeted overtravel.
>   3. If the TP hits the end of the overtravel, it prematurely declares the
>   motion to be complete and stops following the spindle motion.
> 
> Do you still see this behavior if you run the spindle slower? Your spindle
> seems to take a long time to reverse, so at high speeds you may be hitting
> this limit.
> 
> Best,
> Rob
> 
> 
> On Tue, Jul 21, 2020 at 11:18 AM Matthew Herd  wrote:
> 
>> Ahh, so I do use limit switches and a homing routine.  So it’s homing to
>> the same position (plus or minus a few thousandths or so).
>> 
>>> On Jul 21, 2020, at 11:07 AM, Jon Elson  wrote:
>>> 
>>> On 07/21/2020 04:20 AM, andy pugh wrote:
 On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:

> We are not looking for noise, we are looking for spurious encoder
>> count resets.
 But, thinking further, even if there _is_ noise on the index line, the
 encoder counter should ignore it. It ignores all the _real_ indexes
 unless index-enable is set true in HAL.

>>> Yes, the only thing I can think of is he's hitting his soft limits. Over
>> time, starting and stopping LinuxCNC,
>>> without homing, the machine limits will drift.  If you have rational
>> limits in the .ini file, you will eventually reach the end of them and have
>> really strange behavior.  it can be fixed by homing in a safe position,
>>> but best to put in home switches and actually home the machine to a
>> repeatable position every time.
>>> 
>>> 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
>> 
> 
> ___
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg  wrote:

>1. The rigid tapping cycle allows a hard-coded 10 revolutions
>
>of overtravel beyond the nominal bottom of the hole when reversing
>direction.

That feels like there should be an error message.

"Maximum rigid tapping limit exceeded. And furthermore I have just
broken your tap"

-- 
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] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Robert Ellenberg

Based on the videos and your descriptions of the behavior, you may be
running into a TP issue I've seen (in simulation) with very sluggish
spindles or very high spindle speeds. Here's what I think is going on:

   1. The rigid tapping cycle allows a hard-coded 10 revolutions

   of overtravel beyond the nominal bottom of the hole when reversing
   direction.
   2. The spindle starts reversing direction only after the Z axis has
   reached the bottom, so the spindle has to be able to stop in 10 revolutions
   to stay within the budgeted overtravel.
   3. If the TP hits the end of the overtravel, it prematurely declares the
   motion to be complete and stops following the spindle motion.

Do you still see this behavior if you run the spindle slower? Your spindle
seems to take a long time to reverse, so at high speeds you may be hitting
this limit.

Best,
Rob

On Tue, Jul 21, 2020 at 11:18 AM Matthew Herd  wrote:

> Ahh, so I do use limit switches and a homing routine.  So it’s homing to
> the same position (plus or minus a few thousandths or so).
>
> > On Jul 21, 2020, at 11:07 AM, Jon Elson  wrote:
> >
> > On 07/21/2020 04:20 AM, andy pugh wrote:
> >> On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:
> >>
> >>> We are not looking for noise, we are looking for spurious encoder
> count resets.
> >> But, thinking further, even if there _is_ noise on the index line, the
> >> encoder counter should ignore it. It ignores all the _real_ indexes
> >> unless index-enable is set true in HAL.
> >>
> > Yes, the only thing I can think of is he's hitting his soft limits. Over
> time, starting and stopping LinuxCNC,
> > without homing, the machine limits will drift.  If you have rational
> limits in the .ini file, you will eventually reach the end of them and have
> really strange behavior.  it can be fixed by homing in a safe position,
> > but best to put in home switches and actually home the machine to a
> repeatable position every time.
> >
> > 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
>

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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

Ahh, so I do use limit switches and a homing routine.  So it’s homing to the 
same position (plus or minus a few thousandths or so).

> On Jul 21, 2020, at 11:07 AM, Jon Elson  wrote:
> 
> On 07/21/2020 04:20 AM, andy pugh wrote:
>> On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:
>> 
>>> We are not looking for noise, we are looking for spurious encoder count 
>>> resets.
>> But, thinking further, even if there _is_ noise on the index line, the
>> encoder counter should ignore it. It ignores all the _real_ indexes
>> unless index-enable is set true in HAL.
>> 
> Yes, the only thing I can think of is he's hitting his soft limits. Over 
> time, starting and stopping LinuxCNC,
> without homing, the machine limits will drift.  If you have rational limits 
> in the .ini file, you will eventually reach the end of them and have really 
> strange behavior.  it can be fixed by homing in a safe position,
> but best to put in home switches and actually home the machine to a 
> repeatable position every time.
> 
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

The ppmc.0.encoder.03.index pin is something I can halscope easily enough.  I 
was having a little trouble getting used to the halscope interface, and without 
a signal that I know will repeat every revolution, it’s hard to be sure you’re 
not just missing it with your scope parameters.

I’m sure the machine is homed because I tried to run G33.1 and it wouldn’t run 
the command with the machine un-homed.  I can’t say with certainty I have 
enough travel but I do have far more travel than was being used.

I’ll take a look at the machine grounding and may re-wire some of it this 
week/weekend, but I am aware of star grounding.  The only possibility I can 
think of off hand is that I may have created a ground loop through the machine 
by connecting the power cabinet ground bolt to the control cabinet ground bolt 
via a wired connection.  Both cabinets are bolted to the machine so they’re 
also grounded via the machine.  I did the conversion 8 years ago, so I’m a 
little fuzzy on the details of how I ran the grounds.

> On Jul 21, 2020, at 11:04 AM, Jon Elson  wrote:
> 
> On 07/21/2020 04:18 AM, andy pugh wrote:
>> On Tue, 21 Jul 2020 at 01:59, Gene Heskett  wrote:
>> 
 Try halscoping motion.spindle-revs through a G33,1 cycle in air.
>>> halscope hasn't, Andy, by decades, enough bandwidth to register the noise
>>> I'd be looking for.
>> We are not looking for noise, we are looking for spurious encoder count 
>> resets.
>> 
>> If you can't see it in halscope (by looking in the right place) then
>> it can't affect LinuxCNC.
>> 
> Halscope can view this signal through the ppmc.0.encoder.03.index pin.  On 
> the rising edge of the index pulse, a hardware register bit is set.  After 
> the register is read, the bit is cleared.  Viewing this register with 
> Halscope, you should see one pulse per revolution of the spindle.  If you see 
> more, and they appear to be random, then you have a noise issue.
> 
> 
> BUT -- I don't think that is the problem.  Noise on the index would make it 
> impossible to do multi-pass threading, as on a lathe.  But, it should not 
> affect single-pass G33.1 rigid tapping, just that the start angle would be 
> random.  I really think the issue is an un-homed machine that is hitting the 
> soft travel limits.
> 
> What would you rather have the trajectory planner do in this case? Your only 
> choices are to stay in spindle sync and drive the axis off the end of the 
> soft limits, or stop at the limit and break the tap.
> Neither is a good choice.
> 
> Matt should check the MAX_LIMIT and MIN_LIMIT in his .ini file, and then 
> check the machine coordinate position by clicking the "#" key to show the 
> machine coordinates.
> 
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/21/2020 04:20 AM, andy pugh wrote:

On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:


We are not looking for noise, we are looking for spurious encoder count resets.

But, thinking further, even if there _is_ noise on the index line, the
encoder counter should ignore it. It ignores all the _real_ indexes
unless index-enable is set true in HAL.

Yes, the only thing I can think of is he's hitting his soft 
limits. Over time, starting and stopping LinuxCNC,
without homing, the machine limits will drift.  If you have 
rational limits in the .ini file, you will eventually reach 
the end of them and have really strange behavior.  it can be 
fixed by homing in a safe position,
but best to put in home switches and actually home the 
machine to a repeatable position every time.


Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/21/2020 04:18 AM, andy pugh wrote:

On Tue, 21 Jul 2020 at 01:59, Gene Heskett  wrote:


Try halscoping motion.spindle-revs through a G33,1 cycle in air.

halscope hasn't, Andy, by decades, enough bandwidth to register the noise
I'd be looking for.

We are not looking for noise, we are looking for spurious encoder count resets.

If you can't see it in halscope (by looking in the right place) then
it can't affect LinuxCNC.

Halscope can view this signal through the 
ppmc.0.encoder.03.index pin.  On the rising edge of the 
index pulse, a hardware register bit is set.  After the 
register is read, the bit is cleared.  Viewing this register 
with Halscope, you should see one pulse per revolution of 
the spindle.  If you see more, and they appear to be random, 
then you have a noise issue.



BUT -- I don't think that is the problem.  Noise on the 
index would make it impossible to do multi-pass threading, 
as on a lathe.  But, it should not affect single-pass G33.1 
rigid tapping, just that the start angle would be random.  I 
really think the issue is an un-homed machine that is 
hitting the soft travel limits.


What would you rather have the trajectory planner do in this 
case? Your only choices are to stay in spindle sync and 
drive the axis off the end of the soft limits, or stop at 
the limit and break the tap.

Neither is a good choice.

Matt should check the MAX_LIMIT and MIN_LIMIT in his .ini 
file, and then check the machine coordinate position by 
clicking the "#" key to show the machine coordinates.


Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:

> We are not looking for noise, we are looking for spurious encoder count 
> resets.

But, thinking further, even if there _is_ noise on the index line, the
encoder counter should ignore it. It ignores all the _real_ indexes
unless index-enable is set true in HAL.

-- 
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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tue, 21 Jul 2020 at 01:59, Gene Heskett  wrote:

> > Try halscoping motion.spindle-revs through a G33,1 cycle in air.
>
> halscope hasn't, Andy, by decades, enough bandwidth to register the noise
> I'd be looking for.

We are not looking for noise, we are looking for spurious encoder count resets.

If you can't see it in halscope (by looking in the right place) then
it can't affect LinuxCNC.

-- 
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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Monday 20 July 2020 22:14:10 Jon Elson wrote:

> On 07/20/2020 07:43 PM, Gene Heskett wrote:
> > Interesting. I wonder if he accidently fixed an unwanted ground, or
> > made a bad one good doing it?  Murphy is alive and well despite our
> > reward funds.
>
> Yes, he had unwanted grounds (loops) all over the place.
> Actually, he has NO ground, only a neutral, which is
> connected to some 120 V loads.  Clearly not NEC compliant.
>
Ohmy   gawd

> Also, he had the grounds for the servo amps looped all over
> the place, had the signals and  grounds to the servo amps
> following wildly different paths, all sorts of stuff.  I had
> him rewire so the signal and ground
> for the servo amp inputs were bundled together, and logic
> power and enable follow the shortest path.
> He had to rewire the thing at least a dozen times, but it
> eventually cleared up the issues.
>
> I just instinctively know how to wire signals in a
> high-noise environment, so I didn't know how touchy
> things actually were.
>
> One of the shortcuts I took in my servo amps was to not
> isolate the power stage from the logic, and to
> only have one ground, common for both the power stage and
> the logic.

I've had thoughts about that, but with an isolated analog supply for just 
that motor, its not turned out to be a problem at the end of the day.

I use switchers for everything else in both cases The opto on the enable 
line would have made the hoops I've had to jump thru a little easier by 
making it controllable with normal 5 volt pulldown logic. ISTR I've got 
something from sparkfun switching the 12 volts into that interface in 
both of them, works so well I've forgotten what it is. :)  With the 
extra toroids for spindle duty, its runs at room temps.


> I SHOULD have also opto-isolated the enable pin 
> on the servo amp.  So, if you have long wires on that common
> ground, a star connection from the distant motor power
> supply, large voltages will appear on the ground for the
> logic as well.
> That was the basic problem.  I had to have him put a
> terminal block as close to the servo amps as
> possible, so the path from one amp's ground to the other was
> as short as possible.  Then, bundling the PWM, direction and
> ground to the servo amps finished the fix.
>
> I've sold 124 of these PWM servo controllers, and NEVER run
> into a problem like this.  I've had a few people run into
> minor noise issues, but this one really had me going in circles.
>
Its a great controller Jon. With suitable toroids, and a suitable current 
limiting resistor, mine are both set at around 17 amps, its best 
described as bullet-proof, you simply cannot make it hurt itself. If I 
have a PMDC motor to control, no discussion, you get the order.
> Jon
>
>
> ___
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/20/2020 07:43 PM, Gene Heskett wrote:


Interesting. I wonder if he accidently fixed an unwanted ground, or made
a bad one good doing it?  Murphy is alive and well despite our reward
funds.


Yes, he had unwanted grounds (loops) all over the place.  
Actually, he has NO ground, only a neutral, which is 
connected to some 120 V loads.  Clearly not NEC compliant.


Also, he had the grounds for the servo amps looped all over 
the place, had the signals and  grounds to the servo amps 
following wildly different paths, all sorts of stuff.  I had 
him rewire so the signal and ground
for the servo amp inputs were bundled together, and logic 
power and enable follow the shortest path.
He had to rewire the thing at least a dozen times, but it 
eventually cleared up the issues.


I just instinctively know how to wire signals in a 
high-noise environment, so I didn't know how touchy

things actually were.

One of the shortcuts I took in my servo amps was to not 
isolate the power stage from the logic, and to
only have one ground, common for both the power stage and 
the logic.  I SHOULD have also opto-isolated the enable pin 
on the servo amp.  So, if you have long wires on that common 
ground, a star connection from the distant motor power 
supply, large voltages will appear on the ground for the 
logic as well.
That was the basic problem.  I had to have him put a 
terminal block as close to the servo amps as
possible, so the path from one amp's ground to the other was 
as short as possible.  Then, bundling the PWM, direction and 
ground to the servo amps finished the fix.


I've sold 124 of these PWM servo controllers, and NEVER run 
into a problem like this.  I've had a few people run into 
minor noise issues, but this one really had me going in circles.


Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On Monday 20 July 2020 20:39:38 andy pugh wrote:

> On Tue, 21 Jul 2020 at 01:33, Matthew Herd  wrote:
> > Good thoughts Jon and Gene, I was thinking the same thing.  The
> > count when running the encoder diagnostics keeps resetting to 0.  So
> > I will drag out my scope and see what I find.
>
> I think you will have a lot more luck with halscope than real-scope
> here.
>
> Try halscoping motion.spindle-revs through a G33,1 cycle in air.

halscope hasn't, Andy, by decades, enough bandwidth to register the noise 
I'd be looking for. 3 to 10 nanosecond stuff. That is right at the 
bandwidth limit of my digital, and approaching the limits of my elderly 
Hitachi V-1065 which is still showing me a usable signal at 180 MHZ. 
Mesa cards see it well.  No clue how fast Matthews stuff is though. 

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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Monday 20 July 2020 20:30:59 Matthew Herd wrote:

> Good thoughts Jon and Gene, I was thinking the same thing.  The count
> when running the encoder diagnostics keeps resetting to 0.  So I will
> drag out my scope and see what I find.  Hopefully a little checking of
> the grounds plus a braking resistor and I’ll be able to rigid tap. 
> I’ve got a project coming up that involves tapping about a thousand
> 6-32 holes, hence this experiment.  It’d be a real hassle to do it by
> hand.  At any rate, I probably won’t get to it until Wednesday.
>
Be sure and let us know what you find Matthew.

> > On Jul 20, 2020, at 8:04 PM, Gene Heskett 
> > wrote:
> >
> > On Monday 20 July 2020 18:57:03 Jon Elson wrote:
> >> On 07/20/2020 05:27 PM, Matthew Herd wrote:
> >>> Working through Jon’s suggestions, the answers to his questions
> >>> are as follows.  Also, I’m running version 2.7.11 if that helps. 
> >>> No internet in my shop means it gets infrequent updates.
> >>>
> >>> Running the universal stepper diagnostics program with the command
> >>> sudo .univstepdiags 378 bus indicates board 0 is firmware version
> >>> 3. No board 1 is shown, boards 2 and 4-f are "No Board" and board
> >>> 3 is "Unknown."
> >>>
> >>> Running the command sudo .univstepdiags 378 indexres 3 (from a
> >>> forum post) gives me +517.00, +517.00, +517.00, and a jittery
> >>> +0.000/+/-1.000 that seems to increase/decrease (depending on
> >>> CW/CCW rotation) then go back to zero as fast as I turn the
> >>> spindle.  I can see numbers greater than 1, but they flash back to
> >>> zero within a fraction of a second and keep jittering.
> >>
> >> Yes, that is normal.  The position count is being reset to
> >> zero each time the encoder passes the index position.
> >> Turning it by hand, you might want to see it count up to
> >> whatever your quadrature counts/rev is, before it resets.
> >> If it keeps resetting to zero with just a little rotation,
> >> then you are getting pulses on the Z channel that is
> >> resetting the counter in between the index positions.  That
> >> would be a hardware issue with the encoder or encoder wiring.
> >>
> >>> The encoder scale on axis 03 is "setp ppmc.0.encoder.03.scale
> >>> 2048" which is consistent with a 512 CPR encoder in quadrature. 
> >>> That’s what I’ve got installed.
> >>>
> >>> the connection to LinuxCNC looks like this:
> >>> newsig spindle-index-en bit
> >>> linkps motion.spindle-index-enable => spindle-index-en
> >>> linksp spindle-index-en => ppmc.0.encoder.03.index-enable
> >>>
> >>> AND
> >>>
> >>> newsig spindle-pos float
> >>> linkps ppmc.0.encoder.03.position => spindle-pos
> >>> linksp spindle-pos => motion.spindle-revs
> >>>
> >>> At 3600 RPM (as reported from the encoder) the velocity is 60.  At
> >>> 3600 RPM CCW, the velocity is -60.  I don’t readily have a means
> >>> of verifying actual RPM, but the dial on the vari-speed head seems
> >>> to read lower than actual RPMs, though I understand this is
> >>> consistent with a worn varispeed drive.  I also confirmed that one
> >>> revolution appears to correspond to one increase/decrease of the
> >>> ppmc.0.encoder.03.position as displayed by Hal Meter.  I took care
> >>> to rotate it one revolution as closely as I could manage and the
> >>> results checked out.
> >>>
> >>> Regarding the index, I probed it with a meter and found the
> >>> position at which it triggers.  I can confirm that it should work
> >>> as it showed 4.64V when at the index position.
> >>>
> >>> See below for my HAL files:
> >>>
> >>> univstep_motion.hal:  https://paste.ubuntu.com/p/h66KJZx3hC/
> >>>  univstep_io.hal:
> >>> https://paste.ubuntu.com/p/gMNkMwKDVw/
> >>>  univstep_load.hal:
> >>> https://paste.ubuntu.com/p/d36HgfwZ5Z/
> >>>  univstep_servo.hal:
> >>> https://paste.ubuntu.com/p/wyb6JPX7ts/
> >>>  xhc-hb04.hal:
> >>> https://paste.ubuntu.com/p/w9mNn8hSdT/
> >>>  pycp_panel.hal:
> >>> https://paste.ubuntu.com/p/dVNwxHWJD2/
> >>> 
> >>>
> >>> I realize most of these are not likely to be relevant, but I’ve
> >>> included them anyway.  The encoder is connected in the
> >>> univstep_motion.hal file.
> >>>
> >>> Also, re-testing the behavior, I seem to get two different
> >>> outcomes when I run G33.1.  First error behavior is shown here:
> >>> https://youtu.be/GMspKB5ZkoQ  and
> >>> the second error behavior is shown here: 
> >>> https://youtu.be/HJBOtFtXF5o .  In
> >>> the first behavior (which appears to be random, but I didn’t
> >>> restart axis repeatedly to test), the spindle is running before
> >>> the G33.1 command.  It feeds downward past the commanded 0.5" to
> >>> 0.8125 or so, then stops Z motion while it decelerates.  Then it
> >>> reverses, spins up to

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On Monday 20 July 2020 20:30:30 Jon Elson wrote:

> On 07/20/2020 07:04 PM, Gene Heskett wrote:
> > I think I'd drag out one of my 100+ MHZ scopes and look for noise of
> > the type one might get from lack of a single point ground.
>
> Right.  if the indexres test of the diagnostics shows the
> position resetting multiple times/rev
> (may only happen when spindle drive is on) then there is
> noise on the Z.  The A and B have digital filtering that
> only accepts valid state transitions of the quadrature wave,
> that hides a lot of really nasty garbage that some systems
> have.  There is no way to digital filter the index pulse, it
> is edge-triggered, and a 10 ns pulse could trigger it.
>
> But, noise on the index will only affect the place where the
> spindle sync motion starts.  Once the spindle encoder senses
> an index pulse, then everything is counted from there.  So,
> a noisy index pulse should NOT cause the Z axis to behave as
> the videos show.  OHH, wait a minute!  One thing that COULD
> cause this behavior is if the move exceeded the Z soft
> limits.  Z would freeze at the most extended part, and then
> pull back when the spindle count brought the position back
> within the soft limits.  That's exactly what it did in the
> first video.
>
> So, Matt should check what his Z soft limits are set to in
> the .ini file, and then home the axis so
> it won't be exceeding the soft limits.

I've not encountered that particular symptom, so didn'tthink of it, but 
you obviously have.

> Having just spent about 3 weeks solving a ground loop issue
> on a PWM servo system remotely, they
> can cause an amazing array of crazy symptoms.  Having the
> user shorten up all the wiring fixed it.

Interesting. I wonder if he accidently fixed an unwanted ground, or made 
a bad one good doing it?  Murphy is alive and well despite our reward 
funds.

> Jon
>
>
> ___
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Tue, 21 Jul 2020 at 01:33, Matthew Herd  wrote:
>
> Good thoughts Jon and Gene, I was thinking the same thing.  The count when 
> running the encoder diagnostics keeps resetting to 0.  So I will drag out my 
> scope and see what I find.

I think you will have a lot more luck with halscope than real-scope here.

Try halscoping motion.spindle-revs through a G33,1 cycle in air.

-- 
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] Problem with Rigid Tapping on USC Equipped Bridgeport

I had a suspicion that the very long deceleration times might have exposed a 
bug in the software.  I doubt I’m exceeding soft limits, but I’ll run some more 
tests when I play with it next.

> On Jul 20, 2020, at 8:30 PM, Jon Elson  wrote:
> 
> On 07/20/2020 07:04 PM, Gene Heskett wrote:
>> 
>> I think I'd drag out one of my 100+ MHZ scopes and look for noise of the
>> type one might get from lack of a single point ground.
> Right.  if the indexres test of the diagnostics shows the position resetting 
> multiple times/rev
> (may only happen when spindle drive is on) then there is noise on the Z.  The 
> A and B have digital filtering that only accepts valid state transitions of 
> the quadrature wave, that hides a lot of really nasty garbage that some 
> systems have.  There is no way to digital filter the index pulse, it is 
> edge-triggered, and a 10 ns pulse could trigger it.
> 
> But, noise on the index will only affect the place where the spindle sync 
> motion starts.  Once the spindle encoder senses an index pulse, then 
> everything is counted from there.  So, a noisy index pulse should NOT cause 
> the Z axis to behave as the videos show.  OHH, wait a minute!  One thing that 
> COULD cause this behavior is if the move exceeded the Z soft limits.  Z would 
> freeze at the most extended part, and then pull back when the spindle count 
> brought the position back within the soft limits.  That's exactly what it did 
> in the first video.
> 
> So, Matt should check what his Z soft limits are set to in the .ini file, and 
> then home the axis so
> it won't be exceeding the soft limits.
> 
> Having just spent about 3 weeks solving a ground loop issue on a PWM servo 
> system remotely, they
> can cause an amazing array of crazy symptoms.  Having the user shorten up all 
> the wiring fixed it.
> 
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

Good thoughts Jon and Gene, I was thinking the same thing.  The count when 
running the encoder diagnostics keeps resetting to 0.  So I will drag out my 
scope and see what I find.  Hopefully a little checking of the grounds plus a 
braking resistor and I’ll be able to rigid tap.  I’ve got a project coming up 
that involves tapping about a thousand 6-32 holes, hence this experiment.  It’d 
be a real hassle to do it by hand.  At any rate, I probably won’t get to it 
until Wednesday.

> On Jul 20, 2020, at 8:04 PM, Gene Heskett  wrote:
> 
> On Monday 20 July 2020 18:57:03 Jon Elson wrote:
> 
>> On 07/20/2020 05:27 PM, Matthew Herd wrote:
>>> Working through Jon’s suggestions, the answers to his questions are
>>> as follows.  Also, I’m running version 2.7.11 if that helps.  No
>>> internet in my shop means it gets infrequent updates.
>>> 
>>> Running the universal stepper diagnostics program with the command
>>> sudo .univstepdiags 378 bus indicates board 0 is firmware version 3.
>>> No board 1 is shown, boards 2 and 4-f are "No Board" and board 3 is
>>> "Unknown."
>>> 
>>> Running the command sudo .univstepdiags 378 indexres 3 (from a forum
>>> post) gives me +517.00, +517.00, +517.00, and a jittery
>>> +0.000/+/-1.000 that seems to increase/decrease (depending on CW/CCW
>>> rotation) then go back to zero as fast as I turn the spindle.  I can
>>> see numbers greater than 1, but they flash back to zero within a
>>> fraction of a second and keep jittering.
>> 
>> Yes, that is normal.  The position count is being reset to
>> zero each time the encoder passes the index position.
>> Turning it by hand, you might want to see it count up to
>> whatever your quadrature counts/rev is, before it resets.
>> If it keeps resetting to zero with just a little rotation,
>> then you are getting pulses on the Z channel that is
>> resetting the counter in between the index positions.  That
>> would be a hardware issue with the encoder or encoder wiring.
>> 
>>> The encoder scale on axis 03 is "setp ppmc.0.encoder.03.scale 2048"
>>> which is consistent with a 512 CPR encoder in quadrature.  That’s
>>> what I’ve got installed.
>>> 
>>> the connection to LinuxCNC looks like this:
>>> newsig spindle-index-en bit
>>> linkps motion.spindle-index-enable => spindle-index-en
>>> linksp spindle-index-en => ppmc.0.encoder.03.index-enable
>>> 
>>> AND
>>> 
>>> newsig spindle-pos float
>>> linkps ppmc.0.encoder.03.position => spindle-pos
>>> linksp spindle-pos => motion.spindle-revs
>>> 
>>> At 3600 RPM (as reported from the encoder) the velocity is 60.  At
>>> 3600 RPM CCW, the velocity is -60.  I don’t readily have a means of
>>> verifying actual RPM, but the dial on the vari-speed head seems to
>>> read lower than actual RPMs, though I understand this is consistent
>>> with a worn varispeed drive.  I also confirmed that one revolution
>>> appears to correspond to one increase/decrease of the
>>> ppmc.0.encoder.03.position as displayed by Hal Meter.  I took care
>>> to rotate it one revolution as closely as I could manage and the
>>> results checked out.
>>> 
>>> Regarding the index, I probed it with a meter and found the position
>>> at which it triggers.  I can confirm that it should work as it
>>> showed 4.64V when at the index position.
>>> 
>>> See below for my HAL files:
>>> 
>>> univstep_motion.hal:  https://paste.ubuntu.com/p/h66KJZx3hC/
>>>  univstep_io.hal: 
>>> https://paste.ubuntu.com/p/gMNkMwKDVw/
>>>  univstep_load.hal: 
>>> https://paste.ubuntu.com/p/d36HgfwZ5Z/
>>>  univstep_servo.hal: 
>>> https://paste.ubuntu.com/p/wyb6JPX7ts/
>>>  xhc-hb04.hal: 
>>> https://paste.ubuntu.com/p/w9mNn8hSdT/
>>>  pycp_panel.hal: 
>>> https://paste.ubuntu.com/p/dVNwxHWJD2/
>>> 
>>> 
>>> I realize most of these are not likely to be relevant, but I’ve
>>> included them anyway.  The encoder is connected in the
>>> univstep_motion.hal file.
>>> 
>>> Also, re-testing the behavior, I seem to get two different outcomes
>>> when I run G33.1.  First error behavior is shown here: 
>>> https://youtu.be/GMspKB5ZkoQ  and the
>>> second error behavior is shown here:  https://youtu.be/HJBOtFtXF5o
>>> .  In the first behavior (which
>>> appears to be random, but I didn’t restart axis repeatedly to test),
>>> the spindle is running before the G33.1 command.  It feeds downward
>>> past the commanded 0.5" to 0.8125 or so, then stops Z motion while
>>> it decelerates.  Then it reverses, spins up to speed, and retracts
>>> in what appears to be synchronized motion.  The second error appears
>>> to do the same until it hangs somewhere after reversing.  It also
>>> won’t respond to MDI commands.  I had to go to manual mode and click
>>> the spindle stop button to get

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/20/2020 07:04 PM, Gene Heskett wrote:


I think I'd drag out one of my 100+ MHZ scopes and look for noise of the
type one might get from lack of a single point ground.
Right.  if the indexres test of the diagnostics shows the 
position resetting multiple times/rev
(may only happen when spindle drive is on) then there is 
noise on the Z.  The A and B have digital filtering that 
only accepts valid state transitions of the quadrature wave, 
that hides a lot of really nasty garbage that some systems 
have.  There is no way to digital filter the index pulse, it 
is edge-triggered, and a 10 ns pulse could trigger it.


But, noise on the index will only affect the place where the 
spindle sync motion starts.  Once the spindle encoder senses 
an index pulse, then everything is counted from there.  So, 
a noisy index pulse should NOT cause the Z axis to behave as 
the videos show.  OHH, wait a minute!  One thing that COULD 
cause this behavior is if the move exceeded the Z soft 
limits.  Z would freeze at the most extended part, and then 
pull back when the spindle count brought the position back 
within the soft limits.  That's exactly what it did in the 
first video.


So, Matt should check what his Z soft limits are set to in 
the .ini file, and then home the axis so

it won't be exceeding the soft limits.

Having just spent about 3 weeks solving a ground loop issue 
on a PWM servo system remotely, they
can cause an amazing array of crazy symptoms.  Having the 
user shorten up all the wiring fixed it.


Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On Monday 20 July 2020 18:57:03 Jon Elson wrote:

> On 07/20/2020 05:27 PM, Matthew Herd wrote:
> > Working through Jon’s suggestions, the answers to his questions are
> > as follows.  Also, I’m running version 2.7.11 if that helps.  No
> > internet in my shop means it gets infrequent updates.
> >
> > Running the universal stepper diagnostics program with the command
> > sudo .univstepdiags 378 bus indicates board 0 is firmware version 3.
> >  No board 1 is shown, boards 2 and 4-f are "No Board" and board 3 is
> > "Unknown."
> >
> > Running the command sudo .univstepdiags 378 indexres 3 (from a forum
> > post) gives me +517.00, +517.00, +517.00, and a jittery
> > +0.000/+/-1.000 that seems to increase/decrease (depending on CW/CCW
> > rotation) then go back to zero as fast as I turn the spindle.  I can
> > see numbers greater than 1, but they flash back to zero within a
> > fraction of a second and keep jittering.
>
> Yes, that is normal.  The position count is being reset to
> zero each time the encoder passes the index position.
> Turning it by hand, you might want to see it count up to
> whatever your quadrature counts/rev is, before it resets.
> If it keeps resetting to zero with just a little rotation,
> then you are getting pulses on the Z channel that is
> resetting the counter in between the index positions.  That
> would be a hardware issue with the encoder or encoder wiring.
>
> > The encoder scale on axis 03 is "setp ppmc.0.encoder.03.scale 2048"
> > which is consistent with a 512 CPR encoder in quadrature.  That’s
> > what I’ve got installed.
> >
> > the connection to LinuxCNC looks like this:
> > newsig spindle-index-en bit
> > linkps motion.spindle-index-enable => spindle-index-en
> > linksp spindle-index-en => ppmc.0.encoder.03.index-enable
> >
> > AND
> >
> > newsig spindle-pos float
> > linkps ppmc.0.encoder.03.position => spindle-pos
> > linksp spindle-pos => motion.spindle-revs
> >
> > At 3600 RPM (as reported from the encoder) the velocity is 60.  At
> > 3600 RPM CCW, the velocity is -60.  I don’t readily have a means of
> > verifying actual RPM, but the dial on the vari-speed head seems to
> > read lower than actual RPMs, though I understand this is consistent
> > with a worn varispeed drive.  I also confirmed that one revolution
> > appears to correspond to one increase/decrease of the
> > ppmc.0.encoder.03.position as displayed by Hal Meter.  I took care
> > to rotate it one revolution as closely as I could manage and the
> > results checked out.
> >
> > Regarding the index, I probed it with a meter and found the position
> > at which it triggers.  I can confirm that it should work as it
> > showed 4.64V when at the index position.
> >
> > See below for my HAL files:
> >
> > univstep_motion.hal:  https://paste.ubuntu.com/p/h66KJZx3hC/
> >  univstep_io.hal: 
> > https://paste.ubuntu.com/p/gMNkMwKDVw/
> >  univstep_load.hal: 
> > https://paste.ubuntu.com/p/d36HgfwZ5Z/
> >  univstep_servo.hal: 
> > https://paste.ubuntu.com/p/wyb6JPX7ts/
> >  xhc-hb04.hal: 
> > https://paste.ubuntu.com/p/w9mNn8hSdT/
> >  pycp_panel.hal: 
> > https://paste.ubuntu.com/p/dVNwxHWJD2/
> > 
> >
> > I realize most of these are not likely to be relevant, but I’ve
> > included them anyway.  The encoder is connected in the
> > univstep_motion.hal file.
> >
> > Also, re-testing the behavior, I seem to get two different outcomes
> > when I run G33.1.  First error behavior is shown here: 
> > https://youtu.be/GMspKB5ZkoQ  and the
> > second error behavior is shown here:  https://youtu.be/HJBOtFtXF5o
> > .  In the first behavior (which
> > appears to be random, but I didn’t restart axis repeatedly to test),
> > the spindle is running before the G33.1 command.  It feeds downward
> > past the commanded 0.5" to 0.8125 or so, then stops Z motion while
> > it decelerates.  Then it reverses, spins up to speed, and retracts
> > in what appears to be synchronized motion.  The second error appears
> > to do the same until it hangs somewhere after reversing.  It also
> > won’t respond to MDI commands.  I had to go to manual mode and click
> > the spindle stop button to get it to respond.
>
> I have no idea what is causing this.  You might set up
> halscope to trigger on the spindle reverse command and show
> Z velocity and spindle encoder position.  The G33.1 is
> supposed to follow the encoder count until the command has
> completed.  Clearly, it follows it for a while, then stops
> following it, and then in the first video it eventually
> follows it in the reverse direction.
>
> I did not see anything wrong in your hal files.
>
> Jon

I think I'd drag out one of my 100+ MHZ scopes and look for noise of the 
type one might get from

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On 07/20/2020 05:27 PM, Matthew Herd wrote:

Working through Jon’s suggestions, the answers to his questions are as follows.
Also, I’m running version 2.7.11 if that helps. No internet in my shop means
it gets infrequent updates.

Running the universal stepper diagnostics program with the command sudo .univstepdiags 378 bus
indicates board 0 is firmware version 3. No board 1 is shown, boards 2 and 4-f are "No
Board" and board 3 is "Unknown."

Running the command sudo .univstepdiags 378 indexres 3 (from a forum post)
gives me +517.00, +517.00, +517.00, and a jittery +0.000/+/-1.000 that seems to
increase/decrease (depending on CW/CCW rotation) then go back to zero as fast
as I turn the spindle. I can see numbers greater than 1, but they flash back
to zero within a fraction of a second and keep jittering.
Yes, that is normal. The position count is being reset to
zero each time the encoder passes the index position.
Turning it by hand, you might want to see it count up to
whatever your quadrature counts/rev is, before it resets.
If it keeps resetting to zero with just a little rotation,
then you are getting pulses on the Z channel that is
resetting the counter in between the index positions. That
would be a hardware issue with the encoder or encoder wiring.

The encoder scale on axis 03 is "setp ppmc.0.encoder.03.scale 2048" which is
consistent with a 512 CPR encoder in quadrature. That’s what I’ve got installed.

the connection to LinuxCNC looks like this:
newsig spindle-index-en bit
linkps motion.spindle-index-enable => spindle-index-en
linksp spindle-index-en => ppmc.0.encoder.03.index-enable

AND

newsig spindle-pos float
linkps ppmc.0.encoder.03.position => spindle-pos
linksp spindle-pos => motion.spindle-revs

At 3600 RPM (as reported from the encoder) the velocity is 60. At 3600 RPM
CCW, the velocity is -60. I don’t readily have a means of verifying actual
RPM, but the dial on the vari-speed head seems to read lower than actual RPMs,
though I understand this is consistent with a worn varispeed drive. I also
confirmed that one revolution appears to correspond to one increase/decrease of
the ppmc.0.encoder.03.position as displayed by Hal Meter. I took care to
rotate it one revolution as closely as I could manage and the results checked
out.

Regarding the index, I probed it with a meter and found the position at which
it triggers. I can confirm that it should work as it showed 4.64V when at the
index position.

See below for my HAL files:

univstep_motion.hal: https://paste.ubuntu.com/p/h66KJZx3hC/

univstep_io.hal: https://paste.ubuntu.com/p/gMNkMwKDVw/

univstep_load.hal: https://paste.ubuntu.com/p/d36HgfwZ5Z/

univstep_servo.hal: https://paste.ubuntu.com/p/wyb6JPX7ts/

xhc-hb04.hal: https://paste.ubuntu.com/p/w9mNn8hSdT/

pycp_panel.hal: https://paste.ubuntu.com/p/dVNwxHWJD2/

I realize most of these are not likely to be relevant, but I’ve included them
anyway. The encoder is connected in the univstep_motion.hal file.

Also, re-testing the behavior, I seem to get two different outcomes when I run G33.1. First
error behavior is shown here: https://youtu.be/GMspKB5ZkoQ
and the second error behavior is shown here: https://youtu.be/HJBOtFtXF5o
. In the first behavior (which appears to be random, but I
didn’t restart axis repeatedly to test), the spindle is running before the G33.1 command. It
feeds downward past the commanded 0.5" to 0.8125 or so, then stops Z motion while it
decelerates. Then it reverses, spins up to speed, and retracts in what appears to be
synchronized motion. The second error appears to do the same until it hangs somewhere after
reversing. It also won’t respond to MDI commands. I had to go to manual mode and click the
spindle stop button to get it to respond.

I have no idea what is causing this. You might set up
halscope to trigger on the spindle reverse command and show
Z velocity and spindle encoder position. The G33.1 is
supposed to follow the encoder count until the command has
completed. Clearly, it follows it for a while, then stops
following it, and then in the first video it eventually
follows it in the reverse direction.

I did not see anything wrong in your hal files.

Jon

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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

Working through Jon’s suggestions, the answers to his questions are as follows. 
 Also, I’m running version 2.7.11 if that helps.  No internet in my shop means 
it gets infrequent updates.  

Running the universal stepper diagnostics program with the command sudo 
.univstepdiags 378 bus indicates board 0 is firmware version 3.  No board 1 is 
shown, boards 2 and 4-f are "No Board" and board 3 is "Unknown."

Running the command sudo .univstepdiags 378 indexres 3 (from a forum post) 
gives me +517.00, +517.00, +517.00, and a jittery +0.000/+/-1.000 that seems to 
increase/decrease (depending on CW/CCW rotation) then go back to zero as fast 
as I turn the spindle.  I can see numbers greater than 1, but they flash back 
to zero within a fraction of a second and keep jittering.

The encoder scale on axis 03 is "setp ppmc.0.encoder.03.scale 2048" which is 
consistent with a 512 CPR encoder in quadrature.  That’s what I’ve got 
installed.

the connection to LinuxCNC looks like this:
newsig spindle-index-en bit
linkps motion.spindle-index-enable => spindle-index-en
linksp spindle-index-en => ppmc.0.encoder.03.index-enable

AND

newsig spindle-pos float
linkps ppmc.0.encoder.03.position => spindle-pos
linksp spindle-pos => motion.spindle-revs

At 3600 RPM (as reported from the encoder) the velocity is 60.  At 3600 RPM 
CCW, the velocity is -60.  I don’t readily have a means of verifying actual 
RPM, but the dial on the vari-speed head seems to read lower than actual RPMs, 
though I understand this is consistent with a worn varispeed drive.  I also 
confirmed that one revolution appears to correspond to one increase/decrease of 
the ppmc.0.encoder.03.position as displayed by Hal Meter.  I took care to 
rotate it one revolution as closely as I could manage and the results checked 
out.

Regarding the index, I probed it with a meter and found the position at which 
it triggers.  I can confirm that it should work as it showed 4.64V when at the 
index position.

See below for my HAL files:

univstep_motion.hal:  https://paste.ubuntu.com/p/h66KJZx3hC/ 

univstep_io.hal:  https://paste.ubuntu.com/p/gMNkMwKDVw/ 

univstep_load.hal:  https://paste.ubuntu.com/p/d36HgfwZ5Z/ 

univstep_servo.hal:  https://paste.ubuntu.com/p/wyb6JPX7ts/ 

xhc-hb04.hal:  https://paste.ubuntu.com/p/w9mNn8hSdT/ 

pycp_panel.hal:  https://paste.ubuntu.com/p/dVNwxHWJD2/ 

I realize most of these are not likely to be relevant, but I’ve included them 
anyway.  The encoder is connected in the univstep_motion.hal file.

Also, re-testing the behavior, I seem to get two different outcomes when I run 
G33.1.  First error behavior is shown here:  https://youtu.be/GMspKB5ZkoQ 
 and the second error behavior is shown here:  
https://youtu.be/HJBOtFtXF5o .  In the first 
behavior (which appears to be random, but I didn’t restart axis repeatedly to 
test), the spindle is running before the G33.1 command.  It feeds downward past 
the commanded 0.5" to 0.8125 or so, then stops Z motion while it decelerates.  
Then it reverses, spins up to speed, and retracts in what appears to be 
synchronized motion.  The second error appears to do the same until it hangs 
somewhere after reversing.  It also won’t respond to MDI commands.  I had to go 
to manual mode and click the spindle stop button to get it to respond.

Thanks!
Matt

> On Jul 20, 2020, at 12:47 PM, Jon Elson  wrote:
> 
> On 07/20/2020 10:51 AM, Matthew Herd wrote:
>> Hi Andy,
>> 
>> "But does it also count negative in reverse?"
>> Yes, counts go up and down, depending on the direction I turn the spindle, 
>> either manually or under power.
>> 
>> 
> Hmmm, the mystery deepens!  Well, it may be that the encoder index-enable 
> connection in hal is not set up correctly.  Although, it seems that in that 
> case it would never begin the Z move.
> 
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Monday 20 July 2020 15:28:22 Jon Elson wrote:

> On 07/20/2020 01:59 PM, Gene Heskett wrote:
> > Jon's (Pico Systems) pwm-servo is a full 4 quadrant controller,
> > without a brakiing R, it will charge the caps in the supply from 125
> > to about 160 but turns my 1 hp PMDC motor on my GO704 around in
> > about 400 milliseconds.  If your supply is higher than mine, and it
> > probably is, talk to Jon about the higher voltage.
>
> But, he's running an AC motor.

With a vfd? That might need some programming mods in the vfd to slow the 
speed slew, but on my lathe, the max rigid tap revs is under 300, and it 
took a limit3 to slow it so it didn't trip the vfd which is cheap and 
brakeless.  I get about 3 turns of a 40 lb chuck after motion has issued 
the reverse at the bottom of the hole. 200 revs is correspondingly less 
overshoot of coarse.  Put it in backgear and the motors armature inertia 
is even worse at the higher spin speed.  Its not a vfd rated motor.

> Jon
>
>
> ___
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/20/2020 01:59 PM, Gene Heskett wrote:

Jon's (Pico Systems) pwm-servo is a full 4 quadrant controller, without a
brakiing R, it will charge the caps in the supply from 125 to about 160
but turns my 1 hp PMDC motor on my GO704 around in about 400
milliseconds.  If your supply is higher than mine, and it probably is,
talk to Jon about the higher voltage.


But, he's running an AC motor.

Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On Monday 20 July 2020 10:57:30 Matthew Herd wrote:

> Thanks for the input Jon, Andy, and Scott.  Unfortunately, it already
> counts positive in the clockwise direction, so that’s not it.  I’ll go
> through Jon’s list of suggestions step by step when I get back to the
> machine in a few days and let you know how it goes.  I also realized
> that a spindle braking resistor will be necessary because the G33.1
> motion doesn’t engage the mechanical brake on deceleration.  That was
> something I hadn’t accounted for, but I have one on order now.
>
> Matt
>
Jon's (Pico Systems) pwm-servo is a full 4 quadrant controller, without a 
brakiing R, it will charge the caps in the supply from 125 to about 160 
but turns my 1 hp PMDC motor on my GO704 around in about 400  
milliseconds.  If your supply is higher than mine, and it probably is, 
talk to Jon about the higher voltage.
> ___
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

I am using the vari-speed head, so I’m already in the high range and running at 
minimum speed.  Unfortunately I can’t tune the VFD ramp down to be optimum for 
low speed because at high speed it overloads (due to the increased inertia).  
And so far as I know my Hitachi VFD can only ramp down in a fixed time period.  
Thanks though!

> On Jul 20, 2020, at 2:39 PM, Scott Harwell via Emc-users 
>  wrote:
> 
> Do you have a 2 speed gear box? If so try tapping in high range with lower 
> spindle (motor) speed. This will give you a much better ramp. 
> 
> Scott
> 
>On Monday, July 20, 2020, 10:00:14 AM CDT, Matthew Herd 
>  wrote:  
> 
> Thanks for the input Jon, Andy, and Scott.  Unfortunately, it already counts 
> positive in the clockwise direction, so that’s not it.  I’ll go through Jon’s 
> list of suggestions step by step when I get back to the machine in a few days 
> and let you know how it goes.  I also realized that a spindle braking 
> resistor will be necessary because the G33.1 motion doesn’t engage the 
> mechanical brake on deceleration.  That was something I hadn’t accounted for, 
> but I have one on order now.
> 
> Matt
> 
> ___
> 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



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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-20 Thread Scott Harwell via Emc-users

 Do you have a 2 speed gear box? If so try tapping in high range with lower 
spindle (motor) speed. This will give you a much better ramp. 

Scott

On Monday, July 20, 2020, 10:00:14 AM CDT, Matthew Herd 
 wrote:  
 
 Thanks for the input Jon, Andy, and Scott.  Unfortunately, it already counts 
positive in the clockwise direction, so that’s not it.  I’ll go through Jon’s 
list of suggestions step by step when I get back to the machine in a few days 
and let you know how it goes.  I also realized that a spindle braking resistor 
will be necessary because the G33.1 motion doesn’t engage the mechanical brake 
on deceleration.  That was something I hadn’t accounted for, but I have one on 
order now.

Matt

___
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] Problem with Rigid Tapping on USC Equipped Bridgeport


On 07/20/2020 10:51 AM, Matthew Herd wrote:

Hi Andy,

"But does it also count negative in reverse?"
Yes, counts go up and down, depending on the direction I turn the spindle, 
either manually or under power.


Hmmm, the mystery deepens!  Well, it may be that the encoder 
index-enable connection in hal is not set up correctly.  
Although, it seems that in that case it would never begin 
the Z move.


Jon


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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On Mon, 20 Jul 2020 at 17:07, Matthew Herd  wrote:
>
> It appears to increment/decrement by exactly 1 for each revolution, but I 
> didn’t put a degree wheel on the spindle to be sure of my rotation 
> measurement.

If it is close to 1, then it probably is 1.

I think we need to see your HAL file. https://paste.ubuntu.com is a
handy place to put a plain text file.

-- 
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] Problem with Rigid Tapping on USC Equipped Bridgeport

It appears to increment/decrement by exactly 1 for each revolution, but I 
didn’t put a degree wheel on the spindle to be sure of my rotation measurement.

> On Jul 20, 2020, at 11:58 AM, andy pugh  wrote:
> 
> On Mon, 20 Jul 2020 at 16:53, Matthew Herd  wrote:
> 
>> "But does it also count negative in reverse?"
>> Yes, counts go up and down, depending on the direction I turn the spindle, 
>> either manually or under power.
> 
> And motion.spindle-revs goes up or down by exactly 1.0 for each revolution?
> 
> -- 
> 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 mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On Mon, 20 Jul 2020 at 16:53, Matthew Herd  wrote:

> "But does it also count negative in reverse?"
> Yes, counts go up and down, depending on the direction I turn the spindle, 
> either manually or under power.

And motion.spindle-revs goes up or down by exactly 1.0 for each revolution?

-- 
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] Problem with Rigid Tapping on USC Equipped Bridgeport

Hi Andy,

"But does it also count negative in reverse?"
Yes, counts go up and down, depending on the direction I turn the spindle, 
either manually or under power.

Matt

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

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

On Mon, 20 Jul 2020 at 16:00, Matthew Herd  wrote:
>
> Thanks for the input Jon, Andy, and Scott.  Unfortunately, it already counts 
> positive in the clockwise direction, so that’s not it.

But does it also count negative in reverse?

-- 
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] Problem with Rigid Tapping on USC Equipped Bridgeport