On Monday 19 November 2018 14:28:14 Nicklas Karlsson wrote: > > On Monday 19 November 2018 05:06:29 Nicklas SB Karlsson wrote: > > > What did you want to discuss with the addf function? > > > > > > I used it and think it works but what's more? > > > > We need a utility that detects out of order addf's, each of which > > then causes a one thread execution delay in the data traveling that > > path. Data from a limit/home switch to use a real simple circuit, > > should be present at the motion input when motion is invoked. But > > what if the debounce addf is out of its assumed order? Placed below > > motion in that thread? > > With out of order you mean output from one thread is used in another > thread?
Only where it makes sense, see below. > Otherwise I anywhere within period is ok. No, its not, because if a module is out of order, too early, and is being fed from another module thats later in the thread, then its input is always stale by one thread time. That can be hell to find when you can't move 2 thou without generating a following error. > > But to use the jog dials on my bigger lathe as another example, > > which run in a slower 200 hertz thread, theres at least 40 LOC > > between the dial and the data applied to motions jog inputs. For > > each dial. > > Then data from slower thread is used update is done within same > periodicity in higher priority? Or jitter around? Or you do not know? Yes, its used in a faster thread once its been processed in the slower thread. This lack of synch is not a problem, but within each thread, out of order is going to be a problem. > > > I see that addf can take a 3rd optional argument "location" ... > > "location" is execution order? Don't know, no docs that I can find, so that is a reasonable assumption, however I am not going out on that limb with intentions of sawing it off behind me without the someone who added that option confirming that. The next question is, if we are going to diddle the execution order, are the threads isolated? The idea of using a separate slower thread came to mind as a way to alleviate some of the main "servo" thread from having to process data generated by human hands that move at <2.5% of the servo threads responses. This on the Rpi-3b thats running my 11x36 Sheldon. I've not totally converted it to dual thread, I am sure there are functions that could be moved to the slower thread, and the thread itself further slowed, but what I have right now is working well, like the jog dials. With those, I've restricted the range quite a bit from my original idea as I can still turn the dials faster than the machine can move, so theres a windup, however I've read that I can configure to have a jog stop when I stop turning the dial, throwing away the windup, but thats not tested (yet). That may need a lowpass running at servo speed just to keep it running if no new data arrives in a given servo cycle. Equ to a 20 ms max_accel might be enough to make it move smoother. There are so many things that can be done with linuxcnc that I've not had the time or the need so far to explore. Like coercing a G76 to cut a tapered 50 tpi thread 3/4" long where I needed to get a grip on an unmachined ball screw. It works perfectly if the length of the taper is one spindle turn shorter than the length of the thread, and that grip is whats driving the x screw in the Sheldon right now. Made all of that stuff on The Little Monster as my 7x12 is known as here on this list. Also cnc'd. Tapered gibs, threw the willow tree compound away & made a cast base for the qctp.. :) > > A well defined execution order could be a solution. Then there a > simple cases with output from one used in other, simple criss cross > and hard to sort out feedback. +1, Understatement of the month... But one thing I'm generally doing is mixing only at the motion inputs. Unless I've accidently jumped the fence. :( All machine moves and feedback remains in the servo thread, but the human stuff only has to be faster than the human. My x corrections for the worn bed are all in the slow thread except the offset module itself, its inputs from the lincurve are far slower than the machine can move. One step at time stuff. -- 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> _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
