On 25 June 2010 10:18, Alexey Starikovskiy <[email protected]> wrote:
Firstly, many thanks for looking at my module. > You use C from previous call in case of dx=0 and dy=0. > It could be anything and could move you anywhere. That is intentional. "C" represents the direction that the cutting head is moving in, and should hold its value if the axis stops. I might add code at a later point that limits the speed that C can swing at and enforces a cw/ccw direction, but for the moment it seems to work. Mathematically the module works exactly as expected and desired in a "sim" configuration, it is only when running on a "live" RTAI installation that problems occur, and the problems seem to be separate from the kinematics mathematics. No matter how wrong my calculations are, I don't understand why stepgen.0.position-fb increases every time the forwards kinematics function runs, even though there is no signal connected to its input. Then, when I remove line 53 (which refers to a C-axis which is not connected to any stepgen at all in the HAL) the problem goes away. I am almost tempted to add another stepgen and just not use stepgen.0, but that would only solve one of the problems. Something in my module appears to be writing "out of bounds" into the memory occupied by the stepgen. Also, though I have not managed to track down where yet, valid numerical values from my module are giving NaN values in downstream calculations Something I haven't tried yet is changing the order in which functions are declared and added to threads in the HAL file (and, in fact, I didn't write the HAL file) -- atp ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
