Some background on the "hunting" behavior of the dir line. It goes back to the implementation of the step generator. This applies specifically to the software step generator, but some of the FPGA based ones and perhaps the BBB PRU one use the same core algorithm and have the same behavior.
Everything in the base thread of the step generator is based on integers. The way that the step generator works is that it has a fairly wide (32 to 48 bits) "position accumulator". For example purposes, I'm going to pretend that it is a 9 digit wide decimal number - it can run from 0 to 999,999,999, then it rolls over back to zero. Every base period, the code adds a number to this position accumulator. The number is directly proportional to the desired step frequency. For my example, I'm going to pretend that the base period is 100uS, which means the addition happens 10,000 times per second. If I want a frequency of 1 step per second, I can add 1 every time. Since I'm adding 10,000 times per second, the accumulator will increase by 10,000 every second. But I only want one step per second. So the code generates a step only when the 5th digit of the accumulator changes. So when the accumulator rolls over from 9,999 to 10,000, it makes a step. It makes another step when it rolls from 19,999 to 20,000, and when it goes from 29,999 to 30,000. If the axis is moving the other way, it adds -1 every time, and generates a reverse step when it rolls from 30,000 down to 29,999, etc. If I want to generate 3827 steps per second, I simply add 3827 to the accumulator every 1/10000th of a second. It will count something like: 0 3827 7654 11481 <-- fifth digit changed, make a step 15208 19125 22962 <-- fifth digit changed, make a step 26789 30616 <-- fifth digit changed, make a step In that example, you can see that sometimes it steps after three base periods (300uS) and sometimes after only two (200uS). The desired period is actually 261.3uS (1/3827), but this algorithm will jump back and forth between 200uS and 300uS such that the average is exactly what we want. Basically, the position accumulator is split into two parts. The lower digits count fractions of a step (1/10,000s of a step in my example), and the higher digits count whole steps. The entire accumulator is used to close the position loop, so you can command a position that is between steps and the loop can still be satisfied. But depending on tuning, it might be hunting back and forth by a very small fraction of a step - maybe 1/100th of a step. As the position loop fiddles with the velocity to try to get to the exact position (down to 1/10000th of a step), it will hunt back and forth, changing the velocity from a small negative value to positive and back. In some versions of the step generator, the direction bit comes straight from the sign of the velocity command, so it will change too. I think that the software step generator was tweaked a long time ago so that it doesn't change the direction bit unless it actually needs to because it is about to roll over and generate a real step. But it's been a long time and I'm not sure. I also have no idea if the FPGA based step generators (or the BBB PRU step generator) can do the same thing. John Kasunich (I wrote the original HAL software step generator) On Sat, Feb 22, 2014, at 01:08 PM, Mark Tucker wrote: > John > > I don't suppose you are using Gecko's? > As Jeff mentioned earlier it seems like a Gecko driver does not like the > Dir line wiggled about in that fashion. > Why it should make a noise beats me,but i can assure everyone that the > drives are running without these noises on a pc setup and have been for > many years. > Also if the machine comes to a halt and the motor hunts because it is > not in the exact position ie 1/2 step out,The step line would also be > stepping to adjust the position. > Or am i not grasping this? > > On 22/02/14 17:11, John Prentice (FS) wrote: > > Jumping in - I have had this with the MachineKit. No noise but as I had the > > 'scope on the signals I spotted the fidgeting Dir. I had no pulses on Step > > line, just Dir hunting. I was worried that it might stop the stepper drivers > > going to reduced current mode but with the ones I was using this was OK. > > > > Best wishes > > > > John Prentice > > > > -----Original Message----- > > From: Stephen Dubovsky [mailto:[email protected]] > > Sent: 22 February 2014 16:33 > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] Crackling motors using Beaglebone > > > > Are steps also being generated (back and forth) or is just the direction > > line toggling (w/ no steps)? > > > > > > On Sat, Feb 22, 2014 at 10:56 AM, Mark Tucker <[email protected]> wrote: > > > >> I seem to remember there being a fix for this around v2.3 or something > >> to stop the stepper motors hunting.which i assume must have been a > >> parameter to set the tolerance for acceptable position. > >> Does this not apply when using hardware generated pulses? > >> I will have to leave the beaglebone on the bench until charles has > >> time to sort this one out. > >> I don't think it is doing any damage but it really does sound awful. > >> > > > > ------------------------------------------------------------------------------ > > Managing the Performance of Cloud-Based Applications > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > > _______________________________________________ > > Emc-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users -- John Kasunich [email protected] ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
