Michael, I just tried to give you what was asked for. You can reexpress it however seems most clear to you or your users. What I was getting at is that the answer depends on your give setup, but if you give me a couple of specs of your hardware then I can give you some guidance. I picked the g540 because it is a give piece of equiptment that some people use. You could just as well write up the same ting for the Mesa hardware, etc. Expressing it in terms of % or raw numbers is fundamentally the same -- for a given spec and use you need a jitter no worse than JERR. You can generate such a table give the original specs.
On May 6 2013 12:24 PM, Michael Haberler wrote: > EBo, > > > Am 06.05.2013 um 19:44 schrieb EBo <[email protected]>: > >> On May 6 2013 8:06 AM, Kent A. Reed wrote: >>> On 5/6/2013 9:16 AM, Lars Segerlund wrote: >>>> check the data on osadl.org ... with RT-Preempt you should be >>>> able >>>> to >>>> get worstcase jitters of less than 50 us ... or you have a 'bad' >>>> system / bad drivers. >>>> >>>> With a 'good' RT-Preempt system you get < 20 us as worstcase. >>>> >>>> osadl is good since they are really hammering the systems while >>>> measuring. >>>> >>>> / regards, Lars Segerlund. >>>> >>> >>> Lars: >>> >>> I'm not looking to open a discussion about the definition of jitter >>> and >>> the appropriate methodology for measuring it (we've had some of >>> those >>> in >>> the past on this list, and some of us are quite familiar with >>> OSADL). >>> >>> What I'm looking for is better guidance to our CNC users, most of >>> whom >>> find the details about latency as understandable as details about >>> the >>> fuel-injection algorithm used in their car's computer. What we have >>> seen >>> in the time I've been reading the emc2- lists amounts to constant >>> schoolyard taunting, "my latency is better than your latency." Look >>> how >>> excited we get when the latest Atom board yields 1us lower or >>> higher >>> jitter results than another. If the better guidance includes >>> pointing >>> to >>> the OSADL as another source of data (along with suggestions on how >>> to >>> interpret those data) so much the better for the folks who wish to >>> use >>> RT-PREEMPT enabled kernels (and my thanks to those on this list who >>> have >>> been making it possible for the average user to even consider using >>> them). >> >> Kent, >> >> What I would like to see, and will help generate as my limited time >> allows, generate some basic formulas to help guide people. This is >> off >> the top of my head, and is likely wrong given that I am spacey as >> hell >> with allergies... >> >> max_pulse_rate (in Hz) = 1.0 /(maxjitter * Const) > > from a user perspective I think measures like latency or perceived > maximum pulse rates are useless as guidance, for the simple reason > that they do not express what a user might be interested in, but > happen to be some low-level number which happens to be measurable > easily > > what _I_ would be interested in isnt what happens to be easily > measurable, but what a given setup can do for me > > for example: > > given a configuration, what is the quality of tracking the commanded > path, and the speed/speed deviation at which that can be done > > tracking quality (I just made that term up) might translate into > either a maximum path deviation (hard limit), or a distribution with > percentiles plus a boundary > > this probably has both a spatial and a temporal dimension > > example for spacial accuracy: for test path X, results are within A > uM 95% of the time with a maximum deviation of B uM > > I admit this probably cant be expressed as easily - I'm lacking > theory and literature know how here but I would bet there is actually > work in the area (or in related weapons or rocket research ;) > > maybe even there is a way to compute such values on the fly and > mirror them in (a) pin(s); again that is blue sky and pure > speculation > > > from that perspective, messages like 'unexpected realtime delay' are > about as useful as dashboard message in my car saying 'cylinder #3 > took 0.7mS too long to fire': > > very interesting detail, now what bearing has that on my goals - do I > need to stop, can I continue driving or will I bump into another car? > > --- > > at times it might be useful to lean back and ask yourself: does this > make sense or can we do better than that > > - Michael > > >> >> where Const is probably something from 3 to 10 and denotes some >> fraction of base time period that you can put up with the jitter. >> Knowing how fast you can run the stepgen thread (assuming stepgen) >> will >> then allow you to calculate your max speed using a given piece of >> mechanics/electronics/etc. For example, if you are using something >> like >> the Gecko G540, and motors that can do just over 300RPM, and >> typically >> have 200 steps/rev. We know that the G540 is hard-wired to 10 >> microsteps/step. So, we have 300*200*10 maximum steps/rev that the >> motors can do, and 10KHz for the step/sec. So if we back calculate >> that, we are talking 100us for the max step rate, and you want your >> jitter to be a very small portion of that (for argument lets say 1/5 >> or >> <20%). So, if we have a latency of <20us we can easily keep up with >> the >> G540. If I am not mistaken, the latest RT_PREEMPT is able to do >> that on >> all my hardware. Not sure about yours. >> >> Sometime back I remember reading a paper that looked at the %jitter >> to >> duty-cycle and the overall effect on power loss. I do not have an >> intuitive feel for that or what implies for the current discussion >> but >> this is a start. I am sure that others will tare this apart but so >> be >> it. This is intended to start a reasoned discussion on spec'ing the >> max >> speed of a setup given the jitter and other considerations. >> >> EBo -- >> >> >> ------------------------------------------------------------------------------ >> Introducing AppDynamics Lite, a free troubleshooting tool for >> Java/.NET >> Get 100% visibility into your production application - at no cost. >> Code-level diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
