On Mon, Jan 9, 2017, at 08:19 AM, Les Newell wrote: > I have an application where I need to send jog commands at a high rate > (anything up to 30 updates/second on two axes). Basically the machine > needs to chase a moving target. Using sendJogCont with emcWaitType set > to EMC_WAIT_RECEIVED takes over 100ms per axis which is way to slow. If > I set emcWaitType to 1 (undocumented use of emcWaitType ) sendJogCont > returns virtually immediately. I understand that doing this means that I > have no way of knowing if the jog command has actually been executed but > in this application an occasional missed command won't make a huge > amount of difference. Is there a limit to how fast I can send commands? > Presumably there is a buffer somewhere that is going to fill up if I > send more data than the realtime side can consume. Are there any other > likely issues with doing this? >
Are you sure that sending jogs is the right way to do the application? Is this a "normal", g-code controlled machine that sometimes needs to do this "chase a moving target" thing? Or is it a special machine that only does the chasing thing? If the latter, you probably don't need a large part of LinuxCNC, including NML, and can probably do all or most of the application using real-time modules such as limit3. -- John Kasunich [email protected] ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
