Ergo, say, if I could specify the tool geometry, location, raw
material geometry and location, then applied G-Code, I want to see
what I would end up with AS IF I machined it.
Any suggestions?
Preferably Linux
thanks
i
Ig, there are demos in there you can modify, I think. I know I've run
the demos. You do have to load the RTAI version of the kernel.
Pete Keillor
OK, I will look some more. I am about 1/3 through the EMC2 manual,
which is actually very well written. This EMC2 looks like a fine piece
of software also.
I was hoping to use it in simulation mode without RTAI mode on later
versions of Ubuntu, this way I can try it on many computers, like my
laptop.
Or maybe I will just run it remotely via ssh.
i
FYI, what you're looking for is really a CAM simulator, not CNC control
like EMC2.
I haven't played with EMC2, but I expect that it's like Mach3 and
defaults to a "demo" mode, i.e. a configuration where it isn't expecting
feedback from an actual machine so it can run "blind" with no machine
connected.
I'm sure EMC2 will show you the toolpath movements when running and the
toolpath simulation, since EMC did and Mach3 does. The CNC control
toolpath simulation only shows you the moves, it does not attempt to
show anything relating to the cutter geometry or the actual material
being machined. I believe most CNC controls are that was since the
cutter geometry is the domain of the CAM software that is generating the
G code, not the domain of the CNC controller.
There is a live CD for EMC2 that will let you boot and run EMC2 in demo mode
from the CD without installing it. At the time I was converting my mill,
PIII's had some of the better scores on latency tests, so I bought a PIII
800mHz on eBay for ~$35 with ~$35 shipping, that's my $70 EMC2 controller.
When I first bought my CNC mill I bought Bobcad/cam V17 and have since
upgraded to V21. It lets you draw the part, generate the G code, and run
the code giving you a 3D view of what it cuts. You can download a demo of
BobCAD/CAM from their website but their salesmen will call. If you tell
them you're just using it for hobby use you might be able to get a cheap
price on it. There are also some free viewers I've seen years ago but
haven't looked lately.
RogerN
"Ignoramus5280" <ignora...@NOSPAM.5280.invalid> wrote in message
news:Oo6dnZncgZPW1hDW...@giganews.com...
Can't help ya there, but I hear a good firewall for linux is vinnywall 1.0
http://www.derkeiler.com/Newsgroups/comp.security.firewalls/2002-10/6957.html
IIRC there are some Yahoo groups ....
http://groups.yahoo.com/group/jobshophomeshop/
http://tech.groups.yahoo.com/group/emc_list/
http://tech.groups.yahoo.com/group/emc_list/
http://groups.yahoo.com/group/ABQMachine/
I think there is a mailing list too ....
--
Cliff
Jon
Maybe I will write a free, GPLed previewer. It does not seem to be
monumentally complicated, given enough RAM.
i
Please get started. That piece of software is missing from the open source world.
Seriously, by the time you understand what you need to know to write it, making things out
of scraps of metal using a CNC will be childs play.
Go Iggy Go!
Wes
I was thinking of something very simple.
Take the raw piece of material to be milled. Represent it as a
collection of points on a 3D grid (most likely a rectangular set, as
you normally start with a steel rectangle). When the milling bit
goes through its path, every point on its path is removed from material,
and this means it is removed from the set of points that we began
with. We will end up with a set of points at the end that, if
displayed properly, would visualize the remaining piece.
i
============
Take a look at
http://www.cncsimulator.com/
price is right [free] Runs in windows.
also see
http://www.youtube.com/watch?v=T4tH_UQWw-Q
http://www.cnczone.com/forums/archive/index.php/t-28790.html
http://www.cnczone.com/forums/archive/index.php/t-11895.html
http://appdb.winehq.org/objectManager.php?sClass=application&iId=5115
http://www.brothersoft.com/downloads/cnc-simulator.html
and many more
Be sure and let the group know what you find.
Unka George (George McDuffee)
..............................
The past is a foreign country;
they do things differently there.
L. P. Hartley (1895-1972), British author.
The Go-Between, Prologue (1953).
>I was thinking of something very simple.
>
>Take the raw piece of material to be milled. Represent it as a
>collection of points on a 3D grid (most likely a rectangular set, as
>you normally start with a steel rectangle). When the milling bit
>goes through its path, every point on its path is removed from material,
>and this means it is removed from the set of points that we began
>with. We will end up with a set of points at the end that, if
>displayed properly, would visualize the remaining piece.
>
>i
Look up cutter compensation left, cutter compensation right.
http://www.stanford.edu/group/prl/documents/pdf/cuttrcmp.pdf
Then consider it when cutting a radius.
Wes
[ ... ]
> I was thinking of something very simple.
>
> Take the raw piece of material to be milled. Represent it as a
> collection of points on a 3D grid (most likely a rectangular set, as
> you normally start with a steel rectangle). When the milling bit
> goes through its path, every point on its path is removed from material,
> and this means it is removed from the set of points that we began
> with. We will end up with a set of points at the end that, if
> displayed properly, would visualize the remaining piece.
Hmm ... what resolution were you thinking of? With a resolution
of 0.001", that is 1e9 points per cubic inch (times the number of bytes
per integer in that CPU), so my Bridgeport, which will handle 12" Y, 18"
X and 5" Z (not counting knee height moves), so 1.08e12 data points
worst case.
Cut it down to a resolution of 0.010" and you get a much smaller
data set -- a total of 1.080e9 and assuming four bytes per integer (32
bits) that would be a mere 4.3 GB of data space. It might keep your
swap space rather busy for a while, depending on physical RAM in the
system, but it looks doable. I would suggest using a third program to
actually display the results -- perhaps something like gnuplot could do
it. Once it is configured into a surface, you could probably turn it
into a sparse matrix to save space, especially since gnuplot would not
need to display the internal points.
Enjoy,
DoN.
--
Email: <dnic...@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
You can be smarter about data storage, since in most cases data is
contiguous (you cannot mill out a sponge). So you can store an
enumerated value about each cubic millimeter, one out of three values:
1) Material was not removed 2) material was partly removed 3) material
was removed fully. For cubic millimeters that are 1 and 3, no further
storage is necessary. For cubic millimeters that are number 2 (partly
removed) you can store further details. 8,000 _bits_ per cubic
millimeter would cover it in great detail of sub-cubes of 0.05mm step.
If, say, 1,000,000 cubic millimeters are in state 2 (1 square meter of
surface), then we need 8,000*1,000,000 bits, or 8 gigabits, or
appx. 1 gigabyte. Memory access structures and such will always add
some memory need. But it seems not to be excessive.
Since this is done mainly for GUI display, extreme precision is not
necessary.
Let me know if my math is wrong.
i
> Let me know if my math is wrong.
Your math is known as voxels. This has all of course been researched and
developed for decades. No need for you to reinvent it; just study computer
graphics and modeling, and computational geometry. If you're not a
computer scientist, then it doesn't get easier pretending it is not
computer science.
A quicker approach if you're trying to develop this yourself would be to
use solid models, and write just a translator to parse and convert the G
code semantics into the equivalent 3D solids representation. Then you can
just feed the resulting shapes and add/subtract operations into a solid
modeler, and you have escaped all of the hard work, and get all the
rendering and drawing generation for free.
>
>A quicker approach if you're trying to develop this yourself would be to
>use solid models, and write just a translator to parse and convert the G
>code semantics into the equivalent 3D solids representation. Then you can
>just feed the resulting shapes and add/subtract operations into a solid
>modeler, and you have escaped all of the hard work, and get all the
>rendering and drawing generation for free.
If you were to generate STEP, SAT, or IGES files you'd have the option
of using one of the free 3D CAD viewers in addition to most any solid
modeler.
--
Ned Simmons
Conceptually, yes. As a practical programming exercise, you pretty much
need to come up with a much more efficient representation.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
[ ... ]
>> Hmm ... what resolution were you thinking of? With a resolution
>> of 0.001", that is 1e9 points per cubic inch (times the number of bytes
>> per integer in that CPU), so my Bridgeport, which will handle 12" Y, 18"
>> X and 5" Z (not counting knee height moves), so 1.08e12 data points
>> worst case.
>>
>> Cut it down to a resolution of 0.010" and you get a much smaller
>> data set -- a total of 1.080e9 and assuming four bytes per integer (32
>> bits) that would be a mere 4.3 GB of data space. It might keep your
>> swap space rather busy for a while, depending on physical RAM in the
>> system, but it looks doable. I would suggest using a third program to
>> actually display the results -- perhaps something like gnuplot could do
>> it. Once it is configured into a surface, you could probably turn it
>> into a sparse matrix to save space, especially since gnuplot would not
>> need to display the internal points.
>
> You can be smarter about data storage, since in most cases data is
> contiguous (you cannot mill out a sponge). So you can store an
> enumerated value about each cubic millimeter, one out of three values:
> 1) Material was not removed 2) material was partly removed 3) material
> was removed fully. For cubic millimeters that are 1 and 3, no further
> storage is necessary. For cubic millimeters that are number 2 (partly
> removed) you can store further details. 8,000 _bits_ per cubic
> millimeter would cover it in great detail of sub-cubes of 0.05mm step.
O.K. Smarter about the storage, but much greater complexity in
storing and accessing it. This will probably slow down the construction
and the readout of the data.
> If, say, 1,000,000 cubic millimeters are in state 2 (1 square meter of
> surface), then we need 8,000*1,000,000 bits, or 8 gigabits, or
> appx. 1 gigabyte. Memory access structures and such will always add
> some memory need. But it seems not to be excessive.
>
> Since this is done mainly for GUI display, extreme precision is not
> necessary.
>
> Let me know if my math is wrong.
Your math looks good -- and I suspect that really we only need a
resolution of 1mm, not 0.05mm -- except when displaying a very small
workpiece, in which case we will be working with tiny milling cutters as
well.
If you do this -- I hope that it is X11 based, and does not use
any of the weird linux-only features of the OS.
If you need someone to compile-test it on a UltraSPARC Solaris
system, I would be willing to do this.
<big snip>
> I would suggest using a third program to
>actually display the results -- perhaps something like gnuplot could do
>it.
Grace maybe be able to do this too, see:
http://plasma-gate.weizmann.ac.il/Grace/
"Grace is a WYSIWYG 2D plotting tool for the X Window System
and M*tif. Grace runs on practically any version of
Unix-like OS. As well, it has been successfully ported to
VMS, OS/2, and Win9*/NT/2000/XP (some minor functionality
may be missing, though)..."
Just happened to come across it yesterday while running down
applications that might be useful.
What you are trying to do is very similar to terrain
mapping. You maybe able to modify some of the software
utilities that are used for importing elevation data. They
normally accept something like csv with lat, long, elev
data.
Just some wild ideas to ponder...
--
Leon Fisk
Grand Rapids MI/Zone 5b
Remove no.spam for email