2013/4/21 Michael Haberler <mai...@mah.priv.at<https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&to=mai...@mah.priv.at> >
> > Sure, this is one point. And another point is low latency > > yes > > > (you say 200kHz > > step rate) > > yes, but that has nothing to do with each other in case of the PRU: > latency is the jitter introduced by the host operating system - xenomai in > that case > > the step rate is determined by the clock frequency of the PRU (200Mhz) and > the code path execution time between 'stepgen cycles' _in the PRU_; the PRU > stepper jitter is likely negligible because the PRU lacks a cache or other > bells and whistles like virtual memory which make timing less > deterministic. The techref manual actually says 'Cache: none > (intentionally)' meaning: low jitter was more important than more MIPS > during design. > > conceptually that is exactly the same as say a Mesanet card clock and its > jitter (not relevant) has anything to do with Linux thread jitter (relevant) > > > could help increase servo frequency to say 10KHz. > > You can try, but these are unrelated concepts. What will be limiting here is the code path execution time of all the > components executed in a servo cycle. That's exactly what I meant. A lot of calculations for CPU during a servo cycle: trajectory, kinematics, PID etc. But I did not figure out that it also has PRU so it's just like PC and MESA card on one board. And I thought that ARM Linux jitter is negligible, but it's proved not. Negligible is RPU's jitter. > Or ARM CPU is > > not enough for that servo frequency? Though, 4-core 2GHz ARMs already > > released... > > This could help with floating point 'umph', but not necessarily with Linux > thread jitter. Absolutely. Could rather make it worse with powersaving features. > >> Again, how do you estimate max servo frequency for ARM platform, > precisely > > BeagleBone? And what if some weird kinematics like Stewart platform > should > > be computed? > > As above: go measure, everthing else is sorta-kinda and conjecture. It's > all there - set it up, read the halcmd manual, take timings, make sense of > them. Then you'll know if the platform is good enough for the purpose or > not. > > That in fact could be determined without actually driving any hardware > with a sim-like config; that wont give you timings for the hardware I/O > times but I'm fairly sure those dont break the camel's back. Motion, Pid > maybe; a high-rate base thread causes overhead; eg when using software > encoders. > > I'll definitely try that when I get hold of the board and install LinuxCNC. Andrew ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
