On 12/08/13 11:12, andy pugh wrote: > On 8 December 2013 17:06, Charles Steinkuehler <char...@steinkuehler.net> > wrote: > >> I'll add the processing to the kinematics if I need to, but it seems >> like it should really be in the gcode processor. > > I disagree. G-code works in idealised cartesian space, and the output > should be idealised cartesian too.
Then why, exactly, are there all the various coordinate offsets (including rotation around Z) already available? :) > Have you seen: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ProbeKins Yes, that's how I'll do it if there's nothing in existing gcode to support tilting, but I'd still rather run a 3D rotation in a user-space thread vs. tying up cycles in a real-time thread. Also, the math only needs to happen on the endpoints, not every mS as the machine is moving along the commanded path. The BeagleBone has hard floating point, but does not directly support complex trig functions. Even on an x86, doing a tilt in kinematics is needlessly increasing the computation overhead and pushing stuff into the realtime threads that doesn't need to be there. Note that probekins *DOES* need to do it's job in the realtime thread, since it's not doing a simple transform but compensating for errors along the path of the move. I have no problem with that, it's just overkill for what I'm trying to do, and I'm simply surprised a simple 3D transform is apparently beyond was provided for in the gcode language. :-/ -- Charles ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
