Re: librecad

[Gene Heskett <gheskett@shentel.net>]

On Friday 07 December 2018 22:56:03 Joe Pfeiffer wrote:

> Gene Heskett <gheskett@shentel.net> writes:
> > On Friday 07 December 2018 19:54:56 John Hasler wrote:
> >> Joe writes:
> >> > ...he's still on wheezy.
> >>
> >> I wrote:
> >> > That is easily fixed.
> >>
> >> Gene writes:
> >> > Not until an rtai patched kernel is available for the newer
> >> > stuffs.
> >>
> >> Why would you run your CAD software on your machine controller?
> >
> > Why not John? With 6 machines here running 32 bit wheezy, one
> > running jessie on an R-PI-3B, and one running armbian stretch on a
> > arm64, all but the arm64 actually running a machine or the card
> > firmware updater, the only one w/o enough iron to run cad stuff is
> > the pi.
> >
> > This machine, with its comfy chair, can run anything installed on
> > the other 6 machines via ssh -Y logins, and all are or can be
> > mounted over an sshfs facility for moving files around. Samba/cifs
> > has turned into a headache precisely because of all the windows crap
> > that been incorporated in the last years since Andrew T. got a
> > helper.
> >
> > NFS, any version is at best a chain with broken links, whereas sshfs
> > Just Works.
> >
> > The machine that will carve the back panel is the best simulator
> > ever for code that will be run on it, simply by turning off all
> > motor power, I can run gcode on it, with the gui exported to this
> > machine and its comfy chair. This allows me to exercise the code,
> > making sure it does exactly what I had in mind, without carving up a
> > hundred bucks worth of raw material and putting more wear on a
> > cutting tool.
> >
> > alu is the hardest stuff to cut in terms of tool wear there is, only
> > partially mitigated by a mister directed fog of sealing oil directed
> > at the back of the cutting tool so the alu is sealed away from the
> > air, majorly sealing the just cut surface.
> >
> > 99% of the heat you get from machining alu is not the cutting tool
> > friction, but the burning of the alu as it forms a new layer of alu
> > oxide in the thousandth of a second after the passing cutting edge
> > of the tool has exposed the alu to the airborn oxygen. That alox
> > layer is the 2nd hardest substance we have, 2nd to diamond, and
> > asking the tool to cut thru it with every passing cutting edge is
> > pure hell even on silicon carbide tooling. At $10 to $50 a tool.
> >
> > CAD/CAM may be able to do it faster, but they do not yield editable
> > gcode. This file I am working with, if exported as gcode from
> > freecad, would be 5 to 20 megabytes because the cad/cam programs
> > have no clue about the use of loops and conditionals. I am doing all
> > this, with one hole of unk size to cut yet, with 199 LOC. 50+ is
> > comments, keeping track of what I'm doing.  And I can fix it with
> > the same editor I used to write it. geany.
> >
> > Biggest problem ATM is I'm one eyed, haven't let the left eye settle
> > long enough after the surgery Tuesday to be able to write a
> > prescription and get the correct lens in the frame, so its empty on
> > that side. Since I'm partial to hard coated Transitions lenses
> > (special order, takes 7 to 9 days in this neck of the woods), that
> > will be 2 more weeks till I've got two medium good eyes again.
> >
> > Other than that, whats not to like, John?
>
> First, because if you *really* need real time response, you shouldn't
> be running anything else that might be computationally intensive.  I'm
> happy to believe the developers of RTAI are competent, even excellent,
> programmers.  All the same, if I want real time levels of predictable
> response I don't want to put anything that might decide to be
> computationally intensive on the same machine.
>
> Second, because you're forcing yourself to look for workarounds due to
> the decision to use an obsolete (as in, not even in LTS since last
> May) distribution.  As we've seen in this thread.

LinuxCNC depends on a low latency IRQ response. No 64 bit kernel comes 
even close to being useable as the context switch itself can cost 20 
microseconds. When the same hardware can show 3 microseconds running an 
rtai patched 32 bit kernel, on a slow atom powered mobo, there is zero 
reason to upgrade. I am behind a router running dd-wrt. No one gets in. 
So I am not overy worried about security.

To compare that to this 64 bit phenon running 150% faster that the atom 
board with a 32 bit install but not a realtime kernel, runs that same 
latency-test, and comes up with a worst case lag of 5 milliseconds for 
what is supposed to be a 25 u-second loop. even the simulator is visibly 
slow. Yet its running kmail as I type this on another workspace with no 
visible lag.

And I have no reason to run a heavy app while its carving metal unless I 
am chasing down a fix, in which case there may be firefox and an IRC 
client, running too, but I don't expect miracles though.

When you can upgrade me to stretch or beyond on all those machines w/o 
killing the main job I built or bought those machines to do, I'll be 
happy to upgrade. Until that time I'll ignore the snide remarks from 
those who obviously do not understand the problem the upgrade will 
bring.

-- 
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>