Re: [Emc-users] Question about index pulse on high resolution encoder

[dave engvall]

just checked the price on ebay. ouch! glad I don't do anything that 
really need one.


On the other hand that $800 only buys about 1.5 glass scales.

Dave

On 3/22/20 3:20 PM, andy pugh wrote:

On Sun, 22 Mar 2020 at 22:01, Gene Heskett  wrote:


That is an impressive widget. :-)

So was the price.

They turn up on eBay.




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

Re: [Emc-users] Question about index pulse on high resolution encoder

[andy pugh]

On Sun, 22 Mar 2020 at 22:01, Gene Heskett  wrote:

> > That is an impressive widget. :-)
>
> So was the price.

They turn up on eBay.

-- 
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] Question about index pulse on high resolution encoder

[Gene Heskett]

On Sunday 22 March 2020 16:32:31 dave engvall wrote:

> That is an impressive widget. :-)

So was the price.

> On 3/22/20 12:08 PM, andy pugh wrote:
> > On Sun, 22 Mar 2020 at 18:27, dave engvall  
wrote:
> >> I bought one of these a few years ago when they were somewhat less
> >> expensive. The polarizer helps the beam considerably. I think one
> >> can get something on the order of 0.01" repeatability using your
> >> eye.
> >
> > This is for cam grinding. 0.01" is far too much. 0.01mm would be
> > more like it.
> >
> > The widget I linked to has a resolution of 0.0001mmm or 0.04"
>
> ___
> 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] Question about index pulse on high resolution encoder

[dave engvall]

That is an impressive widget. :-)

On 3/22/20 12:08 PM, andy pugh wrote:

On Sun, 22 Mar 2020 at 18:27, dave engvall  wrote:


I bought one of these a few years ago when they were somewhat less
expensive. The polarizer helps the beam considerably. I think one can
get something on the order of 0.01" repeatability using your eye.

This is for cam grinding. 0.01" is far too much. 0.01mm would be more like it.

The widget I linked to has a resolution of 0.0001mmm or 0.04"




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

Re: [Emc-users] Question about index pulse on high resolution encoder

[andy pugh]

On Sun, 22 Mar 2020 at 18:27, dave engvall  wrote:

> I bought one of these a few years ago when they were somewhat less
> expensive. The polarizer helps the beam considerably. I think one can
> get something on the order of 0.01" repeatability using your eye.

This is for cam grinding. 0.01" is far too much. 0.01mm would be more like it.

The widget I linked to has a resolution of 0.0001mmm or 0.04"

-- 
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] Question about index pulse on high resolution encoder

[dave engvall]

https://www.amazon.com/Laser-Center-Edge-Finder-polarizer/dp/B00WVG4DF4

I bought one of these a few years ago when they were somewhat less 
expensive. The polarizer helps the beam considerably. I think one can 
get something on the order of 0.01" repeatability using your eye. A 
sensor and a pin hole should do better. There just ain't no free lunch.


Dave

On 3/22/20 11:09 AM, Gene Heskett wrote:

On Sunday 22 March 2020 12:57:34 Leonardo Marsaglia wrote:


You would have to turn the coolant off to measure, but have a look
at laser triangulation distance sensors:
https://www.micro-epsilon.co.uk/news/2018/2018-05-15-optoNCDT-1750LL
/ (specifically mentions grinding wheels)

  Thanks for the link Andy. But these I assume measure distance,
reflecting the beam against a surface and then receiving it and
measuring the time elapsed between the two events am I right?

I was thinking in something more like two IR barriers transversally
crossed by the wheel. The problem is, this is just an idea it came to
me because geometrically ,for me, this is the simplest way I came up
with to measure the wheel radius only depending on the accuracy of the
ballscrew and the motor driving it. But I don't really know if one can
achieve good levels of repeatability with such a setup.

That would be quite a heavy reponsibility on the ability to repeatedly
dial in half of the beam blocked. I measured the bed wear of mt lathe
with a 38 cartridge bore siting leser and an ir cell fixed to the point
of a dead center in the tailstock, with the laser moditied for power
thru a contact on the other end of a 18" tail sticking out of the back
of the spindle and a cutoff blade raised high enough to block it fully.
Fist adjusting thetail stock to center the beam on it photocell.  Then
mount the cutoff tool and advanced it in front of the receiver cell
until half the beam was being cut off by the cutoff blade.  Touched off
x at 0. at that point, jogged z a short distance each way to check
for torque on the carriage, found under a thou, the jogged toward the
spindle and recorded both z and the x jog offset.  Every inch of travel.
pretty close to a straight line for almost 20" of Z but then the bed
wear closer to the spindle started to show so I wound up at he spindle
pretty close to zero. Then I picked out the peaks and composed a
settings table for a lincurve from that, inserted the lincurves output
thru h offset to modify the x to keep its =- a thou or better over the z
range checked. Taint perfect but it plenty close enough for the girls
I've gone with.  Ranges up to 8 thou if disabled. Using the method I've
described I that methods accuracy budget would show that friction in the
home switch would account for the huge majority of the errors, and I
found those to be repeatable to .0002". or better.  More than enough to
measure thermal effects.


El dom., 22 mar. 2020 a las 13:52, Leonardo Marsaglia (<

ldmarsag...@gmail.com>) escribió:

You only need one beam. I would use the first beam interruption as a


second home switch of sorts, setting that with the home_offset when
you install a new wheel. The established home offset then becomes
your new wheel reference. This should then be considered a fixed
reference and a suitable distance from the work to prevent
accidental contact during setup.

   I was thinking about using the two beams that are transversally
cut by the well because that way I can measure the length of a
circular portion and have an exact measure of the radius
independently of the home distance or the part diameter being known.
The only thing that would matter with this approach would be to know
exact distance between one beam and the other and they off course
must be perfectly perpendicular to the wheel axis of movement.

And obviously Leonardo, make a youtube video and tell us about it
when


its working. :)

  Be sure I'll let you guys know as soon as I do something. In fact,
I can't wait to see and show you the mazak turning with LCNC. After
that, I hope I can start converting the grinder as soon as poosible!



El dom., 22 mar. 2020 a las 10:41, Thaddeus Waldner
()

escribió:

The most


primitive idea I have is to measure the wheel before placing it
into the machine and then keep track of its diameter as it gets
dressed. But sometimes we have to adjust the offset of the
dressing tool because a diamond just detaches from the tool and
then you need to correct for

that


difference.

I don’t know what the dressing system looks like, but if it’s
motorized in both axis( cut depth and motion across the wheel) then
why don’t you touch off the dressing point? You could do an initial
homing when machine starts, and again after each dressing
operation. Use the info to determine dressing point depth of cut
and also to infer actual wheel diameter. You could also use it to
catch the event of a diamond point being knocked loose, and alarm
the operator.



___
Emc-users mailing list
Emc-

Re: [Emc-users] Question about index pulse on high resolution encoder

[Gene Heskett]

On Sunday 22 March 2020 12:57:34 Leonardo Marsaglia wrote:

> > You would have to turn the coolant off to measure, but have a look
> > at laser triangulation distance sensors:
> > https://www.micro-epsilon.co.uk/news/2018/2018-05-15-optoNCDT-1750LL
> >/ (specifically mentions grinding wheels)
>
>  Thanks for the link Andy. But these I assume measure distance,
> reflecting the beam against a surface and then receiving it and
> measuring the time elapsed between the two events am I right?
>
> I was thinking in something more like two IR barriers transversally
> crossed by the wheel. The problem is, this is just an idea it came to
> me because geometrically ,for me, this is the simplest way I came up
> with to measure the wheel radius only depending on the accuracy of the
> ballscrew and the motor driving it. But I don't really know if one can
> achieve good levels of repeatability with such a setup.

That would be quite a heavy reponsibility on the ability to repeatedly 
dial in half of the beam blocked. I measured the bed wear of mt lathe 
with a 38 cartridge bore siting leser and an ir cell fixed to the point 
of a dead center in the tailstock, with the laser moditied for power 
thru a contact on the other end of a 18" tail sticking out of the back 
of the spindle and a cutoff blade raised high enough to block it fully. 
Fist adjusting thetail stock to center the beam on it photocell.  Then 
mount the cutoff tool and advanced it in front of the receiver cell 
until half the beam was being cut off by the cutoff blade.  Touched off  
x at 0. at that point, jogged z a short distance each way to check 
for torque on the carriage, found under a thou, the jogged toward the 
spindle and recorded both z and the x jog offset.  Every inch of travel. 
pretty close to a straight line for almost 20" of Z but then the bed 
wear closer to the spindle started to show so I wound up at he spindle 
pretty close to zero. Then I picked out the peaks and composed a 
settings table for a lincurve from that, inserted the lincurves output 
thru h offset to modify the x to keep its =- a thou or better over the z 
range checked. Taint perfect but it plenty close enough for the girls 
I've gone with.  Ranges up to 8 thou if disabled. Using the method I've 
described I that methods accuracy budget would show that friction in the 
home switch would account for the huge majority of the errors, and I 
found those to be repeatable to .0002". or better.  More than enough to 
measure thermal effects.

> El dom., 22 mar. 2020 a las 13:52, Leonardo Marsaglia (<
>
> ldmarsag...@gmail.com>) escribió:
> > You only need one beam. I would use the first beam interruption as a
> >
> >> second home switch of sorts, setting that with the home_offset when
> >> you install a new wheel. The established home offset then becomes
> >> your new wheel reference. This should then be considered a fixed
> >> reference and a suitable distance from the work to prevent
> >> accidental contact during setup.
> >
> >   I was thinking about using the two beams that are transversally
> > cut by the well because that way I can measure the length of a
> > circular portion and have an exact measure of the radius
> > independently of the home distance or the part diameter being known.
> > The only thing that would matter with this approach would be to know
> > exact distance between one beam and the other and they off course
> > must be perfectly perpendicular to the wheel axis of movement.
> >
> > And obviously Leonardo, make a youtube video and tell us about it
> > when
> >
> >> its working. :)
> >
> >  Be sure I'll let you guys know as soon as I do something. In fact,
> > I can't wait to see and show you the mazak turning with LCNC. After
> > that, I hope I can start converting the grinder as soon as poosible!
> >
> >
> >
> > El dom., 22 mar. 2020 a las 10:41, Thaddeus Waldner
> > ()
> >
> > escribió:
> >> The most
> >>
> >> > primitive idea I have is to measure the wheel before placing it
> >> > into the machine and then keep track of its diameter as it gets
> >> > dressed. But sometimes we have to adjust the offset of the
> >> > dressing tool because a diamond just detaches from the tool and
> >> > then you need to correct for
> >>
> >> that
> >>
> >> > difference.
> >>
> >> I don’t know what the dressing system looks like, but if it’s
> >> motorized in both axis( cut depth and motion across the wheel) then
> >> why don’t you touch off the dressing point? You could do an initial
> >> homing when machine starts, and again after each dressing
> >> operation. Use the info to determine dressing point depth of cut
> >> and also to infer actual wheel diameter. You could also use it to
> >> catch the event of a diamond point being knocked loose, and alarm
> >> the operator.
> >>
> >>
> >>
> >> ___
> >> Emc-users mailing list
> >> Emc-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-users
>
> 

Re: [Emc-users] Question about index pulse on high resolution encoder

[Leonardo Marsaglia]

>
> I don’t know what the dressing system looks like, but if it’s motorized in
> both axis( cut depth and motion across the wheel) then why don’t you touch
> off the dressing point? You could do an initial homing when machine starts,
> and again after each dressing operation. Use the info to determine dressing
> point depth of cut and also to infer actual wheel diameter. You could also
> use it to catch the event of a diamond point being knocked loose, and alarm
> the operator.


Hello Thaddeus,

The machine doesn't have an independent wheel dresser so I plan to mount
the dresser on the right hand corner of the tailstock way. It has enough
room for this.

Actually we're doing what you suggest with the grinder that we have driven
by LCNC. But this one uses a master to shape the lobes to be machined, so
we only need to know the diameter of the part being ground. The problem I
see with only touching the wheel in one point, is that I need an exact
reference of the center of rotation of the wheel and I don't know if in
practice that's possible for me.

I don't understand the part about knowing the event of a diamond being
detached from the dressing tool. Please correct me if I don't understand
you well.

El dom., 22 mar. 2020 a las 10:41, Thaddeus Waldner ()
escribió:

> The most
> > primitive idea I have is to measure the wheel before placing it into the
> > machine and then keep track of its diameter as it gets dressed. But
> > sometimes we have to adjust the offset of the dressing tool because a
> > diamond just detaches from the tool and then you need to correct for that
> > difference.
>
> I don’t know what the dressing system looks like, but if it’s motorized in
> both axis( cut depth and motion across the wheel) then why don’t you touch
> off the dressing point? You could do an initial homing when machine starts,
> and again after each dressing operation. Use the info to determine dressing
> point depth of cut and also to infer actual wheel diameter. You could also
> use it to catch the event of a diamond point being knocked loose, and alarm
> the operator.
>
>
>
> ___
> 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] Question about index pulse on high resolution encoder

[andy pugh]

On Sun, 22 Mar 2020 at 16:59, Leonardo Marsaglia  wrote:

>  Thanks for the link Andy. But these I assume measure distance, reflecting
> the beam against a surface and then receiving it and measuring the time
> elapsed between the two events am I right?

No, these use triangulation rather than time-of-flight which is how
they manage such good resolution at small ranges.

You could have one mounted rigidly relative to the grinding wheel
spindle (behind a cover). Dress the wheel, open the cover, take a
reading and have a very accurate measure of wheel diameter to use in
offsetting and grinding geometry calcs.

-- 
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] Question about index pulse on high resolution encoder

[Leonardo Marsaglia]

>
> You would have to turn the coolant off to measure, but have a look at
> laser triangulation distance sensors:
> https://www.micro-epsilon.co.uk/news/2018/2018-05-15-optoNCDT-1750LL/
> (specifically mentions grinding wheels)


 Thanks for the link Andy. But these I assume measure distance, reflecting
the beam against a surface and then receiving it and measuring the time
elapsed between the two events am I right?

I was thinking in something more like two IR barriers transversally crossed
by the wheel. The problem is, this is just an idea it came to me because
geometrically ,for me, this is the simplest way I came up with to measure
the wheel radius only depending on the accuracy of the ballscrew and the
motor driving it. But I don't really know if one can achieve good levels
of repeatability with such a setup.


El dom., 22 mar. 2020 a las 13:52, Leonardo Marsaglia (<
ldmarsag...@gmail.com>) escribió:

> You only need one beam. I would use the first beam interruption as a
>> second home switch of sorts, setting that with the home_offset when you
>> install a new wheel. The established home offset then becomes your new
>> wheel reference. This should then be considered a fixed reference and a
>> suitable distance from the work to prevent accidental contact during
>> setup.
>
>
>   I was thinking about using the two beams that are transversally cut by
> the well because that way I can measure the length of a circular portion
> and have an exact measure of the radius independently of the home distance
> or the part diameter being known. The only thing that would matter with
> this approach would be to know exact distance between one beam and the
> other and they off course must be perfectly perpendicular to the wheel axis
> of movement.
>
> And obviously Leonardo, make a youtube video and tell us about it when
>> its working. :)
>
>
>  Be sure I'll let you guys know as soon as I do something. In fact, I
> can't wait to see and show you the mazak turning with LCNC. After that, I
> hope I can start converting the grinder as soon as poosible!
>
>
>
> El dom., 22 mar. 2020 a las 10:41, Thaddeus Waldner ()
> escribió:
>
>> The most
>> > primitive idea I have is to measure the wheel before placing it into the
>> > machine and then keep track of its diameter as it gets dressed. But
>> > sometimes we have to adjust the offset of the dressing tool because a
>> > diamond just detaches from the tool and then you need to correct for
>> that
>> > difference.
>>
>> I don’t know what the dressing system looks like, but if it’s motorized
>> in both axis( cut depth and motion across the wheel) then why don’t you
>> touch off the dressing point? You could do an initial homing when machine
>> starts, and again after each dressing operation. Use the info to determine
>> dressing point depth of cut and also to infer actual wheel diameter. You
>> could also use it to catch the event of a diamond point being knocked
>> loose, and alarm the operator.
>>
>>
>>
>> ___
>> 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] Question about index pulse on high resolution encoder

[Leonardo Marsaglia]

>
> You only need one beam. I would use the first beam interruption as a
> second home switch of sorts, setting that with the home_offset when you
> install a new wheel. The established home offset then becomes your new
> wheel reference. This should then be considered a fixed reference and a
> suitable distance from the work to prevent accidental contact during
> setup.


  I was thinking about using the two beams that are transversally cut by
the well because that way I can measure the length of a circular portion
and have an exact measure of the radius independently of the home distance
or the part diameter being known. The only thing that would matter with
this approach would be to know exact distance between one beam and the
other and they off course must be perfectly perpendicular to the wheel axis
of movement.

And obviously Leonardo, make a youtube video and tell us about it when
> its working. :)


 Be sure I'll let you guys know as soon as I do something. In fact, I can't
wait to see and show you the mazak turning with LCNC. After that, I hope I
can start converting the grinder as soon as poosible!



El dom., 22 mar. 2020 a las 10:41, Thaddeus Waldner ()
escribió:

> The most
> > primitive idea I have is to measure the wheel before placing it into the
> > machine and then keep track of its diameter as it gets dressed. But
> > sometimes we have to adjust the offset of the dressing tool because a
> > diamond just detaches from the tool and then you need to correct for that
> > difference.
>
> I don’t know what the dressing system looks like, but if it’s motorized in
> both axis( cut depth and motion across the wheel) then why don’t you touch
> off the dressing point? You could do an initial homing when machine starts,
> and again after each dressing operation. Use the info to determine dressing
> point depth of cut and also to infer actual wheel diameter. You could also
> use it to catch the event of a diamond point being knocked loose, and alarm
> the operator.
>
>
>
> ___
> 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] Question about index pulse on high resolution encoder

[Thaddeus Waldner]

The most
> primitive idea I have is to measure the wheel before placing it into the
> machine and then keep track of its diameter as it gets dressed. But
> sometimes we have to adjust the offset of the dressing tool because a
> diamond just detaches from the tool and then you need to correct for that
> difference.

I don’t know what the dressing system looks like, but if it’s motorized in both 
axis( cut depth and motion across the wheel) then why don’t you touch off the 
dressing point? You could do an initial homing when machine starts, and again 
after each dressing operation. Use the info to determine dressing point depth 
of cut and also to infer actual wheel diameter. You could also use it to catch 
the event of a diamond point being knocked loose, and alarm the operator.



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

Re: [Emc-users] Question about index pulse on high resolution encoder --> laser distance sensor

[Nicklas Karlsson]

> On Sun, 22 Mar 2020 at 00:52, Leonardo Marsaglia  
> wrote:
> 
> > The only real problem I see is how
> > to get a good measure of the grinding wheel as you dress it.
> 
> You would have to turn the coolant off to measure, but have a look at
> laser triangulation distance sensors:
> https://www.micro-epsilon.co.uk/news/2018/2018-05-15-optoNCDT-1750LL/
> (specifically mentions grinding wheels)

It seems like a rather good measurement probe, always been in doubt about these 
using time as speed of light is very fast. Accuracy seems rather good unless 
coolant is subtracted from distance of course.


Nicklas Karlsson


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

Re: [Emc-users] Question about index pulse on high resolution encoder

[andy pugh]

On Sun, 22 Mar 2020 at 00:52, Leonardo Marsaglia  wrote:

> The only real problem I see is how
> to get a good measure of the grinding wheel as you dress it.

You would have to turn the coolant off to measure, but have a look at
laser triangulation distance sensors:
https://www.micro-epsilon.co.uk/news/2018/2018-05-15-optoNCDT-1750LL/
(specifically mentions grinding wheels)

Alternatively you could simply stop the wheel and use a touch-probe.

-- 
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] Question about index pulse on high resolution encoder

[Gene Heskett]

On Saturday 21 March 2020 20:49:21 Leonardo Marsaglia wrote:

> I'm just guessing 200 rpm because of the speed I can develop on the
> Mazak now wich is 10 meter/min. I would love to have some more speed
> available but that will come with testing.
>
> What I intend to do with the grinder is something like this:
> https://www.youtube.com/watch?v=UGgR1GFOFhU
>
> This guy did it with a chinese control and used the spindle as a C
> axis. Is another way of doing it but I really preffer the spindle
> tracking method. I already have a cylindrical grinder that's waiting
> to be retrofitted with LCNC. In fact, right after the Mazak I plan to
> start working on that machine.
>
> I don't see it as a problem to compensate for the wheel radius because
> as you know HAL can handle almost anything. The only real problem I
> see is how to get a good measure of the grinding wheel as you dress
> it. The most primitive idea I have is to measure the wheel before
> placing it into the machine and then keep track of its diameter as it
> gets dressed. But sometimes we have to adjust the offset of the
> dressing tool because a diamond just detaches from the tool and then
> you need to correct for that difference. Although little variations in
> wheel radius are not that significant in such diameters (600 mm more
> or less) I would like to have a way to measure the wheel without
> stopping it. By the way these machines don't use the small CBN wheels
> because they are anything but new.
>
> The first thing I have in mind for measuring the wheel are two laser
> pointers one above the other so when the wheel "touches" the first
> beam you have the first point of the circumference and then the wheel
> continues moving until it "touches" the second beam and now you can
> calculate the lenght of the circular sector and hence the radius. The
> problem is, this is just theory and having such a system working with
> the accuracy needed escapes from my actual knowledge and experience in
> optics which is very poor. I attached a picture so it's more clear
> what I came up with in my head.
>
>  So I guess the measure the wheel and keep track of the diameter will
> be my first method to compensate for the radius.

TL, read anyway.

You only need one beam. I would use the first beam interruption as a 
second home switch of sorts, setting that with the home_offset when you 
install a new wheel. The established home offset then becomes your new 
wheel reference. This should then be considered a fixed reference and a 
suitable distance from the work to prevent accidental contact during 
setup.

Next write an xml file to draw a couple pyvcp buttons, something like 
this perhaps:
!-- and stuff to control mist motor speed -->
  

  

  ("5")
  "mist-on-adj"
  .000
  .025
  .005
  0.001
  ".3f"
  ("Helvitica",12)
  0


  ("5")
  "mist-off-adj"
  .000
  .250
  .100
  0.001
  ".3f"
  ("Helvitica",12)
  0

  


Both of the spinboxes that makes have halpin outputs of their displays 
but that mess, which I'm using to twiddle the on and offtimes of a timer 
driving a peristaltic coolant pump to spray wet the tool in my 6040 
mill, but here it could be reduced to one spinbutton by making the 
second one a tach bar to display the outout of the laser's rx cell, and 
the first one is used to twiddle a gcode var which becomes your wheel 
wear amount, displayed by the spinbox, and ship it back across motion 
with one of the m6x analogue channels. Subtract that from the radius of 
the new wheel before doing the up/down calcs. From there on, your gcode 
carves the cam with automatic wear comp. If wheel wear is so fast your 
need to comp it mid-lobe, you can write a suitable pause and do it in 
the middle of a lobe. You could even use a charge-pump output to drive 
the adjustment in that mid-lobe correction making it an automatic null 
and a lights out operation you wouldn't have to hover over. Don't forget 
to turn the coolant off (and back on when done) since it would interfer 
with the laser if running. And don't forget to refresh that variable in 
your main code loop so if its been corrected in the middle of carving a 
lobe, the new value is used by the rest of the calcs your code will do.

I'm obviously better at dreaming this stuff up than in writing a cogent 
explanation but I hope this will help.

And obviously Leonardo, make a youtube video and tell us about it when 
its working. :)
>
> El sáb., 21 mar. 2020 a las 20:35, Gene Heskett
> ()
>
> escribió:
> > On Saturday 21 March 2020 16:11:44 andy pugh wrote:
> > > On Sat, 21 Mar 2020 at 17:44, Leonardo Marsaglia
> >
> >  wrote:
> > > > I intend to turn automotive camshafts, that is with a minimum of
> > > > 180º of base circle (sometimes called heel I think

Re: [Emc-users] Question about index pulse on high resolution encoder

[Leonardo Marsaglia]

I'm just guessing 200 rpm because of the speed I can develop on the Mazak
now wich is 10 meter/min. I would love to have some more speed available
but that will come with testing.

What I intend to do with the grinder is something like this:
https://www.youtube.com/watch?v=UGgR1GFOFhU

This guy did it with a chinese control and used the spindle as a C axis. Is
another way of doing it but I really preffer the spindle tracking method. I
already have a cylindrical grinder that's waiting to be retrofitted with
LCNC. In fact, right after the Mazak I plan to start working on that
machine.

I don't see it as a problem to compensate for the wheel radius because as
you know HAL can handle almost anything. The only real problem I see is how
to get a good measure of the grinding wheel as you dress it. The most
primitive idea I have is to measure the wheel before placing it into the
machine and then keep track of its diameter as it gets dressed. But
sometimes we have to adjust the offset of the dressing tool because a
diamond just detaches from the tool and then you need to correct for that
difference. Although little variations in wheel radius are not that
significant in such diameters (600 mm more or less) I would like to have a
way to measure the wheel without stopping it. By the way these machines
don't use the small CBN wheels because they are anything but new.

The first thing I have in mind for measuring the wheel are two laser
pointers one above the other so when the wheel "touches" the first beam you
have the first point of the circumference and then the wheel continues
moving until it "touches" the second beam and now you can calculate the
lenght of the circular sector and hence the radius. The problem is, this is
just theory and having such a system working with the accuracy needed
escapes from my actual knowledge and experience in optics which is very
poor. I attached a picture so it's more clear what I came up with in my
head.

 So I guess the measure the wheel and keep track of the diameter will be my
first method to compensate for the radius.



El sáb., 21 mar. 2020 a las 20:35, Gene Heskett ()
escribió:

> On Saturday 21 March 2020 16:11:44 andy pugh wrote:
>
> > On Sat, 21 Mar 2020 at 17:44, Leonardo Marsaglia
>  wrote:
> > > I intend to turn automotive camshafts, that is with a minimum of
> > > 180º of base circle (sometimes called heel I think), and a maximum
> > > lift of about 8 mm
> >
> > In that case the high resolution encoder might be good. I doubt that
> > you will me machining camshafts at 20,000 rpm.
> > (Especially not if the cutter needs to dive in and out)
> >
> > For grinding you need to consider how the contact point rolls above
> > and below the centre line. I did do the maths, when I did the
> > crank-grinding mock-up. But only for a circular but eccentric result.
>
> Another thought or 2 here.
>
> The weight of the grinder you'll have sitting on the crossfeed will
> effect your usable spindle rpms by slowing down the maximum attainable
> accel's. My nema 24, x on the sheldon, geared 2/1 has a 3o ipm max
> limit, so that motor will need a serious boost in top speed to even try
> doing that at 200 rpm.
>
> If room for its diameter, the use of a flat faced CBN wheel would
> eliminate some of the math by eliminating the calculation of the wheels
> up and down due to the curvature of the wheel face but I think whats
> available is way too big for this. The use of CBN should however
> lengthen the cutting life of the wheel compared to the alox versions,
> particularly if running wet as I have seen it done in some of the you
> tube videos.
>
> 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
>


Grinding wheel example.PDF
Description: Adobe PDF document
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Question about index pulse on high resolution encoder

[Gene Heskett]

On Saturday 21 March 2020 16:11:44 andy pugh wrote:

> On Sat, 21 Mar 2020 at 17:44, Leonardo Marsaglia 
 wrote:
> > I intend to turn automotive camshafts, that is with a minimum of
> > 180º of base circle (sometimes called heel I think), and a maximum
> > lift of about 8 mm
>
> In that case the high resolution encoder might be good. I doubt that
> you will me machining camshafts at 20,000 rpm.
> (Especially not if the cutter needs to dive in and out)
>
> For grinding you need to consider how the contact point rolls above
> and below the centre line. I did do the maths, when I did the
> crank-grinding mock-up. But only for a circular but eccentric result.

Another thought or 2 here.

The weight of the grinder you'll have sitting on the crossfeed will 
effect your usable spindle rpms by slowing down the maximum attainable 
accel's. My nema 24, x on the sheldon, geared 2/1 has a 3o ipm max 
limit, so that motor will need a serious boost in top speed to even try 
doing that at 200 rpm.

If room for its diameter, the use of a flat faced CBN wheel would 
eliminate some of the math by eliminating the calculation of the wheels 
up and down due to the curvature of the wheel face but I think whats 
available is way too big for this. The use of CBN should however 
lengthen the cutting life of the wheel compared to the alox versions, 
particularly if running wet as I have seen it done in some of the you 
tube videos.

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] Question about index pulse on high resolution encoder

[Leonardo Marsaglia]

>
> In that case the high resolution encoder might be good. I doubt that
> you will me machining camshafts at 20,000 rpm.
> (Especially not if the cutter needs to dive in and out)
>
> For grinding you need to consider how the contact point rolls above
> and below the centre line. I did do the maths, when I did the
> crank-grinding mock-up. But only for a circular but eccentric result.


I remember the first time I took a look at your oval comp I started to
calculate the radius compensation for the grinding wheel. I only did it in
solidworks with lines and triangles but it worked. The good thing is that
for eccentrics you only use equations but for the different lobes/cams I
have I can only get the control points.

I would love to have the possibility to extract the data from the lobes in
the form of a function defined in parts. Now I can only rely on acquire the
lift in intervals of 5 degrees and complete the spline using software. Then
export that curve with the number of control points I need. But reverse
engineering the equations seems to be a pain in the ass and I don't know
how much of an advantage that would give me.

>
>

El sáb., 21 mar. 2020 a las 18:46, Leonardo Marsaglia (<
ldmarsag...@gmail.com>) escribió:

> correction whenever, scale is encoder input A count for 100 turns,
>> divided by 100, do not throw away the decimal fraction.
>> In my ini file under [SPINDEL] i HAVE:
>> ENCODER_SCALE_H = 7161.61
>> ENCODER_SCALE_L = 14095.34
>> and:
>> SCALE_UP= 1.96818033933710437
>> SCALE_DOWN  = 0.508083522639397134
>>
>
> Indded I didn't and I try to use the more decimal numbers the calculator
> allows me to use. Fortunately I only have 1 gear on the Mazak, but anyway
> the encoder is directly coupled to the spindle shaft with a timing belt so
> no issues with that matter. Its working flawlessly now that it has the
> original control so it should do equally right with LCNC. The beauty of
> having a continuous curve for lobes drawn in autocad is that I can export
> them with the amount of points I want so I can match the encoder exactly.
> Now I'm doing fine with 512 control points, but If I want I  could use the
> 1024 pulses of the encoder each one with a control point.
>
> The only thing I have left to test is how it goes on the Mazak at around
> 200 RPM which is the average speed I plan to use to turn the lobes. I hope
> I can go back as soon as possible to install the new control and start the
> real machining :).
>
> El sáb., 21 mar. 2020 a las 17:15, andy pugh ()
> escribió:
>
>> On Sat, 21 Mar 2020 at 17:44, Leonardo Marsaglia 
>> wrote:
>>
>> > I intend to turn automotive camshafts, that is with a minimum of 180º of
>> > base circle (sometimes called heel I think), and a maximum lift of
>> about 8
>> > mm
>>
>> In that case the high resolution encoder might be good. I doubt that
>> you will me machining camshafts at 20,000 rpm.
>> (Especially not if the cutter needs to dive in and out)
>>
>> For grinding you need to consider how the contact point rolls above
>> and below the centre line. I did do the maths, when I did the
>> crank-grinding mock-up. But only for a circular but eccentric result.
>>
>> --
>> 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] Question about index pulse on high resolution encoder

[Leonardo Marsaglia]

>
> correction whenever, scale is encoder input A count for 100 turns,
> divided by 100, do not throw away the decimal fraction.
> In my ini file under [SPINDEL] i HAVE:
> ENCODER_SCALE_H = 7161.61
> ENCODER_SCALE_L = 14095.34
> and:
> SCALE_UP= 1.96818033933710437
> SCALE_DOWN  = 0.508083522639397134
>

Indded I didn't and I try to use the more decimal numbers the calculator
allows me to use. Fortunately I only have 1 gear on the Mazak, but anyway
the encoder is directly coupled to the spindle shaft with a timing belt so
no issues with that matter. Its working flawlessly now that it has the
original control so it should do equally right with LCNC. The beauty of
having a continuous curve for lobes drawn in autocad is that I can export
them with the amount of points I want so I can match the encoder exactly.
Now I'm doing fine with 512 control points, but If I want I  could use the
1024 pulses of the encoder each one with a control point.

The only thing I have left to test is how it goes on the Mazak at around
200 RPM which is the average speed I plan to use to turn the lobes. I hope
I can go back as soon as possible to install the new control and start the
real machining :).

El sáb., 21 mar. 2020 a las 17:15, andy pugh ()
escribió:

> On Sat, 21 Mar 2020 at 17:44, Leonardo Marsaglia 
> wrote:
>
> > I intend to turn automotive camshafts, that is with a minimum of 180º of
> > base circle (sometimes called heel I think), and a maximum lift of about
> 8
> > mm
>
> In that case the high resolution encoder might be good. I doubt that
> you will me machining camshafts at 20,000 rpm.
> (Especially not if the cutter needs to dive in and out)
>
> For grinding you need to consider how the contact point rolls above
> and below the centre line. I did do the maths, when I did the
> crank-grinding mock-up. But only for a circular but eccentric result.
>
> --
> 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] Question about index pulse on high resolution encoder

[andy pugh]

On Sat, 21 Mar 2020 at 17:44, Leonardo Marsaglia  wrote:

> I intend to turn automotive camshafts, that is with a minimum of 180º of
> base circle (sometimes called heel I think), and a maximum lift of about 8
> mm

In that case the high resolution encoder might be good. I doubt that
you will me machining camshafts at 20,000 rpm.
(Especially not if the cutter needs to dive in and out)

For grinding you need to consider how the contact point rolls above
and below the centre line. I did do the maths, when I did the
crank-grinding mock-up. But only for a circular but eccentric result.

-- 
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] Question about index pulse on high resolution encoder

[Gene Heskett]

On Saturday 21 March 2020 12:29:13 Leonardo Marsaglia wrote:

> Answering to Andy and Gene,
>
> I'm tracking the position of the spindle (now simulated with this
> encoder but in the final machine I'll be using a 1024 PPR encoder)
> resetting the position counter after each index pulse and using that
> as reference for a new turn of the spindle.
>
They may have a better way, I an using 2 separate systems on by g0704 
that look like a totally custom encoder because it is.

First I have a piece of a nail jbwelded to the side of the drawbar cap, a 
good 5/8's of an inch long, vertical of course.
 
Then an ATS667 is mounted to the vertical face faceing the drawbar cap 
and clearing the nail as it spins by about 10 thou. With a 3.1mm 3 pin 
socket glued to the top of the block withe the tantalum by pass on it 
rear pins where the 667's legs are attached. This cable is routed into a 
small small Hammond box containing a pair of rs485 to ttl convertors.

The encoder carrying and generating the A/B an -A/-B signals is mounted 
on top of the G0704's spindle motor on a small brass extension shaft and 
there for reads motor rev at 4k edges per turn. Scale for the ini files 
Spindle section was determined by count A pulses for 100 index pulses 
and freezing the count, it just over 7K in high gear, and just over 14K 
in low gear.

Then I cut a micro switch roller sized notch in the edge of the gear 
shift knobs skirt. And sandwitched two switches positioned to drop there 
levers into the notches, and wired their NC tabs up to a couple inputs 
on the bobs. Using some hal parts, I change the SCALE so the tach is 
accurate in either gear, and the scale itself, so the number used is 
correct for a full rev in either spindle gear.

Then while grabbing the stopped spindle to change gears, An idea hit me 
to make that easier if I changed the mux2 to a mux4 giving me a motor 
speed input if neither tally switch was closed. So I changed the mux to 
a mux4, and setp'd the other two inputs to about a 15 rpm tickle.  Now I 
can reach for the knob and change it on the fly at any spindle speed 
without having to grab the spindle and feel for the engagement of the 
flat faced gears. The servo is both fast and powerfull, so if its 
running wide open at 1500 in low gear, the spindle is down to 5 rpm 100 
millisecs after the knob has started to move, it stops in the middle and 
goes up to 10 revs as the other gears start to mesh, and snaps back to 
3k rpms when the switch roller drops the last 10 thou into the notch.
I need to change that out of gear logic to run the motor even if LCNC 
isn't so I can change gears just as painlessly when its stopped. But 
thats also the shoemakers kids story too. :)

Hal is your friend and you can do a heck of a lot more than you can 
imagine, all you have to do is imagine it, and code it up.

> Do you think it's better for me to only use one index pulse to set the
> reference and then count the position output to keep tracking of the
> spindle position and whenever I sum 1024 pulses I get one turn? I
> mean, not using the index for each revolution, only using it as a
> reference starting point.

correction whenever, scale is encoder input A count for 100 turns, 
divided by 100, do not throw away the decimal fraction.
In my ini file under [SPINDEL] i HAVE:
ENCODER_SCALE_H = 7161.61
ENCODER_SCALE_L = 14095.34
and:
SCALE_UP= 1.96818033933710437
SCALE_DOWN  = 0.508083522639397134

So I have whichever scale, and the multipliers to get what I want very 
accurately.
To determine that scale, but now commented, I have:
#*
# calibrate spindle to new encoder   *
# use halshow to reset updown for new count  *
# this code is not part of normal operation  *
# used only to determine working gear ratios *
#*
# sample rate now turned up so filter can be used
# add modules and addf's to suit, and comment them out when done
# remove one # below to activate
setp hm2_5i25.0.encoder.00.filter true
#net scalibrate0 mux2cal0.out mux2cal0.in1 spndl_tally.in0 
## above makes a sample-hold
#net scalibrate1 mux2cal1.out mux2cal1.in1 spndl_tally.in1 # ditto
#net ztrack <= hm2_5i25.0.gpio.016.in spndl_cntr.countup
#net ztrakS32 spndl_cntr.count S32_float-cntr.in
#net ztrackF S32_float-cntr.out comp_cal0.in1 comp_cal1.in1
## spndl_tally is actually a sum2
#setp spndl_tally.gain0 -1.000 #make it a diff2
#setp spndl_tally.gain1  1.000
##** set to log 100 indexes
#setp comp_cal0.in0 5.5
#setp comp_cal1.in0 105.5
#net Scounter-in hm2_5i25.0.encoder.00.rawcounts S32_float-cal.in
#net Fcounter-in S32_float-cal.out mux2cal0.in0 mux2cal1.in0
#net shhold0 comp_cal0.out mux2cal0.sel
#net shhold1 comp_cal1.out mux2cal1.sel

## when mux2-cal1.out is frozen, do [spndl-tally.out / 100] to get scale.
## repeat for other gear for 2nd scale factor. When done, comment it all 
## out

>
> El sáb., 21 mar. 

Re: [Emc-users] Question about index pulse on high resolution encoder

[Nicklas Karlsson]

> Answering to Andy and Gene,
> 
> I'm tracking the position of the spindle (now simulated with this encoder
> but in the final machine I'll be using a 1024 PPR encoder) resetting the
> position counter after each index pulse and using that as reference for a
> new turn of the spindle.
> 
> Do you think it's better for me to only use one index pulse to set the
> reference and then count the position output to keep tracking of the
> spindle position and whenever I sum 1024 pulses I get one turn? I mean, not
> using the index for each revolution, only using it as a reference starting
> point.

Sum 1024 pulses to get one turn is most probably the best choice otherwise 
there might be a one turn glitch if number of turns is not perfectly updated.

If you know number of pulses per turn best would however be to use index pulse 
to detect if any pulse is missed and maybe correct it. Have seen example for 
Micro controller from manufacturer there they made choice to reset counter at 
zero pulse from encoder but decided to connect input to caputer instead for 
this reason.


Got datasheet but did not immidately figure out signals from encoder, use to be 
either sin/cos or quadrature. 5000 lines and 125000 pulses per turn must be 
from the 25-fold interpolation, I would expect interpolation to add much. 5000 
lines per turn is in line with high resolution optical encoder from other 
manufacturer, have 2000P/R but think same manufacturer have some higher also.


Regards Nicklas Karlsson


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

Re: [Emc-users] Question about index pulse on high resolution encoder

[Leonardo Marsaglia]

>
> Probably. It rather depends on what you are trying to do. From the
> fact that you are considering options, I assume that this is something
> other than normal built-in linuxcnc operation?


Basicly I'm inspiring myself in your non circular turning, but using
external offsets since is not needed anymore to fool the motion module of
LinuxCNC.

I intend to turn automotive camshafts, that is with a minimum of 180º of
base circle (sometimes called heel I think), and a maximum lift of about 8
mm.

So far, it's the same as you did back then. The only difference is that I
in general I need to use two profiles (one for intake and one exhaust) and
offset them in 90º, 180º and 270º to machine the majority of camshafts we
machine now which are for 4 cylinder engines.

Off course if this probes to be reliable (wich I'm more than confident It
will be) the next step is to install LinuxCNC on a cylindrical grinder to
finish the lobes without master.





El sáb., 21 mar. 2020 a las 14:04, andy pugh ()
escribió:

> On Sat, 21 Mar 2020 at 16:32, Leonardo Marsaglia 
> wrote:
> >
> > Do you think it's better for me to only use one index pulse to set the
> > reference and then count the position output to keep tracking of the
> > spindle position and whenever I sum 1024 pulses I get one turn?
>
> Probably. It rather depends on what you are trying to do. From the
> fact that you are considering options, I assume that this is something
> other than normal built-in linuxcnc operation?
>
> --
> 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] Question about index pulse on high resolution encoder

[andy pugh]

On Sat, 21 Mar 2020 at 16:32, Leonardo Marsaglia  wrote:
>
> Do you think it's better for me to only use one index pulse to set the
> reference and then count the position output to keep tracking of the
> spindle position and whenever I sum 1024 pulses I get one turn?

Probably. It rather depends on what you are trying to do. From the
fact that you are considering options, I assume that this is something
other than normal built-in linuxcnc operation?

-- 
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] Question about index pulse on high resolution encoder

[Leonardo Marsaglia]

By the way Nicklas, I attached the manual but it's waiting for approval. If
it can't be attached I'll upload to some file storage page.

El sáb., 21 mar. 2020 a las 13:29, Leonardo Marsaglia (<
ldmarsag...@gmail.com>) escribió:

> Answering to Andy and Gene,
>
> I'm tracking the position of the spindle (now simulated with this encoder
> but in the final machine I'll be using a 1024 PPR encoder) resetting the
> position counter after each index pulse and using that as reference for a
> new turn of the spindle.
>
> Do you think it's better for me to only use one index pulse to set the
> reference and then count the position output to keep tracking of the
> spindle position and whenever I sum 1024 pulses I get one turn? I mean, not
> using the index for each revolution, only using it as a reference starting
> point.
>
>
>
> El sáb., 21 mar. 2020 a las 13:19, Leonardo Marsaglia (<
> ldmarsag...@gmail.com>) escribió:
>
>> You happen to have a datasheet for the ERN471 encoder?
>>
>>
>> I'm attaching it to the message. Hope it uploads.
>>
>> El sáb., 21 mar. 2020 a las 10:33, Nicklas Karlsson (<
>> nicklas.karlsso...@gmail.com>) escribió:
>>
>>> > On Saturday 21 March 2020 04:04:03 Nicklas Karlsson wrote:
>>> >
>>> > > > Hello guys,
>>> > > >
>>> > > > I'm testing a phisical encoder to simulate how the spindle will
>>> work
>>> > > > with the external offsets. So far so good but I need to clarify
>>> > > > something that I suspect. Here it comes:
>>> > > >
>>> > > > The encoder I'm testing is an ERN471 from Heidenhain. A beast of
>>> > > > encoder. It says 5.000 line counts on the datasheet but also says
>>> it
>>> > > > outputs 125.000 signal periods per revolution, so when I read it in
>>> > > > LinuxCNC with a scale of 1 I find that I'm having 500.000 pulses
>>> per
>>> > > > turn. A lot of resolution. ...
>>> > >
>>> > > Maybe me stupid. My machine had Heidenhein encoders but I did not get
>>> > > them work and replaced them with 2000P/R encoders.
>>> > >
>>> > Don't be so hard on yourself. Probably the smartest move you could
>>> have
>>> > made. Those ERN471's would be much more suitable on a fraction of a
>>> turn
>>> > robotic arm.
>>>
>>> You happen to have a datasheet for the ERN471 encoder?
>>>
>>>
>>> ___
>>> 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] Question about index pulse on high resolution encoder

[Leonardo Marsaglia]

Answering to Andy and Gene,

I'm tracking the position of the spindle (now simulated with this encoder
but in the final machine I'll be using a 1024 PPR encoder) resetting the
position counter after each index pulse and using that as reference for a
new turn of the spindle.

Do you think it's better for me to only use one index pulse to set the
reference and then count the position output to keep tracking of the
spindle position and whenever I sum 1024 pulses I get one turn? I mean, not
using the index for each revolution, only using it as a reference starting
point.



El sáb., 21 mar. 2020 a las 13:19, Leonardo Marsaglia (<
ldmarsag...@gmail.com>) escribió:

> You happen to have a datasheet for the ERN471 encoder?
>
>
> I'm attaching it to the message. Hope it uploads.
>
> El sáb., 21 mar. 2020 a las 10:33, Nicklas Karlsson (<
> nicklas.karlsso...@gmail.com>) escribió:
>
>> > On Saturday 21 March 2020 04:04:03 Nicklas Karlsson wrote:
>> >
>> > > > Hello guys,
>> > > >
>> > > > I'm testing a phisical encoder to simulate how the spindle will work
>> > > > with the external offsets. So far so good but I need to clarify
>> > > > something that I suspect. Here it comes:
>> > > >
>> > > > The encoder I'm testing is an ERN471 from Heidenhain. A beast of
>> > > > encoder. It says 5.000 line counts on the datasheet but also says it
>> > > > outputs 125.000 signal periods per revolution, so when I read it in
>> > > > LinuxCNC with a scale of 1 I find that I'm having 500.000 pulses per
>> > > > turn. A lot of resolution. ...
>> > >
>> > > Maybe me stupid. My machine had Heidenhein encoders but I did not get
>> > > them work and replaced them with 2000P/R encoders.
>> > >
>> > Don't be so hard on yourself. Probably the smartest move you could have
>> > made. Those ERN471's would be much more suitable on a fraction of a
>> turn
>> > robotic arm.
>>
>> You happen to have a datasheet for the ERN471 encoder?
>>
>>
>> ___
>> 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] Question about index pulse on high resolution encoder

[Nicklas Karlsson]

> On Saturday 21 March 2020 04:04:03 Nicklas Karlsson wrote:
> 
> > > Hello guys,
> > >
> > > I'm testing a phisical encoder to simulate how the spindle will work
> > > with the external offsets. So far so good but I need to clarify
> > > something that I suspect. Here it comes:
> > >
> > > The encoder I'm testing is an ERN471 from Heidenhain. A beast of
> > > encoder. It says 5.000 line counts on the datasheet but also says it
> > > outputs 125.000 signal periods per revolution, so when I read it in
> > > LinuxCNC with a scale of 1 I find that I'm having 500.000 pulses per
> > > turn. A lot of resolution. ...
> >
> > Maybe me stupid. My machine had Heidenhein encoders but I did not get
> > them work and replaced them with 2000P/R encoders.
> >
> Don't be so hard on yourself. Probably the smartest move you could have 
> made. Those ERN471's would be much more suitable on a fraction of a turn 
> robotic arm.

You happen to have a datasheet for the ERN471 encoder?


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

Re: [Emc-users] Question about index pulse on high resolution encoder

[Gene Heskett]

On Saturday 21 March 2020 08:29:41 andy pugh wrote:

> On Sat, 21 Mar 2020 at 03:52, Leonardo Marsaglia 
 wrote:
> > I would like to hear your thoughts just to be relaxed, since a
> > missing index pulse on this kind of processes is likely to break the
> > tool and spoil the part.
>
> Missing an index isn't a problem, it just means that the threading
> cycle will start next time the spindle comes round, or the time after
> that.
> From that point on the index isn't used.
>
> Getting an _extra_ index would be bad, but even then, only on
> multi-pass tapping or threading processes.

I believe this may be why I'm getting sloppier threads when rigid tapping 
by pecking at the hole with an increasing depth.  Are there any actions 
we can take in that scenario that will tighten that up?

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] Question about index pulse on high resolution encoder

[andy pugh]

On Sat, 21 Mar 2020 at 03:52, Leonardo Marsaglia  wrote:

> I would like to hear your thoughts just to be relaxed, since a missing
> index pulse on this kind of processes is likely to break the tool and
> spoil the part.

Missing an index isn't a problem, it just means that the threading
cycle will start next time the spindle comes round, or the time after
that.
From that point on the index isn't used.

Getting an _extra_ index would be bad, but even then, only on
multi-pass tapping or threading processes.

-- 
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] Question about index pulse on high resolution encoder

[Gene Heskett]

On Saturday 21 March 2020 04:04:03 Nicklas Karlsson wrote:

> > Hello guys,
> >
> > I'm testing a phisical encoder to simulate how the spindle will work
> > with the external offsets. So far so good but I need to clarify
> > something that I suspect. Here it comes:
> >
> > The encoder I'm testing is an ERN471 from Heidenhain. A beast of
> > encoder. It says 5.000 line counts on the datasheet but also says it
> > outputs 125.000 signal periods per revolution, so when I read it in
> > LinuxCNC with a scale of 1 I find that I'm having 500.000 pulses per
> > turn. A lot of resolution. ...
>
> Maybe me stupid. My machine had Heidenhein encoders but I did not get
> them work and replaced them with 2000P/R encoders.
>
Don't be so hard on yourself. Probably the smartest move you could have 
made. Those ERN471's would be much more suitable on a fraction of a turn 
robotic arm.

> Nicklas Karlsson
>
>
> ___
> 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] Question about index pulse on high resolution encoder

[Nicklas Karlsson]

> Hello guys,
> 
> I'm testing a phisical encoder to simulate how the spindle will work with
> the external offsets. So far so good but I need to clarify something that I
> suspect. Here it comes:
> 
> The encoder I'm testing is an ERN471 from Heidenhain. A beast of encoder.
> It says 5.000 line counts on the datasheet but also says it outputs 125.000
> signal periods per revolution, so when I read it in LinuxCNC with a scale
> of 1 I find that I'm having 500.000 pulses per turn. A lot of resolution.
> ...

Maybe me stupid. My machine had Heidenhein encoders but I did not get them work 
and replaced them with 2000P/R encoders.


Nicklas Karlsson


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

Re: [Emc-users] Question about index pulse on high resolution encoder

[John Dammeyer]

> >Unfortunately this is the only encoder I have here to make the tests, so I
> >will not have a real conclusion until I test the differential encoder on
> >the Mazak.
> 
> The index pulse will be too short for the slow sampling of halscope to sample
> reliably. The way to check index is to "setp" the encoder index enable pin
> (or if its already connected, "sets" the signal that its connected to)
> Once set, index enable should get cleared at the index position
> This is done in the encoder hardware so not dependent on halscopes
> sample rate

Clever way to test that!
John


> 
> 
> Peter Wallace
> Mesa Electronics
> 
> 
> ___
> 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] Question about index pulse on high resolution encoder

[Peter C. Wallace]

On Sat, 21 Mar 2020, Leonardo Marsaglia wrote:


Date: Sat, 21 Mar 2020 01:27:52 -0300
From: Leonardo Marsaglia 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Question about index pulse on high resolution encoder

I just set index-invert to TRUE and FILTER to false on the hostmot encoder
parameters and until now it's not missing pulses anymore. I'll keep testing
it to see how it goes.



Yes, both the filter setting and the global encoder sample rate setting
determine the minimum detectable A,B, and IDX pulse width:

15 encoder sample frequency periods with the filter on

3 encoder sample frequency periods with the filter off



Peter Wallace
Mesa Electronics



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

Re: [Emc-users] Question about index pulse on high resolution encoder

[Gene Heskett]

On Friday 20 March 2020 23:48:46 Leonardo Marsaglia wrote:

> Hello guys,
>
> I'm testing a phisical encoder to simulate how the spindle will work
> with the external offsets. So far so good but I need to clarify
> something that I suspect. Here it comes:
>
> The encoder I'm testing is an ERN471 from Heidenhain. A beast of
> encoder. It says 5.000 line counts on the datasheet but also says it
> outputs 125.000 signal periods per revolution, so when I read it in
> LinuxCNC with a scale of 1 I find that I'm having 500.000 pulses per
> turn. A lot of resolution.

Yes, too much, there little to be gained by going smaller than 1 degree.
A $20 OMRON ball bearing model from ebay with 1000 lines per rev is more 
that enough.  Save that for motorizing an HS-1 to put gear cutting in 
the lights out category.

> I'm scaling it to 1024 since this is what I 
> have on the Mazak.

You should set the SCALE in the ini file for whatever counts it hits in 
one revolution.  I have code that measures that for 100 triggers of the 
index, and I divide that count by 100 to set the ini files SCALE. I also 
have tally switches on the head gearshifter to change the scale 
multiplier so the tach remains dead accurate.

> My concern is (and I think this is to be expected) that I have missing
> index pulses if I rotate the encoder too fast with my fingers. I tried
> to use a shorter servo-period and that seemed to improve things a
> little but not solving the problem always.
>
> Is this what's happening? Should I not expect this behaviour with the
> 1024 PPR encoder and the spindle turning at about 200 RPM ?
>
> I would like to hear your thoughts just to be relaxed, since a missing
> index pulse on this kind of processes is likely to break the tool and
> spoil the part.
>
> Thanks as always!

I think I'd put a 1 shot chip in the index line to stretch the index 
pulse several times, sending a lengthened pulse to the encoder's 
index.input.

Do it ship in a pill bottle style with the trimpot mounted you can trim 
it while you can look at the pulse hitting the index.input and adjust 
the trimpot so as to make sure the 1 shot recovers within 1/2 a rev with 
the spindle at its maximum rpm.
> ___
> 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] Question about index pulse on high resolution encoder

[Peter C. Wallace]

On Sat, 21 Mar 2020, Leonardo Marsaglia wrote:


Date: Sat, 21 Mar 2020 01:21:16 -0300
From: Leonardo Marsaglia 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Question about index pulse on high resolution encoder

Hello John,



I connected it using the differential pairs. Although the encoder says is
TTL differential and doesn't mention anything about RS-422  but it seems to
be working fine.

From what I've reading I'm not sure if halscope can sense that index pulse
because of the same reason I suspect hal is missing it. I'm triggering the
index with a custom made component to apply offsets to the X axis. I even
forced the component to set index to 1 on each iteration without even
sensing if it's on 0 and the same thing happens, if I turn it too fast the
index pulse is skipped.

Unfortunately this is the only encoder I have here to make the tests, so I
will not have a real conclusion until I test the differential encoder on
the Mazak.


The index pulse will be too short for the slow sampling of halscope to sample 
reliably. The way to check index is to "setp" the encoder index enable pin

(or if its already connected, "sets" the signal that its connected to)
Once set, index enable should get cleared at the index position
This is done in the encoder hardware so not dependent on halscopes
sample rate


Peter Wallace
Mesa Electronics


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

Re: [Emc-users] Question about index pulse on high resolution encoder

[Leonardo Marsaglia]

I just set index-invert to TRUE and FILTER to false on the hostmot encoder
parameters and until now it's not missing pulses anymore. I'll keep testing
it to see how it goes.

El sáb., 21 mar. 2020 a las 1:21, Leonardo Marsaglia ()
escribió:

> Hello John,
>
> I connected it using the differential pairs. Although the encoder says is
> TTL differential and doesn't mention anything about RS-422  but it seems to
> be working fine.
>
> From what I've reading I'm not sure if halscope can sense that index pulse
> because of the same reason I suspect hal is missing it. I'm triggering the
> index with a custom made component to apply offsets to the X axis. I even
> forced the component to set index to 1 on each iteration without even
> sensing if it's on 0 and the same thing happens, if I turn it too fast the
> index pulse is skipped.
>
> Unfortunately this is the only encoder I have here to make the tests, so I
> will not have a real conclusion until I test the differential encoder on
> the Mazak.
>
> El sáb., 21 mar. 2020 a las 1:15, John Dammeyer ()
> escribió:
>
>>
>>
>> > -Original Message-
>> > From: Leonardo Marsaglia [mailto:ldmarsag...@gmail.com]
>> > Sent: March-20-20 8:49 PM
>> > To: Enhanced Machine Controller (EMC)
>> > Subject: [Emc-users] Question about index pulse on high resolution
>> encoder
>> >
>> > Hello guys,
>> >
>> > I'm testing a phisical encoder to simulate how the spindle will work
>> with
>> > the external offsets. So far so good but I need to clarify something
>> that I
>> > suspect. Here it comes:
>> >
>> > The encoder I'm testing is an ERN471 from Heidenhain. A beast of
>> encoder.
>> > It says 5.000 line counts on the datasheet but also says it outputs
>> 125.000
>> > signal periods per revolution, so when I read it in LinuxCNC with a
>> scale
>> > of 1 I find that I'm having 500.000 pulses per turn. A lot of
>> resolution.
>> > I'm scaling it to 1024 since this is what I have on the Mazak.
>> >
>> > My concern is (and I think this is to be expected) that I have missing
>> > index pulses if I rotate the encoder too fast with my fingers. I tried
>> to
>> > use a shorter servo-period and that seemed to improve things a little
>> but
>> > not solving the problem always.
>> >
>> > Is this what's happening? Should I not expect this behaviour with the
>> 1024
>> > PPR encoder and the spindle turning at about 200 RPM ?
>> >
>> > I would like to hear your thoughts just to be relaxed, since a missing
>> > index pulse on this kind of processes is likely to break the tool and
>> > spoil the part.
>> >
>>
>> From what I've read so far the LinuxCNC system only uses the index pulse
>> when it starts a sequence that requires synchronized motion.   The G
>> command for threading sets a flag that tells the system the next time it
>> sees and index pulse to clear the counter and then it cancels the flag.
>> The G command doesn't restart it.  At this point the A/B are tracked for
>> direction based on the other operations generated by the G command.
>>
>> The MESA cards, AFAIK, use a rising edge to trigger this index.  After
>> that they don't care how long the level is or when it drops.  Most
>> interrupts into processors work the same way.  The edges are usually
>> qualified by the processor or system clock so it might check it a few times
>> that it stayed high for 100 nS before it registers as a rising edge.
>>
>> So if you think you are missing pulses first I believe the HAL Scope
>> might be able to see it.  If it doesn't then you need a real scope.
>> Depending on the hardware it may well need full differential signals in
>> order to deliver the pulse into the hardware.
>>
>> John
>>
>>
>>
>> > Thanks as always!
>> >
>> > ___
>> > 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] Question about index pulse on high resolution encoder

[Leonardo Marsaglia]

Hello John,

I connected it using the differential pairs. Although the encoder says is
TTL differential and doesn't mention anything about RS-422  but it seems to
be working fine.

From what I've reading I'm not sure if halscope can sense that index pulse
because of the same reason I suspect hal is missing it. I'm triggering the
index with a custom made component to apply offsets to the X axis. I even
forced the component to set index to 1 on each iteration without even
sensing if it's on 0 and the same thing happens, if I turn it too fast the
index pulse is skipped.

Unfortunately this is the only encoder I have here to make the tests, so I
will not have a real conclusion until I test the differential encoder on
the Mazak.

El sáb., 21 mar. 2020 a las 1:15, John Dammeyer ()
escribió:

>
>
> > -Original Message-
> > From: Leonardo Marsaglia [mailto:ldmarsag...@gmail.com]
> > Sent: March-20-20 8:49 PM
> > To: Enhanced Machine Controller (EMC)
> > Subject: [Emc-users] Question about index pulse on high resolution
> encoder
> >
> > Hello guys,
> >
> > I'm testing a phisical encoder to simulate how the spindle will work with
> > the external offsets. So far so good but I need to clarify something
> that I
> > suspect. Here it comes:
> >
> > The encoder I'm testing is an ERN471 from Heidenhain. A beast of encoder.
> > It says 5.000 line counts on the datasheet but also says it outputs
> 125.000
> > signal periods per revolution, so when I read it in LinuxCNC with a scale
> > of 1 I find that I'm having 500.000 pulses per turn. A lot of resolution.
> > I'm scaling it to 1024 since this is what I have on the Mazak.
> >
> > My concern is (and I think this is to be expected) that I have missing
> > index pulses if I rotate the encoder too fast with my fingers. I tried to
> > use a shorter servo-period and that seemed to improve things a little but
> > not solving the problem always.
> >
> > Is this what's happening? Should I not expect this behaviour with the
> 1024
> > PPR encoder and the spindle turning at about 200 RPM ?
> >
> > I would like to hear your thoughts just to be relaxed, since a missing
> > index pulse on this kind of processes is likely to break the tool and
> > spoil the part.
> >
>
> From what I've read so far the LinuxCNC system only uses the index pulse
> when it starts a sequence that requires synchronized motion.   The G
> command for threading sets a flag that tells the system the next time it
> sees and index pulse to clear the counter and then it cancels the flag.
> The G command doesn't restart it.  At this point the A/B are tracked for
> direction based on the other operations generated by the G command.
>
> The MESA cards, AFAIK, use a rising edge to trigger this index.  After
> that they don't care how long the level is or when it drops.  Most
> interrupts into processors work the same way.  The edges are usually
> qualified by the processor or system clock so it might check it a few times
> that it stayed high for 100 nS before it registers as a rising edge.
>
> So if you think you are missing pulses first I believe the HAL Scope might
> be able to see it.  If it doesn't then you need a real scope.  Depending on
> the hardware it may well need full differential signals in order to deliver
> the pulse into the hardware.
>
> John
>
>
>
> > Thanks as always!
> >
> > ___
> > 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] Question about index pulse on high resolution encoder

[Leonardo Marsaglia]

Hello Peter,

I'm only scaling the position in hal to test my spindle config. The encoder
as you say if fixed at 50.

El sáb., 21 mar. 2020 a las 1:12, Peter C. Wallace ()
escribió:

> On Sat, 21 Mar 2020, Leonardo Marsaglia wrote:
>
> > Date: Sat, 21 Mar 2020 00:48:46 -0300
> > From: Leonardo Marsaglia 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: "Enhanced Machine Controller (EMC)"  >
> > Subject: [Emc-users] Question about index pulse on high resolution
> encoder
> >
> > Hello guys,
> >
> > I'm testing a phisical encoder to simulate how the spindle will work with
> > the external offsets. So far so good but I need to clarify something
> that I
> > suspect. Here it comes:
> >
> > The encoder I'm testing is an ERN471 from Heidenhain. A beast of encoder.
> > It says 5.000 line counts on the datasheet but also says it outputs
> 125.000
> > signal periods per revolution, so when I read it in LinuxCNC with a scale
> > of 1 I find that I'm having 500.000 pulses per turn. A lot of resolution.
> > I'm scaling it to 1024 since this is what I have on the Mazak.
> >
> > My concern is (and I think this is to be expected) that I have missing
> > index pulses if I rotate the encoder too fast with my fingers. I tried to
> > use a shorter servo-period and that seemed to improve things a little but
> > not solving the problem always.
> >
> > Is this what's happening? Should I not expect this behaviour with the
> 1024
> > PPR encoder and the spindle turning at about 200 RPM ?
> >
> > I would like to hear your thoughts just to be relaxed, since a missing
> > index pulse on this kind of processes is likely to break the tool and
> > spoil the part.
> >
> > Thanks as always!
>
>
> Thats looks to be a 5000 line (2 CPR) encoder with a built in 25X
> interpolator to 50 (2x25) counts per turn, I would not expect
> it to work at high speeds, Depending on interface hardware and setup
>
> How can you use a scale of 1024? Isnt the encoder a fixed 50 CPR
> device?
>
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
>
> ___
> 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] Question about index pulse on high resolution encoder

[John Dammeyer]

> -Original Message-
> From: Leonardo Marsaglia [mailto:ldmarsag...@gmail.com]
> Sent: March-20-20 8:49 PM
> To: Enhanced Machine Controller (EMC)
> Subject: [Emc-users] Question about index pulse on high resolution encoder
> 
> Hello guys,
> 
> I'm testing a phisical encoder to simulate how the spindle will work with
> the external offsets. So far so good but I need to clarify something that I
> suspect. Here it comes:
> 
> The encoder I'm testing is an ERN471 from Heidenhain. A beast of encoder.
> It says 5.000 line counts on the datasheet but also says it outputs 125.000
> signal periods per revolution, so when I read it in LinuxCNC with a scale
> of 1 I find that I'm having 500.000 pulses per turn. A lot of resolution.
> I'm scaling it to 1024 since this is what I have on the Mazak.
> 
> My concern is (and I think this is to be expected) that I have missing
> index pulses if I rotate the encoder too fast with my fingers. I tried to
> use a shorter servo-period and that seemed to improve things a little but
> not solving the problem always.
> 
> Is this what's happening? Should I not expect this behaviour with the 1024
> PPR encoder and the spindle turning at about 200 RPM ?
> 
> I would like to hear your thoughts just to be relaxed, since a missing
> index pulse on this kind of processes is likely to break the tool and
> spoil the part.
> 

>From what I've read so far the LinuxCNC system only uses the index pulse when 
>it starts a sequence that requires synchronized motion.   The G command for 
>threading sets a flag that tells the system the next time it sees and index 
>pulse to clear the counter and then it cancels the flag.  The G command 
>doesn't restart it.  At this point the A/B are tracked for direction based on 
>the other operations generated by the G command.

The MESA cards, AFAIK, use a rising edge to trigger this index.  After that 
they don't care how long the level is or when it drops.  Most interrupts into 
processors work the same way.  The edges are usually qualified by the processor 
or system clock so it might check it a few times that it stayed high for 100 nS 
before it registers as a rising edge.

So if you think you are missing pulses first I believe the HAL Scope might be 
able to see it.  If it doesn't then you need a real scope.  Depending on the 
hardware it may well need full differential signals in order to deliver the 
pulse into the hardware.

John



> Thanks as always!
> 
> ___
> 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] Question about index pulse on high resolution encoder

[Peter C. Wallace]

On Sat, 21 Mar 2020, Leonardo Marsaglia wrote:


Date: Sat, 21 Mar 2020 00:48:46 -0300
From: Leonardo Marsaglia 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: [Emc-users] Question about index pulse on high resolution encoder

Hello guys,

I'm testing a phisical encoder to simulate how the spindle will work with
the external offsets. So far so good but I need to clarify something that I
suspect. Here it comes:

The encoder I'm testing is an ERN471 from Heidenhain. A beast of encoder.
It says 5.000 line counts on the datasheet but also says it outputs 125.000
signal periods per revolution, so when I read it in LinuxCNC with a scale
of 1 I find that I'm having 500.000 pulses per turn. A lot of resolution.
I'm scaling it to 1024 since this is what I have on the Mazak.

My concern is (and I think this is to be expected) that I have missing
index pulses if I rotate the encoder too fast with my fingers. I tried to
use a shorter servo-period and that seemed to improve things a little but
not solving the problem always.

Is this what's happening? Should I not expect this behaviour with the 1024
PPR encoder and the spindle turning at about 200 RPM ?

I would like to hear your thoughts just to be relaxed, since a missing
index pulse on this kind of processes is likely to break the tool and
spoil the part.

Thanks as always!



Thats looks to be a 5000 line (2 CPR) encoder with a built in 25X 
interpolator to 50 (2x25) counts per turn, I would not expect

it to work at high speeds, Depending on interface hardware and setup

How can you use a scale of 1024? Isnt the encoder a fixed 50 CPR device?



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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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