On Thursday 12 April 2018 07:44:39 [email protected] wrote: > On Wednesday, April 11, 2018 03:27:48 AM Gene Heskett wrote: > > What seems to be lost on you folks not running realtime patched > > kernels, is that when linuxcnc is running, it has total control over > > the hardware, and that linux becomes a client of the realtime > > system, getting what cpu time is left after linuxcnc has finished > > what it has to do to meet the timing constraints needed to run the > > machine and meet the sub-micron positioning accuracy required. > > Hmm, a more careful 2nd reading may have answered my question, but > I'll ask anyway--on first reading I wondered if that was true of any > program running in / making use of a Linux realtime kernel--that is, > that the realtime program (linuxcnc) (or is that the kernel) has total > control over the machine. > > On 2nd reading, I think the answer is yes, i.e., if I have a midi > program making use of the / a real time kernel, it will have total > control of the machine and other programs will have the "leftovers"?
Yes. Particularly noticeable if running the steppers by software step generation. There, one must run a "base thread", limited to integer only math, in a 20 to 30 nanosecond loop. Because the loop is so slow, this function is often off-loaded to an fpga smart card that is programmed at a 1 to 10 kilohertz rate with most using the default 1 kilohertz. This can quadruple the speeds, from 2 effects. Because the motors see a much steadier heartbeat, they can often be moved much faster without stalling, and 2, this hardware can often generate the step signals 10x faster. OTOH, doing that also frees up the parent cpu, allowing it to do much more without affecting the main process. We can also setup slower "threads" for stuff that are the result of human activity for instance. Humans are rather glacial movers. For less critical duties this works well, and in the case of running bigger machinery with something as puny-powered as an r-pi-3b, I have much of the not so time critical stuff running in a 200 hz thread, so that nearly half of the hal file only gets processed when the higher priority, faster loop is done. This includes the hand driven encoder dials that allow me to run the lathe by hand. Even at 200 hz I can still drive it at anything from the maximum speed of nearly 90 inches a minute, down to as small as .0001" per click of the dial. Thats a larger movement than the software itself can do since if I tell it to move 12" along the bed, while moving the cross-feed 3 thousandths of an inch, it will do what is effectively a dead straight line from that start to that finish. Errors in that motion are generally the coil current mappings of the stepper driver as it divides a full step, 1/200th of a turn, by 8 or 16 in order to get that smoother motion. Loading of course inserts an offset, but is under a .9 degree of the motor shaft rotation as long as the load doesn't cause a step slip. That much may break the micron claim, but not by enough to ruin the part. Lots of other stuff that would be TL;DR for most here. -- 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>
