Good people, I was maybe a bit snappy last night, as I came just out of one of those african music and drama things that take all of you (I participated)
Off course the cnclinux group has discovered some excellent boards over time. And off course the RTAI modified kernel is probably the fastest around. All that is a no issue issue, really. But to compare OSADL numbers and your home grown numbers is quite wrong i think. We do well to take note of OSADL's results because they run boards for weeks, not hours. If you look at those graphs properly, they say that there are perhaps 10.000.000 results in the range we normally detect, and one some laugheable value like 40usecs. One reason for that is the cpu load they apply, which is quite different from a normal cnc controller load. Another reason is genuine hardware latencies that show up only once in a while. And yet another reason is that they run a vanilla kernel, perhaps with some small patches that will become part of the main kernel in due time. And then simply a combination of all those reasons interfering with each other. So why am I so chaffed by OSADL? Because ultimately LinuxCNC would not be dependent anymore on a oneman show or a rather small group that produces the kernel patches, but rather we would only have one dependency which would be Linus' Kernel group. IF and WHEN the software can handle the mainline kernel RT effort, I personally would change earlier rather than later. As an example: the whole Beagle board saga that Jon went through would not have happened if at the time the vanilla kernel would have been more RT aware, and the RTAPI would have been vanilla kernel aware. He could have just built a kernel for his Beagle board! Further the Proview PLC group has been running their software for quite a while already on OSADL patches without any problems. And they did extensive tests. They do not have a software stepper module though But a servo thread at 1 msec is no a problem at all, all bloated C++ code with lots of maths. And that was with 2.6.xx kernels. I have not looked properly yet at the new 3 series. I hope this clarifies my position in the 'jitter' debate. For steppers I like Viesturs solution with harware step generation, but that is a whole new debate that revolves about $$ rather then technicalities. And I feel very strongly that the group as a whole cannot do without those that manage to cut corners (money wise) around every bend. It brings in lots of fresh thinking! j. On Sat, Mar 31, 2012 at 7:52 AM, gene heskett <[email protected]> wrote: > On Saturday, March 31, 2012 01:44:21 AM Jon Elson did opine: > > > Jan de Kruyf wrote: > > > Do you get those errors with servos Gene? or with steppers! > > > > > > I am interested, since Jon was praising that board so much. > > > > > >> But I am encountering following errors after the motor has reached > > >> speed and moved a good distance at that speed, but don't know what > > >> to adjust that affects that. > > > > This is caused by requesting a greater pulse rate than the base thread > > can put out. One possible cause is if the pulse width setting is > > made too large. You want this set correctly for the motor drive, > > but not any larger. Then, figure out at what feedrate the error shows > > up. Say that is 50 IPM. And, for example, say it takes 30,000 > > steps to move one inch. (50 IPM / 60) X 30,000 = 25000 steps/second. > > Now, assuming you are using the best step generator scheme which > > times the pulse width, if your base thread was greater than 40 us > > (40,000 ns) then you can't go that fast. Or, if you set the step pulse > > width to 20 us, then you can't go that fast. (50% hi, 50% low, of > > 20us each adds up to 40 us. > > > > So, just do the calc, and see what time is 1/step pulse rate, and then > > compare to your base thread time. Your base thread really needs to > > be MUCH higher than the fastest step pulse rate, due to the granularity. > > > > If the machine were running at a speed where every other base thread > > cycle produced a step pulse, then the next higher speed would require > > a step pulse EVERY base thread cycle, which is a 100% speed jump. > > LinuxCNC can certainly send pulses at that rate, but that is too > > large a speed jump for the motor to follow. > > > > > > Jon > > ATM, I am waiting on connectors that will allow me to make much shorter > parport cables so I can experiment with narrower pulses. A 6 foot, round > cable has got to ring like the liberty bell so I hadn't tired shorter > pulses. > > ATM pulse widths are set to 3 u-s, as is dir setup and dir hold. 20 u-s > base thread on a D525MW board. I'm hitting the errors at 39-40 ipm. I am > beginning to think I should tolerate the noise and go back to 8 microsteps > to get the higher speed. I expect I'll have to make a damper for the z > motor in that event. > > Thanks Jon. > > Cheers, Gene > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > My web page: <http://coyoteden.dyndns-free.com:85/gene> > HEAD CRASH!! FILES LOST!! > Details at 11. > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
