Post by jon_banquer"Well Sam.
I was going to posy sometheng like "Dumb mother fucking Joe Anand
Asshole",
but I'm civilized.
Hey,when VM6 finally gets out of the gate _TWO YEARS LATE_ and half
assed at
that, I'll link up my machine definition and post library and put the
genteleman out of bussiness. Pray on that
MF'er......................................
They won't require any assistance beyond your "expert" advice apparently.
http://www.mecsoft.com/phpbb/viewtopic.php?t=1115&postdays=0&postorder=asc&start=0
Why is VM doing this?
What you see is a top view of a simple, 2.5D profiling toolpath (CYAN). The
YELLOW shapes are the selected "regions". As you can see, the toolpath (1/8"
bit) should not be going in between the "T" and the "H", as this will
produce very undesirable results.
Profiling only checks for interference in the same curve and not between
curves. If you merge these curves into one single curve then profiling will
work correctly. I am including an edited file here.
have a similar problem with RhinoCAM when 2.5D cutting nested parts. Here
you can see that it's the entry/exit path of one part that fouls the side of
the next part. It would be interesting to know what criteria it uses to
place the entry/exit path as in this case just about anywhere else would
have been ok.
Mecsoft: If/when bugs like this are fixed, where do I download the patches
from please?
Whistler your issues are not bugs.
That's all in your programming
I dont know about RCAM but in VM the entry/exit is 100% customizable. You
can even set all the values at 0 and have no lead-in.
Your exit move doesn't need to be more .001 step and inlet could be set to a
really shallow angle instead of radius. You could also set the radius to
like .005 or something.
It is also extremely easy to change the start point of the region so the
entry/exit is in an enterely different location.
It is VERY likely that these features are available in RCAM.
Yes I agree altering the entry/exit parameters can get around this
however these are actually the defaults so I'd expect a piece of software to
work with those at the very least. Further I'd expect software to work
within any parameter allowed by that software.
Bug/No bug - well there's as many definitions of "bug" as there are
bugs in Windoze, so that's purely a matter of opinion and of course you're
entitled to yours.
I like this definition of bug from the Linux Information Project
(LINFO) "A bug, also referred to as a software bug, is an error or flaw in a
computer program that may prevent it from working correctly or produce an
incorrect or unintended result."
Unless you're suggesting that crashing the entry/exit path into a
neighbouring toolpath is a correct and/or intended feature then I'd say that
fits the above definition.
Hi Gentlemen,
This is an interesting discussion on bugs and this case is a conundrum
that we as software developers face. There is a fascinating story from Issac
Asimov, where a robot can be made to lock up if it is placed in a situation
where a course of action is in conflict with one and not any of the other 3
laws of robotics. This is a similar situation here.
1) First and foremost we have to honor the start point of the profile
that the user has chosen. (First law)
2) Toolpath cannot gouge the part (Second law)
In this particular situation even though the 2nd law is violated we
cannot violate the prime law and so the "bug".
Now the question is if we made the second law the prime law and
allowed the software to override human decisions, some might consider it
good while others might consider it loss of control! ( I think Issac Assimov
has another story where the second law becomes the prime law and this causes
some robots to take over a human colony)
Another choice is to add a parameter in the dialog to allow overrides
in cases such as this. This has its own set of problems such as making the
software difficult to use. (This is what you see in software systems that
have been around a while longer than ours - not to name names here).
Add to this the processor & algorithmic limitations on checking for
the optimal solution and you have the perfect conundrum!
I don't usually post here, but this is an interesting philosophical
discussion, so I thought I would put in my 2 bits... Hopefully without
offending anyone.
My interpretation of the three laws would be as follows:
First Law:
CAM software may not gouge or damage a workpiece or, through inaction,
allow a workpiece become gouged or damaged.
Second Law:
CAM software must obey orders given to it by human beings except where
such orders would conflict with the First Law.
Third Law:
CAM software must inform human beings when any conflicts with the
First or Second Law arise.
The point is, we buy intelligent CAM software that have all kinds of
automatic routines to help us in manufacturing parts efficiently and without
damage. That includes "automatic" gouge checking, even though the operator
has asked the software to do something that could potentially violate the
first law, i.e. gouge the part.
You wouldn't want to use 3axis 3D machining routines that didn't
include automatic gouge checking, would you? Companies have spent years
touting "Gouge-Free toolpaths!" Why are 2D routines any different? 2D gouge
checking also includes lead in/out moves - or at least should as an option -
they are just as important as actually machining the part. Same for 3D.
The fact is that two routines in VM/RC - pocketing and engraving - do
path gouge checking already. Why would they do that? By the theory that
software should blindly obey human commands to the letter means that both
pocketing and engraving shouldn't bother with gouge checking, it is the
responsibility of the human if something goes wrong.
To me that is flawed logic. Software is made to help humans by
automating difficult and calculation intensive tasks. It should do that to
the furthest extent possible. That includes making the necessary decisions
to keep the part from becoming damaged.
Lastly, if you examine the number of cases where fully automatic gouge
checking would actually prevent a human being from making the part they want
versus the number of cases where it would actually save the part and allow
it to be made more easily, I'm sure you'll find that the *overwhelming*
majority are in the second category. I have used other software for years
that does have full 2D gouge checking on profiling and lead moves and it has
NEVER prevented me from doing what I want.
Or, as Bob McNeel is fond of saying... "Am I confused?"
--
John R. Carroll
www.machiningsolution.com
begin 666 icon_razz.gif
M1TE&.#EA#P`/`+,.`/_J`$5%10```/_.`/\``/_)`/^T`/Z=`/_]$__^D___
MQ___ZS,S,__E`````````"'Y! $```X`+ `````/``\```1=T$D9:IW8U:52
M&A<6< @"G,,13$$G""?PIJN6F'$.:@H.G[^"*G #QH*&2B+'!!22`1.C"6 \
I*P/9:[L5K@)9`6$\%A1VFL&@$2 'SBJ6NM!^TS(5@]XPS+ L-1,1`#L`
`
end