Am 21.04.2013 um 20:04 schrieb Andrew <parallel.kinemat...@gmail.com>:
> 2013/4/21 Michael Haberler <mai...@mah.priv.at> > >> >> Am 21.04.2013 um 17:19 schrieb Andrew <parallel.kinemat...@gmail.com>: >> >>> Michael, Kent, thanks for your help! >>> It's a pity that I'm not quite a Linux guy. But when the black BeagleBone >>> appears I'll hopefully try to figure it out. >> >> We'll have a ready-to-go SD card image with xenomai, all prerequisite >> packages and linuxcnc installed in a week or two; that will include >> Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should reduce >> the guru requirements to get things going >> > > That is absolutely great! > > most of the work on that platform concentrated on steppers so far because >> being on the low end this looked like the likely use case >> > > 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. Halcmd gives you timings for those - go measure ;) Actually publishing results on the wiki would be a great idea. > 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. We'll see. >> "DAC" really boils down to PWM output >> > > Sure, PWM output just needs a simple +-10V converter. > > again the linuxcnc stock components like pwmgen are included, and for servo >> their speed should be sufficient >> >> 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. - Michael ------------------------------------------------------------------------------ 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
