Re: SSD's and many edits of a single file
On Thursday 12 April 2018 07:44:39 rhkramer@gmail.com 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>
Reply to: