date:20200713

On Sunday 12 July 2020 22:44:05 Leonardo Marsaglia wrote:

> > Currently - there is no way to adjust it.   I do run the
> > acceleration and velocity as high as I can.  (on the emco it is in
> > above 50in/s^2)  I do have some math that calculates the following
> > error of the shape (actual shape vs axis position) and decide how
> > fast to run the spindle to get the tolerance I want.  There should
> > be some sort of trajectory planning - but that might be above my pay
> > grade
> >
> > (mostly academic for me - just wanted to see how well it works...)
>
> Thanks for the feedback Sam. I'll have to dig in a little more to
> improve what I've done surely, but I guess only for the jobs I need to
> do from time to time the live tool is justified. I usually do 6 mm
> lift cams but sometimes I need to reach 9, 10 and even 11 mm of lift
> wich are almost dynamically impossible to turn with conventional
> tooling.
>
I find trying to imagine the method intriguing, as I already have an 
offset module in use on the Sheldon, doing compensation for bed wear vs 
z position, something that can be done very cheaply in the 200 hz jog 
thread, but thats obviously too slow for this. No reason I couldn't map 
an offset vs spindle, usable at backgear speeds or maybe even in 1st 
gear direct. Something I could feed into the offset thru a sum2 from a 
lookup table based on a MOD of encoder by scale function for the table 
index. Something like a 240 tap deep lincurve, but can the pi4 handle 
that in real time. Doubtfull as I can see other timeing problems Despite 
the newer power supply giving me 40+ ipm at the x axis, I doubt the pi4 
has enough processing power to pull that off. The ultimate limit would 
be reached by adding a base-thread, which I don't have now, because that 
sort of thing would need response at per encoder edge. That speed limit 
then would be the 1 kilohertz servo-thread write to the stepgen.

One might experiment to find what those limits are with a siggen module 
if it could be synched by a phase locked loop running at 6x spindle 
index. Since its default is 1 hertz, it might make more sense for 
testing to go to backgear and turn the spindle at 1/6th turn per second, 
increaseing the gain of the triangle until a following error occurs. And 
finding the minimum time for the phase-locked loop to stabilize the 
spindle speed before advanceing the tool into cutting position, I can 
imagine cutting a bolt head compatible with a 12 point box end wrench, 
but not the pretty flats Sam got.  That would require running a sine 
signal thru an ABS function in real time adjusting the gain for flatness 
of facets.  Since thats a floating point function, servo-thread at 1 
kilohertz would be its speed limit.  But is that speed limit usable?

IDK. :(

Middle of the night thought experiments, darned things cost me sleep but 
never get done... Ought to be a pill for that.
>
> El dom., 12 jul. 2020 a las 15:52, Sam Sokolik ()
>
> escribió:
> > Currently - there is no way to adjust it.   I do run the
> > acceleration and velocity as high as I can.  (on the emco it is in
> > above 50in/s^2)  I do have some math that calculates the following
> > error of the shape (actual shape vs axis position) and decide how
> > fast to run the spindle to get the tolerance I want.  There should
> > be some sort of trajectory planning - but that might be above my pay
> > grade
> >
> > (mostly academic for me - just wanted to see how well it works...)
> >
> > sam
> >
> > On Sun, Jul 12, 2020 at 1:32 PM Leonardo Marsaglia
> > 
> >
> > wrote:
> > > Excellent job Sam.
> > >
> > > One question to the list in general. How are you managing the
> > > atenuation and phase displacement you get when you increase
> > > spindle rpm using eoffsets? Other than increasing the speed and
> > > accel of the axis I mean.
> > >
> > > I could cut cams with some success but I really can't follow the
> > > shape
> >
> > and
> >
> > > the phase with the same success and that's why I'm building a live
> >
> > tooling
> >
> > > jig to cut at really low spindle RPM to avoid this effect as much
> > > as possible. My particular problem is worse because all the
> > > machining of the cams has to be aligned with a keyway in the
> > > camshafts.
> > >
> > > El dom., 12 jul. 2020 a las 5:12, John Dammeyer
> > > ( > >
> > > escribió:
> > > > So question.
> > > > 1. would you post the G-Code that made that?
> > > > 2. I take it virtually 0 backlash on the cross slide?
> > > > 3. I was also impressed with how well the parting off went. 
> > > > Mine tends
> > >
> > > to
> > >
> > > > dig in.
> > > > John
> > > >
> > > > > -Original Message-
> > > > > From: Sam Sokolik [mailto:samco...@gmail.com]
> > > > > Sent: July-11-20 7:39 PM
> > > > > To: Enhanced Machine Controller (EMC)
> > > > > Subject: [Emc-users] Because the hardware store was 4 miles
> > > > > away...
> > > > >
> > > > > Right?  Am I right?
> > > > >
> > > > > https://youtu.be/wv7mMS5xKks
> > > > >
> > > >

Re: [Emc-users] polar co-ords Q

2020-07-13 Thread andy pugh

On Mon, 13 Jul 2020 at 01:17, Chris Albertson  wrote:

> "Everyone" uses the Right-Hand Rule.  Using your right-hand curl your
> fingers and point your thumb up.

Off topic..

Some years ago a student I vaguely knew through the fire engine club
at the college was shown a picture of two people clearly at a party
(the glasses of wine were part of the give-away) and clearly
discussing the right-hand-rule.
The point he was making that it was a perfectly normal thing to
discuss in social situations. It was a random photo that he had
somehow found on the Internet.

The lecturer was a bit surprised when one of his students said "I know
that chap" because it was a photo of a (blonde, 6'1" statuesque in a
cocktail dress) friend and I at a bike club party. And possibly even
more surprised to find that one of the people in the photo was an old
student of his.

After some Googling it seems that the picture has gone from the Internet.

-- 
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] Because the hardware store was 4 miles away...

2020-07-13 Thread Peter C. Wallace

On Sun, 12 Jul 2020, Sam Sokolik wrote:

Date: Sun, 12 Jul 2020 21:42:23 -0500
From: Sam Sokolik 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Because the hardware store was 4 miles away...

On Sun, Jul 12, 2020 at 1:50 PM Sam Sokolik  wrote:

Currently - there is no way to adjust it.   I do run the acceleration and
velocity as high as I can.  (on the emco it is in above 50in/s^2)  I do
have some math that calculates the following error of the shape (actual
shape vs axis position) and decide how fast to run the spindle to get the
tolerance I want.  There should be some sort of trajectory planning - but
that might be above my pay grade

(mostly academic for me - just wanted to see how well it works...)

sam

I wonder if you could compensate for the twisting of the corner
positions (due to acceleration bound) by pre-distorting the X Axis
motion based on acceleration limits and spindle speed. A simple
spindle speed scaled variable lead angle could align the corners
(but would rotate the flats where no compensation may be needed)

Peter Wallace
Mesa Electronics

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

Re: [Emc-users] Because the hardware store was 4 miles away...

2020-07-13 Thread Ralph Stirling

Perhaps Peter could write a hostmot2 axis offset module that would run in the 
fpga.  No base thread needed.

-- Ralph

On Jul 13, 2020 12:24 AM, Gene Heskett  wrote:
CAUTION: This email originated from outside the Walla Walla University email 
system.


On Sunday 12 July 2020 22:44:05 Leonardo Marsaglia wrote:

> > Currently - there is no way to adjust it.   I do run the
> > acceleration and velocity as high as I can.  (on the emco it is in
> > above 50in/s^2)  I do have some math that calculates the following
> > error of the shape (actual shape vs axis position) and decide how
> > fast to run the spindle to get the tolerance I want.  There should
> > be some sort of trajectory planning - but that might be above my pay
> > grade
> >
> > (mostly academic for me - just wanted to see how well it works...)
>
> Thanks for the feedback Sam. I'll have to dig in a little more to
> improve what I've done surely, but I guess only for the jobs I need to
> do from time to time the live tool is justified. I usually do 6 mm
> lift cams but sometimes I need to reach 9, 10 and even 11 mm of lift
> wich are almost dynamically impossible to turn with conventional
> tooling.
>
I find trying to imagine the method intriguing, as I already have an
offset module in use on the Sheldon, doing compensation for bed wear vs
z position, something that can be done very cheaply in the 200 hz jog
thread, but thats obviously too slow for this. No reason I couldn't map
an offset vs spindle, usable at backgear speeds or maybe even in 1st
gear direct. Something I could feed into the offset thru a sum2 from a
lookup table based on a MOD of encoder by scale function for the table
index. Something like a 240 tap deep lincurve, but can the pi4 handle
that in real time. Doubtfull as I can see other timeing problems Despite
the newer power supply giving me 40+ ipm at the x axis, I doubt the pi4
has enough processing power to pull that off. The ultimate limit would
be reached by adding a base-thread, which I don't have now, because that
sort of thing would need response at per encoder edge. That speed limit
then would be the 1 kilohertz servo-thread write to the stepgen.

One might experiment to find what those limits are with a siggen module
if it could be synched by a phase locked loop running at 6x spindle
index. Since its default is 1 hertz, it might make more sense for
testing to go to backgear and turn the spindle at 1/6th turn per second,
increaseing the gain of the triangle until a following error occurs. And
finding the minimum time for the phase-locked loop to stabilize the
spindle speed before advanceing the tool into cutting position, I can
imagine cutting a bolt head compatible with a 12 point box end wrench,
but not the pretty flats Sam got.  That would require running a sine
signal thru an ABS function in real time adjusting the gain for flatness
of facets.  Since thats a floating point function, servo-thread at 1
kilohertz would be its speed limit.  But is that speed limit usable?

IDK. :(

Middle of the night thought experiments, darned things cost me sleep but
never get done... Ought to be a pill for that.
>
> El dom., 12 jul. 2020 a las 15:52, Sam Sokolik ()
>
> escribió:
> > Currently - there is no way to adjust it.   I do run the
> > acceleration and velocity as high as I can.  (on the emco it is in
> > above 50in/s^2)  I do have some math that calculates the following
> > error of the shape (actual shape vs axis position) and decide how
> > fast to run the spindle to get the tolerance I want.  There should
> > be some sort of trajectory planning - but that might be above my pay
> > grade
> >
> > (mostly academic for me - just wanted to see how well it works...)
> >
> > sam
> >
> > On Sun, Jul 12, 2020 at 1:32 PM Leonardo Marsaglia
> > 
> >
> > wrote:
> > > Excellent job Sam.
> > >
> > > One question to the list in general. How are you managing the
> > > atenuation and phase displacement you get when you increase
> > > spindle rpm using eoffsets? Other than increasing the speed and
> > > accel of the axis I mean.
> > >
> > > I could cut cams with some success but I really can't follow the
> > > shape
> >
> > and
> >
> > > the phase with the same success and that's why I'm building a live
> >
> > tooling
> >
> > > jig to cut at really low spindle RPM to avoid this effect as much
> > > as possible. My particular problem is worse because all the
> > > machining of the cams has to be aligned with a keyway in the
> > > camshafts.
> > >
> > > El dom., 12 jul. 2020 a las 5:12, John Dammeyer
> > > ( > >
> > > escribió:
> > > > So question.
> > > > 1. would you post the G-Code that made that?
> > > > 2. I take it virtually 0 backlash on the cross slide?
> > > > 3. I was also impressed with how well the parting off went.
> > > > Mine tends
> > >
> > > to
> > >
> > > > dig in.
> > > > John
> > > >
> > > > > -Original Message-
> > > > > From: Sam Sokolik [mailto:samco...@gmail.com]
> > > > > Sent: July-11-20 7:39 PM
> > > > > To:

Re: [Emc-users] Because the hardware store was 4 miles away...

2020-07-13 Thread Sam Sokolik

There is no base thread currently.

On Mon, Jul 13, 2020, 10:51 AM Ralph Stirling 
wrote:

> Perhaps Peter could write a hostmot2 axis offset module that would run in
> the fpga.  No base thread needed.
>
> -- Ralph
>
> On Jul 13, 2020 12:24 AM, Gene Heskett  wrote:
> CAUTION: This email originated from outside the Walla Walla University
> email system.
>
>
> On Sunday 12 July 2020 22:44:05 Leonardo Marsaglia wrote:
>
> > > Currently - there is no way to adjust it.   I do run the
> > > acceleration and velocity as high as I can.  (on the emco it is in
> > > above 50in/s^2)  I do have some math that calculates the following
> > > error of the shape (actual shape vs axis position) and decide how
> > > fast to run the spindle to get the tolerance I want.  There should
> > > be some sort of trajectory planning - but that might be above my pay
> > > grade
> > >
> > > (mostly academic for me - just wanted to see how well it works...)
> >
> > Thanks for the feedback Sam. I'll have to dig in a little more to
> > improve what I've done surely, but I guess only for the jobs I need to
> > do from time to time the live tool is justified. I usually do 6 mm
> > lift cams but sometimes I need to reach 9, 10 and even 11 mm of lift
> > wich are almost dynamically impossible to turn with conventional
> > tooling.
> >
> I find trying to imagine the method intriguing, as I already have an
> offset module in use on the Sheldon, doing compensation for bed wear vs
> z position, something that can be done very cheaply in the 200 hz jog
> thread, but thats obviously too slow for this. No reason I couldn't map
> an offset vs spindle, usable at backgear speeds or maybe even in 1st
> gear direct. Something I could feed into the offset thru a sum2 from a
> lookup table based on a MOD of encoder by scale function for the table
> index. Something like a 240 tap deep lincurve, but can the pi4 handle
> that in real time. Doubtfull as I can see other timeing problems Despite
> the newer power supply giving me 40+ ipm at the x axis, I doubt the pi4
> has enough processing power to pull that off. The ultimate limit would
> be reached by adding a base-thread, which I don't have now, because that
> sort of thing would need response at per encoder edge. That speed limit
> then would be the 1 kilohertz servo-thread write to the stepgen.
>
> One might experiment to find what those limits are with a siggen module
> if it could be synched by a phase locked loop running at 6x spindle
> index. Since its default is 1 hertz, it might make more sense for
> testing to go to backgear and turn the spindle at 1/6th turn per second,
> increaseing the gain of the triangle until a following error occurs. And
> finding the minimum time for the phase-locked loop to stabilize the
> spindle speed before advanceing the tool into cutting position, I can
> imagine cutting a bolt head compatible with a 12 point box end wrench,
> but not the pretty flats Sam got.  That would require running a sine
> signal thru an ABS function in real time adjusting the gain for flatness
> of facets.  Since thats a floating point function, servo-thread at 1
> kilohertz would be its speed limit.  But is that speed limit usable?
>
> IDK. :(
>
> Middle of the night thought experiments, darned things cost me sleep but
> never get done... Ought to be a pill for that.
> >
> > El dom., 12 jul. 2020 a las 15:52, Sam Sokolik ()
> >
> > escribió:
> > > Currently - there is no way to adjust it.   I do run the
> > > acceleration and velocity as high as I can.  (on the emco it is in
> > > above 50in/s^2)  I do have some math that calculates the following
> > > error of the shape (actual shape vs axis position) and decide how
> > > fast to run the spindle to get the tolerance I want.  There should
> > > be some sort of trajectory planning - but that might be above my pay
> > > grade
> > >
> > > (mostly academic for me - just wanted to see how well it works...)
> > >
> > > sam
> > >
> > > On Sun, Jul 12, 2020 at 1:32 PM Leonardo Marsaglia
> > > 
> > >
> > > wrote:
> > > > Excellent job Sam.
> > > >
> > > > One question to the list in general. How are you managing the
> > > > atenuation and phase displacement you get when you increase
> > > > spindle rpm using eoffsets? Other than increasing the speed and
> > > > accel of the axis I mean.
> > > >
> > > > I could cut cams with some success but I really can't follow the
> > > > shape
> > >
> > > and
> > >
> > > > the phase with the same success and that's why I'm building a live
> > >
> > > tooling
> > >
> > > > jig to cut at really low spindle RPM to avoid this effect as much
> > > > as possible. My particular problem is worse because all the
> > > > machining of the cams has to be aligned with a keyway in the
> > > > camshafts.
> > > >
> > > > El dom., 12 jul. 2020 a las 5:12, John Dammeyer
> > > > ( > > >
> > > > escribió:
> > > > > So question.
> > > > > 1. would you post the G-Code that made that?
> > > > > 2. I take it virtually 0 backlash on the

Re: [Emc-users] Because the hardware store was 4 miles away...

2020-07-13 Thread Peter C. Wallace

On Mon, 13 Jul 2020, Ralph Stirling wrote:

Date: Mon, 13 Jul 2020 13:15:27 +
From: Ralph Stirling 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Because the hardware store was 4 miles away...

Perhaps Peter could write a hostmot2 axis offset module that would run in the 
fpga.  No base thread needed.

-- Ralph

Oh No, thats definately the wrong design path, the philosophy here is to 
push all the hard work into someone elses domain... :-)

On Jul 13, 2020 12:24 AM, Gene Heskett  wrote:
CAUTION: This email originated from outside the Walla Walla University email 
system.

On Sunday 12 July 2020 22:44:05 Leonardo Marsaglia wrote:

Currently - there is no way to adjust it.   I do run the
acceleration and velocity as high as I can.  (on the emco it is in
above 50in/s^2)  I do have some math that calculates the following
error of the shape (actual shape vs axis position) and decide how
fast to run the spindle to get the tolerance I want.  There should
be some sort of trajectory planning - but that might be above my pay
grade

(mostly academic for me - just wanted to see how well it works...)

Thanks for the feedback Sam. I'll have to dig in a little more to
improve what I've done surely, but I guess only for the jobs I need to
do from time to time the live tool is justified. I usually do 6 mm
lift cams but sometimes I need to reach 9, 10 and even 11 mm of lift
wich are almost dynamically impossible to turn with conventional
tooling.

I find trying to imagine the method intriguing, as I already have an
offset module in use on the Sheldon, doing compensation for bed wear vs
z position, something that can be done very cheaply in the 200 hz jog
thread, but thats obviously too slow for this. No reason I couldn't map
an offset vs spindle, usable at backgear speeds or maybe even in 1st
gear direct. Something I could feed into the offset thru a sum2 from a
lookup table based on a MOD of encoder by scale function for the table
index. Something like a 240 tap deep lincurve, but can the pi4 handle
that in real time. Doubtfull as I can see other timeing problems Despite
the newer power supply giving me 40+ ipm at the x axis, I doubt the pi4
has enough processing power to pull that off. The ultimate limit would
be reached by adding a base-thread, which I don't have now, because that
sort of thing would need response at per encoder edge. That speed limit
then would be the 1 kilohertz servo-thread write to the stepgen.

One might experiment to find what those limits are with a siggen module
if it could be synched by a phase locked loop running at 6x spindle
index. Since its default is 1 hertz, it might make more sense for
testing to go to backgear and turn the spindle at 1/6th turn per second,
increaseing the gain of the triangle until a following error occurs. And
finding the minimum time for the phase-locked loop to stabilize the
spindle speed before advanceing the tool into cutting position, I can
imagine cutting a bolt head compatible with a 12 point box end wrench,
but not the pretty flats Sam got.  That would require running a sine
signal thru an ABS function in real time adjusting the gain for flatness
of facets.  Since thats a floating point function, servo-thread at 1
kilohertz would be its speed limit.  But is that speed limit usable?

IDK. :(

Middle of the night thought experiments, darned things cost me sleep but
never get done... Ought to be a pill for that.

El dom., 12 jul. 2020 a las 15:52, Sam Sokolik ()

escribió:

Currently - there is no way to adjust it.   I do run the
acceleration and velocity as high as I can.  (on the emco it is in
above 50in/s^2)  I do have some math that calculates the following
error of the shape (actual shape vs axis position) and decide how
fast to run the spindle to get the tolerance I want.  There should
be some sort of trajectory planning - but that might be above my pay
grade

(mostly academic for me - just wanted to see how well it works...)

sam

On Sun, Jul 12, 2020 at 1:32 PM Leonardo Marsaglia

wrote:

Excellent job Sam.

One question to the list in general. How are you managing the
atenuation and phase displacement you get when you increase
spindle rpm using eoffsets? Other than increasing the speed and
accel of the axis I mean.

I could cut cams with some success but I really can't follow the
shape

and

the phase with the same success and that's why I'm building a live

tooling

jig to cut at really low spindle RPM to avoid this effect as much
as possible. My particular problem is worse because all the
machining of the cams has to be aligned with a keyway in the
camshafts.

El dom., 12 jul. 2020 a las 5:12, John Dammeyer
(
So question.
1. would you post the G-Code that made that?
2. I take it virtually 0 backlash on the cross slide?
3. I was also impressed with how well the parting off went.
Mine tends

to

dig in.
John

-Original Message-
From: Sam Sokolik [mailto:sa

Re: [Emc-users] Because the hardware store was 4 miles away...

On Monday 13 July 2020 09:15:27 Ralph Stirling wrote:

> Perhaps Peter could write a hostmot2 axis offset module that would run
> in the fpga.  No base thread needed.

I think thats a jolly fine idea. But I'd not have a clue where to start.
>
> -- Ralph
>
> On Jul 13, 2020 12:24 AM, Gene Heskett  wrote:
> CAUTION: This email originated from outside the Walla Walla University
> email system.
>
> On Sunday 12 July 2020 22:44:05 Leonardo Marsaglia wrote:
> > > Currently - there is no way to adjust it.   I do run the
> > > acceleration and velocity as high as I can.  (on the emco it is in
> > > above 50in/s^2)  I do have some math that calculates the following
> > > error of the shape (actual shape vs axis position) and decide how
> > > fast to run the spindle to get the tolerance I want.  There should
> > > be some sort of trajectory planning - but that might be above my
> > > pay grade
> > >
> > > (mostly academic for me - just wanted to see how well it works...)
> >
> > Thanks for the feedback Sam. I'll have to dig in a little more to
> > improve what I've done surely, but I guess only for the jobs I need
> > to do from time to time the live tool is justified. I usually do 6
> > mm lift cams but sometimes I need to reach 9, 10 and even 11 mm of
> > lift wich are almost dynamically impossible to turn with
> > conventional tooling.
>
> I find trying to imagine the method intriguing, as I already have an
> offset module in use on the Sheldon, doing compensation for bed wear
> vs z position, something that can be done very cheaply in the 200 hz
> jog thread, but thats obviously too slow for this. No reason I
> couldn't map an offset vs spindle, usable at backgear speeds or maybe
> even in 1st gear direct. Something I could feed into the offset thru a
> sum2 from a lookup table based on a MOD of encoder by scale function
> for the table index. Something like a 240 tap deep lincurve, but can
> the pi4 handle that in real time. Doubtfull as I can see other timeing
> problems Despite the newer power supply giving me 40+ ipm at the x
> axis, I doubt the pi4 has enough processing power to pull that off.
> The ultimate limit would be reached by adding a base-thread, which I
> don't have now, because that sort of thing would need response at per
> encoder edge. That speed limit then would be the 1 kilohertz
> servo-thread write to the stepgen.
>
> One might experiment to find what those limits are with a siggen
> module if it could be synched by a phase locked loop running at 6x
> spindle index. Since its default is 1 hertz, it might make more sense
> for testing to go to backgear and turn the spindle at 1/6th turn per
> second, increaseing the gain of the triangle until a following error
> occurs. And finding the minimum time for the phase-locked loop to
> stabilize the spindle speed before advanceing the tool into cutting
> position, I can imagine cutting a bolt head compatible with a 12 point
> box end wrench, but not the pretty flats Sam got.  That would require
> running a sine signal thru an ABS function in real time adjusting the
> gain for flatness of facets.  Since thats a floating point function,
> servo-thread at 1 kilohertz would be its speed limit.  But is that
> speed limit usable?
>
> IDK. :(
>
> Middle of the night thought experiments, darned things cost me sleep
> but never get done... Ought to be a pill for that.
>
> > El dom., 12 jul. 2020 a las 15:52, Sam Sokolik
> > ()
> >
> > escribió:
> > > Currently - there is no way to adjust it.   I do run the
> > > acceleration and velocity as high as I can.  (on the emco it is in
> > > above 50in/s^2)  I do have some math that calculates the following
> > > error of the shape (actual shape vs axis position) and decide how
> > > fast to run the spindle to get the tolerance I want.  There should
> > > be some sort of trajectory planning - but that might be above my
> > > pay grade
> > >
> > > (mostly academic for me - just wanted to see how well it works...)
> > >
> > > sam
> > >
> > > On Sun, Jul 12, 2020 at 1:32 PM Leonardo Marsaglia
> > > 
> > >
> > > wrote:
> > > > Excellent job Sam.
> > > >
> > > > One question to the list in general. How are you managing the
> > > > atenuation and phase displacement you get when you increase
> > > > spindle rpm using eoffsets? Other than increasing the speed and
> > > > accel of the axis I mean.
> > > >
> > > > I could cut cams with some success but I really can't follow the
> > > > shape
> > >
> > > and
> > >
> > > > the phase with the same success and that's why I'm building a
> > > > live
> > >
> > > tooling
> > >
> > > > jig to cut at really low spindle RPM to avoid this effect as
> > > > much as possible. My particular problem is worse because all the
> > > > machining of the cams has to be aligned with a keyway in the
> > > > camshafts.
> > > >
> > > > El dom., 12 jul. 2020 a las 5:12, John Dammeyer
> > > > ( > > >
> > > > escribió:
> > > > > So question.
> > > > > 1. would you post the G-Code that made that?
> > >

Re: [Emc-users] Because the hardware store was 4 miles away...

On Monday 13 July 2020 12:00:19 Peter C. Wallace wrote:

> On Mon, 13 Jul 2020, Ralph Stirling wrote:
> > Date: Mon, 13 Jul 2020 13:15:27 +
> > From: Ralph Stirling 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: "Enhanced Machine Controller (EMC)"
> >  Subject: Re: [Emc-users] Because
> > the hardware store was 4 miles away...
> >
> > Perhaps Peter could write a hostmot2 axis offset module that would
> > run in the fpga.  No base thread needed.
> >
> > -- Ralph
>
> Oh No, thats definately the wrong design path, the philosophy here is
> to push all the hard work into someone elses domain... :-)

ROTFLMAO, Peter see's right thru us. ;-) But seriously, the FPGA does 
seem like the ideal place for such a module. On chip com with the chosen 
stepgenerator removes that particular bandwidth limit. I could also see 
it doubleing the size of the FPGA needed so its not going to be free.  I 
think, not knowing the first thing about writing FPGA code.  :-(

[...]

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] Because the hardware store was 4 miles away...

2020-07-13 Thread andy pugh

On Mon, 13 Jul 2020 at 17:35, Gene Heskett  wrote:

> ROTFLMAO, Peter see's right thru us. ;-) But seriously, the FPGA does
> seem like the ideal place for such a module.

I disagree, it's a TC / servo thread thing

-- 
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] Because the hardware store was 4 miles away...

2020-07-13 Thread Peter C. Wallace


On Mon, 13 Jul 2020, andy pugh wrote:



On Mon, 13 Jul 2020 at 17:35, Gene Heskett  wrote:

ROTFLMAO, Peter see's right thru us. ;-) But seriously, the FPGA does
seem like the ideal place for such a module.




I disagree, it's a TC / servo thread thing

-- atp



Right, the actual limitation is the axis bandwidth so TP lookahead
is a possible way to improve the performance and compensate for the shift in
corner position as different spindle speeds. I suspect precalculated
X paths for the offset should also be able to optimise for this error
as long the the spindle speed for the pass was known.

Peter Wallace
Mesa Electronics



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

Re: [Emc-users] Because the hardware store was 4 miles away...

2020-07-13 Thread Ralph Stirling

In an ideal world, where Peter has infinite amounts
of time and interest, the entire hal ecosystem could
be put on the fpga.  Practically, though, it is tricky to
figure out exactly where the line should be drawn
between servo thread modules running in the main
processor and "base thread" components that run in
the fpga.  The fpga is parallel logic, so is well suited
to encoder counters, pwm generators, and step
generators.  Motion planning would be a nightmare.
Offset generation is in-between, as you need to
connect different (arbitrary) axes, with different
scaling factors.  Similar to electronic gearing, but
with offset as a real-time input.  The fpga component
would need to combine the "input" axis feedback,
the "output" axis value, and a source for the cam
profile (lookup table).  Size of the lookup table would
be an issue, as well as loading it.  Specifying the
profile as an equation would reduce the memory
requirements, but would be arbitrarily complex.
Perhaps a 3rd order polynomial would suffice.  I'm
sure Peter would love to implement that as well.

This would make a great EE senior project if I had
lots of great students falling all over themselves 
to grab my project ideas.

-- Ralph

From: Gene Heskett [ghesk...@shentel.net]
Sent: Monday, July 13, 2020 9:33 AM
To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Because the hardware store was 4 miles away...

On Monday 13 July 2020 12:00:19 Peter C. Wallace wrote:

> On Mon, 13 Jul 2020, Ralph Stirling wrote:
> > Date: Mon, 13 Jul 2020 13:15:27 +
> > From: Ralph Stirling 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: "Enhanced Machine Controller (EMC)"
> >  Subject: Re: [Emc-users] Because
> > the hardware store was 4 miles away...
> >
> > Perhaps Peter could write a hostmot2 axis offset module that would
> > run in the fpga.  No base thread needed.
> >
> > -- Ralph
>
> Oh No, thats definately the wrong design path, the philosophy here is
> to push all the hard work into someone elses domain... :-)

ROTFLMAO, Peter see's right thru us. ;-) But seriously, the FPGA does
seem like the ideal place for such a module. On chip com with the chosen
stepgenerator removes that particular bandwidth limit. I could also see
it doubleing the size of the FPGA needed so its not going to be free.  I
think, not knowing the first thing about writing FPGA code.  :-(

[...]

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

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

Re: [Emc-users] Because the hardware store was 4 miles away...

2020-07-13 Thread Stuart Stevenson

A couple ounces of glenlivet will help you go to sleep.

You are welcome 😁
Stuart

On Mon, Jul 13, 2020, 12:14 PM Ralph Stirling 
wrote:

> In an ideal world, where Peter has infinite amounts
> of time and interest, the entire hal ecosystem could
> be put on the fpga.  Practically, though, it is tricky to
> figure out exactly where the line should be drawn
> between servo thread modules running in the main
> processor and "base thread" components that run in
> the fpga.  The fpga is parallel logic, so is well suited
> to encoder counters, pwm generators, and step
> generators.  Motion planning would be a nightmare.
> Offset generation is in-between, as you need to
> connect different (arbitrary) axes, with different
> scaling factors.  Similar to electronic gearing, but
> with offset as a real-time input.  The fpga component
> would need to combine the "input" axis feedback,
> the "output" axis value, and a source for the cam
> profile (lookup table).  Size of the lookup table would
> be an issue, as well as loading it.  Specifying the
> profile as an equation would reduce the memory
> requirements, but would be arbitrarily complex.
> Perhaps a 3rd order polynomial would suffice.  I'm
> sure Peter would love to implement that as well.
>
> This would make a great EE senior project if I had
> lots of great students falling all over themselves
> to grab my project ideas.
>
> -- Ralph
> 
> From: Gene Heskett [ghesk...@shentel.net]
> Sent: Monday, July 13, 2020 9:33 AM
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] Because the hardware store was 4 miles away...
>
>
> On Monday 13 July 2020 12:00:19 Peter C. Wallace wrote:
>
> > On Mon, 13 Jul 2020, Ralph Stirling wrote:
> > > Date: Mon, 13 Jul 2020 13:15:27 +
> > > From: Ralph Stirling 
> > > Reply-To: "Enhanced Machine Controller (EMC)"
> > > 
> > > To: "Enhanced Machine Controller (EMC)"
> > >  Subject: Re: [Emc-users] Because
> > > the hardware store was 4 miles away...
> > >
> > > Perhaps Peter could write a hostmot2 axis offset module that would
> > > run in the fpga.  No base thread needed.
> > >
> > > -- Ralph
> >
> > Oh No, thats definately the wrong design path, the philosophy here is
> > to push all the hard work into someone elses domain... :-)
>
> ROTFLMAO, Peter see's right thru us. ;-) But seriously, the FPGA does
> seem like the ideal place for such a module. On chip com with the chosen
> stepgenerator removes that particular bandwidth limit. I could also see
> it doubleing the size of the FPGA needed so its not going to be free.  I
> think, not knowing the first thing about writing FPGA code.  :-(
>
> [...]
>
> 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
>
>
> ___
> 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] Because the hardware store was 4 miles away...

On Monday 13 July 2020 12:44:06 andy pugh wrote:

> On Mon, 13 Jul 2020 at 17:35, Gene Heskett  
wrote:
> > ROTFLMAO, Peter see's right thru us. ;-) But seriously, the FPGA
> > does seem like the ideal place for such a module.
>
> I disagree, it's a TC / servo thread thing
TC?

That servo-thread, at a kilohertz, seems a bit slow to me when it comes 
to shaping a cams accel/decel ramps, and a well controlled dwell time 
open so we are not talking about an easy to follow sine wave.  The 
spindle encoder's accuracy will need to be fine tuned as well since the 
spindle may have more than 1 edge passing in a servo cycle. At 25 rpm, 
and 240 edges from my bull gear, thats 6000 edges to track a minute.  
And 25 revs will need a backgear. Doable for a cam maybe, not for a hex 
headed bolt. I can't test it now, I knocked my index pin off the bull 
gear yesterday with the backgear. I think, theres a patch of glue only 
on the bullgear. Damned goop is not oil-proof. Is RTV?  No clue where it 
went, I'll have to make another I expect. But not today, ppty taxesare 
due.

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] Because the hardware store was 4 miles away...

Actually making a hex head on the lathe would best be done using a
microcontroller.   FPGAs can compute trig functions but I think the method
used is to first implement a "soft CPU" and then run code written in C that
uses math.h   That is a silly-expensive why to replace a $5 STM32 chip.

But really, the Lathe spindle does not run so fast and you can write this
code as a HAL component that runs in the Servo loop.I wanted out how I
would do this last night and was stumped on the math until I remembered the
law of cosines and "SAS" triangle problems from some class I took in the
10th grade.   Look those up on Wikipedia and then it is not hard to
computer the cross slide position as a function of spindle angle.

The hard part is getting such a good cross slide setup with no play of
backlash

On Mon, Jul 13, 2020 at 9:35 AM Gene Heskett  wrote:

> On Monday 13 July 2020 12:00:19 Peter C. Wallace wrote:
>
>
> ROTFLMAO, Peter see's right thru us. ;-) But seriously, the FPGA does
> seem like the ideal place for such a module. On chip com with the chosen
> stepgenerator removes that particular bandwidth limit. I could also see
> it doubleing the size of the FPGA needed so its not going to be free.  I
> think, not knowing the first thing about writing FPGA code.  :-(
>
> [..

-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] Because the hardware store was 4 miles away...

On Monday 13 July 2020 13:56:47 Chris Albertson wrote:

> Actually making a hex head on the lathe would best be done using a
> microcontroller.   FPGAs can compute trig functions but I think the
> method used is to first implement a "soft CPU" and then run code
> written in C that uses math.h   That is a silly-expensive why to
> replace a $5 STM32 chip.
>
> But really, the Lathe spindle does not run so fast and you can write
> this code as a HAL component that runs in the Servo loop.I wanted
> out how I would do this last night and was stumped on the math until I
> remembered the law of cosines and "SAS" triangle problems from some
> class I took in the 10th grade.   Look those up on Wikipedia and then
> it is not hard to computer the cross slide position as a function of
> spindle angle.
>
> The hard part is getting such a good cross slide setup with no play of
> backlash

Does 2 thou count? But I'd be more concerned with following error. A cam 
for valve motion is not a sine wave by quite a long row of apple trees.

> On Mon, Jul 13, 2020 at 9:35 AM Gene Heskett  
wrote:
> > On Monday 13 July 2020 12:00:19 Peter C. Wallace wrote:
> >
> >
> > ROTFLMAO, Peter see's right thru us. ;-) But seriously, the FPGA
> > does seem like the ideal place for such a module. On chip com with
> > the chosen stepgenerator removes that particular bandwidth limit. I
> > could also see it doubleing the size of the FPGA needed so its not
> > going to be free.  I think, not knowing the first thing about
> > writing FPGA code.  :-(
> >
> > [..


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] Because the hardware store was 4 miles away...

2020-07-13 Thread Sam Sokolik

My initial component was based on this formula..  (after racking my brain
on how to do the math - I googled)

https://math.stackexchange.com/questions/41940/is-there-an-equation-to-describe-regular-polygons/41954#41954


It has slightly more smarts to do slaved radius and such - oh - and I
hacked in a D shape too..   It would be cool if it could take in a dxf file
of a shape - or cheap and dirty have a gcode shape that the component could
'scan' in.

On Mon, Jul 13, 2020 at 1:49 PM Gene Heskett  wrote:

> On Monday 13 July 2020 13:56:47 Chris Albertson wrote:
>
> > Actually making a hex head on the lathe would best be done using a
> > microcontroller.   FPGAs can compute trig functions but I think the
> > method used is to first implement a "soft CPU" and then run code
> > written in C that uses math.h   That is a silly-expensive why to
> > replace a $5 STM32 chip.
> >
> > But really, the Lathe spindle does not run so fast and you can write
> > this code as a HAL component that runs in the Servo loop.I wanted
> > out how I would do this last night and was stumped on the math until I
> > remembered the law of cosines and "SAS" triangle problems from some
> > class I took in the 10th grade.   Look those up on Wikipedia and then
> > it is not hard to computer the cross slide position as a function of
> > spindle angle.
> >
> > The hard part is getting such a good cross slide setup with no play of
> > backlash
>
> Does 2 thou count? But I'd be more concerned with following error. A cam
> for valve motion is not a sine wave by quite a long row of apple trees.
>
> > On Mon, Jul 13, 2020 at 9:35 AM Gene Heskett 
> wrote:
> > > On Monday 13 July 2020 12:00:19 Peter C. Wallace wrote:
> > >
> > >
> > > ROTFLMAO, Peter see's right thru us. ;-) But seriously, the FPGA
> > > does seem like the ideal place for such a module. On chip com with
> > > the chosen stepgenerator removes that particular bandwidth limit. I
> > > could also see it doubleing the size of the FPGA needed so its not
> > > going to be free.  I think, not knowing the first thing about
> > > writing FPGA code.  :-(
> > >
> > > [..
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

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

Re: [Emc-users] Because the hardware store was 4 miles away...

2020-07-13 Thread Leonardo Marsaglia

>
> In an ideal world, where Peter has infinite amounts
> of time and interest, the entire hal ecosystem could
> be put on the fpga.  Practically, though, it is tricky to
> figure out exactly where the line should be drawn
> between servo thread modules running in the main
> processor and "base thread" components that run in
> the fpga.  The fpga is parallel logic, so is well suited
> to encoder counters, pwm generators, and step
> generators.  Motion planning would be a nightmare.
> Offset generation is in-between, as you need to
> connect different (arbitrary) axes, with different
> scaling factors.  Similar to electronic gearing, but
> with offset as a real-time input.  The fpga component
> would need to combine the "input" axis feedback,
> the "output" axis value, and a source for the cam
> profile (lookup table).  Size of the lookup table would
> be an issue, as well as loading it.  Specifying the
> profile as an equation would reduce the memory
> requirements, but would be arbitrarily complex.
> Perhaps a 3rd order polynomial would suffice.  I'm
> sure Peter would love to implement that as well.


Pretty nice subject to dig into. In the last few days I returned to the Cam
Design and Manufacturing handbook of Rober L. Norton to try and emulate the
lobes I'm doing mostly and get the equations right. I'm not gonna lie, it's
not an easy subject and I'm getting too much info too hard to digest but oh
boy how thrilling and exciting the subject is. And the good thing is, all
the math involved takes you right into the splines subject wich is another
exciting subject. Anyway, I'm taking it easy because I don't have enough
time to put all my attention into it but I'll try to repliate as soon as
possible the low lift roller followed cams that are the most common
nowadays. Until then, I will keep using look up tables since they work just
fine.


El lun., 13 jul. 2020 a las 18:18, Sam Sokolik ()
escribió:

> My initial component was based on this formula..  (after racking my brain
> on how to do the math - I googled)
>
>
> https://math.stackexchange.com/questions/41940/is-there-an-equation-to-describe-regular-polygons/41954#41954
>
>
> It has slightly more smarts to do slaved radius and such - oh - and I
> hacked in a D shape too..   It would be cool if it could take in a dxf file
> of a shape - or cheap and dirty have a gcode shape that the component could
> 'scan' in.
>
> On Mon, Jul 13, 2020 at 1:49 PM Gene Heskett  wrote:
>
> > On Monday 13 July 2020 13:56:47 Chris Albertson wrote:
> >
> > > Actually making a hex head on the lathe would best be done using a
> > > microcontroller.   FPGAs can compute trig functions but I think the
> > > method used is to first implement a "soft CPU" and then run code
> > > written in C that uses math.h   That is a silly-expensive why to
> > > replace a $5 STM32 chip.
> > >
> > > But really, the Lathe spindle does not run so fast and you can write
> > > this code as a HAL component that runs in the Servo loop.I wanted
> > > out how I would do this last night and was stumped on the math until I
> > > remembered the law of cosines and "SAS" triangle problems from some
> > > class I took in the 10th grade.   Look those up on Wikipedia and then
> > > it is not hard to computer the cross slide position as a function of
> > > spindle angle.
> > >
> > > The hard part is getting such a good cross slide setup with no play of
> > > backlash
> >
> > Does 2 thou count? But I'd be more concerned with following error. A cam
> > for valve motion is not a sine wave by quite a long row of apple trees.
> >
> > > On Mon, Jul 13, 2020 at 9:35 AM Gene Heskett 
> > wrote:
> > > > On Monday 13 July 2020 12:00:19 Peter C. Wallace wrote:
> > > >
> > > >
> > > > ROTFLMAO, Peter see's right thru us. ;-) But seriously, the FPGA
> > > > does seem like the ideal place for such a module. On chip com with
> > > > the chosen stepgenerator removes that particular bandwidth limit. I
> > > > could also see it doubleing the size of the FPGA needed so its not
> > > > going to be free.  I think, not knowing the first thing about
> > > > writing FPGA code.  :-(
> > > >
> > > > [..
> >
> >
> > Cheers, Gene Heskett
> > --
> > "There are four boxes to be used in defense of liberty:
> >  soap, ballot, jury, and ammo. Please use in that order."
> > -Ed Howdershelt (Author)
> > If we desire respect for the law, we must first make the law respectable.
> >  - Louis D. Brandeis
> > Genes Web page 
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

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

Re: [Emc-users] Because the hardware store was 4 miles away...

2020-07-13 Thread Leonardo Marsaglia

>
> Pretty nice subject to dig into. In the last few days I returned to the
> Cam Design and Manufacturing handbook of Rober L. Norton to try and emulate
> the lobes I'm doing mostly and get the equations right. I'm not gonna lie,
> it's not an easy subject and I'm getting too much info too hard to digest
> but oh boy how thrilling and exciting the subject is. And the good thing
> is, all the math involved takes you right into the splines subject wich is
> another exciting subject. Anyway, I'm taking it easy because I don't have
> enough time to put all my attention into it but I'll try to repliate as
> soon as possible the low lift roller followed cams that are the most common
> nowadays. Until then, I will keep using look up tables since they work just
> fine.
>

Did I mention the word subject lately? Lol. I just noticed...

El lun., 13 jul. 2020 a las 18:55, Leonardo Marsaglia (<
ldmarsag...@gmail.com>) escribió:

> In an ideal world, where Peter has infinite amounts
>> of time and interest, the entire hal ecosystem could
>> be put on the fpga.  Practically, though, it is tricky to
>> figure out exactly where the line should be drawn
>> between servo thread modules running in the main
>> processor and "base thread" components that run in
>> the fpga.  The fpga is parallel logic, so is well suited
>> to encoder counters, pwm generators, and step
>> generators.  Motion planning would be a nightmare.
>> Offset generation is in-between, as you need to
>> connect different (arbitrary) axes, with different
>> scaling factors.  Similar to electronic gearing, but
>> with offset as a real-time input.  The fpga component
>> would need to combine the "input" axis feedback,
>> the "output" axis value, and a source for the cam
>> profile (lookup table).  Size of the lookup table would
>> be an issue, as well as loading it.  Specifying the
>> profile as an equation would reduce the memory
>> requirements, but would be arbitrarily complex.
>> Perhaps a 3rd order polynomial would suffice.  I'm
>> sure Peter would love to implement that as well.
>
>
> Pretty nice subject to dig into. In the last few days I returned to the
> Cam Design and Manufacturing handbook of Rober L. Norton to try and emulate
> the lobes I'm doing mostly and get the equations right. I'm not gonna lie,
> it's not an easy subject and I'm getting too much info too hard to digest
> but oh boy how thrilling and exciting the subject is. And the good thing
> is, all the math involved takes you right into the splines subject wich is
> another exciting subject. Anyway, I'm taking it easy because I don't have
> enough time to put all my attention into it but I'll try to repliate as
> soon as possible the low lift roller followed cams that are the most common
> nowadays. Until then, I will keep using look up tables since they work just
> fine.
>
>
> El lun., 13 jul. 2020 a las 18:18, Sam Sokolik ()
> escribió:
>
>> My initial component was based on this formula..  (after racking my brain
>> on how to do the math - I googled)
>>
>>
>> https://math.stackexchange.com/questions/41940/is-there-an-equation-to-describe-regular-polygons/41954#41954
>>
>>
>> It has slightly more smarts to do slaved radius and such - oh - and I
>> hacked in a D shape too..   It would be cool if it could take in a dxf
>> file
>> of a shape - or cheap and dirty have a gcode shape that the component
>> could
>> 'scan' in.
>>
>> On Mon, Jul 13, 2020 at 1:49 PM Gene Heskett 
>> wrote:
>>
>> > On Monday 13 July 2020 13:56:47 Chris Albertson wrote:
>> >
>> > > Actually making a hex head on the lathe would best be done using a
>> > > microcontroller.   FPGAs can compute trig functions but I think the
>> > > method used is to first implement a "soft CPU" and then run code
>> > > written in C that uses math.h   That is a silly-expensive why to
>> > > replace a $5 STM32 chip.
>> > >
>> > > But really, the Lathe spindle does not run so fast and you can write
>> > > this code as a HAL component that runs in the Servo loop.I wanted
>> > > out how I would do this last night and was stumped on the math until I
>> > > remembered the law of cosines and "SAS" triangle problems from some
>> > > class I took in the 10th grade.   Look those up on Wikipedia and then
>> > > it is not hard to computer the cross slide position as a function of
>> > > spindle angle.
>> > >
>> > > The hard part is getting such a good cross slide setup with no play of
>> > > backlash
>> >
>> > Does 2 thou count? But I'd be more concerned with following error. A cam
>> > for valve motion is not a sine wave by quite a long row of apple trees.
>> >
>> > > On Mon, Jul 13, 2020 at 9:35 AM Gene Heskett 
>> > wrote:
>> > > > On Monday 13 July 2020 12:00:19 Peter C. Wallace wrote:
>> > > >
>> > > >
>> > > > ROTFLMAO, Peter see's right thru us. ;-) But seriously, the FPGA
>> > > > does seem like the ideal place for such a module. On chip com with
>> > > > the chosen stepgenerator removes that particular bandwidth limit. I
>> > > > cou

Re: [Emc-users] Because the hardware store was 4 miles away...

Displacement of the cross slide while cutting a hex head is proportional to
the sin of the spindle angle.  Very much like the height of a piston is
proportional to the angle of the crank

Draw a picture of a hexagon and then make a line that crosses one of the
flats at some odd angle.  Figure out how long this line is.  At first it
seems hard then you draw a second line from center to one of the hex's
points and now you have a triangle with two angles and one side known.
The function that drives the cross slide is basically a sine.

You can look up "Angle Side Angle" or "cosine law" in Wikipedia.

The exact same thing could be used to "turn" a flat on a shaft

On Mon, Jul 13, 2020 at 11:49 AM Gene Heskett  wrote:

> On Monday 13 July 2020 13:56:47 Chris Albertson wrote:
>
> > Actually making a hex head on the lathe would best be done using a
> > microcontroller.   FPGAs can compute trig functions but I think the
> > method used is to first implement a "soft CPU" and then run code
> > written in C that uses math.h   That is a silly-expensive why to
> > replace a $5 STM32 chip.
> >
> > But really, the Lathe spindle does not run so fast and you can write
> > this code as a HAL component that runs in the Servo loop.I wanted
> > out how I would do this last night and was stumped on the math until I
> > remembered the law of cosines and "SAS" triangle problems from some
> > class I took in the 10th grade.   Look those up on Wikipedia and then
> > it is not hard to computer the cross slide position as a function of
> > spindle angle.
> >
> > The hard part is getting such a good cross slide setup with no play of
> > backlash
>
> Does 2 thou count? But I'd be more concerned with following error. A cam
> for valve motion is not a sine wave by quite a long row of apple trees.
>
> > On Mon, Jul 13, 2020 at 9:35 AM Gene Heskett 
> wrote:
> > > On Monday 13 July 2020 12:00:19 Peter C. Wallace wrote:
> > >
> > >
> > > ROTFLMAO, Peter see's right thru us. ;-) But seriously, the FPGA
> > > does seem like the ideal place for such a module. On chip com with
> > > the chosen stepgenerator removes that particular bandwidth limit. I
> > > could also see it doubleing the size of the FPGA needed so its not
> > > going to be free.  I think, not knowing the first thing about
> > > writing FPGA code.  :-(
> > >
> > > [..
>
>
> 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
>


-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] Because the hardware store was 4 miles away...

2020-07-13 Thread Gregg Eshelman via Emc-users

Running it like that should make it possible to cut teeth on thread taps with 
relief. Thread it 'lumpy', mill out most of the chip grooves, harden then grind 
to sharpen. Used to be mechanical drive attachments for some lathes to move the 
cross slide in and out for cutting threads for taps.

On Monday, July 13, 2020, 11:59:28 AM MDT, Chris Albertson 
 wrote:  
 Actually making a hex head on the lathe would best be done using a
microcontroller.  FPGAs can compute trig functions but I think the method
used is to first implement a "soft CPU" and then run code written in C that
uses math.h  That is a silly-expensive why to replace a $5 STM32 chip.

But really, the Lathe spindle does not run so fast and you can write this
code as a HAL component that runs in the Servo loop.    I wanted out how I
would do this last night and was stumped on the math until I remembered the
law of cosines and "SAS" triangle problems from some class I took in the
10th grade.  Look those up on Wikipedia and then it is not hard to
computer the cross slide position as a function of spindle angle.

The hard part is getting such a good cross slide setup with no play of
backlash  
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Because the hardware store was 4 miles away...

2020-07-13 Thread Sam Sokolik

Andy has already done that..

https://youtu.be/fo7SwanH50I

On Mon, Jul 13, 2020, 8:11 PM Gregg Eshelman via Emc-users <
emc-users@lists.sourceforge.net> wrote:

> Running it like that should make it possible to cut teeth on thread taps
> with relief. Thread it 'lumpy', mill out most of the chip grooves, harden
> then grind to sharpen. Used to be mechanical drive attachments for some
> lathes to move the cross slide in and out for cutting threads for taps.
>
> On Monday, July 13, 2020, 11:59:28 AM MDT, Chris Albertson <
> albertson.ch...@gmail.com> wrote:
>  Actually making a hex head on the lathe would best be done using a
> microcontroller.  FPGAs can compute trig functions but I think the method
> used is to first implement a "soft CPU" and then run code written in C that
> uses math.h  That is a silly-expensive why to replace a $5 STM32 chip.
>
> But really, the Lathe spindle does not run so fast and you can write this
> code as a HAL component that runs in the Servo loop.I wanted out how I
> would do this last night and was stumped on the math until I remembered the
> law of cosines and "SAS" triangle problems from some class I took in the
> 10th grade.  Look those up on Wikipedia and then it is not hard to
> computer the cross slide position as a function of spindle angle.
>
> The hard part is getting such a good cross slide setup with no play of
> backlash
> ___
> 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] off topic: pwm with a stepper driver/motor

2020-07-13 Thread cogoman via Emc-users

I recently discovered geared stepper motors.

http://www.zyltech.com/nema-17-stepper-motor-geared-planetary-gearbox-1-7-a-3-1-nm-435-ozin/

I've been happy with zyltech in the past. I bought one of these for
evluation, but the specs seem to be great for CNC. Low enough current to
work with a stepstick, High enough torque for a fairly powerful machine,
and less than 4 mH inductance should let it step pretty fast.

5.18:1 gear ratio should reduce that 4 meter spur gear, but the link
below has higher gear ratios that would reduce that spur gear greatly!
Backlash could be a problem for CNC, but if you are only going one way,
the less precision gearboxes might be fine.

https://www.omc-stepperonline.com/geared-stepper-motor/?sort=p.price&order=ASC

Once you visit the stepperonline web page you know as much about them as
I do, but their offerings might be just right for your application.

On 7/9/20 2:23 PM, R C wrote:

Hello,

this is (probably) off topic, been seen that happen. If it is please
ignore it.

I am building a "motorized" telescope mount (dobsonian) with what is
called an equatorial platform, it has 3 axis which I am going to drive
with stepper motors.

The stepper motors I use with a stepper driver, those common DM542
ones, the stepper motors themselves are 2A and 1.8 degrees per step.

What I want to accomplish with the equatorial platform) (it
compensates for the rotation of the earth) is that, the start and end
position accuracy is not that important, smooth and
constant/consistent movement is. for the azimuth/altitude precision
is not a really big deal, but you'd want to move these 2 axis
somewhat swift.

So there are a few factors to decide.

I probably want micro stepping, what settings on the driver for
pulses per rev, is best to use (or is that just trial and error?)

As with PWM itself, I am probably just not too familiar with it. From
what I understand, the voltage I use for the motors determines how
fast I can go (I am going to use a 48V switching power supply).

as for PWM, I can of course change the length of the pulse itself
and, independently, change the time between two pulses. What is the
relation ship there? WHat does a longer width of the pulse itself
do? and what exactly does a longer gap between the pulses do (of
course the wider the gap between two pulses the slower the motor turns).

for, especially, the equatorial platform, I want to avoid "jerking"
it, meaning starting and stopping the stepper motor as little as
possible and just go at a 'slow' constant speed.

sorry if totally of topic

thanks,

Ron

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

Re: [Emc-users] off topic: pwm with a stepper driver/motor

Interesting,

but I already have the motors, and the gears are on their way. What
I was really looking for is how to drive the stepper-drivers, he DM542
series ones.

Ron

On 7/13/20 7:53 PM, cogoman via Emc-users wrote:

I recently discovered geared stepper motors.

http://www.zyltech.com/nema-17-stepper-motor-geared-planetary-gearbox-1-7-a-3-1-nm-435-ozin/

I've been happy with zyltech in the past. I bought one of these for
evluation, but the specs seem to be great for CNC. Low enough current
to work with a stepstick, High enough torque for a fairly powerful
machine, and less than 4 mH inductance should let it step pretty fast.

https://www.omc-stepperonline.com/geared-stepper-motor/?sort=p.price&order=ASC

Once you visit the stepperonline web page you know as much about them
as I do, but their offerings might be just right for your application.

On 7/9/20 2:23 PM, R C wrote:

Hello,

this is (probably) off topic, been seen that happen. If it is please
ignore it.

I am building a "motorized" telescope mount (dobsonian) with what is
called an equatorial platform, it has 3 axis which I am going to
drive with stepper motors.

The stepper motors I use with a stepper driver, those common DM542
ones, the stepper motors themselves are 2A and 1.8 degrees per step.

What I want to accomplish with the equatorial platform) (it
compensates for the rotation of the earth) is that, the start and
end position accuracy is not that important, smooth and
constant/consistent movement is. for the azimuth/altitude precision
is not a really big deal, but you'd want to move these 2 axis
somewhat swift.

So there are a few factors to decide.

I probably want micro stepping, what settings on the driver for
pulses per rev, is best to use (or is that just trial and error?)

for, especially, the equatorial platform, I want to avoid "jerking"
it, meaning starting and stopping the stepper motor as little as
possible and just go at a 'slow' constant speed.

sorry if totally of topic

thanks,

Ron

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

Re: [Emc-users] off topic: pwm with a stepper driver/motor

A fast control loop that drives each motor at a given speed and a second
slower control loop that figures out what that speed should be.   The
second loop typically uses "PID" even if only in fact the "P" is used.

That can be used to drive any number of motors all at their correct speeds.


On Mon, Jul 13, 2020 at 7:28 PM R C  wrote:

> Interesting,
>
>
> but I already have the motors,  and  the gears are on their way.   What
> I was really looking for is how to drive the stepper-drivers, he DM542
> series ones.
>
>
> Ron
>
>
>
> On 7/13/20 7:53 PM, cogoman via Emc-users wrote:
> > I recently discovered geared stepper motors.
> >
> >
> http://www.zyltech.com/nema-17-stepper-motor-geared-planetary-gearbox-1-7-a-3-1-nm-435-ozin/
> >
> >
> > I've been happy with zyltech in the past.  I bought one of these for
> > evluation, but the specs seem to be great for CNC. Low enough current
> > to work with a stepstick, High enough torque for a fairly powerful
> > machine, and less than 4 mH inductance should let it step pretty fast.
> >
> > 5.18:1 gear ratio should reduce that 4 meter spur gear, but the link
> > below has higher gear ratios that would reduce that spur gear greatly!
> > Backlash could be a problem for CNC, but if you are only going one
> > way, the less precision gearboxes might be fine.
> >
> >
> https://www.omc-stepperonline.com/geared-stepper-motor/?sort=p.price&order=ASC
> >
> >
> > Once you visit the stepperonline web page you know as much about them
> > as I do, but their offerings might be just right for your application.
> >
> > On 7/9/20 2:23 PM, R C wrote:
> >> Hello,
> >>
> >> this is (probably) off topic, been seen that happen.  If it is please
> >> ignore it.
> >>
> >>
> >> I am building a "motorized"  telescope mount (dobsonian) with what is
> >> called an equatorial platform, it has 3 axis which I am going to
> >> drive with stepper motors.
> >>
> >>
> >> The stepper motors I use with a stepper driver, those common DM542
> >> ones, the stepper motors themselves are 2A and 1.8 degrees per step.
> >>
> >>
> >> What I want to accomplish with the equatorial platform)  (it
> >> compensates for the rotation of the earth) is that,  the start and
> >> end position accuracy is not that important,  smooth and
> >> constant/consistent movement is.  for the azimuth/altitude precision
> >> is not a really big deal, but you'd want to move these 2 axis
> >> somewhat swift.
> >>
> >>
> >> So there are a few factors to decide.
> >>
> >>
> >> I probably want micro stepping,  what settings on the driver for
> >> pulses per rev, is best to use (or is that just trial and error?)
> >>
> >>
> >> As with PWM itself, I am probably just not too familiar with it. From
> >> what I understand, the voltage I use for the motors determines how
> >> fast I can go (I am going to use a 48V switching power supply).
> >>
> >>
> >> as for PWM,  I can of course  change the length of the pulse itself
> >> and, independently, change the time between two pulses. What is the
> >> relation ship there?  WHat does a longer  width of the pulse itself
> >> do?  and what exactly does a longer gap between the pulses do (of
> >> course the wider the gap between two pulses the slower the motor turns).
> >>
> >>
> >> for, especially, the equatorial platform, I want to avoid "jerking"
> >> it,  meaning  starting and stopping the stepper motor as little as
> >> possible and just go at a 'slow' constant speed.
> >>
> >>
> >>
> >> sorry if totally of topic
> >>
> >>
> >> thanks,
> >>
> >>
> >> Ron
> >>
> >>
> >>
> >> ___
> >> 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
>


-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] off topic: pwm with a stepper driver/motor

well, I can calculate what the speed needs to be, also I can actually
"observe" it too.. by pointing the telescope at a star and see how
much the deviation is. I have encoder to check the actual speed of a shaft.

I found some information in a manual/tech-sheet that comes with the
drivers, so I am trying to figure out what the best stepping rate is and
what the best way of actually sending pulses to the stepper-driver is.

I wrote some c-code that runs the motors in pthreads, I just want to
know what the best way is. pulse lengths, pause/gap length etc.
(basically the best way to use a dm542 (all those steppers are sorta
the same I understand)

The driver tech-sheet basically says it can do pretty all it's
available micro stepping with a 1.8 degree stepper motor, I wonder if
that is really true.

Ron

On 7/13/20 8:35 PM, Chris Albertson wrote:

A fast control loop that drives each motor at a given speed and a second
slower control loop that figures out what that speed should be. The
second loop typically uses "PID" even if only in fact the "P" is used.

That can be used to drive any number of motors all at their correct speeds.

On Mon, Jul 13, 2020 at 7:28 PM R C wrote:

Interesting,

but I already have the motors, and the gears are on their way. What
I was really looking for is how to drive the stepper-drivers, he DM542
series ones.

Ron

On 7/13/20 7:53 PM, cogoman via Emc-users wrote:

I recently discovered geared stepper motors.

http://www.zyltech.com/nema-17-stepper-motor-geared-planetary-gearbox-1-7-a-3-1-nm-435-ozin/

I've been happy with zyltech in the past. I bought one of these for
evluation, but the specs seem to be great for CNC. Low enough current
to work with a stepstick, High enough torque for a fairly powerful
machine, and less than 4 mH inductance should let it step pretty fast.

https://www.omc-stepperonline.com/geared-stepper-motor/?sort=p.price&order=ASC

Once you visit the stepperonline web page you know as much about them
as I do, but their offerings might be just right for your application.

On 7/9/20 2:23 PM, R C wrote:

Hello,

this is (probably) off topic, been seen that happen. If it is please
ignore it.

I am building a "motorized" telescope mount (dobsonian) with what is
called an equatorial platform, it has 3 axis which I am going to
drive with stepper motors.

The stepper motors I use with a stepper driver, those common DM542
ones, the stepper motors themselves are 2A and 1.8 degrees per step.

What I want to accomplish with the equatorial platform) (it
compensates for the rotation of the earth) is that, the start and
end position accuracy is not that important, smooth and
constant/consistent movement is. for the azimuth/altitude precision
is not a really big deal, but you'd want to move these 2 axis
somewhat swift.

So there are a few factors to decide.

I probably want micro stepping, what settings on the driver for
pulses per rev, is best to use (or is that just trial and error?)

for, especially, the equatorial platform, I want to avoid "jerking"
it, meaning starting and stopping the stepper motor as little as
possible and just go at a 'slow' constant speed.

sorry if totally of topic

thanks,

Ron

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

Re: [Emc-users] off topic: pwm with a stepper driver/motor

2020-07-13 Thread Dave Matthews

It may just be my age but wouldn't it be easier to just use a 555 (do they
still make them) and a knob to tweak the pulse rate to match the star?  Add
a slew button to change the speed while the button is pushed and a
direction switch to toggle the direction pin on the driver.  I guess I
don't see the need for a computer to run a stepper at a constant speed.

Dave

On Mon, Jul 13, 2020, 22:46 R C  wrote:

> well,  I can calculate what the speed needs to be, also I can actually
> "observe" it too..  by pointing the  telescope at a star and see how
> much the deviation is.  I have encoder to check the actual speed of a
> shaft.
>
> I found some information in a manual/tech-sheet that comes with the
> drivers, so I am trying to figure out what the best stepping rate is and
> what the best way of actually sending pulses to the stepper-driver is.
>
> I wrote some c-code that runs the motors in pthreads, I just want to
> know what the best way is.  pulse lengths, pause/gap length etc.
> (basically the best way to use a dm542  (all those steppers are sorta
> the same I understand)
>
> The driver tech-sheet  basically says it can do pretty all it's
> available micro stepping with a 1.8 degree stepper motor, I wonder if
> that is really true.
>
>
> Ron
>
>
> On 7/13/20 8:35 PM, Chris Albertson wrote:
> > A fast control loop that drives each motor at a given speed and a second
> > slower control loop that figures out what that speed should be.   The
> > second loop typically uses "PID" even if only in fact the "P" is used.
> >
> > That can be used to drive any number of motors all at their correct
> speeds.
> >
> >
> > On Mon, Jul 13, 2020 at 7:28 PM R C  wrote:
> >
> >> Interesting,
> >>
> >>
> >> but I already have the motors,  and  the gears are on their way.   What
> >> I was really looking for is how to drive the stepper-drivers, he DM542
> >> series ones.
> >>
> >>
> >> Ron
> >>
> >>
> >>
> >> On 7/13/20 7:53 PM, cogoman via Emc-users wrote:
> >>> I recently discovered geared stepper motors.
> >>>
> >>>
> >>
> http://www.zyltech.com/nema-17-stepper-motor-geared-planetary-gearbox-1-7-a-3-1-nm-435-ozin/
> >>>
> >>> I've been happy with zyltech in the past.  I bought one of these for
> >>> evluation, but the specs seem to be great for CNC. Low enough current
> >>> to work with a stepstick, High enough torque for a fairly powerful
> >>> machine, and less than 4 mH inductance should let it step pretty fast.
> >>>
> >>> 5.18:1 gear ratio should reduce that 4 meter spur gear, but the link
> >>> below has higher gear ratios that would reduce that spur gear greatly!
> >>> Backlash could be a problem for CNC, but if you are only going one
> >>> way, the less precision gearboxes might be fine.
> >>>
> >>>
> >>
> https://www.omc-stepperonline.com/geared-stepper-motor/?sort=p.price&order=ASC
> >>>
> >>> Once you visit the stepperonline web page you know as much about them
> >>> as I do, but their offerings might be just right for your application.
> >>>
> >>> On 7/9/20 2:23 PM, R C wrote:
>  Hello,
> 
>  this is (probably) off topic, been seen that happen.  If it is please
>  ignore it.
> 
> 
>  I am building a "motorized"  telescope mount (dobsonian) with what is
>  called an equatorial platform, it has 3 axis which I am going to
>  drive with stepper motors.
> 
> 
>  The stepper motors I use with a stepper driver, those common DM542
>  ones, the stepper motors themselves are 2A and 1.8 degrees per step.
> 
> 
>  What I want to accomplish with the equatorial platform)  (it
>  compensates for the rotation of the earth) is that,  the start and
>  end position accuracy is not that important,  smooth and
>  constant/consistent movement is.  for the azimuth/altitude precision
>  is not a really big deal, but you'd want to move these 2 axis
>  somewhat swift.
> 
> 
>  So there are a few factors to decide.
> 
> 
>  I probably want micro stepping,  what settings on the driver for
>  pulses per rev, is best to use (or is that just trial and error?)
> 
> 
>  As with PWM itself, I am probably just not too familiar with it. From
>  what I understand, the voltage I use for the motors determines how
>  fast I can go (I am going to use a 48V switching power supply).
> 
> 
>  as for PWM,  I can of course  change the length of the pulse itself
>  and, independently, change the time between two pulses. What is the
>  relation ship there?  WHat does a longer  width of the pulse itself
>  do?  and what exactly does a longer gap between the pulses do (of
>  course the wider the gap between two pulses the slower the motor
> turns).
> 
> 
>  for, especially, the equatorial platform, I want to avoid "jerking"
>  it,  meaning  starting and stopping the stepper motor as little as
>  possible and just go at a 'slow' constant speed.
> 
> 
> 
>  sorry if tot

Re: [Emc-users] off topic: pwm with a stepper driver/motor

On Mon, Jul 13, 2020 at 8:02 PM Dave Matthews  wrote:

> It may just be my age but wouldn't it be easier to just use a 555 (do they
> still make them) and a knob to tweak the pulse rate to match the star?


That would be easy but I think there is some plan to have a "go to"
ability where the 'scope slews to a target selected from a database.

Also, a full-up computer today sells for the same price as a 555 chip.  You
can get an AVR (Arduino chip) in an 8-pin package for just a few cents.
-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] off topic: pwm with a stepper driver/motor

yeah that would be easiest, but I want to do something similar for
azimuth and altitude.

On 7/13/20 9:00 PM, Dave Matthews wrote:

It may just be my age but wouldn't it be easier to just use a 555 (do they
still make them) and a knob to tweak the pulse rate to match the star? Add
a slew button to change the speed while the button is pushed and a
direction switch to toggle the direction pin on the driver. I guess I
don't see the need for a computer to run a stepper at a constant speed.

Dave

On Mon, Jul 13, 2020, 22:46 R C wrote:

The driver tech-sheet basically says it can do pretty all it's
available micro stepping with a 1.8 degree stepper motor, I wonder if
that is really true.

Ron

On 7/13/20 8:35 PM, Chris Albertson wrote:

That can be used to drive any number of motors all at their correct

speeds.

On Mon, Jul 13, 2020 at 7:28 PM R C wrote:

Interesting,

but I already have the motors, and the gears are on their way. What
I was really looking for is how to drive the stepper-drivers, he DM542
series ones.

Ron

On 7/13/20 7:53 PM, cogoman via Emc-users wrote:

I recently discovered geared stepper motors.

http://www.zyltech.com/nema-17-stepper-motor-geared-planetary-gearbox-1-7-a-3-1-nm-435-ozin/

I've been happy with zyltech in the past. I bought one of these for
evluation, but the specs seem to be great for CNC. Low enough current
to work with a stepstick, High enough torque for a fairly powerful
machine, and less than 4 mH inductance should let it step pretty fast.

https://www.omc-stepperonline.com/geared-stepper-motor/?sort=p.price&order=ASC

Once you visit the stepperonline web page you know as much about them
as I do, but their offerings might be just right for your application.

On 7/9/20 2:23 PM, R C wrote:

Hello,

this is (probably) off topic, been seen that happen. If it is please
ignore it.

I am building a "motorized" telescope mount (dobsonian) with what is
called an equatorial platform, it has 3 axis which I am going to
drive with stepper motors.

The stepper motors I use with a stepper driver, those common DM542
ones, the stepper motors themselves are 2A and 1.8 degrees per step.

What I want to accomplish with the equatorial platform) (it
compensates for the rotation of the earth) is that, the start and
end position accuracy is not that important, smooth and
constant/consistent movement is. for the azimuth/altitude precision
is not a really big deal, but you'd want to move these 2 axis
somewhat swift.

So there are a few factors to decide.

I probably want micro stepping, what settings on the driver for
pulses per rev, is best to use (or is that just trial and error?)

turns).

for, especially, the equatorial platform, I want to avoid "jerking"
it, meaning starting and stopping the stepper motor as little as
possible and just go at a 'slow' constant speed.

sorry if totally of topic

thanks,

Ron

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

___
Emc-users mailing list
Emc-users@l

Re: [Emc-users] off topic: pwm with a stepper driver/motor

yup exactly,  actually in a way  so I can point at things that you can't 
really see but  would need longer exposures for.


On 7/13/20 9:28 PM, Chris Albertson wrote:

On Mon, Jul 13, 2020 at 8:02 PM Dave Matthews  wrote:


It may just be my age but wouldn't it be easier to just use a 555 (do they
still make them) and a knob to tweak the pulse rate to match the star?


That would be easy but I think there is some plan to have a "go to"
ability where the 'scope slews to a target selected from a database.

Also, a full-up computer today sells for the same price as a 555 chip.  You
can get an AVR (Arduino chip) in an 8-pin package for just a few cents.



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

Re: [Emc-users] Because the hardware store was 4 miles away...

On Monday 13 July 2020 20:12:09 Chris Albertson wrote:

> Displacement of the cross slide while cutting a hex head is
> proportional to the sin of the spindle angle.  Very much like the
> height of a piston is proportional to the angle of the crank

Yes, but for a siggen's sine output, one would need to run the sin thru an ABS 
to generate 2 half sin's as the zero point of the ABS output is the point of 
the hex, and the amplitude is the flatness of the flat. One would want to mul 
the encoder angle by 3 because the ABS makes 2 adjacent flats out of one 
complete sin wave. A fixed offset mixed into that would allow the size of the 
hex to be controlled. By borrowing the output of the X jog dial, the hex can be 
sized by .0001" per click of the dial. Get rid of the siggen after you've 
proved X can move fast enough by subbing a MOD[encoder_scale] out of the 
encoder output to make a SIN[out of that], feed that to an ABS[] would make 4 
or 6 sided heads. Choice of multiplier of the mod product could make a 5 sided 
head that only you could make a wrench for. ;-)

Experimenting while fixing my index generation yesterday, I find that X speed 
isn't going to be a huge problem even for complex shapes as when the backgear 
is engaged, and the vfd is at 5 hertz, which is my lf cutoff arbitrarily set in 
the vfd, it takes about 8 seconds for one turn of the chuck. X has buckets of 
time to do the sailors hornpipe. Or any other dance you might want to teach it. 
I have at least 40 ipm to play with at my current accel settings. And with one 
of the 3 phase motors subbing for the 2 phase nema-24 in the X now, I could 
probably hit 80 ipm peak.  And the 2NM version of that same motor would fit! 
I'm doing 70 with that 3NM motor on Z now and haven't found its limits yet, it 
hasn't stalled unless I hit something.

I could cobble all that together in hal, that part isn't exactly black magic, 
but what would be needed is gcodes to control it.

Thats well above my pay grade.

Is there a family ## that could be used for this already defined in G##PQ for 
on/off, and the same G##.1|2|3|4 etc used for other controls that is already 
semi assigned in rs-274d that we could use without getting too far afield?

> Draw a picture of a hexagon and then make a line that crosses one of
> the flats at some odd angle.  Figure out how long this line is.  At
> first it seems hard then you draw a second line from center to one of
> the hex's points and now you have a triangle with two angles and one
> side known. The function that drives the cross slide is basically a
> sine.

Exactly.

> You can look up "Angle Side Angle" or "cosine law" in Wikipedia.
>
> The exact same thing could be used to "turn" a flat on a shaft

Exactly. There we'd need a switch to enable only one half sin per revolution. 
Or maybe even 2 per, spaced to cut two opposing flats. I need that to do the 
worm shaft drive coupler on this BS-1 clone. :) 

> On Mon, Jul 13, 2020 at 11:49 AM Gene Heskett  wrote:
> > On Monday 13 July 2020 13:56:47 Chris Albertson wrote:
> > > Actually making a hex head on the lathe would best be done using a
> > > microcontroller.   FPGAs can compute trig functions but I think
> > > the method used is to first implement a "soft CPU" and then run
> > > code written in C that uses math.h   That is a silly-expensive why
> > > to replace a $5 STM32 chip.

I think the existing hal tools can do some of this.

> > > But really, the Lathe spindle does not run so fast and you can
> > > write this code as a HAL component that runs in the Servo loop.   
> > > I wanted out how I would do this last night and was stumped on the
> > > math until I remembered the law of cosines and "SAS" triangle
> > > problems from some class I took in the 10th grade.   Look those up
> > > on Wikipedia and then it is not hard to computer the cross slide
> > > position as a function of spindle angle.
> > >
> > > The hard part is getting such a good cross slide setup with no
> > > play of backlash

Ball screws.

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] off topic: pwm with a stepper driver/motor

On Mon, Jul 13, 2020 at 7:28 PM R C  wrote:

> Interesting,
>
>
> but I already have the motors,  and  the gears are on their way.   What
> I was really looking for is how to drive the stepper-drivers, he DM542
> series ones.
>

Do you have the user manual for the DM542?   If not look at the top top
half of page 9 here https://www.omc-stepperonline.com/download/DM542T.pdf

It tells you things like how long you need to hold the "DIR" pin before the
next step pulse and  the minimum pulse widths.

I'd make them all larger than needed by about 4X because you are not trying
to make these go fast.  In fact, a 50% duty cycle square wave works fine.

What you do is in the loop when you set a pin high you store the time for
when it must be set low and every time through the loop you do whatever has
a time-to-do that is expired.  You can juggle N balls at once in one loop
this way.

-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] off topic: pwm with a stepper driver/motor