On Tue, 30 Apr 2019 09:27:25 -0400 Gene Heskett <gheskett(a)shentel.net> wrote: okular is kde5/qt5, so it's a moving target. A quick search suggests that this is a known bug (possibly two separate bugs), it's been fixed, and you're running a very old version. So, yeah, you might want to update to something a little more modern. E. Liddell

On Tuesday 30 April 2019 15:06:22 Gene Heskett wrote: Comes with new KDE, etc., not sure what else. It's not TDE. Bill

On Tuesday 30 April 2019 20:34:09 E. Liddell wrote: Thats a bit odd, this is an R14.0.6 install, but its not in either office or graphics sections of the menu. Xpdf is there, but its yet to do a print job anywhere near complete or correct. Reinstalled it, still can't be found. Does run by cli. But whats all this? gene@coyote:~/linuxcnc/nc_files$ kpdf /etc/magic, 4: Warning: using regular magic file `/etc/trinity/magic/tdeio.magic' /etc/magic, 4: Warning: using regular magic file `/etc/trinity/magic/tdeio.magic' /etc/trinity/magic/tdeio.magic, 17: Warning: using regular magic file `/etc/trinity/magic/drgeo.magic' /etc/magic, 4: Warning: using regular magic file `/etc/trinity/magic/tdeio.magic' /etc/trinity/magic/tdeio.magic, 17: Warning: using regular magic file `/etc/trinity/magic/drgeo.magic' /etc/trinity/magic/drgeo.magic, 2: Warning: using regular magic file `/etc/trinity/magic/cabri.magic' /etc/magic, 4: Warning: using regular magic file `/etc/trinity/magic/tdeio.magic' /etc/trinity/magic/tdeio.magic, 17: Warning: using regular magic file `/etc/trinity/magic/drgeo.magic' /etc/trinity/magic/drgeo.magic, 2: Warning: using regular magic file `/etc/trinity/magic/cabri.magic' /etc/trinity/magic/cabri.magic, 2: Warning: using regular magic file `/etc/trinity/magic/kolf.magic' I loaded up a 750 page linuxcnc documentation pdf, and while its all there, it doesn't quite have the pretty print pizzazz that evince or okular gives. I am about to install stretch on this machine, from an image the LCNC folks are testing, so hopefully wheezy will have reached the end of its use here in the next couple weeks. And this time its a 64 bit install, something I've been avoiding because of the much larger IRQ latencies of a 64 bit install. But they've been fine tuning the preempt-rt kernel builds and now have it good enough (pretty steady 50 u-sec lag) the smarter interface cards can handle the remaining timeing wobblies. Their default windowing system is xfce4, quite capable these days but I'll likely do tde on it too just to get my old friend kmail. You might think 50 u-secs is quick, but I have 2 machines here that can respond to a scheduled IRQ with a worst case wobble in the 4 to 6 u-sec range. Intel Atoms of course. Amd lost that fight years ago. 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>

On Tuesday 30 April 2019 22:22:14 E. Liddell wrote: [...] Actually, I've been generally pleased with this now elderly 2.1GHz phenom. But its not well equiped to run machinery. latency-test shows 70,000,000 ns for the 1 millisecond servo-thread. Thats 70 milliseconds. Take away the base-thread which runs at 25 microsecond intervals and it is still around 50 milliseconds. And it would be 10x worse than that if I was using an nvidia driver. So I'm using nouveau. I'm not much of a gamer ubless you count solitaire. :) For GP computing, I've always favored amd just to keep competition alive. To demo the diff between software stepping, one of those 6 u-s machines has run a small mill for years, at a maximum table speed of about 12 ipm. A damaged ball screw put that mill out of commission, so that computer is now driving a 600x390mm gantry style mill, but it now has Mesa fpga based cards for the i/o because one parport doesn't give near enough i/o. But with those cards to offload the high frequency base thread from the cpu, that machine is moving at 210mm/second top speed, almost 20x faster. It gets homed at about 100mm/sec, and overshoots the switch less that half the overtravel it has. One switch is a button, and is mounted on a spring to protect the switch from being smashed. A 2" piece of .0325" thick sheet alu is the spring. The max flex might allow a 24lb piece of paper to be inserted as thats how fast the machine can be stopped. The other 3 similar function switches are std mini-style microswitches with roller tipped levers. Neither allows a hard crash, stopping the machine about 10 thou from it. But thats not the "home" point because once the switch has tripped, the machine moves away from the switch at 1/20th the search speed because the software only samples the switch at millisecond intervals. So when the switch releases, is the actual home position reference, and that gives me .0001" accuracy. The switches aren't that accurate of course but the individual switch in a bag of 10 for 4 dollars is very very repeatable. Thats about how far the motors turn when being microstepped at 1/8 step, a full step being 1.8 degrees of the motor shaft. Top speed is limited by two things, 1st being the speed of the opto isolators in the motor drivers limits us to a step rate of 200 kilohertz, and how fast the motors inductance can be overcome to establish the magnetic position. To do that we use power supply's of 10x or more than the nameplate label, its the current regulation that counts. Your trivia factoid for the day :) 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>