On Friday 07 April 2017 16:00:04 John Kasunich wrote: > On Fri, Apr 7, 2017, at 11:53 AM, Jon Elson wrote: > > On 04/07/2017 10:29 AM, Gene Heskett wrote: > > > What I want, but don't know if I can get, is to have the > > > servo thread running at the highest priority, fully > > > capable of interrupting the jog-thread, but the jog-thread > > > cannot interrupt the servo thread as its not that time > > > critical. How best to do that, given the tools available? > > > Thanks Peter and everybody. Cheers, Gene Heskett > > > > Faster threads will, in theory, interrupt slower threads. > > But, the way RTAPI threads are set up, at least with RTAI, > > the slower threads will be forced to run at multiples of the > > faster thread period. Therefore, I think, the slower threads > > will actually never get interrupted. I think they will just > > get tacked onto the end after the faster thread runs. > > Slower threads can get interrupted, if they take a long time to > complete. > > Suppose you have a 1mS servo thread that takes 170uS to run. > And a 10mS "jog thread" to use Gene's example, that takes 1300uS to > run. > > starting at time 0, the servo thread will run > it will finish at 170uS, then the jog thread will start > at 1000uS, the servo thread will interrupt the jog thread, even > though the jog thread has only run for 830uS and still has 470uS > of work to do the servo thread will take its 170uS, and finish at > 1170uS > the jog thread will resume where it left off, and run for another > 470uS, finishing its work at 1640uS non-realtime code will run from > 1640uS to 2000uS > at 2000uS, the servo thread will run for 170uS > non-realtime code will run from 2170uS to 3000uS > and so on, until 10000uS, when the process repeats > > If a slow thread has lots to do, it can and will be interrupted by > faster threads. Thread priority in HAL is automatically set up with > the fastest threads having the highest priority so they can interrupt > slower threads.
And thats the answer I was looking for, thank you John. I can get it to last thru 5 to 8 repetitions of the lathe_pawn.ngc, but somewhere, its going to throw errors in both joints. I am now convinced more than ever that the spi bus has a sync problem. I have caught the tach needle bouncing when the spindle is not turning a couple times as the errors were spit out. So I just got off the horn w/digikey from ordering enough stuff to make up all 3 of those pi<->7i90 interface cable assemblies, s/b be here by thursday next. Maybe that will give enough cleaner a signal to stop this BS. If not, the search resumes for a solution. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
