subject:"Re\: \[Emc\-users\] Fluctuating RPM using CUI ATM 10 encoder"

On Friday 08 May 2020 22:36:35 Dan Henderson wrote:

> Thanks for the examples. I'm not going to lie, I've got some homework
> to do on this. You guy's make this sound easy but to the new guy
> looking in? No so much, lol

Don't be glum Dan, you've already demo'd to me that you WILL get there.

The fact that LinuxCNC is being further developed, literally as I type 
this, even if the basic premise is decades old, can't be emphasized 
enough. One of the reasons I posted snips of my old code, old but still 
after the new words were added to the hal recipe, was to demo that, far 
more than any finger pointing at Jon's example. If it works, its right.

I apologize to Jon if it was taken that way.

I cannot today even run that code, because the hardware under it has 
changed.  For the better is an arguable point because that driver Jon 
makes is a no compromise device doing exactly what you tell it to do 
with zero drama. It can now make that same motor break all sorts of 
stuff between it and the chuck it spins if I hadn't taken measures to 
tame the violent acceleration that drive is capable of making it do.  
OTOH, that 1 hp rated motor can now deliver nearly 2hp because the psu I 
built out of junk box parts makes 35 more volts and 10x the current that 
cleared the fuse in the OEM configuration. But it also gets the job 
done.  Its had stuff in that 5" chuck that weigh half what that whole 
lathe weighs, and made the part.

[...]

> > Yes, I'm pretty sure it still does.  But, yes, this is OLD
> > STYLE hal code, for sure.
> > You can combine any newsig / linkps / linksp into one net
> > command, with
> >
> > net signal-name pin pin pin ...
> >
> > And, you don't have to tell it the signal type, it gets it
> > from the first pin.
> >
> > Jon
> >

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] Fluctuating RPM using CUI ATM 10 encoder

Thanks for the examples. I'm not going to lie, I've got some homework to do
on this. You guy's make this sound easy but to the new guy looking in? No
so much, lol



On Fri, May 8, 2020 at 9:01 PM Jon Elson  wrote:

> On 05/08/2020 06:45 PM, Gene Heskett wrote:
> > On Friday 08 May 2020 18:01:41 Jon Elson wrote:
> >
> >> On 05/08/2020 04:04 PM, Dan Henderson wrote:
> >>> Thanks Jon and Chris!
> >>>
> >>> Jon do you have a code example of the Hal filter that is needed?
> >> # set up 4th DAC generator as a spindle speed control
> >> newsig spindle-speed float
> >> newsig spindle-DAC-cmd float
> >> newsig spindle-DAC-filt float
> >> newsig spindle-DAC-abs float
> >> linkps motion.spindle-speed-out => spindle-speed
> >> linksp spindle-speed => mult2.1.in0
> >> setp   mult2.1.in1 0.002457
> >> linkps mult2.1.out => spindle-DAC-cmd
> >> linksp spindle-DAC-cmd => lowpass.0.in
> >> linkps lowpass.0.out => spindle-DAC-filt
> >> setp lowpass.0.gain 0.005
> >> linksp spindle-DAC-filt => abs.0.in
> >> linksp spindle-DAC-abs => abs.0.out
> >> linksp spindle-DAC-abs => ppmc.0.DAC.03.value
> >>
> > That hal code is all, I assume, from your 2.5.4 install Jon.  everything
> but
> > the setp has been deprecated, and I am not sure todays version of hal
> > understands those commands.
> Yes, I'm pretty sure it still does.  But, yes, this is OLD
> STYLE hal code, for sure.
> You can combine any newsig / linkps / linksp into one net
> command, with
>
> net signal-name pin pin pin ...
>
> And, you don't have to tell it the signal type, it gets it
> from the first pin.
>
> 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] Fluctuating RPM using CUI ATM 10 encoder


On 05/08/2020 06:45 PM, Gene Heskett wrote:

On Friday 08 May 2020 18:01:41 Jon Elson wrote:


On 05/08/2020 04:04 PM, Dan Henderson wrote:

Thanks Jon and Chris!

Jon do you have a code example of the Hal filter that is needed?

# set up 4th DAC generator as a spindle speed control
newsig spindle-speed float
newsig spindle-DAC-cmd float
newsig spindle-DAC-filt float
newsig spindle-DAC-abs float
linkps motion.spindle-speed-out => spindle-speed
linksp spindle-speed => mult2.1.in0
setp   mult2.1.in1 0.002457
linkps mult2.1.out => spindle-DAC-cmd
linksp spindle-DAC-cmd => lowpass.0.in
linkps lowpass.0.out => spindle-DAC-filt
setp lowpass.0.gain 0.005
linksp spindle-DAC-filt => abs.0.in
linksp spindle-DAC-abs => abs.0.out
linksp spindle-DAC-abs => ppmc.0.DAC.03.value


That hal code is all, I assume, from your 2.5.4 install Jon.  everything but
the setp has been deprecated, and I am not sure todays version of hal
understands those commands.
Yes, I'm pretty sure it still does.  But, yes, this is OLD 
STYLE hal code, for sure.
You can combine any newsig / linkps / linksp into one net 
command, with


net signal-name pin pin pin ...

And, you don't have to tell it the signal type, it gets it 
from the first pin.


Jon


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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On Friday 08 May 2020 18:01:41 Jon Elson wrote:

> On 05/08/2020 04:04 PM, Dan Henderson wrote:
> > Thanks Jon and Chris!
> >
> > Jon do you have a code example of the Hal filter that is needed?
>
> # set up 4th DAC generator as a spindle speed control
> newsig spindle-speed float
> newsig spindle-DAC-cmd float
> newsig spindle-DAC-filt float
> newsig spindle-DAC-abs float
> linkps motion.spindle-speed-out => spindle-speed
> linksp spindle-speed => mult2.1.in0
> setp   mult2.1.in1 0.002457
> linkps mult2.1.out => spindle-DAC-cmd
> linksp spindle-DAC-cmd => lowpass.0.in
> linkps lowpass.0.out => spindle-DAC-filt
> setp lowpass.0.gain 0.005
> linksp spindle-DAC-filt => abs.0.in
> linksp spindle-DAC-abs => abs.0.out
> linksp spindle-DAC-abs => ppmc.0.DAC.03.value
>
That hal code is all, I assume, from your 2.5.4 install Jon.  everything but 
the setp has been deprecated, and I am not sure todays version of hal 
understands those commands. 

I believe that linksp and newsig have been replaced in general function with 
'net' which has its own newsig function as its first argument and which 
apparently assumes the properties of the 2nd argument, and can link all 
the rest of the arguments as targets to send the newsig's data to. Thats if 
I understand it properly.  Perhaps it can auto-translate ala TWOPASS as its 
loaded? IDK for sure as I have not tried to mix-n-match. 
The newer syntax is more compact

So the first 2 linkps statements then becomes a single:

net spindle-speed <= motion.spindle-speed-out => mult2.1.in0

And once 'spindle-speed' is set and is encountered in a new 'net' 
statement lower in the file because you need that data elsewhere it becomes:

net spindle-speed output2 output3 output4 etc etc etc

The '=>' and '<=' direction arrows are for human readability and are 
ignored by hal.  Me = ancient human with short term memory problems 
so I use them most of the time.

> This is for my PPMC analog boards, but ppmc.0.DAC.03.value
> is the speed value sent to the drive.
> lowpass.0.gain is set to 0.005, the name of the pin is a bit
> odd, as gain is actually what sets the time constant of the
> filter.  You will have to loadrt lowpass and then addf
> lowpass to the servo_thread
>
> mult2 sets up the speed factor so that the S word gives the
> right speed.
>
> Jon
this code is from a config I used quite some time, back, in 2014 TBE
to do this in my 7x12: (turn off word wrap in your reader)

# now spindle direction changes need a forced stop until it has stopped
# need an artificial zero speed for artificial offs when a dir change occurs
setpmux2.0.in0  0.0 # zero speed when off
setpwcomp.1.min 2   # rpm, used as nearly stopped 
indicator
setpwcomp.1.max 1600# rpm, use for runaway 
shutdown, feed into e-stop
# setup pid.0.command channel, with delay for startup surges, otherwise 
straight thru
# describe a "net" specifier line
# type  signal-name sig-src target1 
target2 target3 etc
net spindle-drive0  motion.spindle-speed-out-rps
mux2.0.in1  # active speed when not stopped
net spindle-drive-switched  mux2.0.out  
limit2.0.in # mux feeds 0.000 into pid while stopping

# control acceleration of spindle, decel too
net kill-spindleor2.0.out   # 
lowpass.0.load
setplimit2.0.maxv   4   # max 
delta speed per second
net spindle-drive1  limit2.0.out
abs.pid.in  # all fwd to logic
net spindle-drive2  abs.pid.out 
pid.0.command
# now, we need to disable the probe when an axis is homing so we can use the 
probe as home contact.
net dis-home0   axis.0.homing   
lut5.0.in-0
net dis-home2   axis.2.homing   
lut5.0.in-1
setplut5.0.function 0x10# 3 
input semi-xor?
net home-outlut5.0.out  # 
motion.probe-input

# Setup encoder for closed loop spindle speed control
setpencoder.0.counter-mode  false   # counts quadrature when false, 
200 edges/rev from 50 slot disk
setpencoder.0.index-enable  true
setpencoder.0.x4-mode   true# 
smoother output?  Yes
setpencoder.0.position-scale200.00  # of 
edges in wheel for 1 turn

# now use encoder-velocity, redescribe "net"
# type  signal-name signal-src  target1 
target2 target3
setpscale.0.gain60  # sets spindle display calibration, set 
at 10 rps=600 rpms
setpscale.0.offset  0.0
net spindle-feedback0   encoder.0.velocity

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On 05/08/2020 04:04 PM, Dan Henderson wrote:

Thanks Jon and Chris!

Jon do you have a code example of the Hal filter that is needed?

# set up 4th DAC generator as a spindle speed control
newsig spindle-speed float
newsig spindle-DAC-cmd float
newsig spindle-DAC-filt float
newsig spindle-DAC-abs float
linkps motion.spindle-speed-out => spindle-speed
linksp spindle-speed => mult2.1.in0
setp mult2.1.in1 0.002457
linkps mult2.1.out => spindle-DAC-cmd
linksp spindle-DAC-cmd => lowpass.0.in
linkps lowpass.0.out => spindle-DAC-filt
setp lowpass.0.gain 0.005
linksp spindle-DAC-filt => abs.0.in
linksp spindle-DAC-abs => abs.0.out
linksp spindle-DAC-abs => ppmc.0.DAC.03.value

This is for my PPMC analog boards, but ppmc.0.DAC.03.value
is the speed value sent to the drive.
lowpass.0.gain is set to 0.005, the name of the pin is a bit
odd, as gain is actually what sets the time constant of the
filter. You will have to loadrt lowpass and then addf
lowpass to the servo_thread

mult2 sets up the speed factor so that the S word gives the
right speed.

Jon

On Fri, May 8, 2020 at 3:58 PM Chris Albertson
wrote:

You have to compare the signals on BOTH sides of the interface to see what
is happening. The build-in halscope can only see what has crossed the
interface. Compare this to what is on the parallel port pins and also what
is on the encoder side of the opto-isolators.

If a new digital oscilloscope is out of budget then look at one of these:
ebay.com/itm/USB-SALEAE-24M-8CH-Logic-Analyzer...
<
https://www.ebay.com/itm/USB-SALEAE-24M-8CH-Logic-Analyzer-24M-8-Channel-with-Buffer-Support-1-1-16/173828458153?hash=item2878fbc6a9:g:tDUAAOSwJiddkJ1E
It is an 8-channel logic analyzer that is fast enough fo anything you will
ever do with a machine tool of motion control. It has no trouble sampling
Mhz class square waves. (The above is a Chinese clone of the actual
Saleae unit.)

Get the software for it here. You can try the software without buying the
hardware but obviously can't collect data.
https://www.saleae.com/downloads/

The oscilloscope is best because it shows the actual analog waveform but
the analyzer has more channels and has very complex triggers and can
de-code serial busses

On Thu, May 7, 2020 at 3:45 PM Gene Heskett wrote:

On Thursday 07 May 2020 17:39:32 Dan Henderson wrote:

Why certainly Gene (see attached). I actually have it working a little
better now. My spindle-at-speed LED will start going bonkers around
1200 rpm. I'm guessing this is when the counter "throws up it's hands
and says - I quit!" lol. The spindle will operate all the way to
around 4700 rpm but anything above this and the MC-2100 shuts it down
-- must be some kind of voltage limiter kicking in then.

The one time I tried to use one of them was a failure, it seemed to have
a mind of its own. I made a power supply and bought one of the pico
systems pwm-servo's. Bulletproof but be sure and tell Jon you are going
to drive a PMDC spindle motor with it so he'll add more toroids so it
runs cooler when working continuously.

That said, your config is as well laid out as any I've looked at, and I
don't see anything wrong at all. But I can also see how the parport and
its missing of the encoders signals could be all of the higher speed
problems. The 4700 limit might be the pwmgen going to 100% duty, losing
the 0% recharge pulse. You can check that with halscope. I run more
voltage than the mc2100 can muster, so I can spin a treadmill motor up
to where I worry about the cast iron fan/pulley exploding but set limits
somewhat below that, probably around 7 grand max. Even though its geared
3/1 before it gets near the spindle drive, its still too fast to cut
steel.

If you can set the encoder even lower you might get to a couple thousand
revs before the tach gets funkity.

18:40 here, I'd better go see what my missus wants for dinner.

On Thu, May 7, 2020 at 2:29 PM Gene Heskett

wrote:

On Thursday 07 May 2020 13:19:23 Dan Henderson wrote:

I believe this is open loop. Isn’t PID only used in closed loop
control?

Its (the PID is) a waste of processor time if open loop. I don't use
one of those in any spindle run by a vfd, the vfd is generally stiff
enough control by itself. If I thread on that machine, it will have
a spindle encoder, but its only job is to glue the axis motion being
driven to cut the thread, to the spindle rotation, in the case of a
g33.1, going both in and out of the hole. If you aren't useing a PID
for the spindle, that leaves motion I think.

I think its time we saw your .hal file. Can you insert it into a
mail?

On Thu, May 7, 2020 at 11:03 AM Gene Heskett

wrote:

On Thursday 07 May 2020 11:27:57 Jon Elson wrote:

On 05/06/2020 09:20 PM, Dan Henderson wrote:

I’ve confirmed the fluctuation occurs when spindle-at-speed
is configured. When I remove this feature, the spindle rpm
appears to stabilize. It’s almost like it gets caught in a
loop trying to chase its tail.

This is VERY common in

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-08 Thread andy pugh

On Fri, 8 May 2020 at 21:58, Chris Albertson  wrote:

> If a new digital oscilloscope is out of budget then look at one of these:
> ebay.com/itm/USB-SALEAE-24M-8CH-Logic-Analyzer...
> 
> It is an 8-channel logic analyzer that is fast enough fo anything you will
> ever do with a machine tool of motion control.

Possibly less trouble is something like
https://www.amazon.com/Autek-Pocket-Sized-DSO211-Digital-Oscilloscope/dp/B00BWI0QHG/

I spent a but more and got a "DSO Quad' and it is really rather nice.
Though, as is often the case, I bought it just as my hobbies took a
bit of a swerve in a different direction, so it hasn't seen much use.

(Also, I do tend to use my rather cute 1980s Tektronix with fancy
on-screen menus. Must have been expensive when new.
http://w140.com/tekwiki/wiki/336 It's smaller than it looks, about A4
paper sized. Though cleaerly not smaller than the pocket 'scope)

-- 
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] Fluctuating RPM using CUI ATM 10 encoder

Thanks Jon and Chris!

Jon do you have a code example of the Hal filter that is needed?

On Fri, May 8, 2020 at 3:58 PM Chris Albertson 
wrote:

> You have to compare the signals on BOTH sides of the interface to see what
> is happening.   The build-in halscope can only see what has crossed the
> interface.  Compare this to what is on the parallel port pins and also what
> is on the encoder side of the opto-isolators.
>
> If a new digital oscilloscope is out of budget then look at one of these:
> ebay.com/itm/USB-SALEAE-24M-8CH-Logic-Analyzer...
> <
> https://www.ebay.com/itm/USB-SALEAE-24M-8CH-Logic-Analyzer-24M-8-Channel-with-Buffer-Support-1-1-16/173828458153?hash=item2878fbc6a9:g:tDUAAOSwJiddkJ1E
> >
> It is an 8-channel logic analyzer that is fast enough fo anything you will
> ever do with a machine tool of motion control.  It has no trouble sampling
> Mhz class square waves.   (The above is a Chinese clone of the actual
> Saleae unit.)
>
> Get the software for it here.  You can try the software without buying the
> hardware but obviously can't collect data.
> https://www.saleae.com/downloads/
>
> The oscilloscope is best because it shows the actual analog waveform but
> the analyzer has more channels and has very complex triggers and can
> de-code serial busses
>
>
>
>
>
> On Thu, May 7, 2020 at 3:45 PM Gene Heskett  wrote:
>
> > On Thursday 07 May 2020 17:39:32 Dan Henderson wrote:
> >
> > > Why certainly Gene (see attached). I actually have it working a little
> > > better now. My spindle-at-speed LED will start going bonkers around
> > > 1200 rpm. I'm guessing this is when the counter "throws up it's hands
> > > and says - I quit!" lol. The spindle will operate all the way to
> > > around 4700 rpm but anything above this and the MC-2100 shuts it down
> > > -- must be some kind of voltage limiter kicking in then.
> > >
> > The one time I tried to use one of them was a failure, it seemed to have
> > a mind of its own.  I made a power supply and bought one of the pico
> > systems pwm-servo's. Bulletproof but be sure and tell Jon you are going
> > to drive a PMDC spindle motor with it so he'll add more toroids so it
> > runs cooler when working continuously.
> >
> > That said, your config is as well laid out as any I've looked at, and I
> > don't see anything wrong at all. But I can also see how the parport and
> > its missing of the encoders signals could be all of the higher speed
> > problems.  The 4700 limit might be the pwmgen going to 100% duty, losing
> > the 0% recharge pulse. You can check that with halscope. I run more
> > voltage than the mc2100 can muster, so I can spin a treadmill motor up
> > to where I worry about the cast iron fan/pulley exploding but set limits
> > somewhat below that, probably around 7 grand max. Even though its geared
> > 3/1 before it gets near the spindle drive, its still too fast to cut
> > steel.
> >
> > If you can set the encoder even lower you might get to a couple thousand
> > revs before the tach gets funkity.
> >
> > 18:40 here, I'd better go see what my missus wants for dinner.
> >
> >
> > > On Thu, May 7, 2020 at 2:29 PM Gene Heskett 
> > wrote:
> > > > On Thursday 07 May 2020 13:19:23 Dan Henderson wrote:
> > > > > I believe this is open loop. Isn’t PID only used in closed loop
> > > > > control?
> > > >
> > > > Its (the PID is) a waste of processor time if open loop. I don't use
> > > > one of those in any spindle run by a vfd, the vfd is generally stiff
> > > > enough control by itself. If I thread on that machine, it will have
> > > > a spindle encoder, but its only job is to glue the axis motion being
> > > > driven to cut the thread, to the spindle rotation, in the case of a
> > > > g33.1, going both in and out of the hole. If you aren't useing a PID
> > > > for the spindle, that leaves motion I think.
> > > >
> > > > I think its time we saw your .hal file. Can you insert it into a
> > > > mail?
> > > >
> > > > > On Thu, May 7, 2020 at 11:03 AM Gene Heskett
> > > > > 
> > > >
> > > > wrote:
> > > > > > On Thursday 07 May 2020 11:27:57 Jon Elson wrote:
> > > > > > > On 05/06/2020 09:20 PM, Dan Henderson wrote:
> > > > > > > > I’ve confirmed the fluctuation occurs when spindle-at-speed
> > > > > > > > is configured. When I remove this feature, the spindle rpm
> > > > > > > > appears to stabilize. It’s almost like it gets caught in a
> > > > > > > > loop trying to chase its tail.
> > > > > > >
> > > > > > > This is VERY common in servo systems, and is due to delay in
> > > > > > > response of the object being controlled.
> > > > > > > You need to slow down the response of the PID to ignore the
> > > > > > > delay. This may be possible by adding
> > > > > > > D to it.
> > > > > > >
> > > > > > > Jon
> > > > > >
> > > > > > But my msg was that a near module generated spindle.N.at-speed
> > > > > > was never to be injected into any signal path leading back to a
> > > > > > PID. That near's output s/b only to that input to motion, and
> > > > > > possibly

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-08 Thread Chris Albertson

You have to compare the signals on BOTH sides of the interface to see what
is happening.   The build-in halscope can only see what has crossed the
interface.  Compare this to what is on the parallel port pins and also what
is on the encoder side of the opto-isolators.

If a new digital oscilloscope is out of budget then look at one of these:
ebay.com/itm/USB-SALEAE-24M-8CH-Logic-Analyzer...

It is an 8-channel logic analyzer that is fast enough fo anything you will
ever do with a machine tool of motion control.  It has no trouble sampling
Mhz class square waves.   (The above is a Chinese clone of the actual
Saleae unit.)

Get the software for it here.  You can try the software without buying the
hardware but obviously can't collect data.
https://www.saleae.com/downloads/

The oscilloscope is best because it shows the actual analog waveform but
the analyzer has more channels and has very complex triggers and can
de-code serial busses





On Thu, May 7, 2020 at 3:45 PM Gene Heskett  wrote:

> On Thursday 07 May 2020 17:39:32 Dan Henderson wrote:
>
> > Why certainly Gene (see attached). I actually have it working a little
> > better now. My spindle-at-speed LED will start going bonkers around
> > 1200 rpm. I'm guessing this is when the counter "throws up it's hands
> > and says - I quit!" lol. The spindle will operate all the way to
> > around 4700 rpm but anything above this and the MC-2100 shuts it down
> > -- must be some kind of voltage limiter kicking in then.
> >
> The one time I tried to use one of them was a failure, it seemed to have
> a mind of its own.  I made a power supply and bought one of the pico
> systems pwm-servo's. Bulletproof but be sure and tell Jon you are going
> to drive a PMDC spindle motor with it so he'll add more toroids so it
> runs cooler when working continuously.
>
> That said, your config is as well laid out as any I've looked at, and I
> don't see anything wrong at all. But I can also see how the parport and
> its missing of the encoders signals could be all of the higher speed
> problems.  The 4700 limit might be the pwmgen going to 100% duty, losing
> the 0% recharge pulse. You can check that with halscope. I run more
> voltage than the mc2100 can muster, so I can spin a treadmill motor up
> to where I worry about the cast iron fan/pulley exploding but set limits
> somewhat below that, probably around 7 grand max. Even though its geared
> 3/1 before it gets near the spindle drive, its still too fast to cut
> steel.
>
> If you can set the encoder even lower you might get to a couple thousand
> revs before the tach gets funkity.
>
> 18:40 here, I'd better go see what my missus wants for dinner.
>
>
> > On Thu, May 7, 2020 at 2:29 PM Gene Heskett 
> wrote:
> > > On Thursday 07 May 2020 13:19:23 Dan Henderson wrote:
> > > > I believe this is open loop. Isn’t PID only used in closed loop
> > > > control?
> > >
> > > Its (the PID is) a waste of processor time if open loop. I don't use
> > > one of those in any spindle run by a vfd, the vfd is generally stiff
> > > enough control by itself. If I thread on that machine, it will have
> > > a spindle encoder, but its only job is to glue the axis motion being
> > > driven to cut the thread, to the spindle rotation, in the case of a
> > > g33.1, going both in and out of the hole. If you aren't useing a PID
> > > for the spindle, that leaves motion I think.
> > >
> > > I think its time we saw your .hal file. Can you insert it into a
> > > mail?
> > >
> > > > On Thu, May 7, 2020 at 11:03 AM Gene Heskett
> > > > 
> > >
> > > wrote:
> > > > > On Thursday 07 May 2020 11:27:57 Jon Elson wrote:
> > > > > > On 05/06/2020 09:20 PM, Dan Henderson wrote:
> > > > > > > I’ve confirmed the fluctuation occurs when spindle-at-speed
> > > > > > > is configured. When I remove this feature, the spindle rpm
> > > > > > > appears to stabilize. It’s almost like it gets caught in a
> > > > > > > loop trying to chase its tail.
> > > > > >
> > > > > > This is VERY common in servo systems, and is due to delay in
> > > > > > response of the object being controlled.
> > > > > > You need to slow down the response of the PID to ignore the
> > > > > > delay. This may be possible by adding
> > > > > > D to it.
> > > > > >
> > > > > > Jon
> > > > >
> > > > > But my msg was that a near module generated spindle.N.at-speed
> > > > > was never to be injected into any signal path leading back to a
> > > > > PID. That near's output s/b only to that input to motion, and
> > > > > possibly to an indicator led in the gui so the operator can be
> > > > > advised if its acting funkity. Flickering could be worn brushes
> > > > > in a brushed PMDC motor for instance.
> > > > >
> > > > > What you are describing as delays can often be fixed by the
> > > > > proper re-ordering of the addf's involved for the oscillating
> > > > >

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder


On 05/08/2020 01:34 PM, Dan Henderson wrote:

There are times when letting the smoke escape becomes part of the learning
process :)

Thanks for your guidance Gene. Would think the DC motor energy would be
absorbed by the act of tapping once the M3 is turned off? Surely the G33.1
cycle doesn't flip from 500 CW to 500 CCW does it?
Without filtering, it does exactly that.  But, you can put a 
lowpass filter or a limit component in there

to slow down the reversal.

  I'm going to want to
initiate that cycle with a slow spindle to begin with and I'm not sure how
built-in speed ramp controlled by the MC-2100 will handle this. A hacked in
pause between M3 and M4 may be order, huh?

But, the G33.1 doesn't allow you that control.  It just goes 
from forward to reverse in one servo cycle
when it determines the programmed depth has been reached.  
So, that's why you need a filter

in the spindle command if you want a softer reversal.

(By the way, I do the 4-40 rigid tapping on my machine at 
1000 RPM. The reversal takes about

a half second.)

Jon


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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

Thanks Gene. Will consider how to get this done in the Hal based on your
tips.

On Fri, May 8, 2020 at 2:03 PM Gene Heskett  wrote:

> On Friday 08 May 2020 14:34:06 Dan Henderson wrote:
>
> > There are times when letting the smoke escape becomes part of the
> > learning process :)
> >
> yes, and we all do it, its the nature of us.
>
> > Thanks for your guidance Gene. Would think the DC motor energy would
> > be absorbed by the act of tapping once the M3 is turned off? Surely
> > the G33.1 cycle doesn't flip from 500 CW to 500 CCW does it? I'm going
> > to want to initiate that cycle with a slow spindle to begin with and
> > I'm not sure how built-in speed ramp controlled by the MC-2100 will
> > handle this. A hacked in pause between M3 and M4 may be order, huh?
>
> It can flip from 3k to -3k.Very VERY hard on both the electrics and the
> machinery if not gentled up a bit.  Following my recipe will generally
> work though.
>
> The point being that motion goes directly from M3 to M4, or back.  There
> is no M5 in the middle without your making it happen with hal.
>
> > On Fri, May 8, 2020 at 12:45 PM Gene Heskett 
> wrote:
> > > On Friday 08 May 2020 13:34:36 Gene Heskett wrote:
> > > > On Friday 08 May 2020 12:09:45 Dan Henderson wrote:
> > > > > Thanks Andy/Jon/Gene. To enable Quadrature do I merely turn on
> > > > > phase-A/B/index inputs and remove “encoder-counter-mode = True”?
> > > >
> > > > Sounds good.
> > > >
> > > > > Here’s a pic of the reverse circuit I’m making to enable M4
> > > > > polarity reversal of the DC motor.
> > > >
> > > > We all know this stuff runs on smoke and mirrors.
> > > >
> > > > That controller probably will NOT like being reversed without
> > > > first stopping the motor, then reverse that relay and restart the
> > > > motor.
> > > >
> > > > Doing otherwise will probably break the mirror and let all the
> > > > smoke out. Typically they don't work anymore.
> > > >
> > > > Ideally, two relays. I have used the P ice cubes with 20 amp
> > > > contacts for this.  One to apply a braking resistor to absorb the
> > > > motors energy as its stopping and a second to do the reversal. Its
> > > > wired closest to the motor with the moving contacts to the
> > > > armature.
> > >
> > > Thats ambiguous, the braking relay is closest to the motor.
> > >
> > > > A calrod coil out of an electric cookstove makes a good braking
> > > > load. Somewhat overkill but 100% serviceable forever.
> > > >
> > > > The reversal sequence would be:
> > > > 1. hold the reversal from motion, blocking it from the controller
> > > >
> > > > 2. use that to reduce the drive to zero useing a rate limiter like
> > > > a limit3, switching its input with a mux2.
> > > >
> > > > 3. When the drive is off, switch on the load R relay to stop the
> > > > motor much quicker.
> > > >
> > > > 4. when, according to the encoder, the motor has stopped, release
> > > > the braking relay,
> > > >
> > > > 5. enable the reversal relay AND restore the speed input to the
> > > > limit3 and let it ramp the motor back up to set speed
> > > >
> > > > Do the same thing in reverse at the top of the backout move.
> > > >
> > > > hint, an xor2 is used to detect the change in state of the rev
> > > > signal from motion. A miss-match is the trigger for the stop
> > > > sequence.
> > > >
> > > > I ran my 7x12 that way for about 2 years without letting the smoke
> > > > out. But with a heavy 5" chuck, the overshoot at the bottom of the
> > > > hole was terrible. So I eventually threw more money at it.
> > > >
> > > > Cheers, Gene Heskett
> > >
> > > 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
>

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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On Friday 08 May 2020 14:34:06 Dan Henderson wrote:

> There are times when letting the smoke escape becomes part of the
> learning process :)
>
yes, and we all do it, its the nature of us.

> Thanks for your guidance Gene. Would think the DC motor energy would
> be absorbed by the act of tapping once the M3 is turned off? Surely
> the G33.1 cycle doesn't flip from 500 CW to 500 CCW does it? I'm going
> to want to initiate that cycle with a slow spindle to begin with and
> I'm not sure how built-in speed ramp controlled by the MC-2100 will
> handle this. A hacked in pause between M3 and M4 may be order, huh?

It can flip from 3k to -3k.Very VERY hard on both the electrics and the 
machinery if not gentled up a bit.  Following my recipe will generally 
work though.

The point being that motion goes directly from M3 to M4, or back.  There 
is no M5 in the middle without your making it happen with hal.

> On Fri, May 8, 2020 at 12:45 PM Gene Heskett  
wrote:
> > On Friday 08 May 2020 13:34:36 Gene Heskett wrote:
> > > On Friday 08 May 2020 12:09:45 Dan Henderson wrote:
> > > > Thanks Andy/Jon/Gene. To enable Quadrature do I merely turn on
> > > > phase-A/B/index inputs and remove “encoder-counter-mode = True”?
> > >
> > > Sounds good.
> > >
> > > > Here’s a pic of the reverse circuit I’m making to enable M4
> > > > polarity reversal of the DC motor.
> > >
> > > We all know this stuff runs on smoke and mirrors.
> > >
> > > That controller probably will NOT like being reversed without
> > > first stopping the motor, then reverse that relay and restart the
> > > motor.
> > >
> > > Doing otherwise will probably break the mirror and let all the
> > > smoke out. Typically they don't work anymore.
> > >
> > > Ideally, two relays. I have used the P ice cubes with 20 amp
> > > contacts for this.  One to apply a braking resistor to absorb the
> > > motors energy as its stopping and a second to do the reversal. Its
> > > wired closest to the motor with the moving contacts to the
> > > armature.
> >
> > Thats ambiguous, the braking relay is closest to the motor.
> >
> > > A calrod coil out of an electric cookstove makes a good braking
> > > load. Somewhat overkill but 100% serviceable forever.
> > >
> > > The reversal sequence would be:
> > > 1. hold the reversal from motion, blocking it from the controller
> > >
> > > 2. use that to reduce the drive to zero useing a rate limiter like
> > > a limit3, switching its input with a mux2.
> > >
> > > 3. When the drive is off, switch on the load R relay to stop the
> > > motor much quicker.
> > >
> > > 4. when, according to the encoder, the motor has stopped, release
> > > the braking relay,
> > >
> > > 5. enable the reversal relay AND restore the speed input to the
> > > limit3 and let it ramp the motor back up to set speed
> > >
> > > Do the same thing in reverse at the top of the backout move.
> > >
> > > hint, an xor2 is used to detect the change in state of the rev
> > > signal from motion. A miss-match is the trigger for the stop
> > > sequence.
> > >
> > > I ran my 7x12 that way for about 2 years without letting the smoke
> > > out. But with a heavy 5" chuck, the overshoot at the bottom of the
> > > hole was terrible. So I eventually threw more money at it.
> > >
> > > Cheers, Gene Heskett
> >
> > 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] Fluctuating RPM using CUI ATM 10 encoder

There are times when letting the smoke escape becomes part of the learning
process :)

Thanks for your guidance Gene. Would think the DC motor energy would be
absorbed by the act of tapping once the M3 is turned off? Surely the G33.1
cycle doesn't flip from 500 CW to 500 CCW does it? I'm going to want to
initiate that cycle with a slow spindle to begin with and I'm not sure how
built-in speed ramp controlled by the MC-2100 will handle this. A hacked in
pause between M3 and M4 may be order, huh?


On Fri, May 8, 2020 at 12:45 PM Gene Heskett  wrote:

> On Friday 08 May 2020 13:34:36 Gene Heskett wrote:
>
> > On Friday 08 May 2020 12:09:45 Dan Henderson wrote:
> > > Thanks Andy/Jon/Gene. To enable Quadrature do I merely turn on
> > > phase-A/B/index inputs and remove “encoder-counter-mode = True”?
> >
> > Sounds good.
> >
> > > Here’s a pic of the reverse circuit I’m making to enable M4 polarity
> > > reversal of the DC motor.
> >
> > We all know this stuff runs on smoke and mirrors.
> >
> > That controller probably will NOT like being reversed without first
> > stopping the motor, then reverse that relay and restart the motor.
> >
> > Doing otherwise will probably break the mirror and let all the smoke
> > out. Typically they don't work anymore.
> >
> > Ideally, two relays. I have used the P ice cubes with 20 amp
> > contacts for this.  One to apply a braking resistor to absorb the
> > motors energy as its stopping and a second to do the reversal. Its
> > wired closest to the motor with the moving contacts to the armature.
>
> Thats ambiguous, the braking relay is closest to the motor.
>
> > A calrod coil out of an electric cookstove makes a good braking load.
> > Somewhat overkill but 100% serviceable forever.
> >
> > The reversal sequence would be:
> > 1. hold the reversal from motion, blocking it from the controller
> >
> > 2. use that to reduce the drive to zero useing a rate limiter like a
> > limit3, switching its input with a mux2.
> >
> > 3. When the drive is off, switch on the load R relay to stop the motor
> > much quicker.
> >
> > 4. when, according to the encoder, the motor has stopped, release the
> > braking relay,
> >
> > 5. enable the reversal relay AND restore the speed input to the limit3
> > and let it ramp the motor back up to set speed
> >
> > Do the same thing in reverse at the top of the backout move.
> >
> > hint, an xor2 is used to detect the change in state of the rev signal
> > from motion. A miss-match is the trigger for the stop sequence.
> >
> > I ran my 7x12 that way for about 2 years without letting the smoke
> > out. But with a heavy 5" chuck, the overshoot at the bottom of the
> > hole was terrible. So I eventually threw more money at it.
> >
> > Cheers, Gene Heskett
>
>
> 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] Fluctuating RPM using CUI ATM 10 encoder


On 05/08/2020 11:38 AM, John Dammeyer wrote:


Hi Jon,
I suppose you are using external hardware to create motion and count encoder 
pulses?
So BASE_PERIOD isn't even used?
Or is it still needed for tapping?
  My understanding is the SERVO_PERIOD time is used to calculate the spindle 
velocity from the time between encoder pulses at the BASE_PERIOD.
Yes, I have hardware encoder counters in my machine, and 
there is no BASE_PERIOD.  (Effectively, the
base_period is 1 us.)  The base_period is only used to help 
the software encoders not miss pulses (and the step 
generators go faster).


Depending on hardware, the various encoder drivers may have 
several ways to compute velocity.
It can just take difference between current and last encoder 
position, but this is very noisy due to the
double quantization (in both time and position).  Or, it can 
use a timestamp of the most recent quadrature
transition to compute time between pulses.  This can be less 
noisy, especially with a little arithmetic to filter toward 
zero velocity when there hasn't been a transition in a few 
servo cycles.


Jon


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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On Friday 08 May 2020 13:34:36 Gene Heskett wrote:

> On Friday 08 May 2020 12:09:45 Dan Henderson wrote:
> > Thanks Andy/Jon/Gene. To enable Quadrature do I merely turn on
> > phase-A/B/index inputs and remove “encoder-counter-mode = True”?
>
> Sounds good.
>
> > Here’s a pic of the reverse circuit I’m making to enable M4 polarity
> > reversal of the DC motor.
>
> We all know this stuff runs on smoke and mirrors.
>
> That controller probably will NOT like being reversed without first
> stopping the motor, then reverse that relay and restart the motor.
>
> Doing otherwise will probably break the mirror and let all the smoke
> out. Typically they don't work anymore.
>
> Ideally, two relays. I have used the P ice cubes with 20 amp
> contacts for this.  One to apply a braking resistor to absorb the
> motors energy as its stopping and a second to do the reversal. Its
> wired closest to the motor with the moving contacts to the armature.

Thats ambiguous, the braking relay is closest to the motor.

> A calrod coil out of an electric cookstove makes a good braking load.
> Somewhat overkill but 100% serviceable forever.
>
> The reversal sequence would be:
> 1. hold the reversal from motion, blocking it from the controller
>
> 2. use that to reduce the drive to zero useing a rate limiter like a
> limit3, switching its input with a mux2.
>
> 3. When the drive is off, switch on the load R relay to stop the motor
> much quicker.
>
> 4. when, according to the encoder, the motor has stopped, release the
> braking relay,
>
> 5. enable the reversal relay AND restore the speed input to the limit3
> and let it ramp the motor back up to set speed
>
> Do the same thing in reverse at the top of the backout move.
>
> hint, an xor2 is used to detect the change in state of the rev signal
> from motion. A miss-match is the trigger for the stop sequence.
>
> I ran my 7x12 that way for about 2 years without letting the smoke
> out. But with a heavy 5" chuck, the overshoot at the bottom of the
> hole was terrible. So I eventually threw more money at it.
>
> Cheers, Gene Heskett


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] Fluctuating RPM using CUI ATM 10 encoder

On Friday 08 May 2020 12:35:34 andy pugh wrote:

> On Fri, 8 May 2020 at 16:58, Gene Heskett  wrote:
> > Humm, makes me ask, Andy. I am useing some hal trickery to actually
> > sequence this turnaround and to profile it to where z can follow.
> > Because I am blocking the reversal signal, using it to stop the
> > motor at a controlled decel by a limit3 allowing the encoder time
> > between pulses to detect when it has essentially stopped, then the
> > reversal is allowed thru to the controller, the chosen speed is
> > re-applied to the limit3 and the motor is ramped back up to speed by
> > the output of that limit3.
>
> You can safely limit3 the spindle command, but you mustn't filter the
> spindle position signal, as that will cause a phase lag, and a sloppy
> thread.

I did do that for a short time, and found it made the problem worse. So 
that codes been gone and a really high definition encoder installed.

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] Fluctuating RPM using CUI ATM 10 encoder

On Friday 08 May 2020 12:09:45 Dan Henderson wrote:

> Thanks Andy/Jon/Gene. To enable Quadrature do I merely turn on
> phase-A/B/index inputs and remove “encoder-counter-mode = True”?
>
Sounds good.

> Here’s a pic of the reverse circuit I’m making to enable M4 polarity
> reversal of the DC motor.

We all know this stuff runs on smoke and mirrors.

That controller probably will NOT like being reversed without first 
stopping the motor, then reverse that relay and restart the motor.  

Doing otherwise will probably break the mirror and let all the smoke out.
Typically they don't work anymore.

Ideally, two relays. I have used the P ice cubes with 20 amp contacts 
for this.  One to apply a braking resistor to absorb the motors energy 
as its stopping and a second to do the reversal. Its wired closest to 
the motor with the moving contacts to the armature.

A calrod coil out of an electric cookstove makes a good braking load. 
Somewhat overkill but 100% serviceable forever.

The reversal sequence would be:
1. hold the reversal from motion, blocking it from the controller

2. use that to reduce the drive to zero useing a rate limiter like a 
limit3, switching its input with a mux2.

3. When the drive is off, switch on the load R relay to stop the motor 
much quicker.

4. when, according to the encoder, the motor has stopped, release the 
braking relay,

5. enable the reversal relay AND restore the speed input to the limit3 
and let it ramp the motor back up to set speed

Do the same thing in reverse at the top of the backout move.

hint, an xor2 is used to detect the change in state of the rev signal 
from motion. A miss-match is the trigger for the stop sequence.

I ran my 7x12 that way for about 2 years without letting the smoke out.  
But with a heavy 5" chuck, the overshoot at the bottom of the hole was 
terrible. So I eventually threw more money at it.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-08 Thread John Dammeyer




> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> Sent: May-08-20 9:21 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> 
> On 05/07/2020 06:33 PM, Dan Henderson wrote:
> > Thanks Gene! I can go down to 48 PPR on the encoder. If I do so, what is
> > the trade off for reducing resolution on my mill project? Is that enough to
> > successfully use rigid tapping and synchronized feed/speeds?
> >
> >
> 48 pulses is 192 quadrature counts/rev, so not too bad.
> Roughly 2 degrees.  I do tons of rigid tapping with 4-40
> taps using an 81-tooth gear as the encoder wheel on my
> Bridgeport.  It does just fine.
> 
> You do need to have the index pulse hooked up for rigid
> tapping, lathe threading, etc.
> 
> Jon

Hi Jon,
I suppose you are using external hardware to create motion and count encoder 
pulses?  
So BASE_PERIOD isn't even used? 
Or is it still needed for tapping?
 My understanding is the SERVO_PERIOD time is used to calculate the spindle 
velocity from the time between encoder pulses at the BASE_PERIOD.

John Dammeyer



> 
> 
> ___
> 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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-08 Thread andy pugh

On Fri, 8 May 2020 at 16:58, Gene Heskett  wrote:

> Humm, makes me ask, Andy. I am useing some hal trickery to actually
> sequence this turnaround and to profile it to where z can follow.
> Because I am blocking the reversal signal, using it to stop the motor at
> a controlled decel by a limit3 allowing the encoder time between pulses
> to detect when it has essentially stopped, then the reversal is allowed
> thru to the controller, the chosen speed is re-applied to the limit3 and
> the motor is ramped back up to speed by the output of that limit3.

You can safely limit3 the spindle command, but you mustn't filter the
spindle position signal, as that will cause a phase lag, and a sloppy
thread.

-- 
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] Fluctuating RPM using CUI ATM 10 encoder


On 05/07/2020 06:33 PM, Dan Henderson wrote:

Thanks Gene! I can go down to 48 PPR on the encoder. If I do so, what is
the trade off for reducing resolution on my mill project? Is that enough to
successfully use rigid tapping and synchronized feed/speeds?


48 pulses is 192 quadrature counts/rev, so not too bad.  
Roughly 2 degrees.  I do tons of rigid tapping with 4-40 
taps using an 81-tooth gear as the encoder wheel on my 
Bridgeport.  It does just fine.


You do need to have the index pulse hooked up for rigid 
tapping, lathe threading, etc.


Jon


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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

Thanks Andy/Jon/Gene. To enable Quadrature do I merely turn on
phase-A/B/index inputs and remove “encoder-counter-mode = True”?

Here’s a pic of the reverse circuit I’m making to enable M4 polarity
reversal of the DC motor.





On Fri, May 8, 2020 at 10:50 AM John Dammeyer 
wrote:

> The BASE_PERIOD value is in nanoseconds and the clue is _PERIOD which is
> the inverse of FREQUENCY.
> So
> 1000Hz => 1/1000 = 0.001 or 1000 microseconds.
> 2000Hz => 1/2000 = 0.0005 or 500 microseconds.
>
> As the frequency gets higher, the period gets smaller.
>
> JOHN
>
>
> > -Original Message-
> > From: Dan Henderson [mailto:luvtof...@gmail.com]
> > Sent: May-08-20 4:42 AM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> >
> > Jon,
> > Yours is 24,000 and equals to 41.6667kHz? Mine is 100,000 and equates to
> 10 kHz.  I�m confused by your math here? Thanks.
> >
> > Sent from my iPad
> >
> > > On May 7, 2020, at 9:39 PM, John Dammeyer 
> wrote:
> > >
> > > ?
> > >>
> > >> From: Dan Henderson [mailto:luvtof...@gmail.com]
> > >
> > >> Thanks for that Jon. That helps explain this a bit further. I believe
> the
> > >> base period in the ini is set to 100,000. Not sure if that is nS or u
> > >> value? Can this be change to suit or is it tied to the speed of the
> system?
> > >
> > > Hi Dan,
> > > All of my comments are based on what I think I've learned so far.  If
> anyone else sees an error please correct me.
> > >
> > > It's in nano-seconds and it's pretty big on your system and works out
> to 10kHz.  That's the max step rate you will get from your
> > system as long as you have the addf parport.0.reset base-thread.
> Otherwise the max step rate is half that.
> > >
> > > You generally get that value from running the program that tests your
> system for latency.  The jitter you get from that test will
> > change how accurate that 24uS period actually is.
> > >
> > > From my INI file
> > > BASE_PERIOD = 24000  <-- This is 24,000 nS or 24uS or 0.24 seconds
> and equivalent to 41.6667kHz.
> > > SERVO_PERIOD = 100 <-- this is 1 million nano-seconds or 1mS
> equivalent to 1kHz.
> > >
> > > So what does it mean?
> > > From your HAL file.
> > >
> > > loadrt trivkins
> > > loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD
> servo_period_nsec=[EMCMOT]SERVO_PERIOD
> > num_joints=[TRAJ]AXES
> > > loadrt hal_parport cfg="0xe000 out 0xe800 out"
> > > loadrt stepgen step_type=0,0,0
> > > loadrt encoder num_chan=1
> > > loadrt abs count=1
> > > loadrt scale count=1
> > > loadrt lowpass count=1
> > > loadrt near
> > > loadrt pwmgen output_type=1
> > >
> > > Inside each of these files is a function called
> > > int rtapi_app_main(void) {...}
> > >
> > > In that function the command line arguments like step_type are parsed
> and default values are set up. Here's how the Parallel
> > port read function is configured.
> > >/* make read function name */
> > >rtapi_snprintf(name, sizeof(name), "parport.%d.read", n);
> > >/* export read function */
> > >   retval = hal_export_funct(name, read_port,
> &(port_data_array[n]),0, 0, comp_id);
> > > with the names of the functions you add later in the HAL file with
> commands like:
> > >
> > > addf parport.0.read base-thread
> > >
> > > each addf function with base-thread as an argument must run to
> completion in less than 24uS on my system or there won't be
> > time for anything else.Each of these programs, generally found in
> the src/hal or src/emc path.
> > >
> > > The ones marked servo-thread  run once every SERVO_PERIOD which is set
> at  1mS.
> > >
> > > The PID runs once per 1mS.  The stepgen runs every 24uS on my system.
> > >
> > > Hopefully this helps.  So you know the 'why' rather than just do this
> and tell us what happened.
> > >
> > > John Dammeyer
> > >
> > >>
> > >>> On Thu, May 7, 2020 at 6:54 PM John Dammeyer 
> wrote:
> > >>>
> > >>>
> > >>> If you look at the source code for "encoders.c" John Kasunich's
> excellent
> > >>> documentation says this:
> > >>>
> > >>>"The driver exports va

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On Friday 08 May 2020 10:58:57 Gene Heskett wrote:

> On Friday 08 May 2020 06:59:44 andy pugh wrote:
> > On Fri, 8 May 2020 at 01:23, Gene Heskett  
wrote:
> > > If the spindle speed is steady, I have heard of folks doing rigid
> > > tapping with 1 ppr.  Ditto g76.
> >
> > You can do G76 with 1ppr, but not, sensibly, rigid tapping.
> >
> > For rigid tapping you need quadrature to detect the moment of
> > spindle reversal. There is no reliable way to interpolate that.
> >
Humm, makes me ask, Andy. I am useing some hal trickery to actually 
sequence this turnaround and to profile it to where z can follow.  
Because I am blocking the reversal signal, using it to stop the motor at 
a controlled decel by a limit3 allowing the encoder time between pulses 
to detect when it has essentially stopped, then the reversal is allowed 
thru to the controller, the chosen speed is re-applied to the limit3 and 
the motor is ramped back up to speed by the output of that limit3.  This 
of course allows a wee bit more overshoot at the bottom of a hole, and 
if the hole is blind, the possibility of a broken tap. My question is 
since I've noted looser fitting threads when I am "pecking" a hole thats 
too big for my spindle to power thru in one stroke, is there a chance of 
any counts being lost during this turn-around causing a miss-timing to 
the repeated passes and the tap cutting on the withdrawal? 

I normally tap in low gear at less than 300 rpms to cut down on the 
overshoot. The actual delay is hard to measure, so the only place I've 
tested is from 3k to 3k the other direction, and it does that in about 
400 milliseconds. At 250 revs, its well under a turn of the spindle and 
looks instant but the human eye is very slow.

> > Semi-rigid tapping with a floating holder could be an option with a
> > very low count encoder.
> >
> > I think that 100ppr might be enough for tapping. I wouldn't want to
> > go much lower.
> > Then choose spindle speeds where the software counter can keep up.
>
> Andy is correct of course, I was wrong about rigid tapping.
>
>
> Cheers, Gene Heskett


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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-08 Thread John Dammeyer

The BASE_PERIOD value is in nanoseconds and the clue is _PERIOD which is the 
inverse of FREQUENCY.  
So 
1000Hz => 1/1000 = 0.001 or 1000 microseconds.  
2000Hz => 1/2000 = 0.0005 or 500 microseconds.

As the frequency gets higher, the period gets smaller.

JOHN


> -Original Message-
> From: Dan Henderson [mailto:luvtof...@gmail.com]
> Sent: May-08-20 4:42 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> 
> Jon,
> Yours is 24,000 and equals to 41.6667kHz? Mine is 100,000 and equates to 10 
> kHz.  I�m confused by your math here? Thanks.
> 
> Sent from my iPad
> 
> > On May 7, 2020, at 9:39 PM, John Dammeyer  wrote:
> >
> > ?
> >>
> >> From: Dan Henderson [mailto:luvtof...@gmail.com]
> >
> >> Thanks for that Jon. That helps explain this a bit further. I believe the
> >> base period in the ini is set to 100,000. Not sure if that is nS or u
> >> value? Can this be change to suit or is it tied to the speed of the system?
> >
> > Hi Dan,
> > All of my comments are based on what I think I've learned so far.  If 
> > anyone else sees an error please correct me.
> >
> > It's in nano-seconds and it's pretty big on your system and works out to 
> > 10kHz.  That's the max step rate you will get from your
> system as long as you have the addf parport.0.reset base-thread.  Otherwise 
> the max step rate is half that.
> >
> > You generally get that value from running the program that tests your 
> > system for latency.  The jitter you get from that test will
> change how accurate that 24uS period actually is.
> >
> > From my INI file
> > BASE_PERIOD = 24000  <-- This is 24,000 nS or 24uS or 0.24 seconds and 
> > equivalent to 41.6667kHz.
> > SERVO_PERIOD = 100 <-- this is 1 million nano-seconds or 1mS equivalent 
> > to 1kHz.
> >
> > So what does it mean?
> > From your HAL file.
> >
> > loadrt trivkins
> > loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD 
> > servo_period_nsec=[EMCMOT]SERVO_PERIOD
> num_joints=[TRAJ]AXES
> > loadrt hal_parport cfg="0xe000 out 0xe800 out"
> > loadrt stepgen step_type=0,0,0
> > loadrt encoder num_chan=1
> > loadrt abs count=1
> > loadrt scale count=1
> > loadrt lowpass count=1
> > loadrt near
> > loadrt pwmgen output_type=1
> >
> > Inside each of these files is a function called
> > int rtapi_app_main(void) {...}
> >
> > In that function the command line arguments like step_type are parsed and 
> > default values are set up. Here's how the Parallel
> port read function is configured.
> >/* make read function name */
> >rtapi_snprintf(name, sizeof(name), "parport.%d.read", n);
> >/* export read function */
> >   retval = hal_export_funct(name, read_port, 
> > &(port_data_array[n]),0, 0, comp_id);
> > with the names of the functions you add later in the HAL file with commands 
> > like:
> >
> > addf parport.0.read base-thread
> >
> > each addf function with base-thread as an argument must run to completion 
> > in less than 24uS on my system or there won't be
> time for anything else.Each of these programs, generally found in the 
> src/hal or src/emc path.
> >
> > The ones marked servo-thread  run once every SERVO_PERIOD which is set at  
> > 1mS.
> >
> > The PID runs once per 1mS.  The stepgen runs every 24uS on my system.
> >
> > Hopefully this helps.  So you know the 'why' rather than just do this and 
> > tell us what happened.
> >
> > John Dammeyer
> >
> >>
> >>> On Thu, May 7, 2020 at 6:54 PM John Dammeyer  
> >>> wrote:
> >>>
> >>>
> >>> If you look at the source code for "encoders.c" John Kasunich's excellent
> >>> documentation says this:
> >>>
> >>>"The driver exports variables for each counters inputs and output.
> >>>It also exports two functions.  "encoder.update-counters" must be
> >>>called in a high speed thread, at least twice the maximum desired
> >>>count rate.  "encoder.capture-position" can be called at a much
> >>>slower rate, and updates the output variables."
> >>>
> >>> So if your encoder provides a quadrature count of 200 lines (800
> >>> quadrature) and you turn that spindle at 4700 RPM (78.RPS) then 800
> >>> pulses/turn * 78.3 turns/sec  = 62.666KHz so your BASE_PER

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On Friday 08 May 2020 06:59:44 andy pugh wrote:

> On Fri, 8 May 2020 at 01:23, Gene Heskett  wrote:
> > If the spindle speed is steady, I have heard of folks doing rigid
> > tapping with 1 ppr.  Ditto g76.
>
> You can do G76 with 1ppr, but not, sensibly, rigid tapping.
>
> For rigid tapping you need quadrature to detect the moment of spindle
> reversal. There is no reliable way to interpolate that.
>
> Semi-rigid tapping with a floating holder could be an option with a
> very low count encoder.
>
> I think that 100ppr might be enough for tapping. I wouldn't want to go
> much lower.
> Then choose spindle speeds where the software counter can keep up.

Andy is correct of course, I was wrong about rigid tapping.


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] Fluctuating RPM using CUI ATM 10 encoder

Jon,
Yours is 24,000 and equals to 41.6667kHz? Mine is 100,000 and equates to 10 
kHz.  I’m confused by your math here? Thanks. 

Sent from my iPad

> On May 7, 2020, at 9:39 PM, John Dammeyer  wrote:
> 
> 
>> 
>> From: Dan Henderson [mailto:luvtof...@gmail.com]
> 
>> Thanks for that Jon. That helps explain this a bit further. I believe the
>> base period in the ini is set to 100,000. Not sure if that is nS or u
>> value? Can this be change to suit or is it tied to the speed of the system?
> 
> Hi Dan,
> All of my comments are based on what I think I've learned so far.  If anyone 
> else sees an error please correct me.
> 
> It's in nano-seconds and it's pretty big on your system and works out to 
> 10kHz.  That's the max step rate you will get from your system as long as you 
> have the addf parport.0.reset base-thread.  Otherwise the max step rate is 
> half that.
> 
> You generally get that value from running the program that tests your system 
> for latency.  The jitter you get from that test will change how accurate that 
> 24uS period actually is.
> 
> From my INI file
> BASE_PERIOD = 24000  <-- This is 24,000 nS or 24uS or 0.24 seconds and 
> equivalent to 41.6667kHz. 
> SERVO_PERIOD = 100 <-- this is 1 million nano-seconds or 1mS equivalent 
> to 1kHz.
> 
> So what does it mean?
> From your HAL file.
> 
> loadrt trivkins
> loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD 
> servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
> loadrt hal_parport cfg="0xe000 out 0xe800 out"
> loadrt stepgen step_type=0,0,0
> loadrt encoder num_chan=1
> loadrt abs count=1
> loadrt scale count=1
> loadrt lowpass count=1
> loadrt near
> loadrt pwmgen output_type=1
> 
> Inside each of these files is a function called 
> int rtapi_app_main(void) {...}
> 
> In that function the command line arguments like step_type are parsed and 
> default values are set up. Here's how the Parallel port read function is 
> configured.
>/* make read function name */
>rtapi_snprintf(name, sizeof(name), "parport.%d.read", n);
>/* export read function */
>   retval = hal_export_funct(name, read_port, 
> &(port_data_array[n]),0, 0, comp_id);
> with the names of the functions you add later in the HAL file with commands 
> like:
> 
> addf parport.0.read base-thread
>
> each addf function with base-thread as an argument must run to completion in 
> less than 24uS on my system or there won't be time for anything else.Each 
> of these programs, generally found in the src/hal or src/emc path.
> 
> The ones marked servo-thread  run once every SERVO_PERIOD which is set at  
> 1mS.  
> 
> The PID runs once per 1mS.  The stepgen runs every 24uS on my system.
> 
> Hopefully this helps.  So you know the 'why' rather than just do this and 
> tell us what happened.
> 
> John Dammeyer
> 
>> 
>>> On Thu, May 7, 2020 at 6:54 PM John Dammeyer  wrote:
>>> 
>>> 
>>> If you look at the source code for "encoders.c" John Kasunich's excellent
>>> documentation says this:
>>> 
>>>"The driver exports variables for each counters inputs and output.
>>>It also exports two functions.  "encoder.update-counters" must be
>>>called in a high speed thread, at least twice the maximum desired
>>>count rate.  "encoder.capture-position" can be called at a much
>>>slower rate, and updates the output variables."
>>> 
>>> So if your encoder provides a quadrature count of 200 lines (800
>>> quadrature) and you turn that spindle at 4700 RPM (78.RPS) then 800
>>> pulses/turn * 78.3 turns/sec  = 62.666KHz so your BASE_PERIOD must be
>>> at least 125kHz (8,000 nS)
>>> 
>>> In your working example 1200 RPM is 20 RPS * 800 = 16,000 and twice that
>>> is 32,000Hz (31,250 nS BASE_PERIOD).
>>> What is your BASE_PERIOD set at in your INI file?
>>> 
>>> Work it backwards.  For example my PP HAL file says 24,000nS for the BASE
>>> THREAD (41,667kHz).  Assuming I have a 200 line encoder on the spindle then
>>> 41,667kHz/2=20,8333 and divided by 800 = 26 RPS or 1562 RPM.  Since I want
>>> to turn my spindle up to 3000 RPM that means either I have to decrease the
>>> BASE_PERIOD (increase frequency)  or reduce the spindle encoder count to
>>> about 100.
>>> 
>>> That means I need no more than 100 slots per rev on a disk.  That's doable
>>> and from what I've read lots of people can thread with that.
>>> 
>>> And, Sam Sokolik has been able to do rudimentary hex holes (although
>>> slowly) with less than that.
>>> 
>>> Now since I have a MESA 7i92H all the numbers will change.  I've not yet
>>> looked at the MESA software.
>>> 
>>> Haven't even really followed the entire path from a
>>> G33.1 Z-0.55 K0.025
>>> to the Z axis motion in steps/second tracking spindle RPM.
>>> 
>>> John Dammeyer
>>> 
> 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-08 Thread andy pugh

On Fri, 8 May 2020 at 01:23, Gene Heskett  wrote:

> If the spindle speed is steady, I have heard of folks doing rigid tapping
> with 1 ppr.  Ditto g76.

You can do G76 with 1ppr, but not, sensibly, rigid tapping.

For rigid tapping you need quadrature to detect the moment of spindle
reversal. There is no reliable way to interpolate that.

Semi-rigid tapping with a floating holder could be an option with a
very low count encoder.

I think that 100ppr might be enough for tapping. I wouldn't want to go
much lower.
Then choose spindle speeds where the software counter can keep up.

-- 
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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-07 Thread John Dammeyer

> From: Dan Henderson [mailto:luvtof...@gmail.com]

> Thanks for that Jon. That helps explain this a bit further. I believe the
> base period in the ini is set to 100,000. Not sure if that is nS or u
> value? Can this be change to suit or is it tied to the speed of the system?

Hi Dan,
All of my comments are based on what I think I've learned so far.  If anyone 
else sees an error please correct me.

It's in nano-seconds and it's pretty big on your system and works out to 10kHz. 
 That's the max step rate you will get from your system as long as you have the 
addf parport.0.reset base-thread.  Otherwise the max step rate is half that.

You generally get that value from running the program that tests your system 
for latency.  The jitter you get from that test will change how accurate that 
24uS period actually is.

>From my INI file
BASE_PERIOD = 24000  <-- This is 24,000 nS or 24uS or 0.24 seconds and 
equivalent to 41.6667kHz. 
SERVO_PERIOD = 100 <-- this is 1 million nano-seconds or 1mS equivalent to 
1kHz.

So what does it mean?
>From your HAL file.

loadrt trivkins
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD 
servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
loadrt hal_parport cfg="0xe000 out 0xe800 out"
loadrt stepgen step_type=0,0,0
loadrt encoder num_chan=1
loadrt abs count=1
loadrt scale count=1
loadrt lowpass count=1
loadrt near
loadrt pwmgen output_type=1

Inside each of these files is a function called 
int rtapi_app_main(void) {...}

In that function the command line arguments like step_type are parsed and 
default values are set up. Here's how the Parallel port read function is 
configured.
/* make read function name */
rtapi_snprintf(name, sizeof(name), "parport.%d.read", n);
/* export read function */  
   retval = hal_export_funct(name, read_port, 
&(port_data_array[n]),0, 0, comp_id);
with the names of the functions you add later in the HAL file with commands 
like:

addf parport.0.read base-thread

each addf function with base-thread as an argument must run to completion in 
less than 24uS on my system or there won't be time for anything else.Each 
of these programs, generally found in the src/hal or src/emc path.

The ones marked servo-thread  run once every SERVO_PERIOD which is set at  1mS. 

The PID runs once per 1mS.  The stepgen runs every 24uS on my system.

Hopefully this helps.  So you know the 'why' rather than just do this and tell 
us what happened.

John Dammeyer

> 
> On Thu, May 7, 2020 at 6:54 PM John Dammeyer  wrote:
> 
> >
> > If you look at the source code for "encoders.c" John Kasunich's excellent
> > documentation says this:
> >
> > "The driver exports variables for each counters inputs and output.
> > It also exports two functions.  "encoder.update-counters" must be
> > called in a high speed thread, at least twice the maximum desired
> > count rate.  "encoder.capture-position" can be called at a much
> > slower rate, and updates the output variables."
> >
> > So if your encoder provides a quadrature count of 200 lines (800
> > quadrature) and you turn that spindle at 4700 RPM (78.RPS) then 800
> > pulses/turn * 78.3 turns/sec  = 62.666KHz so your BASE_PERIOD must be
> > at least 125kHz (8,000 nS)
> >
> > In your working example 1200 RPM is 20 RPS * 800 = 16,000 and twice that
> > is 32,000Hz (31,250 nS BASE_PERIOD).
> > What is your BASE_PERIOD set at in your INI file?
> >
> > Work it backwards.  For example my PP HAL file says 24,000nS for the BASE
> > THREAD (41,667kHz).  Assuming I have a 200 line encoder on the spindle then
> > 41,667kHz/2=20,8333 and divided by 800 = 26 RPS or 1562 RPM.  Since I want
> > to turn my spindle up to 3000 RPM that means either I have to decrease the
> > BASE_PERIOD (increase frequency)  or reduce the spindle encoder count to
> > about 100.
> >
> > That means I need no more than 100 slots per rev on a disk.  That's doable
> > and from what I've read lots of people can thread with that.
> >
> > And, Sam Sokolik has been able to do rudimentary hex holes (although
> > slowly) with less than that.
> >
> > Now since I have a MESA 7i92H all the numbers will change.  I've not yet
> > looked at the MESA software.
> >
> > Haven't even really followed the entire path from a
> > G33.1 Z-0.55 K0.025
> > to the Z axis motion in steps/second tracking spindle RPM.
> >
> > John Dammeyer
> >

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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

Thanks for that Jon. That helps explain this a bit further. I believe the
base period in the ini is set to 100,000. Not sure if that is nS or u
value? Can this be change to suit or is it tied to the speed of the system?

On Thu, May 7, 2020 at 6:54 PM John Dammeyer  wrote:

>
> > -Original Message-
> > From: Dan Henderson [mailto:luvtof...@gmail.com]
> > Sent: May-07-20 2:40 PM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> >
> > Why certainly Gene (see attached). I actually have it working a little
> > better now. My spindle-at-speed LED will start going bonkers around 1200
> > rpm. I'm guessing this is when the counter "throws up it's hands and
> says -
> > I quit!" lol. The spindle will operate all the way to around 4700 rpm but
> > anything above this and the MC-2100 shuts it down -- must be some kind of
> > voltage limiter kicking in then.
> >
>
> If you look at the source code for "encoders.c" John Kasunich's excellent
> documentation says this:
>
> "The driver exports variables for each counters inputs and output.
> It also exports two functions.  "encoder.update-counters" must be
> called in a high speed thread, at least twice the maximum desired
> count rate.  "encoder.capture-position" can be called at a much
> slower rate, and updates the output variables."
>
> So if your encoder provides a quadrature count of 200 lines (800
> quadrature) and you turn that spindle at 4700 RPM (78.RPS) then 800
> pulses/turn * 78.3 turns/sec  = 62.666KHz so your BASE_PERIOD must be
> at least 125kHz (8,000 nS)
>
> In your working example 1200 RPM is 20 RPS * 800 = 16,000 and twice that
> is 32,000Hz (31,250 nS BASE_PERIOD).
> What is your BASE_PERIOD set at in your INI file?
>
> Work it backwards.  For example my PP HAL file says 24,000nS for the BASE
> THREAD (41,667kHz).  Assuming I have a 200 line encoder on the spindle then
> 41,667kHz/2=20,8333 and divided by 800 = 26 RPS or 1562 RPM.  Since I want
> to turn my spindle up to 3000 RPM that means either I have to decrease the
> BASE_PERIOD (increase frequency)  or reduce the spindle encoder count to
> about 100.
>
> That means I need no more than 100 slots per rev on a disk.  That's doable
> and from what I've read lots of people can thread with that.
>
> And, Sam Sokolik has been able to do rudimentary hex holes (although
> slowly) with less than that.
>
> Now since I have a MESA 7i92H all the numbers will change.  I've not yet
> looked at the MESA software.
>
> Haven't even really followed the entire path from a
> G33.1 Z-0.55 K0.025
> to the Z axis motion in steps/second tracking spindle RPM.
>
> John Dammeyer
>
>
> >
> >
> >
> >
> > On Thu, May 7, 2020 at 2:29 PM Gene Heskett 
> wrote:
> >
> > > On Thursday 07 May 2020 13:19:23 Dan Henderson wrote:
> > >
> > > > I believe this is open loop. Isn�t PID only used in closed loop
> > > > control?
> > > >
> > > Its (the PID is) a waste of processor time if open loop. I don't use
> one
> > > of those in any spindle run by a vfd, the vfd is generally stiff enough
> > > control by itself. If I thread on that machine, it will have a spindle
> > > encoder, but its only job is to glue the axis motion being driven to
> cut
> > > the thread, to the spindle rotation, in the case of a g33.1, going both
> > > in and out of the hole. If you aren't useing a PID for the spindle,
> that
> > > leaves motion I think.
> > >
> > > I think its time we saw your .hal file. Can you insert it into a mail?
> > >
> > > > On Thu, May 7, 2020 at 11:03 AM Gene Heskett 
> > > wrote:
> > > > > On Thursday 07 May 2020 11:27:57 Jon Elson wrote:
> > > > > > On 05/06/2020 09:20 PM, Dan Henderson wrote:
> > > > > > > I�ve confirmed the fluctuation occurs when spindle-at-speed is
> > > > > > > configured. When I remove this feature, the spindle rpm appears
> > > > > > > to stabilize. It�s almost like it gets caught in a loop trying
> > > > > > > to chase its tail.
> > > > > >
> > > > > > This is VERY common in servo systems, and is due to delay in
> > > > > > response of the object being controlled.
> > > > > > You need to slow down the response of the PID to ignore the
> > > > > > delay. This may be possible by adding
> > > > > > D to it.
> > > >

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On Thursday 07 May 2020 19:33:49 Dan Henderson wrote:

> Thanks Gene! I can go down to 48 PPR on the encoder. If I do so, what
> is the trade off for reducing resolution on my mill project? Is that
> enough to successfully use rigid tapping and synchronized feed/speeds?

If the spindle speed is steady, I have heard of folks doing rigid tapping 
with 1 ppr.  Ditto g76.  I have not personally tried it.  Somebody that 
may have made it work might be Sam S., he seems to oooze black magic at 
times.  I'd think it might need 5 or so turns of clearance for a 
starting position just so it could get a better average, but thats just 
a SWAG. IDK for sure.

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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-07 Thread John Dammeyer

> -Original Message-
> From: Dan Henderson [mailto:luvtof...@gmail.com]
> Sent: May-07-20 2:40 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> 
> Why certainly Gene (see attached). I actually have it working a little
> better now. My spindle-at-speed LED will start going bonkers around 1200
> rpm. I'm guessing this is when the counter "throws up it's hands and says -
> I quit!" lol. The spindle will operate all the way to around 4700 rpm but
> anything above this and the MC-2100 shuts it down -- must be some kind of
> voltage limiter kicking in then.
> 

If you look at the source code for "encoders.c" John Kasunich's excellent 
documentation says this:

"The driver exports variables for each counters inputs and output.
It also exports two functions.  "encoder.update-counters" must be
called in a high speed thread, at least twice the maximum desired
count rate.  "encoder.capture-position" can be called at a much
slower rate, and updates the output variables."

So if your encoder provides a quadrature count of 200 lines (800 quadrature) 
and you turn that spindle at 4700 RPM (78.RPS) then 800 pulses/turn * 
78.3 turns/sec  = 62.666KHz so your BASE_PERIOD must be at least 125kHz 
(8,000 nS)  

In your working example 1200 RPM is 20 RPS * 800 = 16,000 and twice that is 
32,000Hz (31,250 nS BASE_PERIOD).  
What is your BASE_PERIOD set at in your INI file?

Work it backwards.  For example my PP HAL file says 24,000nS for the BASE 
THREAD (41,667kHz).  Assuming I have a 200 line encoder on the spindle then 
41,667kHz/2=20,8333 and divided by 800 = 26 RPS or 1562 RPM.  Since I want to 
turn my spindle up to 3000 RPM that means either I have to decrease the 
BASE_PERIOD (increase frequency)  or reduce the spindle encoder count to about 
100.

That means I need no more than 100 slots per rev on a disk.  That's doable and 
from what I've read lots of people can thread with that.

And, Sam Sokolik has been able to do rudimentary hex holes (although slowly) 
with less than that.

Now since I have a MESA 7i92H all the numbers will change.  I've not yet looked 
at the MESA software.  

Haven't even really followed the entire path from a 
G33.1 Z-0.55 K0.025
to the Z axis motion in steps/second tracking spindle RPM.

John Dammeyer

> 
> 
> 
> 
> On Thu, May 7, 2020 at 2:29 PM Gene Heskett  wrote:
> 
> > On Thursday 07 May 2020 13:19:23 Dan Henderson wrote:
> >
> > > I believe this is open loop. Isn�t PID only used in closed loop
> > > control?
> > >
> > Its (the PID is) a waste of processor time if open loop. I don't use one
> > of those in any spindle run by a vfd, the vfd is generally stiff enough
> > control by itself. If I thread on that machine, it will have a spindle
> > encoder, but its only job is to glue the axis motion being driven to cut
> > the thread, to the spindle rotation, in the case of a g33.1, going both
> > in and out of the hole. If you aren't useing a PID for the spindle, that
> > leaves motion I think.
> >
> > I think its time we saw your .hal file. Can you insert it into a mail?
> >
> > > On Thu, May 7, 2020 at 11:03 AM Gene Heskett 
> > wrote:
> > > > On Thursday 07 May 2020 11:27:57 Jon Elson wrote:
> > > > > On 05/06/2020 09:20 PM, Dan Henderson wrote:
> > > > > > I�ve confirmed the fluctuation occurs when spindle-at-speed is
> > > > > > configured. When I remove this feature, the spindle rpm appears
> > > > > > to stabilize. It�s almost like it gets caught in a loop trying
> > > > > > to chase its tail.
> > > > >
> > > > > This is VERY common in servo systems, and is due to delay in
> > > > > response of the object being controlled.
> > > > > You need to slow down the response of the PID to ignore the
> > > > > delay. This may be possible by adding
> > > > > D to it.
> > > > >
> > > > > Jon
> > > >
> > > > But my msg was that a near module generated spindle.N.at-speed was
> > > > never to be injected into any signal path leading back to a PID.
> > > > That near's output s/b only to that input to motion, and possibly to
> > > > an indicator led in the gui so the operator can be advised if its
> > > > acting funkity. Flickering could be worn brushes in a brushed PMDC
> > > > motor for instance.
> > > >
> > > > What you are describing as delays can often be fixed by the proper
> > > > re-ordering of the addf's involved for the oscillating axi

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

Thanks Gene! I can go down to 48 PPR on the encoder. If I do so, what is
the trade off for reducing resolution on my mill project? Is that enough to
successfully use rigid tapping and synchronized feed/speeds?

On Thu, May 7, 2020 at 5:45 PM Gene Heskett  wrote:

> On Thursday 07 May 2020 17:39:32 Dan Henderson wrote:
>
> > Why certainly Gene (see attached). I actually have it working a little
> > better now. My spindle-at-speed LED will start going bonkers around
> > 1200 rpm. I'm guessing this is when the counter "throws up it's hands
> > and says - I quit!" lol. The spindle will operate all the way to
> > around 4700 rpm but anything above this and the MC-2100 shuts it down
> > -- must be some kind of voltage limiter kicking in then.
> >
> The one time I tried to use one of them was a failure, it seemed to have
> a mind of its own.  I made a power supply and bought one of the pico
> systems pwm-servo's. Bulletproof but be sure and tell Jon you are going
> to drive a PMDC spindle motor with it so he'll add more toroids so it
> runs cooler when working continuously.
>
> That said, your config is as well laid out as any I've looked at, and I
> don't see anything wrong at all. But I can also see how the parport and
> its missing of the encoders signals could be all of the higher speed
> problems.  The 4700 limit might be the pwmgen going to 100% duty, losing
> the 0% recharge pulse. You can check that with halscope. I run more
> voltage than the mc2100 can muster, so I can spin a treadmill motor up
> to where I worry about the cast iron fan/pulley exploding but set limits
> somewhat below that, probably around 7 grand max. Even though its geared
> 3/1 before it gets near the spindle drive, its still too fast to cut
> steel.
>
> If you can set the encoder even lower you might get to a couple thousand
> revs before the tach gets funkity.
>
> 18:40 here, I'd better go see what my missus wants for dinner.
>
>
> > On Thu, May 7, 2020 at 2:29 PM Gene Heskett 
> wrote:
> > > On Thursday 07 May 2020 13:19:23 Dan Henderson wrote:
> > > > I believe this is open loop. Isn’t PID only used in closed loop
> > > > control?
> > >
> > > Its (the PID is) a waste of processor time if open loop. I don't use
> > > one of those in any spindle run by a vfd, the vfd is generally stiff
> > > enough control by itself. If I thread on that machine, it will have
> > > a spindle encoder, but its only job is to glue the axis motion being
> > > driven to cut the thread, to the spindle rotation, in the case of a
> > > g33.1, going both in and out of the hole. If you aren't useing a PID
> > > for the spindle, that leaves motion I think.
> > >
> > > I think its time we saw your .hal file. Can you insert it into a
> > > mail?
> > >
> > > > On Thu, May 7, 2020 at 11:03 AM Gene Heskett
> > > > 
> > >
> > > wrote:
> > > > > On Thursday 07 May 2020 11:27:57 Jon Elson wrote:
> > > > > > On 05/06/2020 09:20 PM, Dan Henderson wrote:
> > > > > > > I’ve confirmed the fluctuation occurs when spindle-at-speed
> > > > > > > is configured. When I remove this feature, the spindle rpm
> > > > > > > appears to stabilize. It’s almost like it gets caught in a
> > > > > > > loop trying to chase its tail.
> > > > > >
> > > > > > This is VERY common in servo systems, and is due to delay in
> > > > > > response of the object being controlled.
> > > > > > You need to slow down the response of the PID to ignore the
> > > > > > delay. This may be possible by adding
> > > > > > D to it.
> > > > > >
> > > > > > Jon
> > > > >
> > > > > But my msg was that a near module generated spindle.N.at-speed
> > > > > was never to be injected into any signal path leading back to a
> > > > > PID. That near's output s/b only to that input to motion, and
> > > > > possibly to an indicator led in the gui so the operator can be
> > > > > advised if its acting funkity. Flickering could be worn brushes
> > > > > in a brushed PMDC motor for instance.
> > > > >
> > > > > What you are describing as delays can often be fixed by the
> > > > > proper re-ordering of the addf's involved for the oscillating
> > > > > axis. That aspect of configuring LinuxCNC hasn't been mentioned
> > > > > recently or I wouldn't even have included that paragraph in my
> > > > > reply.
> > > > >
> > > > > And from Dan's description above, I think this is an entirely
> > > > > different critter from a timeing delay.
> > > > >
> > > > > Cheers Jon & stay well, 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] Fluctuating RPM using CUI ATM 10 encoder

On Thursday 07 May 2020 17:39:32 Dan Henderson wrote:

> Why certainly Gene (see attached). I actually have it working a little
> better now. My spindle-at-speed LED will start going bonkers around
> 1200 rpm. I'm guessing this is when the counter "throws up it's hands
> and says - I quit!" lol. The spindle will operate all the way to
> around 4700 rpm but anything above this and the MC-2100 shuts it down
> -- must be some kind of voltage limiter kicking in then.
>
The one time I tried to use one of them was a failure, it seemed to have 
a mind of its own.  I made a power supply and bought one of the pico 
systems pwm-servo's. Bulletproof but be sure and tell Jon you are going 
to drive a PMDC spindle motor with it so he'll add more toroids so it 
runs cooler when working continuously.

That said, your config is as well laid out as any I've looked at, and I 
don't see anything wrong at all. But I can also see how the parport and 
its missing of the encoders signals could be all of the higher speed 
problems.  The 4700 limit might be the pwmgen going to 100% duty, losing 
the 0% recharge pulse. You can check that with halscope. I run more 
voltage than the mc2100 can muster, so I can spin a treadmill motor up 
to where I worry about the cast iron fan/pulley exploding but set limits 
somewhat below that, probably around 7 grand max. Even though its geared 
3/1 before it gets near the spindle drive, its still too fast to cut 
steel.

If you can set the encoder even lower you might get to a couple thousand 
revs before the tach gets funkity.

18:40 here, I'd better go see what my missus wants for dinner.


> On Thu, May 7, 2020 at 2:29 PM Gene Heskett  
wrote:
> > On Thursday 07 May 2020 13:19:23 Dan Henderson wrote:
> > > I believe this is open loop. Isn’t PID only used in closed loop
> > > control?
> >
> > Its (the PID is) a waste of processor time if open loop. I don't use
> > one of those in any spindle run by a vfd, the vfd is generally stiff
> > enough control by itself. If I thread on that machine, it will have
> > a spindle encoder, but its only job is to glue the axis motion being
> > driven to cut the thread, to the spindle rotation, in the case of a
> > g33.1, going both in and out of the hole. If you aren't useing a PID
> > for the spindle, that leaves motion I think.
> >
> > I think its time we saw your .hal file. Can you insert it into a
> > mail?
> >
> > > On Thu, May 7, 2020 at 11:03 AM Gene Heskett
> > > 
> >
> > wrote:
> > > > On Thursday 07 May 2020 11:27:57 Jon Elson wrote:
> > > > > On 05/06/2020 09:20 PM, Dan Henderson wrote:
> > > > > > I’ve confirmed the fluctuation occurs when spindle-at-speed
> > > > > > is configured. When I remove this feature, the spindle rpm
> > > > > > appears to stabilize. It’s almost like it gets caught in a
> > > > > > loop trying to chase its tail.
> > > > >
> > > > > This is VERY common in servo systems, and is due to delay in
> > > > > response of the object being controlled.
> > > > > You need to slow down the response of the PID to ignore the
> > > > > delay. This may be possible by adding
> > > > > D to it.
> > > > >
> > > > > Jon
> > > >
> > > > But my msg was that a near module generated spindle.N.at-speed
> > > > was never to be injected into any signal path leading back to a
> > > > PID. That near's output s/b only to that input to motion, and
> > > > possibly to an indicator led in the gui so the operator can be
> > > > advised if its acting funkity. Flickering could be worn brushes
> > > > in a brushed PMDC motor for instance.
> > > >
> > > > What you are describing as delays can often be fixed by the
> > > > proper re-ordering of the addf's involved for the oscillating
> > > > axis. That aspect of configuring LinuxCNC hasn't been mentioned
> > > > recently or I wouldn't even have included that paragraph in my
> > > > reply.
> > > >
> > > > And from Dan's description above, I think this is an entirely
> > > > different critter from a timeing delay.
> > > >
> > > > Cheers Jon & stay well, 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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

Why certainly Gene (see attached). I actually have it working a little
better now. My spindle-at-speed LED will start going bonkers around 1200
rpm. I'm guessing this is when the counter "throws up it's hands and says -
I quit!" lol. The spindle will operate all the way to around 4700 rpm but
anything above this and the MC-2100 shuts it down -- must be some kind of
voltage limiter kicking in then.





On Thu, May 7, 2020 at 2:29 PM Gene Heskett  wrote:

> On Thursday 07 May 2020 13:19:23 Dan Henderson wrote:
>
> > I believe this is open loop. Isn’t PID only used in closed loop
> > control?
> >
> Its (the PID is) a waste of processor time if open loop. I don't use one
> of those in any spindle run by a vfd, the vfd is generally stiff enough
> control by itself. If I thread on that machine, it will have a spindle
> encoder, but its only job is to glue the axis motion being driven to cut
> the thread, to the spindle rotation, in the case of a g33.1, going both
> in and out of the hole. If you aren't useing a PID for the spindle, that
> leaves motion I think.
>
> I think its time we saw your .hal file. Can you insert it into a mail?
>
> > On Thu, May 7, 2020 at 11:03 AM Gene Heskett 
> wrote:
> > > On Thursday 07 May 2020 11:27:57 Jon Elson wrote:
> > > > On 05/06/2020 09:20 PM, Dan Henderson wrote:
> > > > > I’ve confirmed the fluctuation occurs when spindle-at-speed is
> > > > > configured. When I remove this feature, the spindle rpm appears
> > > > > to stabilize. It’s almost like it gets caught in a loop trying
> > > > > to chase its tail.
> > > >
> > > > This is VERY common in servo systems, and is due to delay in
> > > > response of the object being controlled.
> > > > You need to slow down the response of the PID to ignore the
> > > > delay. This may be possible by adding
> > > > D to it.
> > > >
> > > > Jon
> > >
> > > But my msg was that a near module generated spindle.N.at-speed was
> > > never to be injected into any signal path leading back to a PID.
> > > That near's output s/b only to that input to motion, and possibly to
> > > an indicator led in the gui so the operator can be advised if its
> > > acting funkity. Flickering could be worn brushes in a brushed PMDC
> > > motor for instance.
> > >
> > > What you are describing as delays can often be fixed by the proper
> > > re-ordering of the addf's involved for the oscillating axis. That
> > > aspect of configuring LinuxCNC hasn't been mentioned recently or I
> > > wouldn't even have included that paragraph in my reply.
> > >
> > > And from Dan's description above, I think this is an entirely
> > > different critter from a timeing delay.
> > >
> > > Cheers Jon & stay well, 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
>


my-mill.hal
Description: Binary data


custom_postgui.hal
Description: Binary data


 
 RIDGE 
 6

"Spindle Speed:"
("Helvetica",20)


"spindle-speed"
3000


"Spindle-At-Speed:"
("Helvetica",20)



" "
("Helvetica",20)


"spindle-at-speed-led" 
30 
"green"
"red"




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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On Thursday 07 May 2020 13:19:23 Dan Henderson wrote:

> I believe this is open loop. Isn’t PID only used in closed loop
> control?
>
Its (the PID is) a waste of processor time if open loop. I don't use one 
of those in any spindle run by a vfd, the vfd is generally stiff enough 
control by itself. If I thread on that machine, it will have a spindle 
encoder, but its only job is to glue the axis motion being driven to cut 
the thread, to the spindle rotation, in the case of a g33.1, going both 
in and out of the hole. If you aren't useing a PID for the spindle, that 
leaves motion I think.

I think its time we saw your .hal file. Can you insert it into a mail?

> On Thu, May 7, 2020 at 11:03 AM Gene Heskett  
wrote:
> > On Thursday 07 May 2020 11:27:57 Jon Elson wrote:
> > > On 05/06/2020 09:20 PM, Dan Henderson wrote:
> > > > I’ve confirmed the fluctuation occurs when spindle-at-speed is
> > > > configured. When I remove this feature, the spindle rpm appears
> > > > to stabilize. It’s almost like it gets caught in a loop trying
> > > > to chase its tail.
> > >
> > > This is VERY common in servo systems, and is due to delay in
> > > response of the object being controlled.
> > > You need to slow down the response of the PID to ignore the
> > > delay. This may be possible by adding
> > > D to it.
> > >
> > > Jon
> >
> > But my msg was that a near module generated spindle.N.at-speed was
> > never to be injected into any signal path leading back to a PID. 
> > That near's output s/b only to that input to motion, and possibly to
> > an indicator led in the gui so the operator can be advised if its
> > acting funkity. Flickering could be worn brushes in a brushed PMDC
> > motor for instance.
> >
> > What you are describing as delays can often be fixed by the proper
> > re-ordering of the addf's involved for the oscillating axis. That
> > aspect of configuring LinuxCNC hasn't been mentioned recently or I
> > wouldn't even have included that paragraph in my reply.
> >
> > And from Dan's description above, I think this is an entirely
> > different critter from a timeing delay.
> >
> > Cheers Jon & stay well, 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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-07 Thread Jon Elson


On 05/07/2020 12:19 PM, Dan Henderson wrote:

I believe this is open loop. Isn’t PID only used in closed loop control?


Oh, so the situation with and without spindle-at-speed were 
BOTH open loop?  That is
totally different, then, and now I have no idea what is 
going on. But, checking all signals

related to the spindle speed control with Halscope is indicated.

Jon


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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

I believe this is open loop. Isn’t PID only used in closed loop control?

On Thu, May 7, 2020 at 11:03 AM Gene Heskett  wrote:

> On Thursday 07 May 2020 11:27:57 Jon Elson wrote:
>
> > On 05/06/2020 09:20 PM, Dan Henderson wrote:
> > > I’ve confirmed the fluctuation occurs when spindle-at-speed is
> > > configured. When I remove this feature, the spindle rpm appears to
> > > stabilize. It’s almost like it gets caught in a loop trying to chase
> > > its tail.
> >
> > This is VERY common in servo systems, and is due to delay in
> > response of the object being controlled.
> > You need to slow down the response of the PID to ignore the
> > delay. This may be possible by adding
> > D to it.
> >
> > Jon
>
> But my msg was that a near module generated spindle.N.at-speed was never
> to be injected into any signal path leading back to a PID.  That near's
> output s/b only to that input to motion, and possibly to an indicator
> led in the gui so the operator can be advised if its acting funkity.
> Flickering could be worn brushes in a brushed PMDC motor for instance.
>
> What you are describing as delays can often be fixed by the proper
> re-ordering of the addf's involved for the oscillating axis. That aspect
> of configuring LinuxCNC hasn't been mentioned recently or I wouldn't
> even have included that paragraph in my reply.
>
> And from Dan's description above, I think this is an entirely different
> critter from a timeing delay.
>
> Cheers Jon & stay well, 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] Fluctuating RPM using CUI ATM 10 encoder

On Thursday 07 May 2020 11:27:57 Jon Elson wrote:

> On 05/06/2020 09:20 PM, Dan Henderson wrote:
> > I’ve confirmed the fluctuation occurs when spindle-at-speed is
> > configured. When I remove this feature, the spindle rpm appears to
> > stabilize. It’s almost like it gets caught in a loop trying to chase
> > its tail.
>
> This is VERY common in servo systems, and is due to delay in
> response of the object being controlled.
> You need to slow down the response of the PID to ignore the
> delay. This may be possible by adding
> D to it.
>
> Jon

But my msg was that a near module generated spindle.N.at-speed was never 
to be injected into any signal path leading back to a PID.  That near's 
output s/b only to that input to motion, and possibly to an indicator 
led in the gui so the operator can be advised if its acting funkity.  
Flickering could be worn brushes in a brushed PMDC motor for instance.

What you are describing as delays can often be fixed by the proper 
re-ordering of the addf's involved for the oscillating axis. That aspect 
of configuring LinuxCNC hasn't been mentioned recently or I wouldn't 
even have included that paragraph in my reply.

And from Dan's description above, I think this is an entirely different 
critter from a timeing delay.

Cheers Jon & stay well, 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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-07 Thread Jon Elson


On 05/06/2020 09:20 PM, Dan Henderson wrote:

I’ve confirmed the fluctuation occurs when spindle-at-speed is configured.
When I remove this feature, the spindle rpm appears to stabilize. It’s
almost like it gets caught in a loop trying to chase its tail.


This is VERY common in servo systems, and is due to delay in 
response of the object being controlled.
You need to slow down the response of the PID to ignore the 
delay. This may be possible by adding

D to it.

Jon


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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On Wednesday 06 May 2020 23:30:19 Gene Heskett wrote:

> On Wednesday 06 May 2020 22:20:12 Dan Henderson wrote:
> > I’ve confirmed the fluctuation occurs when spindle-at-speed is
> > configured. When I remove this feature, the spindle rpm appears to
> > stabilize. It’s almost like it gets caught in a loop trying to chase
> > its tail.
>
> The clues would tend to point in the direction of the output of the
> spindle-at-speed signal somehow getting into the feedback loop to
> modify the feedback value.
>
Dan: Be aware if using master, that the syntax has changed, due to new 
multiple spindle control abilities LinuxCNC has grown, it is now 
spindle.N.at-speed, where for you with one spindle, N is 0. And I've 
some configs to fix too...

Did you find anything yet?

> Check, and then recheck your hal file for some sort of coupling that's
> probably unintended. Look at otherwise identical modules you've used
> more than one of and make sure the unique marker such as an instance
> number is correct, it could be a classic off by one typu.  Such as
> that will eat your lunch.  In rare cases you may have to survey the
> running system with "rockhopper", (google for it, pain in the butt to
> use but its also very very good at what it does, which is to graphicly
> trace every active signal in a system.) I'm not a touch typist, never
> got that far in school, and my code is often contaminated with such
> stuff I have to go back and fix. I've had to use rockhopper, several
> times.  The output by the time its printed and pasted/taped up, can
> occupy a 4x8 sheet of plywood.  But it also works.
>
> Any "spindle-at-speed" signal you generate, should connect only to
> motion but I've forgotten the exact name of that pin so dbl-check man
> motion to get it right, and nothing else, (except maybe an led in a
> pyvcp generated gui) as motion uses the lack of that signal to hold
> off the initiation of a synchronized move such as a g76 or g33.1 so
> its not started if the spindle just started, generates an index but is
> not yet up to speed.
>
> Because there is an acceleration delay as the axis being moved gets up
> to locked speed, if the spindle is not at a constant speed, this delay
> will vary causeing an offset in the final locked positions, screwing
> up the thread, so LCNC goes out of it way to make sure this signal is
> also true.  For the same reason you can't start a thread slow, see
> that its going to be ok, then grab the rpm slider and crank it up, the
> diff in the accell delay will wreck your thread by causeing an offset
> between the slow pass and the sped up passes.
>
> Good luck with the hunting, Dan.  And stay well. I just read tonight
> there are children that appear to have a different illness from this
> covid19, causeing extremely high fevers, heart attacks and strokes.
> And here I'm worried because I'm in my 86th trip around this star.
>
> Cheers, Gene Heskett


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] Fluctuating RPM using CUI ATM 10 encoder

On Wednesday 06 May 2020 22:20:12 Dan Henderson wrote:

> I’ve confirmed the fluctuation occurs when spindle-at-speed is
> configured. When I remove this feature, the spindle rpm appears to
> stabilize. It’s almost like it gets caught in a loop trying to chase
> its tail.

The clues would tend to point in the direction of the output of the 
spindle-at-speed signal somehow getting into the feedback loop to modify 
the feedback value.

Check, and then recheck your hal file for some sort of coupling that's 
probably unintended. Look at otherwise identical modules you've used 
more than one of and make sure the unique marker such as an instance 
number is correct, it could be a classic off by one typu.  Such as that 
will eat your lunch.  In rare cases you may have to survey the running 
system with "rockhopper", (google for it, pain in the butt to use but 
its also very very good at what it does, which is to graphicly trace 
every active signal in a system.) I'm not a touch typist, never got that 
far in school, and my code is often contaminated with such stuff I have 
to go back and fix. I've had to use rockhopper, several times.  The 
output by the time its printed and pasted/taped up, can occupy a 4x8 
sheet of plywood.  But it also works.

Any "spindle-at-speed" signal you generate, should connect only to motion 
but I've forgotten the exact name of that pin so dbl-check man motion to 
get it right, and nothing else, (except maybe an led in a pyvcp 
generated gui) as motion uses the lack of that signal to hold off the 
initiation of a synchronized move such as a g76 or g33.1 so its not 
started if the spindle just started, generates an index but is not yet 
up to speed.

Because there is an acceleration delay as the axis being moved gets up to 
locked speed, if the spindle is not at a constant speed, this delay will 
vary causeing an offset in the final locked positions, screwing up the 
thread, so LCNC goes out of it way to make sure this signal is also 
true.  For the same reason you can't start a thread slow, see that its 
going to be ok, then grab the rpm slider and crank it up, the diff in 
the accell delay will wreck your thread by causeing an offset between 
the slow pass and the sped up passes.

Good luck with the hunting, Dan.  And stay well. I just read tonight 
there are children that appear to have a different illness from this 
covid19, causeing extremely high fevers, heart attacks and strokes. And 
here I'm worried because I'm in my 86th trip around this star.

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] Fluctuating RPM using CUI ATM 10 encoder

I’ve confirmed the fluctuation occurs when spindle-at-speed is configured.
When I remove this feature, the spindle rpm appears to stabilize. It’s
almost like it gets caught in a loop trying to chase its tail.

On Wed, May 6, 2020 at 4:02 PM Gene Heskett  wrote:

> On Wednesday 06 May 2020 14:46:41 Dan Henderson wrote:
>
> > Great stuff guys, I’ve learned a lot here. So, Gene are you throwing
> > in the towel with respect to the parallel port vs Mesa hardware speed
> > differences? I set my PPR down to 100 and it helped some. As a test I
> > also increased to 500 PPR and it got way worse.  So is there any use
> > in my attempting to bypass those isocouplers on the BOB snider inputs?
>
> It might help, but it would surprise me, a lot.
> [...]
>
> 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] Fluctuating RPM using CUI ATM 10 encoder

On Wednesday 06 May 2020 14:46:41 Dan Henderson wrote:

> Great stuff guys, I’ve learned a lot here. So, Gene are you throwing
> in the towel with respect to the parallel port vs Mesa hardware speed
> differences? I set my PPR down to 100 and it helped some. As a test I
> also increased to 500 PPR and it got way worse.  So is there any use
> in my attempting to bypass those isocouplers on the BOB snider inputs?

It might help, but it would surprise me, a lot.
[...]

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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-06 Thread Thaddeus Waldner

I can recommend the Rigol DS1054Z, which is a 4-channel scope capable of 
plotting up to 100mhz. If you watch deals you can pick it up for a bit over 
$300. This instrument has been the single most insightful tool in my hobbyist 
attempt to learn electronics. It will also decode serial signals.


> On May 6, 2020, at 12:46 PM, John Dammeyer  wrote:
> 
> 
> 
>> -Original Message-
>> From: Dan Henderson [mailto:luvtof...@gmail.com]
>> Sent: May-06-20 10:22 AM
>> To: Enhanced Machine Controller (EMC)
>> Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
>> 
>> My steppers are set for half stepping and are working well enough just not
>> blazingly fast. I�m only pushing 36v to them at the moment. The drivers I
>> have are limited to a max of 50v
>> 
>> My main issue is the spindle motor rpm fluctuation. I�m in the process of
>> trying a different BOB that doesn�t appear to use isocouplers between it
>> and the outputs. It does however use them for the inputs. I�ll post up what
>> I find. I�m hoping for better results with this different brand of BOB.
> 
> Try and find someone with a real scope so you can look at the signals.
> 
> I needed to capture RS232 signals and decode them for timing a few years 
> back.   The UART module for my scope is $1200 and I didn't buy it at the time 
> because I thought I'd never need it.  I have CAN bus and SPI/I2C and they are 
> great.
> 
> But instead of spending $1200 I bought one of these.
> 
> https://store.digilentinc.com/analog-discovery-2-100msps-usb-oscilloscope-logic-analyzer-and-variable-power-supply/
>  
> <https://store.digilentinc.com/analog-discovery-2-100msps-usb-oscilloscope-logic-analyzer-and-variable-power-supply/>
> 
> If you can find the funds for something like this you won't be disappointed.  
> With it I was able to discover the sender of the RS232 packets was breaking 
> up the messages in half with a delay between that caused timeouts.  Long 
> story short I haven't used it since because I have a really nice TEK scope 
> but it solved a problem and I'd recommend it to anyone.
> 
> For example, it has a waveform generator.  You can simulate an encoder with 
> it.
> 
> John Dammeyer
> 
> 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net <mailto:Emc-users@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/emc-users 
> <https://lists.sourceforge.net/lists/listinfo/emc-users>

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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

That’s a great point Andy. I won’t be threading at high speeds anyway

On Wed, May 6, 2020 at 2:24 PM andy pugh  wrote:

> On Wed, 6 May 2020 at 19:49, Dan Henderson  wrote:
>
> > I set my PPR down to 100 and it helped some. As a test I also increased
> to
> > 500 PPR and it got way worse.
>
> Note that it might not matter. You can simply choose to thread at
> speeds that the parport can handle, and just not look at the speed
> feedback at higher rpm.
>
> --
> 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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-06 Thread andy pugh

On Wed, 6 May 2020 at 19:49, Dan Henderson  wrote:

> I set my PPR down to 100 and it helped some. As a test I also increased to
> 500 PPR and it got way worse.

Note that it might not matter. You can simply choose to thread at
speeds that the parport can handle, and just not look at the speed
feedback at higher rpm.

-- 
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] Fluctuating RPM using CUI ATM 10 encoder

Great stuff guys, I’ve learned a lot here. So, Gene are you throwing in the
towel with respect to the parallel port vs Mesa hardware speed differences?
I set my PPR down to 100 and it helped some. As a test I also increased to
500 PPR and it got way worse.  So is there any use in my attempting to
bypass those isocouplers on the BOB snider inputs?

On Wed, May 6, 2020 at 1:21 PM Gene Heskett  wrote:

> On Wednesday 06 May 2020 12:16:17 John Dammeyer wrote:
>
> > Hi Gene,
> > Thanks for the details.
> > However, I'm trying to learn how LinuxCNC works at the simple level.
> > Not with a high speed co-processor tied on the output doing the heavy
> > lifting.  Then it becomes LinuxMESA rather than LinuxCNC and those
> > appear to be very different animals.
> >
> > Kind of like saying in third gear my electric bicycle makes funny
> > noises and doesn't go as fast as I think it should and having someone
> > mention their Honda 350 motorcycle has no problem with speed and
> > doesn't make noise in third gear.
> >
> > Now I don't own either an electric bicycle nor a Honda 350 so it's
> > really just an example.  I do own a MESA 7i92H and expect to be able
> > to tie onto a hi res spindle encoder with it when I finally get the
> > variable speed motor mounted.
> >
> > But right now it's all about the electric bike.
> > 
> >
> > John
> >
> > > -Original Message-----
> > > From: Gene Heskett [mailto:ghesk...@shentel.net]
> > > Sent: May-06-20 6:35 AM
> > > To: emc-users@lists.sourceforge.net
> > > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> > >
> > > On Wednesday 06 May 2020 04:41:17 John Dammeyer wrote:
> > > > 1000 PPR encoder turning 300 RPS (18000 RPM) will produce 300,000
> > > > Hz output.  At 1 RPM it's 167 RPS or 167Khz.
> > > >
> > > > I've been reading through the LinuxCNC source code for the last
> > > > hour or two.  If one was just using a parallel port and not
> > > > sophisticated external hardware the hal_parport.c code looks like
> > > > it reads the input at the base_period rate; say 25kHz => 40 uS.
> > > >
> > > > If you figure a standard mill running max 3000 RPM (50 RPS) then a
> > > > you probably need to look at the spindle encoder at least twice
> > > > per encoder period.  At 25kHz we're seeing a ParPort task run time
> > > > of 40 uS.  So I'd guess the max pulse size from the spindle
> > > > encoder has to be at least 80 uS.
> > > >
> > > > The spindle at 50 RPS uses up 20mS.  Divide that by the 80uS
> > > > implies the largest usable encoder is 250 lines.
> > > >
> > > > Have I got that right?  I've not found the spindle support code
> > > > yet. Only the HAL install code.
> > > >
> > > > John
> > >
> > > Neither have I John. But I've made it a rule of thumb in my builds,
> > > that the instant I thought of a spindle encoder, my thoughts just
> > > assumed that it would be read by external hardware if for no other
> > > reason but to remove that 1 kilohertz servo sample rate with its
> > > propensity for missing the higher speed events, from the equation.
> > > I have given base thread rates down to 27 u-secs on the D-525-MW
> > > boards and simply did not get the desired results on either machine
> > > until I put a 5i25 Superport in the pci slot.  With a 50 megacycle
> > > sample clock, it doesn't miss a lick.
> > >
> > > Low counts from the encoder finally got the best of me on the G0704
> > > so although I was proud of the disk and photo-interrupter with 268
> > > slots I'd made for it, I bought a 1000 line differential output
> > > omron encoder from fleabay for a $21 bill, made and installed an
> > > extension shaft to drive it on the rear of the motor and installed
> > > it there, but left the index signal from the spindle intact.  Wrote
> > > some hal code to measure the counts, and put tally switches on the
> > > gearshift knob to tell hal which gear it was in.
> > >
> > > That 1000 line encoder had to have a pair of $2.00 rs485
> > > transceivers wired as rx only to make a single ended ttl signal out
> > > of it that was actually rail to rail.  Worked up to about 300 rpms
> > > and found the opto's in the sainsmart bob were way too slow, so I
> > > bypassed them, works great. Where before, the 268 count encoders
> > > quantization noise was banging on the motor h

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On Wednesday 06 May 2020 12:16:17 John Dammeyer wrote:

> Hi Gene,
> Thanks for the details.
> However, I'm trying to learn how LinuxCNC works at the simple level. 
> Not with a high speed co-processor tied on the output doing the heavy
> lifting.  Then it becomes LinuxMESA rather than LinuxCNC and those
> appear to be very different animals.
>
> Kind of like saying in third gear my electric bicycle makes funny
> noises and doesn't go as fast as I think it should and having someone
> mention their Honda 350 motorcycle has no problem with speed and
> doesn't make noise in third gear.
>
> Now I don't own either an electric bicycle nor a Honda 350 so it's
> really just an example.  I do own a MESA 7i92H and expect to be able
> to tie onto a hi res spindle encoder with it when I finally get the
> variable speed motor mounted.
>
> But right now it's all about the electric bike.
> 
>
> John
>
> > -Original Message-
> > From: Gene Heskett [mailto:ghesk...@shentel.net]
> > Sent: May-06-20 6:35 AM
> > To: emc-users@lists.sourceforge.net
> > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> >
> > On Wednesday 06 May 2020 04:41:17 John Dammeyer wrote:
> > > 1000 PPR encoder turning 300 RPS (18000 RPM) will produce 300,000
> > > Hz output.  At 1 RPM it's 167 RPS or 167Khz.
> > >
> > > I've been reading through the LinuxCNC source code for the last
> > > hour or two.  If one was just using a parallel port and not
> > > sophisticated external hardware the hal_parport.c code looks like
> > > it reads the input at the base_period rate; say 25kHz => 40 uS.
> > >
> > > If you figure a standard mill running max 3000 RPM (50 RPS) then a
> > > you probably need to look at the spindle encoder at least twice
> > > per encoder period.  At 25kHz we're seeing a ParPort task run time
> > > of 40 uS.  So I'd guess the max pulse size from the spindle
> > > encoder has to be at least 80 uS.
> > >
> > > The spindle at 50 RPS uses up 20mS.  Divide that by the 80uS
> > > implies the largest usable encoder is 250 lines.
> > >
> > > Have I got that right?  I've not found the spindle support code
> > > yet. Only the HAL install code.
> > >
> > > John
> >
> > Neither have I John. But I've made it a rule of thumb in my builds,
> > that the instant I thought of a spindle encoder, my thoughts just
> > assumed that it would be read by external hardware if for no other
> > reason but to remove that 1 kilohertz servo sample rate with its
> > propensity for missing the higher speed events, from the equation. 
> > I have given base thread rates down to 27 u-secs on the D-525-MW
> > boards and simply did not get the desired results on either machine
> > until I put a 5i25 Superport in the pci slot.  With a 50 megacycle
> > sample clock, it doesn't miss a lick.
> >
> > Low counts from the encoder finally got the best of me on the G0704
> > so although I was proud of the disk and photo-interrupter with 268
> > slots I'd made for it, I bought a 1000 line differential output
> > omron encoder from fleabay for a $21 bill, made and installed an
> > extension shaft to drive it on the rear of the motor and installed
> > it there, but left the index signal from the spindle intact.  Wrote
> > some hal code to measure the counts, and put tally switches on the
> > gearshift knob to tell hal which gear it was in.
> >
> > That 1000 line encoder had to have a pair of $2.00 rs485
> > transceivers wired as rx only to make a single ended ttl signal out
> > of it that was actually rail to rail.  Worked up to about 300 rpms
> > and found the opto's in the sainsmart bob were way too slow, so I
> > bypassed them, works great. Where before, the 268 count encoders
> > quantization noise was banging on the motor hard enough it sounded
> > like every bearing in the head was square and well on its way out,
> > now it runs dead silent up until when rigid tapping with a 5/16 or
> > bigger tap that works the motor too hard and I hear the iron in the
> > motor squeak as the 17 amp current limit setting in the pwm-servo
> > amplifier kicks in.
> >
> > That 704's head gears are plastic, and I've no clue why I haven't
> > stripped them doing rigid tapping with it, but I haven't yet.  That
> > spindle, originally a 2250 rpm fwd, 1100 reverse, now with Jon's
> > pwm-servo driver and a shop made psu good for 125 volts and a 20 amp
> > surge, now turns 3000 revs in either direction. The effective
> > encoder count/scale changes wit

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder



> -Original Message-
> From: Dan Henderson [mailto:luvtof...@gmail.com]
> Sent: May-06-20 10:22 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> 
> My steppers are set for half stepping and are working well enough just not
> blazingly fast. I�m only pushing 36v to them at the moment. The drivers I
> have are limited to a max of 50v
> 
> My main issue is the spindle motor rpm fluctuation. I�m in the process of
> trying a different BOB that doesn�t appear to use isocouplers between it
> and the outputs. It does however use them for the inputs. I�ll post up what
> I find. I�m hoping for better results with this different brand of BOB.

Try and find someone with a real scope so you can look at the signals.

I needed to capture RS232 signals and decode them for timing a few years back.  
 The UART module for my scope is $1200 and I didn't buy it at the time because 
I thought I'd never need it.  I have CAN bus and SPI/I2C and they are great.

But instead of spending $1200 I bought one of these.

https://store.digilentinc.com/analog-discovery-2-100msps-usb-oscilloscope-logic-analyzer-and-variable-power-supply/

If you can find the funds for something like this you won't be disappointed.  
With it I was able to discover the sender of the RS232 packets was breaking up 
the messages in half with a delay between that caused timeouts.  Long story 
short I haven't used it since because I have a really nice TEK scope but it 
solved a problem and I'd recommend it to anyone.

For example, it has a waveform generator.  You can simulate an encoder with it.

John Dammeyer




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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

My steppers are set for half stepping and are working well enough just not
blazingly fast. I’m only pushing 36v to them at the moment. The drivers I
have are limited to a max of 50v

My main issue is the spindle motor rpm fluctuation. I’m in the process of
trying a different BOB that doesn’t appear to use isocouplers between it
and the outputs. It does however use them for the inputs. I’ll post up what
I find. I’m hoping for better results with this different brand of BOB.

On Wed, May 6, 2020 at 11:19 AM John Dammeyer 
wrote:

> Hi Gene,
> Thanks for the details.
> However, I'm trying to learn how LinuxCNC works at the simple level.  Not
> with a high speed co-processor tied on the output doing the heavy lifting.
> Then it becomes LinuxMESA rather than LinuxCNC and those appear to be very
> different animals.
>
> Kind of like saying in third gear my electric bicycle makes funny noises
> and doesn't go as fast as I think it should and having someone mention
> their Honda 350 motorcycle has no problem with speed and doesn't make noise
> in third gear.
>
> Now I don't own either an electric bicycle nor a Honda 350 so it's really
> just an example.  I do own a MESA 7i92H and expect to be able to tie onto a
> hi res spindle encoder with it when I finally get the variable speed motor
> mounted.
>
> But right now it's all about the electric bike.
> 
>
> John
>
>
> > -Original Message-
> > From: Gene Heskett [mailto:ghesk...@shentel.net]
> > Sent: May-06-20 6:35 AM
> > To: emc-users@lists.sourceforge.net
> > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> >
> > On Wednesday 06 May 2020 04:41:17 John Dammeyer wrote:
> >
> > > 1000 PPR encoder turning 300 RPS (18000 RPM) will produce 300,000 Hz
> > > output.  At 1 RPM it's 167 RPS or 167Khz.
> > >
> > > I've been reading through the LinuxCNC source code for the last hour
> > > or two.  If one was just using a parallel port and not sophisticated
> > > external hardware the hal_parport.c code looks like it reads the input
> > > at the base_period rate; say 25kHz => 40 uS.
> > >
> > > If you figure a standard mill running max 3000 RPM (50 RPS) then a you
> > > probably need to look at the spindle encoder at least twice per
> > > encoder period.  At 25kHz we're seeing a ParPort task run time of 40
> > > uS.  So I'd guess the max pulse size from the spindle encoder has to
> > > be at least 80 uS.
> > >
> > > The spindle at 50 RPS uses up 20mS.  Divide that by the 80uS implies
> > > the largest usable encoder is 250 lines.
> > >
> > > Have I got that right?  I've not found the spindle support code yet.
> > > Only the HAL install code.
> > >
> > > John
> >
> > Neither have I John. But I've made it a rule of thumb in my builds, that
> > the instant I thought of a spindle encoder, my thoughts just assumed
> > that it would be read by external hardware if for no other reason but to
> > remove that 1 kilohertz servo sample rate with its propensity for
> > missing the higher speed events, from the equation.  I have given base
> > thread rates down to 27 u-secs on the D-525-MW boards and simply did not
> > get the desired results on either machine until I put a 5i25 Superport
> > in the pci slot.  With a 50 megacycle sample clock, it doesn't miss a
> > lick.
> >
> > Low counts from the encoder finally got the best of me on the G0704 so
> > although I was proud of the disk and photo-interrupter with 268 slots
> > I'd made for it, I bought a 1000 line differential output omron encoder
> > from fleabay for a $21 bill, made and installed an extension shaft to
> > drive it on the rear of the motor and installed it there, but left the
> > index signal from the spindle intact.  Wrote some hal code to measure
> > the counts, and put tally switches on the gearshift knob to tell hal
> > which gear it was in.
> >
> > That 1000 line encoder had to have a pair of $2.00 rs485 transceivers
> > wired as rx only to make a single ended ttl signal out of it that was
> > actually rail to rail.  Worked up to about 300 rpms and found the opto's
> > in the sainsmart bob were way too slow, so I bypassed them, works great.
> > Where before, the 268 count encoders quantization noise was banging on
> > the motor hard enough it sounded like every bearing in the head was
> > square and well on its way out, now it runs dead silent up until when
> > rigid tapping with a 5/16 or bigger tap that works the motor too hard
> > and I hear the iron in the motor squeak as the 17 amp current limit
>

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-06 Thread Jon Elson


On 05/06/2020 09:20 AM, Gene Heskett wrote:

On Wednesday 06 May 2020 09:14:20 Dan Henderson wrote:


Here are a couple screen shots of the encoder inputs using Halscope.
The first is captured at 300 rpm spindle speed. The second is at 2500
rpm. The signals are inconsistent at the higher speed. Not sure if
this is normal or an issue?

That _is_ the issue. Ir you have a real scope, take a look at the cable
from the encoder.. If you still see that, the encoder is the problem.
Conversely if that looks good, the port is mussing pulses

Or, the sample rate of Halscope is just too low.  But, 
clearly, the displayed results at 2500 RPM
show a major problem.  Since it clearly shows less pulses on 
B than on A, however, it may really

be an optoisolator problem or something of that nature.

Jon


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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

Chris Albertson is correct. The halscope photos show that you are missing 
encoder pulses.  With a parallel port based LinuxCNC you are stuck with the 
base_period speed for stepping pulses and sampling the input.   Feed data 
faster than that and you lose pulses.

Think of pouring a bag of rice down a small opening in a container.  If you 
pour slowly enough the rice all goes into the hole.  If you pour too fast a 
bunch spills over.  

For your stepper motors you didn't say what resolution you'd programmed the 
drivers at.  I've found that even with 8 micro-steps/step the max speed, before 
the load overwhelms the motor, is about 10KHz.  Now if I was running say 32 
steps/step I'd probably not have any smoother stepping and positioning wouldn't 
be any better either but now I could run 40kHz to turn the exact same shaft 
speed.  Except if the parport LinuxCNC can only do 30kHz you won't get the 
speed you thought you would.

So make sure you motors aren't running more than 8 micro steps/step.

John Dammeyer

> -Original Message-
> From: Dan Henderson [mailto:luvtof...@gmail.com]
> Sent: May-06-20 6:14 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> 
> Here are a couple screen shots of the encoder inputs using Halscope. The
> first is captured at 300 rpm spindle speed. The second is at 2500 rpm. The
> signals are inconsistent at the higher speed. Not sure if this is normal or
> an issue?
> 
> 
> On Wed, May 6, 2020 at 7:01 AM Dan Henderson  wrote:
> 
> > A lot of great input here. I�m not sure I fully understand all of the
> > talking points around kHz and PPR and RPM vs optocoupler speed and parallel
> > port timing.
> >
> > I also have 3 stepper motors in xyz that are being controlled via the same
> > BOB parallel port combo. They appear to be working okay with the exception
> > of maxing out at 1� ips jog speed before they lose steps. That seems slow
> > to me. They are nema 23 425 oz-in with DMQ542 drivers rated up to 80v. I�m
> > only supplying them 36v.
> >
> > But back to the original concern with the spindle motor rpm fluctuation
> > with encoder feedback. Without the encoder configured in the HAL the
> > spindle speed is more consistent but not 100% steady. I can drop the PPR on
> > the encoder from 200 down to 48. I�m not sure if this would significantly
> > improve the situation at the expense of lower resolution.
> >
> > I believe Gene gave me some items to look at in Halscope. I�m going to
> > attempt to pull this up now and see if I can draw any conclusions as to
> > where the fluctuation is occurring.
> >
> > Thanks for all the input!
> >
> > On Wed, May 6, 2020 at 3:44 AM John Dammeyer 
> > wrote:
> >
> >> 1000 PPR encoder turning 300 RPS (18000 RPM) will produce 300,000 Hz
> >> output.  At 1 RPM it's 167 RPS or 167Khz.
> >>
> >> I've been reading through the LinuxCNC source code for the last hour or
> >> two.  If one was just using a parallel port and not sophisticated external
> >> hardware the hal_parport.c code looks like it reads the input at the
> >> base_period rate; say 25kHz => 40 uS.
> >>
> >> If you figure a standard mill running max 3000 RPM (50 RPS) then a you
> >> probably need to look at the spindle encoder at least twice per encoder
> >> period.  At 25kHz we're seeing a ParPort task run time of 40 uS.  So I'd
> >> guess the max pulse size from the spindle encoder has to be at least 80
> >> uS.
> >>
> >> The spindle at 50 RPS uses up 20mS.  Divide that by the 80uS implies the
> >> largest usable encoder is 250 lines.
> >>
> >> Have I got that right?  I've not found the spindle support code yet.
> >> Only the HAL install code.
> >>
> >> John
> >>
> >>
> >> > -Original Message-
> >> > From: andrew beck [mailto:andrewbeck0...@gmail.com]
> >> > Sent: May-06-20 12:31 AM
> >> > To: Enhanced Machine Controller (EMC)
> >> > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> >> >
> >> > John while we are on this subject got a quick question.  Just want to
> >> check
> >> > my maths.
> >> >
> >> > My encoder card on vfd max count rate is 300Khz.  Max rpm is 10000rpm
> >> >
> >> > So a 1000 ppr encoder should give me 18000 rpm at 300khz.  I just need
> >> > 1 rpm so that should be well within spec
> >> >
> >> > Regards
> >> >
> >> > Andrew
> >> >
> >>

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

Hi Gene,
Thanks for the details.  
However, I'm trying to learn how LinuxCNC works at the simple level.  Not with 
a high speed co-processor tied on the output doing the heavy lifting.  Then it 
becomes LinuxMESA rather than LinuxCNC and those appear to be very different 
animals.

Kind of like saying in third gear my electric bicycle makes funny noises and 
doesn't go as fast as I think it should and having someone mention their Honda 
350 motorcycle has no problem with speed and doesn't make noise in third gear.  

Now I don't own either an electric bicycle nor a Honda 350 so it's really just 
an example.  I do own a MESA 7i92H and expect to be able to tie onto a hi res 
spindle encoder with it when I finally get the variable speed motor mounted.  

But right now it's all about the electric bike.


John


> -Original Message-
> From: Gene Heskett [mailto:ghesk...@shentel.net]
> Sent: May-06-20 6:35 AM
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> 
> On Wednesday 06 May 2020 04:41:17 John Dammeyer wrote:
> 
> > 1000 PPR encoder turning 300 RPS (18000 RPM) will produce 300,000 Hz
> > output.  At 1 RPM it's 167 RPS or 167Khz.
> >
> > I've been reading through the LinuxCNC source code for the last hour
> > or two.  If one was just using a parallel port and not sophisticated
> > external hardware the hal_parport.c code looks like it reads the input
> > at the base_period rate; say 25kHz => 40 uS.
> >
> > If you figure a standard mill running max 3000 RPM (50 RPS) then a you
> > probably need to look at the spindle encoder at least twice per
> > encoder period.  At 25kHz we're seeing a ParPort task run time of 40
> > uS.  So I'd guess the max pulse size from the spindle encoder has to
> > be at least 80 uS.
> >
> > The spindle at 50 RPS uses up 20mS.  Divide that by the 80uS implies
> > the largest usable encoder is 250 lines.
> >
> > Have I got that right?  I've not found the spindle support code yet.
> > Only the HAL install code.
> >
> > John
> 
> Neither have I John. But I've made it a rule of thumb in my builds, that
> the instant I thought of a spindle encoder, my thoughts just assumed
> that it would be read by external hardware if for no other reason but to
> remove that 1 kilohertz servo sample rate with its propensity for
> missing the higher speed events, from the equation.  I have given base
> thread rates down to 27 u-secs on the D-525-MW boards and simply did not
> get the desired results on either machine until I put a 5i25 Superport
> in the pci slot.  With a 50 megacycle sample clock, it doesn't miss a
> lick.
> 
> Low counts from the encoder finally got the best of me on the G0704 so
> although I was proud of the disk and photo-interrupter with 268 slots
> I'd made for it, I bought a 1000 line differential output omron encoder
> from fleabay for a $21 bill, made and installed an extension shaft to
> drive it on the rear of the motor and installed it there, but left the
> index signal from the spindle intact.  Wrote some hal code to measure
> the counts, and put tally switches on the gearshift knob to tell hal
> which gear it was in.
> 
> That 1000 line encoder had to have a pair of $2.00 rs485 transceivers
> wired as rx only to make a single ended ttl signal out of it that was
> actually rail to rail.  Worked up to about 300 rpms and found the opto's
> in the sainsmart bob were way too slow, so I bypassed them, works great.
> Where before, the 268 count encoders quantization noise was banging on
> the motor hard enough it sounded like every bearing in the head was
> square and well on its way out, now it runs dead silent up until when
> rigid tapping with a 5/16 or bigger tap that works the motor too hard
> and I hear the iron in the motor squeak as the 17 amp current limit
> setting in the pwm-servo amplifier kicks in.
> 
> That 704's head gears are plastic, and I've no clue why I haven't
> stripped them doing rigid tapping with it, but I haven't yet.  That
> spindle, originally a 2250 rpm fwd, 1100 reverse, now with Jon's
> pwm-servo driver and a shop made psu good for 125 volts and a 20 amp
> surge, now turns 3000 revs in either direction. The effective encoder
> count/scale changes with the gear shift of coarse but that just more hal
> modules to fix.
> 
> The scale in high gear is a bit over 7000 counts per spindle rev, and is
> a bit over 14,000 in low gear.  So at 1500 revs in low gear, its about
> 14150 counts per rev, so (1500 * 14150)/60=353750 cps into that 5i25
> cards A/B inputs, and hasn't missed a lick yet. My optical disk for an
> index came loose and ate the opticals up so there is now an ats667
> reading

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-06 Thread Chris Albertson

The stepper skipping steps and the encoders not working at high speed is
the same issue.   The bottleneck is the parallel port.   The software only
"looks" at the port at a finite rate.  If stuff happens faster than that it
is not noticed and falls into the "bucket of missing bits"

On Wed, May 6, 2020 at 5:04 AM Dan Henderson  wrote:

> A lot of great input here. I’m not sure I fully understand all of the
> talking points around kHz and PPR and RPM vs optocoupler speed and parallel
> port timing.
>
> I also have 3 stepper motors in xyz that are being controlled via the same
> BOB parallel port combo. They appear to be working okay with the exception
> of maxing out at 1” ips jog speed before they lose steps. That seems slow
> to me. They are nema 23 425 oz-in with DMQ542 drivers rated up to 80v. I’m
> only supplying them 36v.
>
> But back to the original concern with the spindle motor rpm fluctuation
> with encoder feedback. Without the encoder configured in the HAL the
> spindle speed is more consistent but not 100% steady. I can drop the PPR on
> the encoder from 200 down to 48. I’m not sure if this would significantly
> improve the situation at the expense of lower resolution.
>
> I believe Gene gave me some items to look at in Halscope. I’m going to
> attempt to pull this up now and see if I can draw any conclusions as to
> where the fluctuation is occurring.
>
> Thanks for all the input!
>
> On Wed, May 6, 2020 at 3:44 AM John Dammeyer 
> wrote:
>
> > 1000 PPR encoder turning 300 RPS (18000 RPM) will produce 300,000 Hz
> > output.  At 1 RPM it's 167 RPS or 167Khz.
> >
> > I've been reading through the LinuxCNC source code for the last hour or
> > two.  If one was just using a parallel port and not sophisticated
> external
> > hardware the hal_parport.c code looks like it reads the input at the
> > base_period rate; say 25kHz => 40 uS.
> >
> > If you figure a standard mill running max 3000 RPM (50 RPS) then a you
> > probably need to look at the spindle encoder at least twice per encoder
> > period.  At 25kHz we're seeing a ParPort task run time of 40 uS.  So I'd
> > guess the max pulse size from the spindle encoder has to be at least 80
> > uS.
> >
> > The spindle at 50 RPS uses up 20mS.  Divide that by the 80uS implies the
> > largest usable encoder is 250 lines.
> >
> > Have I got that right?  I've not found the spindle support code yet.
> Only
> > the HAL install code.
> >
> > John
> >
> >
> > > -Original Message-
> > > From: andrew beck [mailto:andrewbeck0...@gmail.com]
> > > Sent: May-06-20 12:31 AM
> > > To: Enhanced Machine Controller (EMC)
> > > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> > >
> > > John while we are on this subject got a quick question.  Just want to
> > check
> > > my maths.
> > >
> > > My encoder card on vfd max count rate is 300Khz.  Max rpm is 1rpm
> > >
> > > So a 1000 ppr encoder should give me 18000 rpm at 300khz.  I just need
> > > 1 rpm so that should be well within spec
> > >
> > > Regards
> > >
> > > Andrew
> > >
> > > On Wed, May 6, 2020, 6:45 PM John Dammeyer 
> > wrote:
> > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com]
> > > > > Sent: May-05-20 9:13 PM
> > > > > To: Enhanced Machine Controller (EMC)
> > > > > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> > > > >
> > > > > > Do you have a dual trace 'scope?  Spin the spindle and look at
> the
> > > > input
> > > > > > and output of the opto-isolator.  See if there really is a lag.
> >  If
> > > > you
> > > > > > have a new scope would you have it capture the screen and post
> it.
> > > >  I'm
> > > > > > really skeptical that those isolators are THAT bad.
> > > > > >
> > > > > > Here is the datasheet for the opto.
> > > > > > https://www.mouser.com/datasheet/2/143/EL817-G-26528.pdf
> > > > > > They claim an 18 uS rise and fall time.A 1KHz square wave
> will
> > > > have a
> > > > > > 1000 uS period and a 500 uS pulse width at 2 KHz the pulse width
> is
> > > > still
> > > > > > more than 10X the raise time of the opto.But maybe the opto
> is
> > a
>

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On Wednesday 06 May 2020 09:14:20 Dan Henderson wrote:

> Here are a couple screen shots of the encoder inputs using Halscope.
> The first is captured at 300 rpm spindle speed. The second is at 2500
> rpm. The signals are inconsistent at the higher speed. Not sure if
> this is normal or an issue?

That _is_ the issue. Ir you have a real scope, take a look at the cable 
from the encoder.. If you still see that, the encoder is the problem. 
Conversely if that looks good, the port is mussing pulses

> On Wed, May 6, 2020 at 7:01 AM Dan Henderson  
wrote:
> > A lot of great input here. I’m not sure I fully understand all of
> > the talking points around kHz and PPR and RPM vs optocoupler speed
> > and parallel port timing.
> >
> > I also have 3 stepper motors in xyz that are being controlled via
> > the same BOB parallel port combo. They appear to be working okay
> > with the exception of maxing out at 1” ips jog speed before they
> > lose steps. That seems slow to me. They are nema 23 425 oz-in with
> > DMQ542 drivers rated up to 80v. I’m only supplying them 36v.

More voltage will help.  Those 425 motors are fairly high inductance 
windings and they need more volts to get sufficient current flow at the 
higher speeds. You must have newer 542's than I, mine are only rated for 
50 volts. I'm feeding mine around 42 volts, peaking at about 90 ipm. Or 
1.5 ips.

When I bought a kit to cnc this g0704, it came with a 1600 oz z motor 
because the head is so heavy, but its top speed going up was about 27 
ipm. I replaced the 1600 with a 940, and its DM860 driver with an AC 
powered unit that made more coil voltage, that 940 can now lift the head 
at 90 ipm.
[...]

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] Fluctuating RPM using CUI ATM 10 encoder

On Wednesday 06 May 2020 04:41:17 John Dammeyer wrote:

> 1000 PPR encoder turning 300 RPS (18000 RPM) will produce 300,000 Hz
> output.  At 1 RPM it's 167 RPS or 167Khz.
>
> I've been reading through the LinuxCNC source code for the last hour
> or two.  If one was just using a parallel port and not sophisticated
> external hardware the hal_parport.c code looks like it reads the input
> at the base_period rate; say 25kHz => 40 uS.
>
> If you figure a standard mill running max 3000 RPM (50 RPS) then a you
> probably need to look at the spindle encoder at least twice per
> encoder period.  At 25kHz we're seeing a ParPort task run time of 40
> uS.  So I'd guess the max pulse size from the spindle encoder has to
> be at least 80 uS.
>
> The spindle at 50 RPS uses up 20mS.  Divide that by the 80uS implies
> the largest usable encoder is 250 lines.
>
> Have I got that right?  I've not found the spindle support code yet. 
> Only the HAL install code.
>
> John

Neither have I John. But I've made it a rule of thumb in my builds, that 
the instant I thought of a spindle encoder, my thoughts just assumed 
that it would be read by external hardware if for no other reason but to 
remove that 1 kilohertz servo sample rate with its propensity for 
missing the higher speed events, from the equation.  I have given base 
thread rates down to 27 u-secs on the D-525-MW boards and simply did not 
get the desired results on either machine until I put a 5i25 Superport 
in the pci slot.  With a 50 megacycle sample clock, it doesn't miss a 
lick.

Low counts from the encoder finally got the best of me on the G0704 so 
although I was proud of the disk and photo-interrupter with 268 slots 
I'd made for it, I bought a 1000 line differential output omron encoder 
from fleabay for a $21 bill, made and installed an extension shaft to 
drive it on the rear of the motor and installed it there, but left the 
index signal from the spindle intact.  Wrote some hal code to measure 
the counts, and put tally switches on the gearshift knob to tell hal 
which gear it was in.

That 1000 line encoder had to have a pair of $2.00 rs485 transceivers 
wired as rx only to make a single ended ttl signal out of it that was 
actually rail to rail.  Worked up to about 300 rpms and found the opto's 
in the sainsmart bob were way too slow, so I bypassed them, works great. 
Where before, the 268 count encoders quantization noise was banging on 
the motor hard enough it sounded like every bearing in the head was 
square and well on its way out, now it runs dead silent up until when 
rigid tapping with a 5/16 or bigger tap that works the motor too hard 
and I hear the iron in the motor squeak as the 17 amp current limit 
setting in the pwm-servo amplifier kicks in.

That 704's head gears are plastic, and I've no clue why I haven't 
stripped them doing rigid tapping with it, but I haven't yet.  That 
spindle, originally a 2250 rpm fwd, 1100 reverse, now with Jon's 
pwm-servo driver and a shop made psu good for 125 volts and a 20 amp 
surge, now turns 3000 revs in either direction. The effective encoder 
count/scale changes with the gear shift of coarse but that just more hal 
modules to fix.

The scale in high gear is a bit over 7000 counts per spindle rev, and is 
a bit over 14,000 in low gear.  So at 1500 revs in low gear, its about 
14150 counts per rev, so (1500 * 14150)/60=353750 cps into that 5i25 
cards A/B inputs, and hasn't missed a lick yet. My optical disk for an 
index came loose and ate the opticals up so there is now an ats667 
reading a screw glued to the side of the drawbar cap for an index 
generator. 

Since the gears are plastic and not molded for easy gear shifting, I took 
advantage of the tally switches and swapped the mux2 that changes the 
scale for a mux4, and did a setp for about 15 revs at the motor to the 
unused inputs, so when between gears its turning slowly and the gear 
shift is without the drama of grabbing the spindle and manually 
re-engaging the gears by hand.  And the control response is fast enough 
I can change gears while its running wide open.

I have since run out of i/o on that machine, so that 5i25 is now driving 
a 7i76D on P3, but the machine runs the same.

And I am still convinced the bare parport is a bad idea. But its a piece 
of cake for the 5i25.
>
> > -Original Message-
> > From: andrew beck [mailto:andrewbeck0...@gmail.com]
> > Sent: May-06-20 12:31 AM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> >
> > John while we are on this subject got a quick question.  Just want
> > to check my maths.
> >
> > My encoder card on vfd max count rate is 300Khz.  Max rpm is
> > 1rpm
> >
> > So a 1000 ppr encoder should give me 18000 rpm at 300khz.  I just
> > need 1 rpm so

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

Here are a couple screen shots of the encoder inputs using Halscope. The
first is captured at 300 rpm spindle speed. The second is at 2500 rpm. The
signals are inconsistent at the higher speed. Not sure if this is normal or
an issue?


On Wed, May 6, 2020 at 7:01 AM Dan Henderson  wrote:

> A lot of great input here. I’m not sure I fully understand all of the
> talking points around kHz and PPR and RPM vs optocoupler speed and parallel
> port timing.
>
> I also have 3 stepper motors in xyz that are being controlled via the same
> BOB parallel port combo. They appear to be working okay with the exception
> of maxing out at 1” ips jog speed before they lose steps. That seems slow
> to me. They are nema 23 425 oz-in with DMQ542 drivers rated up to 80v. I’m
> only supplying them 36v.
>
> But back to the original concern with the spindle motor rpm fluctuation
> with encoder feedback. Without the encoder configured in the HAL the
> spindle speed is more consistent but not 100% steady. I can drop the PPR on
> the encoder from 200 down to 48. I’m not sure if this would significantly
> improve the situation at the expense of lower resolution.
>
> I believe Gene gave me some items to look at in Halscope. I’m going to
> attempt to pull this up now and see if I can draw any conclusions as to
> where the fluctuation is occurring.
>
> Thanks for all the input!
>
> On Wed, May 6, 2020 at 3:44 AM John Dammeyer 
> wrote:
>
>> 1000 PPR encoder turning 300 RPS (18000 RPM) will produce 300,000 Hz
>> output.  At 1 RPM it's 167 RPS or 167Khz.
>>
>> I've been reading through the LinuxCNC source code for the last hour or
>> two.  If one was just using a parallel port and not sophisticated external
>> hardware the hal_parport.c code looks like it reads the input at the
>> base_period rate; say 25kHz => 40 uS.
>>
>> If you figure a standard mill running max 3000 RPM (50 RPS) then a you
>> probably need to look at the spindle encoder at least twice per encoder
>> period.  At 25kHz we're seeing a ParPort task run time of 40 uS.  So I'd
>> guess the max pulse size from the spindle encoder has to be at least 80
>> uS.
>>
>> The spindle at 50 RPS uses up 20mS.  Divide that by the 80uS implies the
>> largest usable encoder is 250 lines.
>>
>> Have I got that right?  I've not found the spindle support code yet.
>> Only the HAL install code.
>>
>> John
>>
>>
>> > -----Original Message-
>> > From: andrew beck [mailto:andrewbeck0...@gmail.com]
>> > Sent: May-06-20 12:31 AM
>> > To: Enhanced Machine Controller (EMC)
>> > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
>> >
>> > John while we are on this subject got a quick question.  Just want to
>> check
>> > my maths.
>> >
>> > My encoder card on vfd max count rate is 300Khz.  Max rpm is 1rpm
>> >
>> > So a 1000 ppr encoder should give me 18000 rpm at 300khz.  I just need
>> > 1 rpm so that should be well within spec
>> >
>> > Regards
>> >
>> > Andrew
>> >
>> > On Wed, May 6, 2020, 6:45 PM John Dammeyer 
>> wrote:
>> >
>> > >
>> > >
>> > > > -Original Message-
>> > > > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com]
>> > > > Sent: May-05-20 9:13 PM
>> > > > To: Enhanced Machine Controller (EMC)
>> > > > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
>> > > >
>> > > > > Do you have a dual trace 'scope?  Spin the spindle and look at the
>> > > input
>> > > > > and output of the opto-isolator.  See if there really is a lag.
>>  If
>> > > you
>> > > > > have a new scope would you have it capture the screen and post it.
>> > >  I'm
>> > > > > really skeptical that those isolators are THAT bad.
>> > > > >
>> > > > > Here is the datasheet for the opto.
>> > > > > https://www.mouser.com/datasheet/2/143/EL817-G-26528.pdf
>> > > > > They claim an 18 uS rise and fall time.A 1KHz square wave will
>> > > have a
>> > > > > 1000 uS period and a 500 uS pulse width at 2 KHz the pulse width
>> is
>> > > still
>> > > > > more than 10X the raise time of the opto.But maybe the opto
>> is a
>> > > fake
>> > > > > counterfeit part with very poor performance.
>> > > >
>> > > > Opto couplers are rather slow.

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

A lot of great input here. I’m not sure I fully understand all of the
talking points around kHz and PPR and RPM vs optocoupler speed and parallel
port timing.

I also have 3 stepper motors in xyz that are being controlled via the same
BOB parallel port combo. They appear to be working okay with the exception
of maxing out at 1” ips jog speed before they lose steps. That seems slow
to me. They are nema 23 425 oz-in with DMQ542 drivers rated up to 80v. I’m
only supplying them 36v.

But back to the original concern with the spindle motor rpm fluctuation
with encoder feedback. Without the encoder configured in the HAL the
spindle speed is more consistent but not 100% steady. I can drop the PPR on
the encoder from 200 down to 48. I’m not sure if this would significantly
improve the situation at the expense of lower resolution.

I believe Gene gave me some items to look at in Halscope. I’m going to
attempt to pull this up now and see if I can draw any conclusions as to
where the fluctuation is occurring.

Thanks for all the input!

On Wed, May 6, 2020 at 3:44 AM John Dammeyer  wrote:

> 1000 PPR encoder turning 300 RPS (18000 RPM) will produce 300,000 Hz
> output.  At 1 RPM it's 167 RPS or 167Khz.
>
> I've been reading through the LinuxCNC source code for the last hour or
> two.  If one was just using a parallel port and not sophisticated external
> hardware the hal_parport.c code looks like it reads the input at the
> base_period rate; say 25kHz => 40 uS.
>
> If you figure a standard mill running max 3000 RPM (50 RPS) then a you
> probably need to look at the spindle encoder at least twice per encoder
> period.  At 25kHz we're seeing a ParPort task run time of 40 uS.  So I'd
> guess the max pulse size from the spindle encoder has to be at least 80
> uS.
>
> The spindle at 50 RPS uses up 20mS.  Divide that by the 80uS implies the
> largest usable encoder is 250 lines.
>
> Have I got that right?  I've not found the spindle support code yet.  Only
> the HAL install code.
>
> John
>
>
> > -Original Message-
> > From: andrew beck [mailto:andrewbeck0...@gmail.com]
> > Sent: May-06-20 12:31 AM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> >
> > John while we are on this subject got a quick question.  Just want to
> check
> > my maths.
> >
> > My encoder card on vfd max count rate is 300Khz.  Max rpm is 1rpm
> >
> > So a 1000 ppr encoder should give me 18000 rpm at 300khz.  I just need
> > 1 rpm so that should be well within spec
> >
> > Regards
> >
> > Andrew
> >
> > On Wed, May 6, 2020, 6:45 PM John Dammeyer 
> wrote:
> >
> > >
> > >
> > > > -----Original Message-
> > > > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com]
> > > > Sent: May-05-20 9:13 PM
> > > > To: Enhanced Machine Controller (EMC)
> > > > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> > > >
> > > > > Do you have a dual trace 'scope?  Spin the spindle and look at the
> > > input
> > > > > and output of the opto-isolator.  See if there really is a lag.
>  If
> > > you
> > > > > have a new scope would you have it capture the screen and post it.
> > >  I'm
> > > > > really skeptical that those isolators are THAT bad.
> > > > >
> > > > > Here is the datasheet for the opto.
> > > > > https://www.mouser.com/datasheet/2/143/EL817-G-26528.pdf
> > > > > They claim an 18 uS rise and fall time.A 1KHz square wave will
> > > have a
> > > > > 1000 uS period and a 500 uS pulse width at 2 KHz the pulse width is
> > > still
> > > > > more than 10X the raise time of the opto.But maybe the opto is
> a
> > > fake
> > > > > counterfeit part with very poor performance.
> > > >
> > > > Opto couplers are rather slow. With a high resolution encoder
> frequency
> > > could be maybe up to a few hundred kHz,
> > > > 2000*period/revolution*3600rpm=12period/second=120kHz, 200PPR
> will
> > > be 12kHz at 3600rpm, 1/(2*18�s) = about 27778Hz =
> > > > about a little bit below 28kHz if mad no misstake.
> > > >
> > >
> > > I think your math is out.  Most of the hi res encoders are running 2500
> > > lines per rev.  Many are less.But we're only looking at one encoder
> > > channel and that works out to twice the number of edges but the actual
> > > frequency is still lines per rev p

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

1000 PPR encoder turning 300 RPS (18000 RPM) will produce 300,000 Hz output.  
At 1 RPM it's 167 RPS or 167Khz.

I've been reading through the LinuxCNC source code for the last hour or two.  
If one was just using a parallel port and not sophisticated external hardware 
the hal_parport.c code looks like it reads the input at the base_period rate; 
say 25kHz => 40 uS.  

If you figure a standard mill running max 3000 RPM (50 RPS) then a you probably 
need to look at the spindle encoder at least twice per encoder period.  At 
25kHz we're seeing a ParPort task run time of 40 uS.  So I'd guess the max 
pulse size from the spindle encoder has to be at least 80 uS.  

The spindle at 50 RPS uses up 20mS.  Divide that by the 80uS implies the 
largest usable encoder is 250 lines.

Have I got that right?  I've not found the spindle support code yet.  Only the 
HAL install code.

John


> -Original Message-
> From: andrew beck [mailto:andrewbeck0...@gmail.com]
> Sent: May-06-20 12:31 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> 
> John while we are on this subject got a quick question.  Just want to check
> my maths.
> 
> My encoder card on vfd max count rate is 300Khz.  Max rpm is 1rpm
> 
> So a 1000 ppr encoder should give me 18000 rpm at 300khz.  I just need
> 1 rpm so that should be well within spec
> 
> Regards
> 
> Andrew
> 
> On Wed, May 6, 2020, 6:45 PM John Dammeyer  wrote:
> 
> >
> >
> > > -Original Message-
> > > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com]
> > > Sent: May-05-20 9:13 PM
> > > To: Enhanced Machine Controller (EMC)
> > > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> > >
> > > > Do you have a dual trace 'scope?  Spin the spindle and look at the
> > input
> > > > and output of the opto-isolator.  See if there really is a lag.   If
> > you
> > > > have a new scope would you have it capture the screen and post it.
> >  I'm
> > > > really skeptical that those isolators are THAT bad.
> > > >
> > > > Here is the datasheet for the opto.
> > > > https://www.mouser.com/datasheet/2/143/EL817-G-26528.pdf
> > > > They claim an 18 uS rise and fall time.A 1KHz square wave will
> > have a
> > > > 1000 uS period and a 500 uS pulse width at 2 KHz the pulse width is
> > still
> > > > more than 10X the raise time of the opto.But maybe the opto is a
> > fake
> > > > counterfeit part with very poor performance.
> > >
> > > Opto couplers are rather slow. With a high resolution encoder frequency
> > could be maybe up to a few hundred kHz,
> > > 2000*period/revolution*3600rpm=12period/second=120kHz, 200PPR will
> > be 12kHz at 3600rpm, 1/(2*18�s) = about 27778Hz =
> > > about a little bit below 28kHz if mad no misstake.
> > >
> >
> > I think your math is out.  Most of the hi res encoders are running 2500
> > lines per rev.  Many are less.But we're only looking at one encoder
> > channel and that works out to twice the number of edges but the actual
> > frequency is still lines per rev per second.
> >
> > So how many revs per second is that?You have to divide RPM by 60 to
> > get revs per second so 3600 RPM is 60 RPS.
> >
> > Now you have 60 * 2500 Hz = 150kHz.  Still way too high for that
> > opto-isolator.
> >
> > Now if you do like Sam did for his hex milling you update the encoder.
> > But initially he was milling with about 60 teeth and Linux is more than
> > fine for that when power tapping etc.  So 60 * 60 is 3600 Hz and the opto
> > would be fine for that.Even 200 lines at 60 rps  (3600 RPM) is 12,000
> > hz.
> >
> > Don't understand how you got 27778Hz
> >
> > John
> >
> > >
> > > ___
> > > 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] Fluctuating RPM using CUI ATM 10 encoder

On Tuesday 05 May 2020 23:55:21 Nicklas Karlsson wrote:

> > I have a PMDC motor I’ve scavenged along with the MC-2100 motor
> > control from a treadmill rated for 1.5 hp @ 90 volts. I’ve been
> > testing it with LinuxCNC v2.7.15 in a mock-up environment I built
> > for testing. I’m able to control the spindle speed via PWM pulses to
> > the controller (HD2 pin 4). M3 S500 will get me somewhere between
> > 520 and 580 rpm. You can hear the motor whine fluctuating with the
> > RPM. I’ve also installed a CUI ATM 10 encoder on the back and seem
> > to have it working with both an index and phase A signal. I have the
> > jumpers on it set to 200 PPR but it can go all the way to 2048. I’m
> > using a cheap china 5 axis BOB connected via parallel cable.
> >
> > Does anybody have any idea why I’m get so much flux on the rpm?
> > Surely this isn’t normal? I know enough about the HAL to be
> > dangerous. Is there some things I can check to smooth this out?
> > Thanks.
>
> You are sure drive pwm signal outputs are constant duty cycle?
>
They probably aren't going to absolutely constant unless the math has no 
residual from a divide.  And the higher the pwm rep rate, the more 
noticeable this variation will be, but it also going to vary at a high 
enough rate that the motor will average it. What its doing is adding or 
substracting one clock period here and there in order to give you on an 
average over a small fraction of a second, the exact speed requested.  
And its even pretty good at that in the pulse density mode at speeds 
less than 1% of the full on speed.  What it does there is a 1% pulse, 
less and less often. So I believe the encoder is lieing.  The question 
is why.  If its accurate to .25 degrees, that's equ to microstepping the 
motor at 6x. In the real world microstepped steppers aren't any better. 
In any event there no real advantage to a pwn carrier well above the 1 
kilohertz servo rate.

My two cents.
> ___
> 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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-06 Thread andrew beck

John while we are on this subject got a quick question.  Just want to check
my maths.

My encoder card on vfd max count rate is 300Khz.  Max rpm is 1rpm

So a 1000 ppr encoder should give me 18000 rpm at 300khz.  I just need
1 rpm so that should be well within spec

Regards

Andrew

On Wed, May 6, 2020, 6:45 PM John Dammeyer  wrote:

>
>
> > -Original Message-
> > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com]
> > Sent: May-05-20 9:13 PM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> >
> > > Do you have a dual trace 'scope?  Spin the spindle and look at the
> input
> > > and output of the opto-isolator.  See if there really is a lag.   If
> you
> > > have a new scope would you have it capture the screen and post it.
>  I'm
> > > really skeptical that those isolators are THAT bad.
> > >
> > > Here is the datasheet for the opto.
> > > https://www.mouser.com/datasheet/2/143/EL817-G-26528.pdf
> > > They claim an 18 uS rise and fall time.A 1KHz square wave will
> have a
> > > 1000 uS period and a 500 uS pulse width at 2 KHz the pulse width is
> still
> > > more than 10X the raise time of the opto.But maybe the opto is a
> fake
> > > counterfeit part with very poor performance.
> >
> > Opto couplers are rather slow. With a high resolution encoder frequency
> could be maybe up to a few hundred kHz,
> > 2000*period/revolution*3600rpm=12period/second=120kHz, 200PPR will
> be 12kHz at 3600rpm, 1/(2*18µs) = about 27778Hz =
> > about a little bit below 28kHz if mad no misstake.
> >
>
> I think your math is out.  Most of the hi res encoders are running 2500
> lines per rev.  Many are less.But we're only looking at one encoder
> channel and that works out to twice the number of edges but the actual
> frequency is still lines per rev per second.
>
> So how many revs per second is that?You have to divide RPM by 60 to
> get revs per second so 3600 RPM is 60 RPS.
>
> Now you have 60 * 2500 Hz = 150kHz.  Still way too high for that
> opto-isolator.
>
> Now if you do like Sam did for his hex milling you update the encoder.
> But initially he was milling with about 60 teeth and Linux is more than
> fine for that when power tapping etc.  So 60 * 60 is 3600 Hz and the opto
> would be fine for that.Even 200 lines at 60 rps  (3600 RPM) is 12,000
> hz.
>
> Don't understand how you got 27778Hz
>
> John
>
> >
> > ___
> > 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] Fluctuating RPM using CUI ATM 10 encoder



> -Original Message-
> From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com]
> Sent: May-05-20 9:13 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> 
> > Do you have a dual trace 'scope?  Spin the spindle and look at the input
> > and output of the opto-isolator.  See if there really is a lag.   If you
> > have a new scope would you have it capture the screen and post it.   I'm
> > really skeptical that those isolators are THAT bad.
> >
> > Here is the datasheet for the opto.
> > https://www.mouser.com/datasheet/2/143/EL817-G-26528.pdf
> > They claim an 18 uS rise and fall time.A 1KHz square wave will have a
> > 1000 uS period and a 500 uS pulse width at 2 KHz the pulse width is still
> > more than 10X the raise time of the opto.But maybe the opto is a fake
> > counterfeit part with very poor performance.
> 
> Opto couplers are rather slow. With a high resolution encoder frequency could 
> be maybe up to a few hundred kHz,
> 2000*period/revolution*3600rpm=12period/second=120kHz, 200PPR will be 
> 12kHz at 3600rpm, 1/(2*18µs) = about 27778Hz =
> about a little bit below 28kHz if mad no misstake.
> 

I think your math is out.  Most of the hi res encoders are running 2500 lines 
per rev.  Many are less.But we're only looking at one encoder channel and 
that works out to twice the number of edges but the actual frequency is still 
lines per rev per second.

So how many revs per second is that?You have to divide RPM by 60 to get 
revs per second so 3600 RPM is 60 RPS.  

Now you have 60 * 2500 Hz = 150kHz.  Still way too high for that opto-isolator.

Now if you do like Sam did for his hex milling you update the encoder.  But 
initially he was milling with about 60 teeth and Linux is more than fine for 
that when power tapping etc.  So 60 * 60 is 3600 Hz and the opto would be fine 
for that.Even 200 lines at 60 rps  (3600 RPM) is 12,000 hz.

Don't understand how you got 27778Hz 

John

> 
> ___
> 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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-06 Thread Chris Albertson

On Tue, May 5, 2020 at 9:15 PM Nicklas Karlsson <
nicklas.karlsso...@gmail.com> wrote:

> > Do you have a dual trace 'scope?  Spin the spindle and look at the input
> > and output of the opto-isolator.  See if there really is a lag.   If you
> > have a new scope would you have it capture the screen and post it.   I'm
> > really skeptical that those isolators are THAT bad.
> >
> > Here is the datasheet for the opto.
> > https://www.mouser.com/datasheet/2/143/EL817-G-26528.pdf
> > They claim an 18 uS rise and fall time.A 1KHz square wave will have a
> > 1000 uS period and a 500 uS pulse width at 2 KHz the pulse width is still
> > more than 10X the raise time of the opto.But maybe the opto is a fake
> > counterfeit part with very poor performance.
>
> Opto couplers are rather slow. With a high resolution encoder frequency
> could be maybe up to a few hundred kHz,
> 2000*period/revolution*3600rpm=12period/second=120kHz, 200PPR will be
> 12kHz at 3600rpm, 1/(2*18µs) = about 27778Hz = about a little bit below
> 28kHz if mad no misstake.
>

Yes, you can just barely get a 28 kHz signal through one of these
isolators. But this case was 10X slower than that.But it hardly matters
because the parallel port is even slower.   I'm sure the BoB was designed
for stepper motor pulses and limit and home switches.

I think about the fastest signal you can push through one of those optos
might be about 80 uS period or 12.5 kHz square wave.

All optoisolators are not this bad.   My leadshie staper motor driver has
an opto chip in it.   All the signals are isolated that way and you can put
over 100 kHz through it.

In theory, they can be very fast.   After all what is a fiber optic cable
but a kilometers long optical isolator?  The one the comes into my house is
sending data at gigahertz class speed.

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

-- 

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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-05 Thread Nicklas Karlsson

> Do you have a dual trace 'scope?  Spin the spindle and look at the input
> and output of the opto-isolator.  See if there really is a lag.   If you
> have a new scope would you have it capture the screen and post it.   I'm
> really skeptical that those isolators are THAT bad.
> 
> Here is the datasheet for the opto.
> https://www.mouser.com/datasheet/2/143/EL817-G-26528.pdf
> They claim an 18 uS rise and fall time.A 1KHz square wave will have a
> 1000 uS period and a 500 uS pulse width at 2 KHz the pulse width is still
> more than 10X the raise time of the opto.But maybe the opto is a fake
> counterfeit part with very poor performance.

Opto couplers are rather slow. With a high resolution encoder frequency could 
be maybe up to a few hundred kHz, 
2000*period/revolution*3600rpm=12period/second=120kHz, 200PPR will be 12kHz 
at 3600rpm, 1/(2*18µs) = about 27778Hz = about a little bit below 28kHz if mad 
no misstake.


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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-05 Thread Chris Albertson

Do you have a dual trace 'scope?  Spin the spindle and look at the input
and output of the opto-isolator.  See if there really is a lag.   If you
have a new scope would you have it capture the screen and post it.   I'm
really skeptical that those isolators are THAT bad.

Here is the datasheet for the opto.
https://www.mouser.com/datasheet/2/143/EL817-G-26528.pdf
They claim an 18 uS rise and fall time.A 1KHz square wave will have a
1000 uS period and a 500 uS pulse width at 2 KHz the pulse width is still
more than 10X the raise time of the opto.But maybe the opto is a fake
counterfeit part with very poor performance.

Check it out on the scope and if you can post the results. I have a few
of those way-cheap BOBs too in a drawer.   I think I will test them and
maybe post a screen shot.

My bet is the the problem is the parallel port.   I just can't see how to
get encoder data reliably through a parallel printer port.

On Tue, May 5, 2020 at 6:21 PM Dan Henderson  wrote:

> I have LinuxCNC fully operational. In halscope I’m able to view the signals
> for both the spindle index, phase a, and I now have phase b hooked up. I’m
> conducting my  testing with the LinuxCNC MDI. The number on the opto chips
> is EL817C807.
> The BOB PN is DB25-1205.
>
>
>
> On Tue, May 5, 2020 at 8:08 PM Gene Heskett  wrote:
>
> > On Tuesday 05 May 2020 20:17:45 Dan Henderson wrote:
> >
> > > Slowing things down had marginal effect. Okay sounds like I need to by
> > > pass the optocouplers. Would you recommend I bypass all the encoder
> > > inputs as well as the PWM output to the MC2100 controller?
> >
> > Only if it has opto's for isolation, they can effect to duration of the
> > pwm playing hob with the speed linearity.  If the motor is "hunting",
> > something else is going on.  The m2100 ISTR is the controller that came
> > in the treadmill and its a very serious case of built by lowest bidder,
> > I was not able to use it in anything I've tried. Control was extremely
> > non-linear until I put a 47k resistor between linuxcnc and its summing
> > point,  That helped but it was still flaky. Not to mention that all of
> > its control circuitry is on the hot side of the power line and quite
> > dangerous.
> >
> > I am not a machinist, but a long retired broadcast engineer and a CET so
> > much of the high power stuff comes out of my junk box. The psu for
> > instance,  makes about 120 volts DC at a surge current of 20 amps, 10
> > forever, way more that the 1hp motor I'd put on the back of a 7x12 lathe
> > is rated for. Capable of getting 2hp out of that 90 volt motor. But it
> > kept breaking drive parts once I had obtained one of the pico systems
> > pwm-servo drivers.  So I've gone into the hal file and slowed the motors
> > acceleration to something that doesn't break stuff any more. But that
> > might explain why my troubleshooting is geared to the electronics, and
> > possibly is different than what a real machinist might do to solve an
> > identical problem.
> >
> > Other than that it doesn't sound as if the opto's speed is your problem.
> >
> > So 2 other questions:
> >
> > What to you have in the way of meters and oscilloscopes for
> > troubleshooting?
> >
> > Do you actually have LinuxCNC running well enough to try to control your
> > motor?
> >
> > 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
>


-- 

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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-05 Thread Nicklas Karlsson

> I have a PMDC motor I’ve scavenged along with the MC-2100 motor control
> from a treadmill rated for 1.5 hp @ 90 volts. I’ve been testing it with
> LinuxCNC v2.7.15 in a mock-up environment I built for testing. I’m able to
> control the spindle speed via PWM pulses to the controller (HD2 pin 4). M3
> S500 will get me somewhere between 520 and 580 rpm. You can hear the motor
> whine fluctuating with the RPM. I’ve also installed a CUI ATM 10 encoder on
> the back and seem to have it working with both an index and phase A signal.
> I have the jumpers on it set to 200 PPR but it can go all the way to 2048.
> I’m using a cheap china 5 axis BOB connected via parallel cable.
> 
> Does anybody have any idea why I’m get so much flux on the rpm? Surely this
> isn’t normal? I know enough about the HAL to be dangerous. Is there some
> things I can check to smooth this out? Thanks.

You are sure drive pwm signal outputs are constant duty cycle?


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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-05 Thread John Dammeyer

I've had good luck with the CUI encoders (Compared to US Digital) on DC Servos 
and the HP_UHU drives.  I found I lost position over time with either missing 
or extra pulses.  I was using differential signalling.  The CUI dispensed with 
that problem.

I was never able to get satisfactory motion from the STMBL driving the same DC 
Servo with the US Digital.  I didn't go back to and try the STMBL with the CUI 
encoders.

John


> -Original Message-
> From: Sam Sokolik [mailto:samco...@gmail.com]
> Sent: May-05-20 7:41 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> 
> I don't know if this is related - but I have had bad luck with
> capacitive encoders like the CUI ATM 10
> in it's spec sheet it is only accurate to 0.25 degrees..  when I tried to
> use it for a closed loop servo - I got a lot of noise..
> 
> https://www.youtube.com/watch?v=gHbemDWXudQ
> 
> https://www.youtube.com/watch?v=i6rJsCKzUK0
> 
> On Tue, May 5, 2020 at 9:13 PM Gene Heskett  wrote:
> 
> > On Tuesday 05 May 2020 21:24:50 Dan Henderson wrote:
> >
> > > I just reverted to a LinuxCNC configuration that isn�t setup to use
> > > the encoder. The spindle speed is much more consistent without the
> > > feedback from the encoder??
> > >
> > And I assume that its steady if the pid is bypassed.  That does point a
> > finger at the encoder.  Can you post a link to it as I'm not familiar
> > with that one.
> >
> > > On Tue, May 5, 2020 at 8:19 PM Dan Henderson 
> > wrote:
> > > > I have LinuxCNC fully operational. In halscope I�m able to view the
> > > > signals for both the spindle index, phase a, and I now have phase b
> > > > hooked up. I�m conducting my  testing with the LinuxCNC MDI. The
> > > > number on the opto chips is EL817C807.
> > > > The BOB PN is DB25-1205.
> >
> > useing the halscope, look at the a and b signals, you should see each
> > with a 50% duty, and a time overlap in each state of 50%.  + or - not
> > more than 5% maximum, when its running steady. But you'll have to stop
> > the hunting before you can read that very accurately.  You won't see
> > amplitude variations there unless something is poorly connected, only
> > time variations.
> >
> > > > On Tue, May 5, 2020 at 8:08 PM Gene Heskett 
> > wrote:
> > > >> On Tuesday 05 May 2020 20:17:45 Dan Henderson wrote:
> > > >> > Slowing things down had marginal effect. Okay sounds like I need
> > > >> > to by pass the optocouplers. Would you recommend I bypass all the
> > > >> > encoder inputs as well as the PWM output to the MC2100
> > > >> > controller?
> > > >>
> > > >> Only if it has opto's for isolation, they can effect to duration of
> > > >> the pwm playing hob with the speed linearity.  If the motor is
> > > >> "hunting", something else is going on.  The m2100 ISTR is the
> > > >> controller that came in the treadmill and its a very serious case
> > > >> of built by lowest bidder, I was not able to use it in anything
> > > >> I've tried. Control was extremely non-linear until I put a 47k
> > > >> resistor between linuxcnc and its summing point,  That helped but
> > > >> it was still flaky. Not to mention that all of its control
> > > >> circuitry is on the hot side of the power line and quite dangerous.
> > > >>
> > > >> I am not a machinist, but a long retired broadcast engineer and a
> > > >> CET so much of the high power stuff comes out of my junk box. The
> > > >> psu for instance,  makes about 120 volts DC at a surge current of
> > > >> 20 amps, 10 forever, way more that the 1hp motor I'd put on the
> > > >> back of a 7x12 lathe is rated for. Capable of getting 2hp out of
> > > >> that 90 volt motor. But it kept breaking drive parts once I had
> > > >> obtained one of the pico systems pwm-servo drivers.  So I've gone
> > > >> into the hal file and slowed the motors acceleration to something
> > > >> that doesn't break stuff any more. But that might explain why my
> > > >> troubleshooting is geared to the electronics, and possibly is
> > > >> different than what a real machinist might do to solve an identical
> > > >> problem.
> > > >>
> > > >> Other than that it doesn't sound as if the opto's speed is your
> > > >> problem.
> > >

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-05 Thread Sam Sokolik

I don't know if this is related - but I have had bad luck with
capacitive encoders like the CUI ATM 10
in it's spec sheet it is only accurate to 0.25 degrees..  when I tried to
use it for a closed loop servo - I got a lot of noise..

https://www.youtube.com/watch?v=gHbemDWXudQ

https://www.youtube.com/watch?v=i6rJsCKzUK0

On Tue, May 5, 2020 at 9:13 PM Gene Heskett  wrote:

> On Tuesday 05 May 2020 21:24:50 Dan Henderson wrote:
>
> > I just reverted to a LinuxCNC configuration that isn’t setup to use
> > the encoder. The spindle speed is much more consistent without the
> > feedback from the encoder??
> >
> And I assume that its steady if the pid is bypassed.  That does point a
> finger at the encoder.  Can you post a link to it as I'm not familiar
> with that one.
>
> > On Tue, May 5, 2020 at 8:19 PM Dan Henderson 
> wrote:
> > > I have LinuxCNC fully operational. In halscope I’m able to view the
> > > signals for both the spindle index, phase a, and I now have phase b
> > > hooked up. I’m conducting my  testing with the LinuxCNC MDI. The
> > > number on the opto chips is EL817C807.
> > > The BOB PN is DB25-1205.
>
> useing the halscope, look at the a and b signals, you should see each
> with a 50% duty, and a time overlap in each state of 50%.  + or - not
> more than 5% maximum, when its running steady. But you'll have to stop
> the hunting before you can read that very accurately.  You won't see
> amplitude variations there unless something is poorly connected, only
> time variations.
>
> > > On Tue, May 5, 2020 at 8:08 PM Gene Heskett 
> wrote:
> > >> On Tuesday 05 May 2020 20:17:45 Dan Henderson wrote:
> > >> > Slowing things down had marginal effect. Okay sounds like I need
> > >> > to by pass the optocouplers. Would you recommend I bypass all the
> > >> > encoder inputs as well as the PWM output to the MC2100
> > >> > controller?
> > >>
> > >> Only if it has opto's for isolation, they can effect to duration of
> > >> the pwm playing hob with the speed linearity.  If the motor is
> > >> "hunting", something else is going on.  The m2100 ISTR is the
> > >> controller that came in the treadmill and its a very serious case
> > >> of built by lowest bidder, I was not able to use it in anything
> > >> I've tried. Control was extremely non-linear until I put a 47k
> > >> resistor between linuxcnc and its summing point,  That helped but
> > >> it was still flaky. Not to mention that all of its control
> > >> circuitry is on the hot side of the power line and quite dangerous.
> > >>
> > >> I am not a machinist, but a long retired broadcast engineer and a
> > >> CET so much of the high power stuff comes out of my junk box. The
> > >> psu for instance,  makes about 120 volts DC at a surge current of
> > >> 20 amps, 10 forever, way more that the 1hp motor I'd put on the
> > >> back of a 7x12 lathe is rated for. Capable of getting 2hp out of
> > >> that 90 volt motor. But it kept breaking drive parts once I had
> > >> obtained one of the pico systems pwm-servo drivers.  So I've gone
> > >> into the hal file and slowed the motors acceleration to something
> > >> that doesn't break stuff any more. But that might explain why my
> > >> troubleshooting is geared to the electronics, and possibly is
> > >> different than what a real machinist might do to solve an identical
> > >> problem.
> > >>
> > >> Other than that it doesn't sound as if the opto's speed is your
> > >> problem.
> > >>
> > >> So 2 other questions:
> > >>
> > >> What to you have in the way of meters and oscilloscopes for
> > >> troubleshooting?
> > >>
> > >> Do you actually have LinuxCNC running well enough to try to control
> > >> your motor?
> > >>
> > >> 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
>

___
Emc-users mailing list

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On Tuesday 05 May 2020 21:24:50 Dan Henderson wrote:

> I just reverted to a LinuxCNC configuration that isn’t setup to use
> the encoder. The spindle speed is much more consistent without the
> feedback from the encoder??
>
And I assume that its steady if the pid is bypassed.  That does point a 
finger at the encoder.  Can you post a link to it as I'm not familiar 
with that one.

> On Tue, May 5, 2020 at 8:19 PM Dan Henderson  
wrote:
> > I have LinuxCNC fully operational. In halscope I’m able to view the
> > signals for both the spindle index, phase a, and I now have phase b
> > hooked up. I’m conducting my  testing with the LinuxCNC MDI. The
> > number on the opto chips is EL817C807.
> > The BOB PN is DB25-1205.

useing the halscope, look at the a and b signals, you should see each 
with a 50% duty, and a time overlap in each state of 50%.  + or - not 
more than 5% maximum, when its running steady. But you'll have to stop 
the hunting before you can read that very accurately.  You won't see 
amplitude variations there unless something is poorly connected, only 
time variations.

> > On Tue, May 5, 2020 at 8:08 PM Gene Heskett  
wrote:
> >> On Tuesday 05 May 2020 20:17:45 Dan Henderson wrote:
> >> > Slowing things down had marginal effect. Okay sounds like I need
> >> > to by pass the optocouplers. Would you recommend I bypass all the
> >> > encoder inputs as well as the PWM output to the MC2100
> >> > controller?
> >>
> >> Only if it has opto's for isolation, they can effect to duration of
> >> the pwm playing hob with the speed linearity.  If the motor is
> >> "hunting", something else is going on.  The m2100 ISTR is the
> >> controller that came in the treadmill and its a very serious case
> >> of built by lowest bidder, I was not able to use it in anything
> >> I've tried. Control was extremely non-linear until I put a 47k
> >> resistor between linuxcnc and its summing point,  That helped but
> >> it was still flaky. Not to mention that all of its control
> >> circuitry is on the hot side of the power line and quite dangerous.
> >>
> >> I am not a machinist, but a long retired broadcast engineer and a
> >> CET so much of the high power stuff comes out of my junk box. The
> >> psu for instance,  makes about 120 volts DC at a surge current of
> >> 20 amps, 10 forever, way more that the 1hp motor I'd put on the
> >> back of a 7x12 lathe is rated for. Capable of getting 2hp out of
> >> that 90 volt motor. But it kept breaking drive parts once I had
> >> obtained one of the pico systems pwm-servo drivers.  So I've gone
> >> into the hal file and slowed the motors acceleration to something
> >> that doesn't break stuff any more. But that might explain why my
> >> troubleshooting is geared to the electronics, and possibly is
> >> different than what a real machinist might do to solve an identical
> >> problem.
> >>
> >> Other than that it doesn't sound as if the opto's speed is your
> >> problem.
> >>
> >> So 2 other questions:
> >>
> >> What to you have in the way of meters and oscilloscopes for
> >> troubleshooting?
> >>
> >> Do you actually have LinuxCNC running well enough to try to control
> >> your motor?
> >>
> >> 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] Fluctuating RPM using CUI ATM 10 encoder

On Tuesday 05 May 2020 21:19:23 Dan Henderson wrote:

> I have LinuxCNC fully operational. In halscope I’m able to view the
> signals for both the spindle index, phase a, and I now have phase b
> hooked up. I’m conducting my  testing with the LinuxCNC MDI. The
> number on the opto chips is EL817C807.
> The BOB PN is DB25-1205.

ok, using the halscope, take a look at the pid.command input, pid.output 
and the pid.feedback input.

If the command input is wandering around, its a control problem.  If the 
output was wandering around, disconnect and ground the pid.feedback pin 
if it goes to a higher speed, steady, its a feedback problem. Look at 
the feedback at various motor speeds, ideally you should only see a 
relatively low variation you can divide into a repeating 4 step pattern 
if its a quality encoder. Larger than 20% variations should be traced 
back to the src. And fixed.

And tell us what you you see and where.

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] Fluctuating RPM using CUI ATM 10 encoder

I just reverted to a LinuxCNC configuration that isn’t setup to use the
encoder. The spindle speed is much more consistent without the feedback
from the encoder??

On Tue, May 5, 2020 at 8:19 PM Dan Henderson  wrote:

> I have LinuxCNC fully operational. In halscope I’m able to view the
> signals for both the spindle index, phase a, and I now have phase b hooked
> up. I’m conducting my  testing with the LinuxCNC MDI. The number on the
> opto chips is EL817C807.
> The BOB PN is DB25-1205.
>
>
>
> On Tue, May 5, 2020 at 8:08 PM Gene Heskett  wrote:
>
>> On Tuesday 05 May 2020 20:17:45 Dan Henderson wrote:
>>
>> > Slowing things down had marginal effect. Okay sounds like I need to by
>> > pass the optocouplers. Would you recommend I bypass all the encoder
>> > inputs as well as the PWM output to the MC2100 controller?
>>
>> Only if it has opto's for isolation, they can effect to duration of the
>> pwm playing hob with the speed linearity.  If the motor is "hunting",
>> something else is going on.  The m2100 ISTR is the controller that came
>> in the treadmill and its a very serious case of built by lowest bidder,
>> I was not able to use it in anything I've tried. Control was extremely
>> non-linear until I put a 47k resistor between linuxcnc and its summing
>> point,  That helped but it was still flaky. Not to mention that all of
>> its control circuitry is on the hot side of the power line and quite
>> dangerous.
>>
>> I am not a machinist, but a long retired broadcast engineer and a CET so
>> much of the high power stuff comes out of my junk box. The psu for
>> instance,  makes about 120 volts DC at a surge current of 20 amps, 10
>> forever, way more that the 1hp motor I'd put on the back of a 7x12 lathe
>> is rated for. Capable of getting 2hp out of that 90 volt motor. But it
>> kept breaking drive parts once I had obtained one of the pico systems
>> pwm-servo drivers.  So I've gone into the hal file and slowed the motors
>> acceleration to something that doesn't break stuff any more. But that
>> might explain why my troubleshooting is geared to the electronics, and
>> possibly is different than what a real machinist might do to solve an
>> identical problem.
>>
>> Other than that it doesn't sound as if the opto's speed is your problem.
>>
>> So 2 other questions:
>>
>> What to you have in the way of meters and oscilloscopes for
>> troubleshooting?
>>
>> Do you actually have LinuxCNC running well enough to try to control your
>> motor?
>>
>> 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] Fluctuating RPM using CUI ATM 10 encoder

I have LinuxCNC fully operational. In halscope I’m able to view the signals
for both the spindle index, phase a, and I now have phase b hooked up. I’m
conducting my  testing with the LinuxCNC MDI. The number on the opto chips
is EL817C807.
The BOB PN is DB25-1205.



On Tue, May 5, 2020 at 8:08 PM Gene Heskett  wrote:

> On Tuesday 05 May 2020 20:17:45 Dan Henderson wrote:
>
> > Slowing things down had marginal effect. Okay sounds like I need to by
> > pass the optocouplers. Would you recommend I bypass all the encoder
> > inputs as well as the PWM output to the MC2100 controller?
>
> Only if it has opto's for isolation, they can effect to duration of the
> pwm playing hob with the speed linearity.  If the motor is "hunting",
> something else is going on.  The m2100 ISTR is the controller that came
> in the treadmill and its a very serious case of built by lowest bidder,
> I was not able to use it in anything I've tried. Control was extremely
> non-linear until I put a 47k resistor between linuxcnc and its summing
> point,  That helped but it was still flaky. Not to mention that all of
> its control circuitry is on the hot side of the power line and quite
> dangerous.
>
> I am not a machinist, but a long retired broadcast engineer and a CET so
> much of the high power stuff comes out of my junk box. The psu for
> instance,  makes about 120 volts DC at a surge current of 20 amps, 10
> forever, way more that the 1hp motor I'd put on the back of a 7x12 lathe
> is rated for. Capable of getting 2hp out of that 90 volt motor. But it
> kept breaking drive parts once I had obtained one of the pico systems
> pwm-servo drivers.  So I've gone into the hal file and slowed the motors
> acceleration to something that doesn't break stuff any more. But that
> might explain why my troubleshooting is geared to the electronics, and
> possibly is different than what a real machinist might do to solve an
> identical problem.
>
> Other than that it doesn't sound as if the opto's speed is your problem.
>
> So 2 other questions:
>
> What to you have in the way of meters and oscilloscopes for
> troubleshooting?
>
> Do you actually have LinuxCNC running well enough to try to control your
> motor?
>
> 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] Fluctuating RPM using CUI ATM 10 encoder

On Tuesday 05 May 2020 20:51:17 John Dammeyer wrote:

> > From: Dan Henderson [mailto:luvtof...@gmail.com]
> > Slowing things down had marginal effect. Okay sounds like I need to
> > by pass the optocouplers. Would you recommend I bypass all the
> > encoder inputs as well as the PWM output to the MC2100 controller?
>
> What's the part number of the opto-couplers on your BoB?
> If it's anyone of these then the data rate is 10Mbps
>
> Single-Channel: 6N137, HCPL2601, HCPL2611
> Dual-Channel: HCPL2630, HCPL2631
> High Speed 10MBit/s Logic Gate Optocouplers
>
> https://www.onsemi.com/pub/Collateral/HCPL2631-D.PDF
>
> John
>
Yes John, but they cost real money, so I'll guarantee these are 1 
megahertz or less pats, 10 cents or less in the door at SainSmart.
>
>
>
> ___
> 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] Fluctuating RPM using CUI ATM 10 encoder

On Tuesday 05 May 2020 20:17:45 Dan Henderson wrote:

> Slowing things down had marginal effect. Okay sounds like I need to by
> pass the optocouplers. Would you recommend I bypass all the encoder
> inputs as well as the PWM output to the MC2100 controller?

Only if it has opto's for isolation, they can effect to duration of the 
pwm playing hob with the speed linearity.  If the motor is "hunting", 
something else is going on.  The m2100 ISTR is the controller that came 
in the treadmill and its a very serious case of built by lowest bidder, 
I was not able to use it in anything I've tried. Control was extremely 
non-linear until I put a 47k resistor between linuxcnc and its summing 
point,  That helped but it was still flaky. Not to mention that all of 
its control circuitry is on the hot side of the power line and quite 
dangerous.

I am not a machinist, but a long retired broadcast engineer and a CET so 
much of the high power stuff comes out of my junk box. The psu for 
instance,  makes about 120 volts DC at a surge current of 20 amps, 10 
forever, way more that the 1hp motor I'd put on the back of a 7x12 lathe 
is rated for. Capable of getting 2hp out of that 90 volt motor. But it 
kept breaking drive parts once I had obtained one of the pico systems 
pwm-servo drivers.  So I've gone into the hal file and slowed the motors 
acceleration to something that doesn't break stuff any more. But that 
might explain why my troubleshooting is geared to the electronics, and 
possibly is different than what a real machinist might do to solve an 
identical problem.

Other than that it doesn't sound as if the opto's speed is your problem.  

So 2 other questions:

What to you have in the way of meters and oscilloscopes for 
troubleshooting?

Do you actually have LinuxCNC running well enough to try to control your 
motor?

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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-05 Thread John Dammeyer




> From: Dan Henderson [mailto:luvtof...@gmail.com]
> Slowing things down had marginal effect. Okay sounds like I need to by pass
> the optocouplers. Would you recommend I bypass all the encoder inputs as
> well as the PWM output to the MC2100 controller?
> 

What's the part number of the opto-couplers on your BoB?
If it's anyone of these then the data rate is 10Mbps

Single-Channel: 6N137, HCPL2601, HCPL2611
Dual-Channel: HCPL2630, HCPL2631
High Speed 10MBit/s Logic Gate Optocouplers

https://www.onsemi.com/pub/Collateral/HCPL2631-D.PDF

John




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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

Slowing things down had marginal effect. Okay sounds like I need to by pass
the optocouplers. Would you recommend I bypass all the encoder inputs as
well as the PWM output to the MC2100 controller?

On Tue, May 5, 2020 at 6:34 PM Gene Heskett  wrote:

> On Tuesday 05 May 2020 18:30:42 Dan Henderson wrote:
>
> > Gene, how do I speed up the servo loop to test your theory? I’ll try
> > that before I perform surgery on the BOB. I also have another BOB I
> > can try, but it requires 12-24v power in order to enable its inputs.
> >
> I meant slow the motor to see if it stabilizes, at say 75 rpm.   zero
> everthing at the pid except some FF0.
>
> Bobs nearly all have opto inputs, the only exception I know of is a long
> discontinued cncv4pc C1G rev 4 board. Great board, but $80someting back
> in the day. Many even have opto outputs.  Mesa cards generally have
> neither so they can work at 100x higher frequencies.  The SainSmart bob
> has no opto's in its outputs, but does have them in its 5 inputs.  When
> its being used with a Mesa 5i25, its totally comfortable with 200+
> kilohertz signals from a high res encoder, once those opto's are
> bypassed.  Without the bypass it only worked up to about 375 rpm at the
> motor, then the opto's failed and the pid and motor went wide open.
>
> > On Tue, May 5, 2020 at 5:07 PM Gene Heskett 
> wrote:
> > > On Tuesday 05 May 2020 17:48:01 Dan Henderson wrote:
> > > > I have a PMDC motor I’ve scavenged along with the MC-2100 motor
> > > > control from a treadmill rated for 1.5 hp @ 90 volts. I’ve been
> > > > testing it with LinuxCNC v2.7.15 in a mock-up environment I built
> > > > for testing. I’m able to control the spindle speed via PWM pulses
> > > > to the controller (HD2 pin 4). M3 S500 will get me somewhere
> > > > between 520 and 580 rpm. You can hear the motor whine fluctuating
> > > > with the RPM. I’ve also installed a CUI ATM 10 encoder on the back
> > > > and seem to have it working with both an index and phase A signal.
> > > > I have the jumpers on it set to 200 PPR but it can go all the way
> > > > to 2048. I’m using a cheap china 5 axis BOB connected via parallel
> > > > cable.
> > > >
> > > > Does anybody have any idea why I’m get so much flux on the rpm?
> > > > Surely this isn’t normal? I know enough about the HAL to be
> > > > dangerous. Is there some things I can check to smooth this out?
> > > > Thanks.
> > >
> > > If using a software encoder, as opposed to a mesa card, the time
> > > delay between samples at the 1 kilohertz servo loop can do odd
> > > things.  Among others, the lag in the input opto-isolators of that
> > > bob can even cause missed pulses from the encoder to the software.
> > > Try a much lower speed to see if it stabilizes.  If handy with a
> > > soldering iron, bypassing those opto's can help, a lot.
> > >
> > > > ___
> > > > 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
> >
> > ___
> > 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
>

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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

On Tuesday 05 May 2020 18:30:42 Dan Henderson wrote:

> Gene, how do I speed up the servo loop to test your theory? I’ll try
> that before I perform surgery on the BOB. I also have another BOB I
> can try, but it requires 12-24v power in order to enable its inputs.
>
I meant slow the motor to see if it stabilizes, at say 75 rpm.   zero 
everthing at the pid except some FF0.

Bobs nearly all have opto inputs, the only exception I know of is a long 
discontinued cncv4pc C1G rev 4 board. Great board, but $80someting back 
in the day. Many even have opto outputs.  Mesa cards generally have 
neither so they can work at 100x higher frequencies.  The SainSmart bob 
has no opto's in its outputs, but does have them in its 5 inputs.  When 
its being used with a Mesa 5i25, its totally comfortable with 200+ 
kilohertz signals from a high res encoder, once those opto's are 
bypassed.  Without the bypass it only worked up to about 375 rpm at the 
motor, then the opto's failed and the pid and motor went wide open.

> On Tue, May 5, 2020 at 5:07 PM Gene Heskett  
wrote:
> > On Tuesday 05 May 2020 17:48:01 Dan Henderson wrote:
> > > I have a PMDC motor I’ve scavenged along with the MC-2100 motor
> > > control from a treadmill rated for 1.5 hp @ 90 volts. I’ve been
> > > testing it with LinuxCNC v2.7.15 in a mock-up environment I built
> > > for testing. I’m able to control the spindle speed via PWM pulses
> > > to the controller (HD2 pin 4). M3 S500 will get me somewhere
> > > between 520 and 580 rpm. You can hear the motor whine fluctuating
> > > with the RPM. I’ve also installed a CUI ATM 10 encoder on the back
> > > and seem to have it working with both an index and phase A signal.
> > > I have the jumpers on it set to 200 PPR but it can go all the way
> > > to 2048. I’m using a cheap china 5 axis BOB connected via parallel
> > > cable.
> > >
> > > Does anybody have any idea why I’m get so much flux on the rpm?
> > > Surely this isn’t normal? I know enough about the HAL to be
> > > dangerous. Is there some things I can check to smooth this out?
> > > Thanks.
> >
> > If using a software encoder, as opposed to a mesa card, the time
> > delay between samples at the 1 kilohertz servo loop can do odd
> > things.  Among others, the lag in the input opto-isolators of that
> > bob can even cause missed pulses from the encoder to the software.
> > Try a much lower speed to see if it stabilizes.  If handy with a
> > soldering iron, bypassing those opto's can help, a lot.
> >
> > > ___
> > > 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
>
> ___
> 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] Fluctuating RPM using CUI ATM 10 encoder

2020-05-05 Thread John Dammeyer

Let's see.

Spindle at 600 RPM is 10 RPS.  That means a 200 line encoder not using 
quadrature and only a rising edge is generating 2000 pulses per second or 4000 
edges per second.  That's because to detect a rising edge you also have to 
detect that it went low.  

That means the hardware has to be looking at those edges at probably twice that 
rate.  I don't know how the MESA hardware is capturing those signals.

One way is to have a high speed counter value that is latched on each rising 
edge.  This value could be added to the previous values until passed up to the 
Servo Thread along with the number of rising edges. Passed up the current value 
is cleared.  So your servo thread is getting the time (so to speak) between 
encoder rising edges.  

If your servo thread is 1mS you'd see sum of two updates.  If the counter is 
clocked at 1MHz then each encoder pulse count  is 500.  Total is 1000 for two 
or still 500 pulses between rising edges.  If the requested speed is 500 clocks 
per encoder pulse then subtracting that count gives you the 'E'rror term for 
the PID.  Zero in this example.

That's just one way to do it.  

John






> -Original Message-
> From: Dan Henderson [mailto:luvtof...@gmail.com]
> Sent: May-05-20 3:31 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder
> 
> Gene, how do I speed up the servo loop to test your theory? I�ll try that
> before I perform surgery on the BOB. I also have another BOB I can try, but
> it requires 12-24v power in order to enable its inputs.
> 
> On Tue, May 5, 2020 at 5:07 PM Gene Heskett  wrote:
> 
> > On Tuesday 05 May 2020 17:48:01 Dan Henderson wrote:
> >
> > > I have a PMDC motor I�ve scavenged along with the MC-2100 motor
> > > control from a treadmill rated for 1.5 hp @ 90 volts. I�ve been
> > > testing it with LinuxCNC v2.7.15 in a mock-up environment I built for
> > > testing. I�m able to control the spindle speed via PWM pulses to the
> > > controller (HD2 pin 4). M3 S500 will get me somewhere between 520 and
> > > 580 rpm. You can hear the motor whine fluctuating with the RPM. I�ve
> > > also installed a CUI ATM 10 encoder on the back and seem to have it
> > > working with both an index and phase A signal. I have the jumpers on
> > > it set to 200 PPR but it can go all the way to 2048. I�m using a cheap
> > > china 5 axis BOB connected via parallel cable.
> > >
> > > Does anybody have any idea why I�m get so much flux on the rpm? Surely
> > > this isn�t normal? I know enough about the HAL to be dangerous. Is
> > > there some things I can check to smooth this out? Thanks.
> > >
> > If using a software encoder, as opposed to a mesa card, the time delay
> > between samples at the 1 kilohertz servo loop can do odd things.  Among
> > others, the lag in the input opto-isolators of that bob can even cause
> > missed pulses from the encoder to the software. Try a much lower speed
> > to see if it stabilizes.  If handy with a soldering iron, bypassing
> > those opto's can help, a lot.
> > > ___
> > > 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 <http://geneslinuxbox.net:6309/gene>
> >
> >
> > ___
> > 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] Fluctuating RPM using CUI ATM 10 encoder

Gene, how do I speed up the servo loop to test your theory? I’ll try that
before I perform surgery on the BOB. I also have another BOB I can try, but
it requires 12-24v power in order to enable its inputs.

On Tue, May 5, 2020 at 5:07 PM Gene Heskett  wrote:

> On Tuesday 05 May 2020 17:48:01 Dan Henderson wrote:
>
> > I have a PMDC motor I’ve scavenged along with the MC-2100 motor
> > control from a treadmill rated for 1.5 hp @ 90 volts. I’ve been
> > testing it with LinuxCNC v2.7.15 in a mock-up environment I built for
> > testing. I’m able to control the spindle speed via PWM pulses to the
> > controller (HD2 pin 4). M3 S500 will get me somewhere between 520 and
> > 580 rpm. You can hear the motor whine fluctuating with the RPM. I’ve
> > also installed a CUI ATM 10 encoder on the back and seem to have it
> > working with both an index and phase A signal. I have the jumpers on
> > it set to 200 PPR but it can go all the way to 2048. I’m using a cheap
> > china 5 axis BOB connected via parallel cable.
> >
> > Does anybody have any idea why I’m get so much flux on the rpm? Surely
> > this isn’t normal? I know enough about the HAL to be dangerous. Is
> > there some things I can check to smooth this out? Thanks.
> >
> If using a software encoder, as opposed to a mesa card, the time delay
> between samples at the 1 kilohertz servo loop can do odd things.  Among
> others, the lag in the input opto-isolators of that bob can even cause
> missed pulses from the encoder to the software. Try a much lower speed
> to see if it stabilizes.  If handy with a soldering iron, bypassing
> those opto's can help, a lot.
> > ___
> > 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
>

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

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder