On Tuesday 26 February 2019 06:43:29 [email protected] wrote:

> hi again,
>
> > I think you are looking for 'double step'
> > This idea is a single edge trigger
> >    ___     ___
> > __|     or    |___
> >
> > the trigger creates a complete step
> >   ___
> > __|  |___
>
> I've tried it with a reset-function inside my
> component - but what sounds like a good idea, does not
> solve the problem:
>
> Yes, I can get very short "high-tick" outside the
> timing limits of the runtime.
> but I also get a square instead of only a rising or
> falling edge.
>
> I found no way to tell the stepgen.c
> (without making changes inside the stepgen-source):
>
> "do not care about any timings or the pin-state. if a
> motor step is needed, just toggle the level of the pin"
>
> this is only one data-telegram via ethernet.
> but a rising and falling edge together need two
> complete packets - 2 data telegrams.
>
> this is wasted time, when the receiver is able to
> interpret every edge as a motorstep himself...
>
>
> now I use this
>
>             if ( stepgen->timer1 != 0 ) {
>                  if (*(stepgen->phase[STEP_PIN]) ==1){
>                          *(stepgen->phase[STEP_PIN])=0;
>                 }else{
>                          *(stepgen->phase[STEP_PIN])=1;
>                 }
>
> instead of this
>
>             if ( stepgen->timer1 != 0 ) {
>                  *(stepgen->phase[STEP_PIN]) = 1;
>             } else {
>                  *(stepgen->phase[STEP_PIN]) = 0;
>             }
>
> in stepgen.c - and I get a square-wave
>
>
> do you see any other way to get this result?
> without changes in stepgen.c ?
>
>
> wicki
>
Most motor drivers I have dealt with, actually step only on the rising 
edge, or the falling edge, so there is zero response to the reset edge.

What its doing, is doubling the rate at which you can issue the steps 
because you can issue a new step per base thread occurrence.

For instance, I am in the process of using all my older 2M542 motor 
drivers on a new 6040 gantry mill. Mainly because the electronics 
supplied are crap and incapable of doing a good job.

With the original computer that drove an elderly HF mill now driving this 
mill over its parport, I find I can move all 3 linear axis's at speeds 
in excess of 100 ipm, nominally 10x faster than I could move the old HF. 
But I'm building an active interface box anyway because I need more i/o 
lines for home & limit switches etc.

I would not be entirely surprised to see 200 ipm when I've got it all 
wired up.

The main speed limit for driving steppers is a step per base thread. With 
a 25 u-second base thread, thats 40,000 steps a second. Well within the 
range of driving a stepper being microstepped, but not always practical 
due to the extreme speed changes needed to get to those speeds. Haveing 
half a megahertz available means the individual speed changes to get to 
that speed are much much easier for the motor to follow, meaning that 
you can move it faster without stalls.  But it really impressed me when 
I hit 120 ipm thru the parport without stalling a motor.

What is it you are trying to do that can't be done already?

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)
Genes Web page <http://geneslinuxbox.net:6309/gene>



_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to