On Sun, 18 Oct 2009, Sebastian Kuzminsky wrote: > Date: Sun, 18 Oct 2009 20:47:32 -0600 > From: Sebastian Kuzminsky <s...@highlab.com> > Reply-To: EMC developers <emc-developers@lists.sourceforge.net> > To: EMC developers <emc-developers@lists.sourceforge.net> > Subject: Re: [Emc-developers] hostmot2 stepping folowing error oddity > > Sebastian Kuzminsky wrote: >> So... If the human asks for (for example) 1 microsecond >> StepLen+StepSpace, and the driver thinks the stepgen clock runs at >> 33,000,000 ticks/second, then it's going to ask for 33 ticks. But if >> the stepgen clock in reality runs at 30 MHz, then those 33 ticks will >> take 1.1 microseconds, and the max step rate will be 10% less than what >> everyone thinks. The human diligently computes the axis MAX_VELOCITY >> based on the 33 MHz stepgen clock, then gets ferrors when the actual >> setpgen clock is slower than that. > > Replying to myself here... > > When the driver asks the firmware for a step rate that is higher than > the firmware's timing parameters allow it to deliver, the firmware > "stalls" or "throttles" the step generator, pausing step output until > timing requirements have been satisfied. > > I'm wondering... When this happens, does the Dir pin see the stall? > Specifically, if i've commanded a very large negative step rate and the > firmware throttles the output to comply with timing parameters, does the > Dir pin see the internal velocity go to 0 (necessitating a DirSetup > pause), then go back to 1 again when the timing constraint has been met > (necessitating another pause)?
No, a stall just "freezes" the position accumulator (Stops adding). There is a potential race condition if the servo rate is faster than the dir setup or hold times, that is if direction is changed before the setup or hold is timed out from the last direction change stepper timing can be violated. This is very unusual timing and unlikely to be run into with real systems but its possible. I dont know if this is the problem with cmorleys system, but one possibility in the VHDL is that I've muffed something with running at programmed velocities greater than 1/(steplen+stepspace) in the negative direction. The step rate is just supposed to be bounded at 1/(steplen+stepspace) if this is done. This (possible) bug might interact with the "inexact clock" problem to generate the wildly assymetric behaviour cmorley has seen. I'll check this tommorow. > > I dont know VHDL well enough to just look up the answer for myself in > the source... > > > -- > Sebastian Kuzminsky > the sky calls to us -- carl sagan > <http://www.youtube.com/watch?v=zSgiXGELjbc> > > ------------------------------------------------------------------------------ > 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 > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. ------------------------------------------------------------------------------ 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 Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
