Re: stepper pulse rate idea

[jmkasunich-at-ra.rockwell.com]

Ray wrote:

> Those of you who have applied the EMC to steppers that run
> from the parport know that you have to design into the machine
> a compromise between speed and resolution.

> This compromise is fixed in part by Jon's PPMC stepper rate
> generator card.

Or any other external hardware rate generator.  This is my
preferred approach.

> I'm thinking here of a direct parport driven system.

> What I'd like you to think about is a two scale pulse train
> for each axis.

> 1 - Software

I'm not qualified to address this, although my immediate thought is
that it would be ugly.

> 2 - Hardware

> I spoke with Mariss at Geckodrive this morning about applying
> this notion to his step and direction servo with the pulse
> multiplier card (G340).  His initial response was, "don't
> even go there."

> I suspect that pretty well matches the initial thinking of
> most the readers of this post.

Yep!  ;-)  though it's not out of the question.

I don't like the idea of putting the gearshifter into the drive.
That immediately limits the usefullness of the idea to those
drive manufacturers who are willing to implement it.

> Or we could simply build a small pulse multiplier card that
> would do the work somewhere between the PC's parport and
> whatever step and direction device we have out there.

This is much better, since you could continue to use any
step/direction drive.

> Matt would be incined to build one of these into one end of
> a parport cable or one of those little Radio Shack db25
> jumper boxes.

The problem with that is that there is no +5V on the parallel
port.  You would need an external supply or a very creative
design.

You would also have to come up with an additional parallel
port pin for the gearshift command, resulting in three pins
per axis instead of two.

> 3 - Value ( your chance to vote or express your thoughts)
>
> 3 - a  Do you see any value to such an approach to expanding
> the range of stepper speeds that the emc can reach?

Expanding EMC's speed range is certainly a good thing.
I'm not so sure about this approach...  ;-)

> 3 - b  Assuming that we can accomplish the hardware side
> of this in one of several ways, would it be worth doing on
> the software side?

I don't know how hard the software side would be.

> 3 - c  Ray needs to reduce his caffeine intake?

Not neccessarily - new ideas are good.

John Kasunich