Web lists-archives.com

Re: SSD's and many edits of a single file

On Thursday 12 April 2018 07:44:39 rhkramer@xxxxxxxxx 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 

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>