NCCode representation of rotated arc movements.

[GoogleCodeExporter]

I need someone to help me to determine an arc's axis (gp_Ax2 or similar)
given two endpoints and a centre point.  This is easy enough when the axis
is straight up the Z axis but I can't figure it out if the arc is rotated
in either/both the XZ or YZ planes.

What steps will reproduce the problem?
1. Place and select a sketch
2. Create a Contour operation
3. Add a significant (30 degrees) rotation to the XZ axis in a Fixture object
4. Generate GCode

What is the expected output? What do you see instead?
The GCode lines (green) are rotated correctly but the arcs represented in
the NCCode (green) lines are not rotated correctly.

The PathArc::Interpolate() method (within NCCode.cpp) assumes that the 'up'
direction is straight up the Z axis.  The generated GCode and the
nc_read.py routines already allow for a rotated arc object by allowing for
values in the 'I', 'J', and 'K' arguments to the G02 and G03 commands. 
These offsets to the arc's centre are already read into the m_c[0], m_c[1]
and m_c[2] variables respectively.  The problem is that the Interpolate()
method doesn't allow for the 'K' (m_c[2]) value when its determining line
endpoints that represent the arc's path.  I suspect it's a trivial exercise
but I have not been able to produce a general solution for an arc that
moves through two points and has a known centre point.

i.e.
CNCPoint start( prev_po->m_x );
CNCPoint centre( prev_po->m_x[0] + m_c[0], prev_po->m_x[1] + m_c[1],
prev_po->m_x[2] + m_c[2]);
CNCPoint end(m_x);

If anyone can tell me how to determine the axis used by an arc that runs
from 'start' to 'end' and uses 'centre' as a centre location, I would be
very grateful.

Original issue reported on code.google.com by David.Ni...@gmail.com on 5 Apr 2010 at 6:51

Attachments:

• [Rotated Arcs Misaligned.png](https://storage.googleapis.com/google-code-attachments/heekscnc/issue-175/comment-0/Rotated Arcs Misaligned.png)

[GoogleCodeExporter]

The answer is to use the cross product of the vectors from start->centre and
end->centre.  If the start, centre and end are in the same line then there can 
be no
way to determine the arc's axis.  i.e. the arc could be at any angle rotated 
around
this line. In this case we can only assume the arc's axis is aligned with the Z 
axis.

To avoid this, we need to generate arc movements that are less than 180 
degrees. 
Only this way can we obtain the arc's axis based on the three points held in the
GCode.  The GCode guide for EMC2 makes this same suggestion.  i.e. that a 
circle is
broken up into at least 4 smaller arcs. (less than 180 degree movements)

Original comment by David.Ni...@gmail.com on 5 Apr 2010 at 10:54

• Changed state: Done

[GoogleCodeExporter]

David,

I don't agree with these changes.

For my machine ( from the manual ):

"The axis of the circle or helix must be parallel to the X, Y, Z-axis of the 
machine
coordinate system. The axis is selected with G17 ( Z axis ), G18 ( Y axis ) or 
G19 (
X axis )."

It goes on to say, later, that if the Z is different from the starting Z, then 
this
is a helical arc.
I create helical arcs when you have a tag on a profile operation, which is on 
an arc
span.

This was working OK, for G17 ( Z-axis ) arc moves.

Currently, I assume that "up" is the z-axis. We need to change this to be 
affected by
G18 and G19.

Original comment by danhe...@gmail.com on 6 Apr 2010 at 9:11

[GoogleCodeExporter]

Dan,

  you're quite right.  I have reverted the change to NCCode.cpp.  I have also changed
the GCode generation for Contour operations so that, if the XZ or YZ planes have
rotation, the arc segments are stroked into lines so that the rotated arcs can 
be
followed.  If the XZ and YZ planes do not have rotation, a proper arc movement 
is
produced.  I know that the proper arc movements are preferable so that the 
machine's
GCode interpreter can interpolate many more coordinates based on the machine's
resolution.

  My goal was to be able to probe a PCB's tilt and have the generated GCode follow
that tilt accurately.  This is due to the very small depths of cut for 
machining PCBs.

  Ta
  David Nicholls

Original comment by David.Ni...@gmail.com on 6 Apr 2010 at 10:47