>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 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
