Re: [Emc-users] Fw: EMC ignoring G2 codes

2007-12-25 Thread Chris Radek
On Tue, Dec 25, 2007 at 09:17:49PM +0200, Alex Joni wrote:
>  the list,
> I removed the attached image, and put it up at:
> http://imagebin.org/12581
> 
> It will only be there for a couple of days though..

Thanks Alex!

> >This apparent Z level sensitivity is interesting. The machine boundaries
> >are set at (X -0.01, 6.67), (Y -2.73, 0.01), (Z -6.78, 0.01) putting the
> >home origin in the top left upper corner. The part (G54) is then zeroed
> >in absolute coord (X2.9361, Y-1.5052, Z-2.1691). All the tool paths
> >appear well within the boundaries and I can see no logical reason for
> >this dependency. I've restarted the program a number of times during
> >these investigations and with the same z zero the errant behaviour is
> >repeatable.

I used exactly these values and still couldn't reproduce it.  If it
is repeatable right now on your system, would you tar up your whole
configuration directory and send it to me please.  The exact G54
offsets etc. will be preserved in the var file.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


[Emc-users] Fw: EMC ignoring G2 codes

2007-12-25 Thread Alex Joni
the list,

I removed the attached image, and put it up at:
http://imagebin.org/12581

It will only be there for a couple of days though..

Regards,
Alex>

- Original Message - 
From: "Andy Lee" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, December 25, 2007 1:15 PM
Subject: Re: [Emc-users] EMC ignoring G2 codes



On Mon, 24 Dec 2007 11:50:22 Chris Radek wrote:

<<
Hi Andy, I ran this code and it worked properly.  The only changes I
made were to add G21 and G0 to the beginning, and M2 to the end.

http://timeguy.com/cradek-files/emc/andy-success.png

The preview and machine motion matched.  If you are getting a
different result, we need more information to reproduce it.
Some things that I wonder are:

Does the preview look wrong?

Does the machine motion match the preview?

What exactly do you mean that the arcs are skipped?

What else is above in the program that might influence the path?
Maybe tool radius or length compensation?  G64 setting?  If tool
radius or length comp, what is in the tool table?

Can you narrow down the problem to a very short program that
reproduces it, so you can post the entire program here?

Chris




Thanks for the quick response Chris.

I've tried paring back the code to just after the point at which things
went wrong and the issue disappeared. It was near the start of the
program so I left everything before unaltered. I then added back in the
deleted code in chunks, running the code at an elevated z level above
the work. With approx 2000 lines it worked fine. Then with the full
original code for this tool it ran ok beyond the forth profile level
where the problems started. I then reset it back to the original z-level
without the tool and the fault reappeared. However all operations are
well within the physical boundaries and the red box. I then pared the
code right back again to the attached and the fault again arose on the
fourth level (N224). The short code and a screenshot is attached.

I've also posted the code at the end in case attachments are lost.

This apparent Z level sensitivity is interesting. The machine boundaries
are set at (X -0.01, 6.67), (Y -2.73, 0.01), (Z -6.78, 0.01) putting the
home origin in the top left upper corner. The part (G54) is then zeroed
in absolute coord (X2.9361, Y-1.5052, Z-2.1691). All the tool paths
appear well within the boundaries and I can see no logical reason for
this dependency. I've restarted the program a number of times during
these investigations and with the same z zero the errant behaviour is
repeatable.

<>
The preview is correct to the code, but the tool path display matches
what the tool did. i.e. a red plot line was drawn where no white line
exists. (See attached)

<>
The lines containing the G2 code after that point (I ran it for approx
10 more lines) were ignored by the controller. The debug output in the
terminal made no mention of them. The tool motion was consistent with
the machine ignoring the G2 code line and enacting the subsequent G1
line immediately, ploughing straight across the part.
A sample of the debug output is given below:
<<
Issuing EMC_TRAJ_LINEAR_MOVE --  (+220,+116,
+0,1.936829,-2.147814,-5.105566,-0.004303,0.00,0.00,0.00,0.00,0.00, 
+1,0.30,0.30,5.00,+0,)

Motion id 107 took 7.317767 seconds.
Outgoing motion id is 2161.
Issuing EMC_TRAJ_LINEAR_MOVE --  (+220,+116,
+0,1.936829,-2.147814,-5.153715,-0.004303,0.00,0.00,0.00,0.00,0.00, 
+2,0.006562,0.30,5.00,+0,)

Motion id 109 took 17.098524 seconds.
Outgoing motion id is 2162.
Issuing EMC_TRAJ_LINEAR_MOVE --  (+220,+116,
+0,2.003561,-2.263208,-5.153715,-0.004303,0.00,0.00,0.00,0.00,0.00, 
+2,0.049213,0.346553,5.775881,+0,)

Motion id 111 took 2.700402 seconds.
Outgoing motion id is 2163.
Issuing EMC_TRAJ_LINEAR_MOVE --  (+220,+116,
+0,2.59,-2.178917,-5.153715,-0.004303,0.00,0.00,0.00,0.00,0.00, 
+2,0.049213,0.381094,6.351569,+0,)

Motion id 113 took 11.997048 seconds.
Outgoing motion id is 2164.
Issuing EMC_TRAJ_LINEAR_MOVE --  (+220,+116,
+0,2.214191,-2.075885,-5.153715,-0.004303,0.00,0.00,0.00,0.00,0.00, 
+2,0.049213,0.424264,7.071068,+0,)

Motion id 115 took 14.614687 seconds.
Outgoing motion id is 2165.>>

As you can see, motion id 108 (N214), 110 (N218), 112 N222 and 114,
(N226) are skipped.


<>

G43 H2 is set and functioning correctly (Mastertool recorded as tool 1).
The tool table line is:
<<1 1 5.24 0.24 Touch off probe
 2 2 -3.2415 0.250 1/4” endmill in 1/4” endmill holder>>

G40 is active, so no radius compensation should be present. The machine
is set and remains on G64 throughout.
One observation is the active G code display looks wacky. The code
displayed does not match that active. This seems to happen fairly
randomly. When stopped, both G1 and G0 are displayed (see screenshot).
This seems indicative of some sort of bug.

Bit of a tricky one, hey? Any ins