> Date: Tue, 13 Oct 2009 20:56:23 -0600
> From: [email protected]
> To: [email protected]
> Subject: Re: [Emc-developers] hostmot2 stepping folowing error oddity
>
> Chris Morley wrote:
> > > Chris: can you try setting max_velocity to .8 so theres no chance the
> > > trajectory planner can outrun the stepgenerator? I think all bets are
> > off
> > > without this.
> > >
> >
> > I will try this later hopefully tonight.
> > Interestingly the reason I was using 100 inches per minute (1.667 ips)...
> > Pncconf has a 'tune test' that sets the hostmot2 stepgen's
> > max velocity and max acceleration. It would let me move at
> > aprox 150 inches per minute. It does not keep track of following error
> > though. So I detuned it to 100 ipm and ran EMC. I'm not sure how
> > hostmot2's stepgens decide on whether it can or cannot move at a
> > specific drive timings and max speed etc.
I switched to the .8 max velocity. It still errors.
It is still magnitudes worse in the negative direction.
I didn't have time to make scope screenshots nor
test very much. I can tomorrow if you would like.
>
> I take this to mean that your "tune test" changes hm2
> stepgen.position-cmd at a rate of 150 ipm without checking if
> position-fb if keeping up. I think if you check, you'll find
> position-fb moving at only 53.6 ipm (0.893 ips as derived earlier),
> because that's the fastest your timings (and leadscrew pitch) allow it
> to go.
I checked again. With pncconf tune test - Yes 53 ipm (.89 ips) is the
max speed it moves
So there is one problem solved!
>
> There are two things that affect what the hm2 stepgen max speed is. The
> first is the four timing parameters, which provides a kind of physical
> max, an absolute upper bound on the frequency of the output signal. The
> other is the .maxvel parameter, which may optionally specify a more
> restrictive limit. The hal file you posted has .maxvel set to 0, which
> is the secret handshake for "go as fast as the timing parameters allow".
>
>
> > But all that aside I still don't see why moving negative and positive
> > is so dramatically different - but then again I know nothing about
> > stepgenning and trajectory planning :)
>
> I think Jeff's analysis of the firmware source code can explain a big
> difference.
>
> When the hm2 stepgen is stopped (when position_cmd = position_fb), it
> relaxes to Dir being zero. If the first step is in the Dir=0 direction
> (positive on your machine, i think), it can step right away. But if the
> first step is in the Dir=1 direction, it has to switch the Dir line
> before it can take the first step. Your .ini file specifies a 200
> microsecond delay every time the Direction pin changes, before starting
> stepping.
>
> So if it's starting from a stand-still, and going in the negative
> (Dir=1) direction, then it falls 200 microseconds behind the trajectory
> planner before it even starts moving. Then, since the TP runs away from
> the stepgen in this config (it's allowed to move faster than the stepgen
> is), stepgen never catches up, and it ferrors.
>
>
Watching the direction relay's LED Jeff of course is right, after moving in the
negative direction it indeed does switch the direction back to forward.
So it will always have to wait the direction changing time, bummer :)
I am still not convinced this is the total problem but probably contributes.
While jogging at 25 ipm (well under the 53 max) it still seems to have problem
catching up. so even if initially it got behind there is plenty of head room to
catch up.
I also changed dir setup and dir hold to 200 nano seconds each and the
negative direction still looks way bad to me.
See if EMC had only follow errored on rapid (or fast jog), I probably
would have just lowered the max velocity/acc. And not noticed the
asymetrical movement.
It was the fact that during slow homing (aprox 3 ipm) and slow jogging
that it follow errored too. (Homing is in the negative direction.)
Of course on a real machine I would not have the slow optos so the
drive timing would be more normal and I probably wouldn't have noticed
any problems.
Chris M
_________________________________________________________________
Click less, chat more: Messenger on MSN.ca
http://go.microsoft.com/?linkid=9677404------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
