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
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 Fi
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 p
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
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 fa
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
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)
>
>
>
> 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 determ
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
>
> 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, refle
>
> 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
> sui
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 th
> 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.m
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/
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 somethi
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
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 hi
>
> 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
>
> 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
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 ma
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 th
> 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
>
> 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 neede
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 o
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 spi
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 bette
> 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 enc
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 in
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
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 i
> 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 co
> >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"
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
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 fr
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
gt; -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
>&g
rdo 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 t
gt; > 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 gu
> -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'
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 encod
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 data
41 matches
Mail list logo