Re: [Machinekit] Re: Stepper motors (3D-Printing): TP and slew-range

2017-05-04 Thread Hedge Hog
Thanks Brian, I'll dig into your material too.

On Thursday, May 4, 2017 at 12:46:28 PM UTC+10, Brian Schousek wrote:
>
> Hedge Hog-
>
> I have been struggling with what appear to be similar issues with the 
> general concepts that you have been. I have written some notes to myself 
> about what I have discovered at [link](
> https://github.com/bschousek/piphat/blob/master/idiot.md) and perhaps 
> they will be useful to you as well.
>
> Brian
>
> On Wednesday, May 3, 2017 at 7:31:52 PM UTC-5, Hedge Hog wrote:
>>
>>
>> On Tuesday, May 2, 2017 at 5:35:33 PM UTC+10, Bas de Bruijn wrote:
>>>
>>>
>>>
>>> On 02 May 2017, at 08:18, Hedge Hog  wrote:
>>>
>>> Thanks for taking the time to reply Alex,
>>>
>>> Re Q3 and using HAL to control the stepper motor.  Is there some example 
>>> you know of that I could review?
>>>
>>>
>>> Why don't you take the stepgen maxvel and maxaccel pins? You'll have to 
>>> set them to a certain value anyway.
>>> http://www.machinekit.io/docs/man/man9/hal_pru_generic/ 
>>> 
>>>
>>
>> Thanks for that reference, I'll start there.  Apologies if I appear to be 
>> obtuse or needy.
>> It strikes me as quite a steep learning curve, and I'm really struggling 
>> to wrap my head a round: a) the components b) where they are documented and 
>> c) which re relevant to the issue/problem/question I have.
>>  
>>
>>> Will your use case include a user setting these pins in Hal? In not, 
>>> then is this "privilege" enough?
>>>
>>
>> I'm sorry I do not know what to say. 
>> Are HAL instructions/settings compiled in any way? are they compiled at 
>> run time? Are the compiled into the binary that is distributed to the user? 
>> Do they just sit there and are interpreted - so the user could edit them?  
>> I feel quite embarrassed :) I've been reading for several days and I do 
>> not feel I've even managed to get some f the basics straight in my mind.
>>  
>>
>>> If the tp has bigger values then the stepgen has. The stepgen will not 
>>> be able to keep up and will be limited to these values. So you won't 
>>> violate your hardware specs, but get deviation from the path.
>>>
>>
>> Okay this is great.  
>> There are TP settings and stepgen settings.  Rather than pester you with 
>> Q's - Where is best to read about these sorts of component hierarchies, and 
>> who can stand on whose toes?
>>  
>>
>>> If you don't want that you need to be sure that the limits on the tp are 
>>> lower than your stepgen.
>>>
>>
>> Okay this is great too.  
>> It sounds like I'm responsible for ensuring that there are no conflicts, 
>> i.e. MK does not, by default, ensure the TP path is adhered to by adjusting 
>> relevant settings (maybe with warnings) to ensure that TP settings are 
>> lower than the stepgen settings.
>>
>> Again rather than reproduce/rewrite the docs in the mail-list, could you 
>> point me to where in the docs this these responsibilities are described/
>>
>> Best wishes
>> Hedge
>>
>>
>>> If not, does this approach employ some sort of Trajectory Planner API, 
>>> or would this approach require implementing a TP from scratch.
>>>
>>> If I understand correctly, that understanding comes mostly from 
>>> reviewing some of the issues in GRBL, a TP is a non-trivial undertaking.
>>>
>>> Best wishes
>>> Hedge
>>>
>>> On Monday, May 1, 2017 at 2:47:22 PM UTC+10, Alexander Rössler wrote:

 I can answer Q3:
 You can protect your stepper motor spec on the HAL level. To ensure the 
 acceleration and maximum velocity values are never violated one could 
 drive 
 the stepper via PID loop tuned with the correct parameters. If you want to 
 ensure the user cannot edit or override the values you can compile them 
 into a HAL component.

 Am Samstag, 15. April 2017 07:49:33 UTC-5 schrieb Hedge Hog:
>
> Hi,
> I am considering a 3D printing use case, which is likely different 
> from most CNC use cases in that the bed load/inertia is relatively 
> constant/stable.
> That's a generalization, but probably reasonable to say that in 80% of 
> cases the mass and forces will be within a very narrow range.  
> Compared to say a CNC machine carving a cubic foot of wood then a 
> cubic foot of steel.
>
> I have read [1]-[8] and have three questions.  
> From [1]-[8] I can't see that the pull-in/pull-out envelope (or slew 
> range) is identified for a stepper motor. Nor does it appear that inputs 
> are sought that would allow them to be guesstimated.  
>
> Q1) Am I wrong (and there is a set of approximations used to define 
> the slew range given the inputs sought)?
>
> AFAICT:
> a) the trajectory planner might be working with a single point on the 
> pull-out curve of a motor, so you can expect the TP to try change 
> direction 
> in the slew-range of 

Re: [Machinekit] Re: Stepper motors (3D-Printing): TP and slew-range

2017-05-03 Thread Brian Schousek
Hedge Hog-

I have been struggling with what appear to be similar issues with the 
general concepts that you have been. I have written some notes to myself 
about what I have discovered at 
[link](https://github.com/bschousek/piphat/blob/master/idiot.md) and 
perhaps they will be useful to you as well.

Brian

On Wednesday, May 3, 2017 at 7:31:52 PM UTC-5, Hedge Hog wrote:
>
>
> On Tuesday, May 2, 2017 at 5:35:33 PM UTC+10, Bas de Bruijn wrote:
>>
>>
>>
>> On 02 May 2017, at 08:18, Hedge Hog  wrote:
>>
>> Thanks for taking the time to reply Alex,
>>
>> Re Q3 and using HAL to control the stepper motor.  Is there some example 
>> you know of that I could review?
>>
>>
>> Why don't you take the stepgen maxvel and maxaccel pins? You'll have to 
>> set them to a certain value anyway.
>> http://www.machinekit.io/docs/man/man9/hal_pru_generic/ 
>> 
>>
>
> Thanks for that reference, I'll start there.  Apologies if I appear to be 
> obtuse or needy.
> It strikes me as quite a steep learning curve, and I'm really struggling 
> to wrap my head a round: a) the components b) where they are documented and 
> c) which re relevant to the issue/problem/question I have.
>  
>
>> Will your use case include a user setting these pins in Hal? In not, then 
>> is this "privilege" enough?
>>
>
> I'm sorry I do not know what to say. 
> Are HAL instructions/settings compiled in any way? are they compiled at 
> run time? Are the compiled into the binary that is distributed to the user? 
> Do they just sit there and are interpreted - so the user could edit them?  
> I feel quite embarrassed :) I've been reading for several days and I do 
> not feel I've even managed to get some f the basics straight in my mind.
>  
>
>> If the tp has bigger values then the stepgen has. The stepgen will not be 
>> able to keep up and will be limited to these values. So you won't violate 
>> your hardware specs, but get deviation from the path.
>>
>
> Okay this is great.  
> There are TP settings and stepgen settings.  Rather than pester you with 
> Q's - Where is best to read about these sorts of component hierarchies, and 
> who can stand on whose toes?
>  
>
>> If you don't want that you need to be sure that the limits on the tp are 
>> lower than your stepgen.
>>
>
> Okay this is great too.  
> It sounds like I'm responsible for ensuring that there are no conflicts, 
> i.e. MK does not, by default, ensure the TP path is adhered to by adjusting 
> relevant settings (maybe with warnings) to ensure that TP settings are 
> lower than the stepgen settings.
>
> Again rather than reproduce/rewrite the docs in the mail-list, could you 
> point me to where in the docs this these responsibilities are described/
>
> Best wishes
> Hedge
>
>
>> If not, does this approach employ some sort of Trajectory Planner API, or 
>> would this approach require implementing a TP from scratch.
>>
>> If I understand correctly, that understanding comes mostly from reviewing 
>> some of the issues in GRBL, a TP is a non-trivial undertaking.
>>
>> Best wishes
>> Hedge
>>
>> On Monday, May 1, 2017 at 2:47:22 PM UTC+10, Alexander Rössler wrote:
>>>
>>> I can answer Q3:
>>> You can protect your stepper motor spec on the HAL level. To ensure the 
>>> acceleration and maximum velocity values are never violated one could drive 
>>> the stepper via PID loop tuned with the correct parameters. If you want to 
>>> ensure the user cannot edit or override the values you can compile them 
>>> into a HAL component.
>>>
>>> Am Samstag, 15. April 2017 07:49:33 UTC-5 schrieb Hedge Hog:

 Hi,
 I am considering a 3D printing use case, which is likely different from 
 most CNC use cases in that the bed load/inertia is relatively 
 constant/stable.
 That's a generalization, but probably reasonable to say that in 80% of 
 cases the mass and forces will be within a very narrow range.  
 Compared to say a CNC machine carving a cubic foot of wood then a cubic 
 foot of steel.

 I have read [1]-[8] and have three questions.  
 From [1]-[8] I can't see that the pull-in/pull-out envelope (or slew 
 range) is identified for a stepper motor. Nor does it appear that inputs 
 are sought that would allow them to be guesstimated.  

 Q1) Am I wrong (and there is a set of approximations used to define the 
 slew range given the inputs sought)?

 AFAICT:
 a) the trajectory planner might be working with a single point on the 
 pull-out curve of a motor, so you can expect the TP to try change 
 direction 
 in the slew-range of a stepper motor.
 b) The TP does not consider/use the stop-start range where direction 
 can be reversed without deceleration.

 Q2) Which of the above possibilities is applicable?

 Q3) Is there a way to ensure that an end user c

Re: [Machinekit] Re: Stepper motors (3D-Printing): TP and slew-range

2017-05-03 Thread Hedge Hog

On Tuesday, May 2, 2017 at 5:35:33 PM UTC+10, Bas de Bruijn wrote:
>
>
>
> On 02 May 2017, at 08:18, Hedge Hog > 
> wrote:
>
> Thanks for taking the time to reply Alex,
>
> Re Q3 and using HAL to control the stepper motor.  Is there some example 
> you know of that I could review?
>
>
> Why don't you take the stepgen maxvel and maxaccel pins? You'll have to 
> set them to a certain value anyway.
> http://www.machinekit.io/docs/man/man9/hal_pru_generic/ 
> 
>

Thanks for that reference, I'll start there.  Apologies if I appear to be 
obtuse or needy.
It strikes me as quite a steep learning curve, and I'm really struggling to 
wrap my head a round: a) the components b) where they are documented and c) 
which re relevant to the issue/problem/question I have.
 

> Will your use case include a user setting these pins in Hal? In not, then 
> is this "privilege" enough?
>

I'm sorry I do not know what to say. 
Are HAL instructions/settings compiled in any way? are they compiled at run 
time? Are the compiled into the binary that is distributed to the user? Do 
they just sit there and are interpreted - so the user could edit them?  
I feel quite embarrassed :) I've been reading for several days and I do not 
feel I've even managed to get some f the basics straight in my mind.
 

> If the tp has bigger values then the stepgen has. The stepgen will not be 
> able to keep up and will be limited to these values. So you won't violate 
> your hardware specs, but get deviation from the path.
>

Okay this is great.  
There are TP settings and stepgen settings.  Rather than pester you with 
Q's - Where is best to read about these sorts of component hierarchies, and 
who can stand on whose toes?
 

> If you don't want that you need to be sure that the limits on the tp are 
> lower than your stepgen.
>

Okay this is great too.  
It sounds like I'm responsible for ensuring that there are no conflicts, 
i.e. MK does not, by default, ensure the TP path is adhered to by adjusting 
relevant settings (maybe with warnings) to ensure that TP settings are 
lower than the stepgen settings.

Again rather than reproduce/rewrite the docs in the mail-list, could you 
point me to where in the docs this these responsibilities are described/

Best wishes
Hedge


> If not, does this approach employ some sort of Trajectory Planner API, or 
> would this approach require implementing a TP from scratch.
>
> If I understand correctly, that understanding comes mostly from reviewing 
> some of the issues in GRBL, a TP is a non-trivial undertaking.
>
> Best wishes
> Hedge
>
> On Monday, May 1, 2017 at 2:47:22 PM UTC+10, Alexander Rössler wrote:
>>
>> I can answer Q3:
>> You can protect your stepper motor spec on the HAL level. To ensure the 
>> acceleration and maximum velocity values are never violated one could drive 
>> the stepper via PID loop tuned with the correct parameters. If you want to 
>> ensure the user cannot edit or override the values you can compile them 
>> into a HAL component.
>>
>> Am Samstag, 15. April 2017 07:49:33 UTC-5 schrieb Hedge Hog:
>>>
>>> Hi,
>>> I am considering a 3D printing use case, which is likely different from 
>>> most CNC use cases in that the bed load/inertia is relatively 
>>> constant/stable.
>>> That's a generalization, but probably reasonable to say that in 80% of 
>>> cases the mass and forces will be within a very narrow range.  
>>> Compared to say a CNC machine carving a cubic foot of wood then a cubic 
>>> foot of steel.
>>>
>>> I have read [1]-[8] and have three questions.  
>>> From [1]-[8] I can't see that the pull-in/pull-out envelope (or slew 
>>> range) is identified for a stepper motor. Nor does it appear that inputs 
>>> are sought that would allow them to be guesstimated.  
>>>
>>> Q1) Am I wrong (and there is a set of approximations used to define the 
>>> slew range given the inputs sought)?
>>>
>>> AFAICT:
>>> a) the trajectory planner might be working with a single point on the 
>>> pull-out curve of a motor, so you can expect the TP to try change direction 
>>> in the slew-range of a stepper motor.
>>> b) The TP does not consider/use the stop-start range where direction can 
>>> be reversed without deceleration.
>>>
>>> Q2) Which of the above possibilities is applicable?
>>>
>>> Q3) Is there a way to ensure that an end user cannot get the trajectory 
>>> planner to violate a stepper motors specs?  
>>> I suppose these settings would have to be a compiled, or set by 
>>> privileged user access, and can't be overridden by a configure file 
>>> settings.
>>>
>>> Thanks again for all the effort that has gone into MachineKit
>>>
>>> Best wishes 
>>> Hedgehog
>>>
>>> [1]: http://www.machinekit.io/docs/quickstart/stepper_quickstart/
>>> [2]: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Stepper_Formulas
>>> [3]: 
>>> http://wiki.linuxcnc.org/cgi-bi

Re: [Machinekit] Re: Stepper motors (3D-Printing): TP and slew-range

2017-05-02 Thread Bas de Bruijn


> On 02 May 2017, at 08:18, Hedge Hog  wrote:
> 
> Thanks for taking the time to reply Alex,
> 
> Re Q3 and using HAL to control the stepper motor.  Is there some example you 
> know of that I could review?

Why don't you take the stepgen maxvel and maxaccel pins? You'll have to set 
them to a certain value anyway.
http://www.machinekit.io/docs/man/man9/hal_pru_generic/

Will your use case include a user setting these pins in Hal? In not, then is 
this "privilege" enough?

If the tp has bigger values then the stepgen has. The stepgen will not be able 
to keep up and will be limited to these values. So you won't violate your 
hardware specs, but get deviation from the path.

If you don't want that you need to be sure that the limits on the tp are lower 
than your stepgen.

> If not, does this approach employ some sort of Trajectory Planner API, or 
> would this approach require implementing a TP from scratch.
> 
> If I understand correctly, that understanding comes mostly from reviewing 
> some of the issues in GRBL, a TP is a non-trivial undertaking.
> 
> Best wishes
> Hedge
> 
>> On Monday, May 1, 2017 at 2:47:22 PM UTC+10, Alexander Rössler wrote:
>> I can answer Q3:
>> You can protect your stepper motor spec on the HAL level. To ensure the 
>> acceleration and maximum velocity values are never violated one could drive 
>> the stepper via PID loop tuned with the correct parameters. If you want to 
>> ensure the user cannot edit or override the values you can compile them into 
>> a HAL component.
>> 
>> Am Samstag, 15. April 2017 07:49:33 UTC-5 schrieb Hedge Hog:
>>> 
>>> Hi,
>>> I am considering a 3D printing use case, which is likely different from 
>>> most CNC use cases in that the bed load/inertia is relatively 
>>> constant/stable.
>>> That's a generalization, but probably reasonable to say that in 80% of 
>>> cases the mass and forces will be within a very narrow range.  
>>> Compared to say a CNC machine carving a cubic foot of wood then a cubic 
>>> foot of steel.
>>> 
>>> I have read [1]-[8] and have three questions.  
>>> From [1]-[8] I can't see that the pull-in/pull-out envelope (or slew range) 
>>> is identified for a stepper motor. Nor does it appear that inputs are 
>>> sought that would allow them to be guesstimated.  
>>> 
>>> Q1) Am I wrong (and there is a set of approximations used to define the 
>>> slew range given the inputs sought)?
>>> 
>>> AFAICT:
>>> a) the trajectory planner might be working with a single point on the 
>>> pull-out curve of a motor, so you can expect the TP to try change direction 
>>> in the slew-range of a stepper motor.
>>> b) The TP does not consider/use the stop-start range where direction can be 
>>> reversed without deceleration.
>>> 
>>> Q2) Which of the above possibilities is applicable?
>>> 
>>> Q3) Is there a way to ensure that an end user cannot get the trajectory 
>>> planner to violate a stepper motors specs?  
>>> I suppose these settings would have to be a compiled, or set by privileged 
>>> user access, and can't be overridden by a configure file settings.
>>> 
>>> Thanks again for all the effort that has gone into MachineKit
>>> 
>>> Best wishes 
>>> Hedgehog
>>> 
>>> [1]: http://www.machinekit.io/docs/quickstart/stepper_quickstart/
>>> [2]: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Stepper_Formulas
>>> [3]: 
>>> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Stepper_Motor_Speed_Limitations
>>> [4]: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Mechanical_Spreadsheet
>>> [5]: http://www.soundproofingforum.co.uk/halitosis/
>>> [6]*: http://www.machinekit.io/docs/config/stepconf/
>>> [7]: http://www.machinekit.io/docs/common/Stepper_Diagnostics/
>>> [8]: http://www.machinekit.io/docs/motion/tweaking_steppers/
> 
> -- 
> website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
> https://github.com/machinekit
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.


[Machinekit] Re: Stepper motors (3D-Printing): TP and slew-range

2017-05-01 Thread Hedge Hog
Thanks for taking the time to reply Alex,

Re Q3 and using HAL to control the stepper motor.  Is there some example 
you know of that I could review?
If not, does this approach employ some sort of Trajectory Planner API, or 
would this approach require implementing a TP from scratch.

If I understand correctly, that understanding comes mostly from reviewing 
some of the issues in GRBL, a TP is a non-trivial undertaking.

Best wishes
Hedge

On Monday, May 1, 2017 at 2:47:22 PM UTC+10, Alexander Rössler wrote:
>
> I can answer Q3:
> You can protect your stepper motor spec on the HAL level. To ensure the 
> acceleration and maximum velocity values are never violated one could drive 
> the stepper via PID loop tuned with the correct parameters. If you want to 
> ensure the user cannot edit or override the values you can compile them 
> into a HAL component.
>
> Am Samstag, 15. April 2017 07:49:33 UTC-5 schrieb Hedge Hog:
>>
>> Hi,
>> I am considering a 3D printing use case, which is likely different from 
>> most CNC use cases in that the bed load/inertia is relatively 
>> constant/stable.
>> That's a generalization, but probably reasonable to say that in 80% of 
>> cases the mass and forces will be within a very narrow range.  
>> Compared to say a CNC machine carving a cubic foot of wood then a cubic 
>> foot of steel.
>>
>> I have read [1]-[8] and have three questions.  
>> From [1]-[8] I can't see that the pull-in/pull-out envelope (or slew 
>> range) is identified for a stepper motor. Nor does it appear that inputs 
>> are sought that would allow them to be guesstimated.  
>>
>> Q1) Am I wrong (and there is a set of approximations used to define the 
>> slew range given the inputs sought)?
>>
>> AFAICT:
>> a) the trajectory planner might be working with a single point on the 
>> pull-out curve of a motor, so you can expect the TP to try change direction 
>> in the slew-range of a stepper motor.
>> b) The TP does not consider/use the stop-start range where direction can 
>> be reversed without deceleration.
>>
>> Q2) Which of the above possibilities is applicable?
>>
>> Q3) Is there a way to ensure that an end user cannot get the trajectory 
>> planner to violate a stepper motors specs?  
>> I suppose these settings would have to be a compiled, or set by 
>> privileged user access, and can't be overridden by a configure file 
>> settings.
>>
>> Thanks again for all the effort that has gone into MachineKit
>>
>> Best wishes 
>> Hedgehog
>>
>> [1]: http://www.machinekit.io/docs/quickstart/stepper_quickstart/
>> [2]: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Stepper_Formulas
>> [3]: 
>> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Stepper_Motor_Speed_Limitations
>> [4]: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Mechanical_Spreadsheet
>> [5]: http://www.soundproofingforum.co.uk/halitosis/
>> [6]*: http://www.machinekit.io/docs/config/stepconf/
>> [7]: http://www.machinekit.io/docs/common/Stepper_Diagnostics/
>> [8]: http://www.machinekit.io/docs/motion/tweaking_steppers/
>>
>>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.


[Machinekit] Re: Stepper motors (3D-Printing): TP and slew-range

2017-04-30 Thread Alexander Rössler
I can answer Q3:
You can protect your stepper motor spec on the HAL level. To ensure the 
acceleration and maximum velocity values are never violated one could drive 
the stepper via PID loop tuned with the correct parameters. If you want to 
ensure the user cannot edit or override the values you can compile them 
into a HAL component.

Am Samstag, 15. April 2017 07:49:33 UTC-5 schrieb Hedge Hog:
>
> Hi,
> I am considering a 3D printing use case, which is likely different from 
> most CNC use cases in that the bed load/inertia is relatively 
> constant/stable.
> That's a generalization, but probably reasonable to say that in 80% of 
> cases the mass and forces will be within a very narrow range.  
> Compared to say a CNC machine carving a cubic foot of wood then a cubic 
> foot of steel.
>
> I have read [1]-[8] and have three questions.  
> From [1]-[8] I can't see that the pull-in/pull-out envelope (or slew 
> range) is identified for a stepper motor. Nor does it appear that inputs 
> are sought that would allow them to be guesstimated.  
>
> Q1) Am I wrong (and there is a set of approximations used to define the 
> slew range given the inputs sought)?
>
> AFAICT:
> a) the trajectory planner might be working with a single point on the 
> pull-out curve of a motor, so you can expect the TP to try change direction 
> in the slew-range of a stepper motor.
> b) The TP does not consider/use the stop-start range where direction can 
> be reversed without deceleration.
>
> Q2) Which of the above possibilities is applicable?
>
> Q3) Is there a way to ensure that an end user cannot get the trajectory 
> planner to violate a stepper motors specs?  
> I suppose these settings would have to be a compiled, or set by privileged 
> user access, and can't be overridden by a configure file settings.
>
> Thanks again for all the effort that has gone into MachineKit
>
> Best wishes 
> Hedgehog
>
> [1]: http://www.machinekit.io/docs/quickstart/stepper_quickstart/
> [2]: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Stepper_Formulas
> [3]: 
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Stepper_Motor_Speed_Limitations
> [4]: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Mechanical_Spreadsheet
> [5]: http://www.soundproofingforum.co.uk/halitosis/
> [6]*: http://www.machinekit.io/docs/config/stepconf/
> [7]: http://www.machinekit.io/docs/common/Stepper_Diagnostics/
> [8]: http://www.machinekit.io/docs/motion/tweaking_steppers/
>
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.