Reverse circular motion in 3D

[Colin]

Can anyone please help ?
When milling in XZ or YZ planes in 3D such as profiling with a ball end mill, the G3 and G2 arc comands produce the opposite of each other. ie. the CW G2 comes out as a CCW. This does not happen in the XY plane ! It appears that the CW and CCW comands in CamSoft (for YZ and XZ planes) have been written when viewed from the negative of the axis normal to the plane you are working in instead of the positive (as per the G code standard). Has anyone else come across this ? It has already scrapped one job ! Is there a CamSoft fix or is there special code that can be inserted into the G2 and G3 comands to correct this ? And before anyone asks, yes, I have checked that my post-processor running under MasterCam produces the correct code - when viewed from the positive of the axis normal to the plane. Also, my G18 and G19 are correct for the plane I am working in. I have narrowed the problem down by making very simple short programs, trying both less than and greater than 90 deg arcs and also by using IJK instead or R type arcs and in all cases G3 and G2 are reversed. - Help -

Colin

[Karl_T]

The beaty of Camsofty is you can make it do what you want.

First you need a varaible to indicate which plane you are working in, say \990. Put a
\990=1 in your startup.fil to indicate default plane of XY. For your Gcodes that change planes (G17 G18 G19) change the value of \990 to 1 for XY, 2 for XZ, and 3 for YZ. Now you have a variable that always knows what plane you are operating in.

next change your G02 and G03 to do what you want. This is only the idea, I'm not sure exactly what your'e wanting and your G02 may be different:

DISPLAY4 {f*(\73/100)}
DISPLAY5 {s*(\74/100)}
TIME CYCLE;\4
DISPLAY7 \4
RUNTIME \4
DISPLAY8 \4

IF\990=1 THEN CW x;y;z;i;j;k: EXIT
IF\990=2 THEN CCW x;y;z;i;j;k: EXIT
IF\990=3 THEN CCW x;y;z;i;j;k: EXIT
MESSAGE Error var990 undefined
-----G2

Now, do same idea on G03

[Colin]

Thanks for that Karl,
Actually I had figured out a similar fix and am about to implement it. What really annoys me is that CamSoft have not set their defaults correctly and written bad software and this has cost me money and possibly a lost customer.

Because of the handed ambiguity in defining a set of 3 orthogonal axes most people in this industry use the standard "right hand" set of axes and a consistent set of rules for G2 and G3. The fact that Camsoft mixes the right hand and left hand definitions is not explained in their manual and appears to be left up to every person who buys the software to find out for themselves.

I can do the fix but what happens when I discover in the future that this leads to other unforseen consequences. Do I have to laboriously have to check the software's operation on every type of curve it can possibly do ? Also, does this change affect helical movement ?

Colin

[Karl_T]

Originally Posted by Colin Do I have to laboriously have to check the software's operation on every type of curve it can possibly do ? Also, does this change affect helical movement ? Colin

I think the short answer is yes check it out. how many G and M codes do you use? In my case its a short list.


In my experience, from all of the default .CBKs; one will provide a good starting point for your machine. You won't find a 100% ready to run, your choice of CAM software compatible, .CBK file.

Thanks for the heads up on Plane selection and arcs. I'll watch for that one.

Karl

[Colin]

Many thanks Karl for your reply,

I have implemented changes similar to what you have suggested and checked that the machine does arcs correctly in both XZ and YZ planes. It now does.

Unfortunately as we are a jobbing shop we get called upon to do many different jobs drawn in many different packages. Sometimes a customer will supply the raw G code. I often have no idea what the G code contains and as readers will appreciate the files can be very long and contain changes in planes and different types of arcs. There is no small set of G codes that I use often. To be confident I will have to test to full specification all possibilities - a big job indeed. To give an example, what is the max and min radii allowed in G2 and G3 ?. The CamSoft manual is no help here !

In answer to your comment, Karl, that no one CBK file will be 100% correct, this is a case where none of the CBK file are correct because CW sometimes means CCW !!

I was hoping for a reply from CamSoft as this is a major issue to me (a scrapped job and lost customer !) and I wonder how many other users out there want clarification. Come on CamSoft - do you know about this problem ? And what do you intend to do about it ?

Colin

[Karl_T]

Here is the answer on min/max circle radius. I see it depends on your quadrature counts per inch. This is from the galil command reference


FUNCTION: Circle
DESCRIPTION:
The CR command specifies a 2-dimensional arc segment of radius, r, starting at angle, θ, and
traversing over angle Δθ. A positive Δθ denotes counterclockwise traverse, negative Δθ
denotes clockwise. The VE command must be used to denote the end of the motion sequence
after all CR and VP segments are specified. The BG (Begin Sequence) command is used to
start the motion sequence. All parameters, r, θ, Δθ, must be specified. Radius units are in
quadrature counts. θ and Δθ have units of degrees. The parameter n is optional and
describes the vector speed that is attached to the motion segment.
ARGUMENTS: CR r,θ,Δθ < n > o where
r is an unsigned real number in the range 10 to 6000000 decimal (radius)
θ a signed number in the range 0 to +/-32000 decimal (starting angle in degrees)
Δθ is a signed real number in the range 0.0001 to +/-32000 decimal (angle in degrees)
n specifies a vector speed to be taken into effect at the execution of the vector segment. n is an
unsigned even integer between 0 and 12,000,000 for servo motor operation and between 0 and
3,000,000 for stepper motors.
o specifies a vector speed to be achieved at the end of the vector segment. o is an unsigned even

[camsoft]

Karl,

There is more vital information regarding the CR command.

CamSoft isn't using the native Galil CR circle command, so there are none of these limits.

Systems that do pass Galil commands will find that arcs won't have control over roundness, surface smoothness, direction, can't do arc's in tilted plains and if there are different encoder counts for the XY , XZ or YZ axes the arc will be egg shaped

Using the Galil commands also affects the ability to maintain a constant feedrate velocity around the arc when encoder ratio vary.

The Galil documentation you posted showing unsigned real number usage limitation for accuracy under .0001 plus radius size limitation under 10 counts does not apply to CamSoft.

However, the suggestion you posted using the CW and CCW commands get around all of the above mentioned limitations.


Tech Support
CamSoft Corp.
support@camsoftcorp.com
PH 951-674-8100
Fax 951-674-3110
www.cnccontrols.com