On Sun, 18 Oct 2009, Peter C. Wallace wrote: > Date: Sun, 18 Oct 2009 20:11:36 -0700 (PDT) > From: Peter C. Wallace <p...@mesanet.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 > > 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. >
Stepgenerator hardware (rev 2) tests OK. A requested step rate that is higher than 1/(steplen+stepspace) results in a actual steprate of 1/(stepspace+steplen), regardless of step direction. I have a frequency counter module I could add to HM2 if needed for calibration. That would fix PCI clock within about .01% (I wish I had not used PCI clock as the interface bus clock on the 5I20 and 4I65 as its quite variable between machines) I guess you could also just run the stepgenerator (before the outputs are enabled) and time it for a second or so to get a close idea of the PCI clock frequency. > > >> >> 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 > 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
