On 4/22/2012 11:07 AM, Michael Haberler wrote: > gents, you are busily inventing path queueing mechanism number 3. The > existing ones are: CRC offset curve aka queued_canon, and NCD aka > chained_points. Michael:
I'm trying to get up to speed on the issues discussed in this thread. Not being an aficionado of the LinuxCNC code base, I have to assume that here "NCD" means naive CAM detector. To me, "CRC" means cyclic redundancy check. I see comments in the code base that suggest a CRC computed in some manner is used to detect when a change occurs in "the queue" but I'm don't understand the cause or the consequence. If this mechanism is discussed in some foundational document I'd like to get a reference. In the User Concepts document, we discuss P61 "exact path mode", P64 "blend without tolerance mode", and P64 P- Q- "blend with tolerance mode". I always associated "NCD" with blend with tolerance. Does "CRC" refer to blend without tolerance? As for the rest of your discussion regarding a single path history mechanism, "lay on MacDuff!" I hope to see an ongoing conversation. To my ears, you make a compelling argument, but it sounds like a major disruption to the existing code base (e.g., rightfully something for LinuxCNC3) and I have no idea how hard it would be to pull off, e.g., to code and to test. Regards, Kent ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
