kerf changes side after zero-distance moves

Look at this NC program:

 

G91

G41 H10 (turn on left kerf of 10mm)

G01 X-100 Y300 (kerf on left side of path)

G01 Y0

G01 Y0

G01 Y-100 (kerf changes to right side of path)

G40 (turn off kerf)

 

I wonder how come kerf changes from left to right side of path after 2 zero-distance moves? if I remove the 2 zero-distance moves, kerf is perfect.

I asked yesterday if you had defined a buffer to hold enough moves to get through any moves that are zero-distance in the plane of compensation. The cutter comp (kerf) algorithm must be able to compute the in-plane move after all of these moves before it even starts to execute the in-plane move before these zero-distance moves. Otherwise, it cannot calculate the compensated intersection point properly.

 

Have you used the DEFINE CCBUF command and made sure the buffer structure was saved so it is ready to be used when you need it?

Curt,

 

I use rotary buffer as follows:

 

&1 DEF Rot 2000

 

I didnt use CCBUF. Any clues?

 

Thanks.

 

Luke

Before you run your program, issue a DEFINE CCBUF 8 command. This will permit the buffering of up to 8 moves so a proper intersection can be found even when there are moves in between with no distance in the plane of compensation.

 

Please read the description of the DEFINE CCBUF command in the program command chapter of the Software Reference Manual for more details.

Sorry Curt, I didnt do the test as per your suggestion until today.

 

DEFINE CCBUF 8 issued first

 

Then I run a NC program with M8, motors run away during M8 execution. Here is my M8 sub-program:

N8000

BSTART

M199==1 ;-------Begin--------------

INC

LIN X0Y0 ;these two zero-distance moves used to avoid M8 executed ahead of its previous motion block

LIN X0Y0

ABS

While (M199 = 0)

EndWhile ;-----------End----------

BSTOP

Close

 

If I remove LIN X0Y0, everything is fine. But I have to use them to make sure M8 acts in order. Any solution?

 

Thanks.

I'm having trouble figuring out what this is for.If I understand correctly, the whole point of this subroutine is to set M199 synchronously with the start of execution of the next move in the part program. I get this just by using M199==1. The reason for the "==" is to delay the actual assignment even if the operation had to be calculated ahead of time.

 

I can't create a problem even if I add the two zero-distance moves. What happens if you replace them with DWELL commands?

Curt,

 

tried to attach a cfg file here, too large to work. So I wrote an email to you. plc check ur email for the details of my test.

 

Thanks.

 

Luke

Now that the discussion has been taken offline, when you people resolve this problem, can you post a summary? I think I may have some related strange behavior on one of our machines and am curious about the resolution.