Unfortunately a lot of CAM software doesn't do a great job of producing
Gcode.
I was working with some very high end graphics art software used to make
vinyl sign graphics and the Gcode code that they were outputting was
simply horrendous.
When I asked why they were outputting line segments in
Chris Radek wrote:
> On Thu, Aug 19, 2010 at 06:06:58PM +0200, yann jautard wrote:
>
>> Did you use G64 P when using G41/42 to cut a corner ? This
>> could explain why it did not produced an error.
>>
>
> This is unrelated.
>
>
>
ok, sorry, I must learn to shut my damn mouth when I do
I would like to thank all the people that responded!
>From Your replies I understand that my CAM application - Wrykrys
(www.wrykrys.cz) - is lacking some minor functionality, but their fast
and pleasant customer service has already provided me with the answer
and information that I need to generat
Hello, Dave!
Thank You for Your insight! I totally agree that I should concentrate
on the cad/cam process so that I eliminate the cause of the issue
instead of fighting consequences...
The thing is that I have to complete this pretty large order very
quickly, so I thought that I could quickly reso
Thomas wrote :
> I think possibly for many EMC users, CAM is not an easy thing. Many
> plasma applications are using artistically oriented patterns and
> programs, such as clipart or truetype font cutouts and without a decent
> CAM, offset functionality can be a huge advantage. One could argue
Hi!
As far as I understand from the other replies, EMC should not be the
software that solves these problems.
However, as I develop on a gcode manipulating software, maybe this would
be better suited.
http://code.google.com/p/grecode/
All the gcodes are read to memory, and it would be relativel
Viesturs,
I think you need to work on the Cad to Cam to Gcode process. I put EMC2
on a production waterjet machine in June and it has been buzzing along
happily ever since.
I had to convert about 80 existing Gcode programs so EMC2 could run the
code and I was amazed at some of the poor quality
On Fri, 2010-08-20 at 07:00 +1000, Frank Tkalcevic wrote:
> > > Yes, the problem is just what the error message says. There is a move
> > > that makes a concave corner but the move cannot be reached (the tool
> > > cannot move alongside it as you request) without gouging into the
> > > profile of
> > Yes, the problem is just what the error message says. There is a move
> > that makes a concave corner but the move cannot be reached (the tool
> > cannot move alongside it as you request) without gouging into the
> > profile of the part. Here is a screenshot showing the situation.
> > http:
... snip
Are there any issues with adding an inside radius feature to the part?
Making it as large as acceptable may allow the operator to use a range
of tool radii without changing the program or the resulting part. It
seems better to fix problems on the front end (designing with
fabrication in m
On Thu, Aug 19, 2010 at 12:41:02PM -0500, Viesturs L??cis wrote:
> In Your example all the square pockets would be skipped and outside
> contour would be cut. In my example I would get, what I want.
It cannot possibly be safe to throw away part of the program and
then continue on with the rest of
Do you have the CAD program too? To help your CAM package with tangent arcs
to eliminate the unreachable corners.
The easier way would be to tell your CAM package to compensate for tool
diameter, it would create a tool path at the center of the tool, always
keeping the tool tangent to the feature
2010/8/19 Chris Radek :
>
> Let me try to explain an example. I really think the disconnect
> between how I as a programmer think about it and how a user thinks
> about it is our different understanding of what a "corner" is. I
> tried to explain this in my last message.
>
> Say you are cutting i
On Thu, Aug 19, 2010 at 12:29:39PM -0400, Thomas D. wrote:
>
> I realize that probably everyone has their own idea of what the ideal
> solution is, and wholeheartedly respect that what may seem to be a
> "minor" change from a user perspective can often be massive work from a
> developer perspec
here we go again :)
On Thu, Aug 19, 2010 at 11:29 AM, Thomas D. wrote:
>
> For me this is an issue I have to deal with quite often, - so I'm very
> humbly going to put my 2 cents in.
>
I will contribute 2 cents also
>
> I realize that probably everyone has their own idea of what the ideal
> so
For me this is an issue I have to deal with quite often, - so I'm very
humbly going to put my 2 cents in.
I realize that probably everyone has their own idea of what the ideal
solution is, and wholeheartedly respect that what may seem to be a
"minor" change from a user perspective can often be
2010/8/19 Chris Radek :
>
> The disconnect here is you are thinking of a corner as "where I think
> a corner should be on my part, even if there are several little moves
> in the gcode that the tool can't get in there to touch without gouging
> the part" but EMC thinks of a corner as the point wher
On Thu, Aug 19, 2010 at 06:06:58PM +0200, yann jautard wrote:
>
> Did you use G64 P when using G41/42 to cut a corner ? This
> could explain why it did not produced an error.
This is unrelated.
--
This SF.net email is
On Thu, Aug 19, 2010 at 10:48:37AM -0500, Viesturs L??cis wrote:
> Ok, but then how comes I do not receive this error, when cutting a
> rectangular hole in material, which is defined by 4 G01 moves (and G41
> or G42 is active) - there is sharp 90 degree corner and round tool -
> so the corner cann
Viesturs Lācis wrote:
>
> (...)
>
> I am sorry, but I do not really understand, why it is ok for corner,
> where it is turn by 90 degrees, but error is produced, if the corner
> is sharper than 90 degrees. Are there some limitations on how the path
> of the tool is offset, when G41/G42 is act
2010/8/19 Chris Radek :
>
> Yes I agree the ideal solution is to know what the *desired* behavior
> is and then do it - however there are two problems with that - knowing
> what the desired behavior is - and then doing it.
>
> I don't mean to be flippant, but both are very hard. Like Stuart S
> im
On Thu, Aug 19, 2010 at 09:45:39AM -0500, Stuart Stevenson wrote:
> Chris,
> Sorry for the catty remark it's just that we have had several
> conversations about cutter compensation routines. :)
Yes but thanks for that reminder. I want to be clear enough about
what is going on here for everyone
On Thu, Aug 19, 2010 at 09:31:42AM -0500, Viesturs L??cis wrote:
> Ok, thank You for the explanation, I kind of realised that it is the
> case that there is corner that cannot be completely reached, because
> tool is too big.
>
> The way I see the ideal solution - display the error message so th
Chris,
Sorry for the catty remark it's just that we have had several
conversations about cutter compensation routines. :)
thanks
Stuart
--
dos centavos
--
This SF.net email is sponsored by
Make an app they can't live
2010/8/19 Chris Radek :
>
> Yes, the problem is just what the error message says. There is a move
> that makes a concave corner but the move cannot be reached (the tool
> cannot move alongside it as you request) without gouging into the
> profile of the part. Here is a screenshot showing the situ
On Thu, Aug 19, 2010 at 08:32:49AM -0500, Stuart Stevenson wrote:
> On Thu, Aug 19, 2010 at 8:22 AM, Chris Radek wrote:
>
> > On Thu, Aug 19, 2010 at 07:54:36AM -0500, Viesturs L??cis wrote:
> >
> >
> >
> > Yes, the problem is just what the error message says. There is a move
> > that makes a co
On Thu, Aug 19, 2010 at 8:22 AM, Chris Radek wrote:
> On Thu, Aug 19, 2010 at 07:54:36AM -0500, Viesturs L??cis wrote:
>
>
>
> Yes, the problem is just what the error message says. There is a move
> that makes a concave corner but the move cannot be reached (the tool
> cannot move alongside it a
On Thu, Aug 19, 2010 at 07:54:36AM -0500, Viesturs L??cis wrote:
> I just received also this error message:
> "Straight feed in concave corner cannot be reached by the tool without
> gouging"
> It indicated that the error is around line 24, so here is the part of the
> code:
> G1 X+167.031 Y+46
Hello, guys!
I have been running my waterjet cutting machine with EMC for a while
now (currently that is version 2.4.3.1) and I have gathered few
questions about the way, how EMC interprets the g-code.
The main issue is that sometimes I receive this error message:
"Arc move in concave corner cann
29 matches
Mail list logo
