Hi Gregory, Am 01.02.2013 um 22:45 schrieb Gregory Perry: >> If you understand the latency issues, then by all means port whatever >> you can to the PRU. The example code I pointed to earlier is >> basically a PRU replacement for the software stepgen or something like >> a Mesa card to generate the step/dir pulses, and requires LinuxCNC to >> be running with 'reasonable' latencies, essentially requiring >> PREEMPT_RT, Xenomai, or something similar. >> >> If you pull more functionality into the PRU, however, you could get by >> with worse latency performance on the Linux/ARM side. >> >> Good Luck! >> >> - -- >> Charles Steinkuehler >> char...@steinkuehler.net > > Can LinuxCNC run as a simple userland process which talks to a hardware servo > controller (such as the Mesa card you mention)? Or maybe more to the point, > is there a standard API with LinuxCNC that will treat a servo control board > as a simple device that it outputs gcode to? I am thinking this is where the > Python/PRU interfacing would come into play, in other words LinuxCNC would > treat Python/PRU as the equivalent of a hardware servo control card? I don't > think that would be very hard to implement at all, the majority of the > complexity with the PRU to date has been the PRU assembly language but if the > PRUs can be flashed with firmware from Python (which now it can) then adding > gcode translation to that process shouldn't be that complex.
I think one needs to look at what you're trying to optimize, and what the costs and benefits are. The upside of the current motion/HAL/RTAPI approach of doing everything in software is its very elegant configurability through the halcmd language, and it is also reasonably portable across platforms, if we disregard the RT kernel issue for now. There is a downside as certain parts of motion/HAL/RTAPI which relate to path quality might benefit from having more precise timing of execution. There are around 120 components altogether, but if only the following are really worth considering doing something about in the above 'precise timing' context. I might have overlooked one or the other, but in the minimum these are: - the software stepper generator, stepgen. That issue is addressed by Charles & Bas' work, and covers stepper configs only. - quadrature encoders - the PID components are sensitive to jitter. - certain parts of the rather large motion component are sensitive to jitter, by no means all of it. Now that's 5 out of 120, which doesnt suggest moving all of those to some manufacturer dependent platform, given that 115 components will not benefit significantly; plus - you might loose out on the 'portability' and 'configurability' dimensions. So it is advisably to carry over to hardware/manufacturer dependent elements only the very minimum needed which actually benefit from doing so. That's what Charles does with his hal_pru component - a minimum impact component replacement for stepgen. But assume you take on improving the abovementioned components through hardware support X, say the PRU. First, note the PRU is an _integer only_ cpu. That means it is a good match for the stepgen problem, which is integer in the time-critical code path. Unfortunately, the PID and relevant parts of motion involve FP operations. Doing that through software FP emulation defeats the very purpose, and it is unclear whether that fits into 12Kwords of code space; besides, the indeterministic timing of some emulated FP operations will reintroduce jitter. From a programming perspective, the PRU is not much more than an 32bit/200Mhz Arduino, and it suffers from the same problems. Quadrature encoders are at the core an integer-CPU solvable problem, certain parts like speed estimation do require FP. If one were to improve motion timing, there are approaches to do it - Yishin might want to comment here - but it might require an FPGA with FP or at least fixed point arithmetic, or a DSP; the latter approach is taken by some commercial motion controller manufacturers like Delta Tau (see note below). Doable: yes, but at a cost - extra dependencies on hardware and supporting software, plus likely less configuration flexibility. There is also some structural work to be done on motion to actually make that possible. So given the above, with an integer CPU you're likely only to improve stepper configs without PID loops; the encoder alone is only half the story. Note that improving resilience of components against jitter might have more than one solution, moving to hardware with more deterministic timing behavior being one. Another option is to make the existing code to deal better with adverse timing; that is not generally possible, but a low-effort improvement on some parts of the code is doable without getting into hardware dependencies altogether. as for the Python PRU component - all it does is 'pythonify' the current C level interface between a user process and the PRU like loading, starting and stopping, and that hasnt been a challenge so far; if you read Charles' component you'll find that that part is negligable effort in the overall context. So it might help on lowering the bar for experimenting with the PRU but it wont help solving the underlying issues. - Michael -- this short paper gives a good overview of numeric requirements for motion controllers: http://www.deltatau.com/Common/support/whitepapers/High-Precision%20Controls.pdf > > I apologize in advance if these are newbie questions, I don't have any > familiarity with LinuxCNC but I've been following the EMC/BeagleBone/Xenomai > integration effort for a while now. > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
